Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFP: WebMIDI #58

Open
qdot opened this issue Feb 27, 2018 · 132 comments

Comments

@qdot
Copy link

commented Feb 27, 2018

Request for Mozilla Position on an Emerging Web Specification

Other information

WebMIDI has been in development in Firefox since 2015. The DOM API (https://bugzilla.mozilla.org/show_bug.cgi?id=1201590) recently landed, but is pref'd off on all branches, runs only in tests, and was mostly landed to curb bit-rot. Platform implementation bugs exist at:

The major blocker right now is security issues related to device firmware hijacking. There's a public google doc available listing issues and ideas for mitigation at

https://docs.google.com/document/d/1SjYRmNvQKxOPHufWbx6n0NOeTKKd_O1WIiTBZAjVj5E/edit#heading=h.lavkfo6fb57g

@martinthomson

This comment has been minimized.

Copy link
Member

commented Feb 27, 2018

Thanks for the extra context, that made reviewing this easy.

The big concern here is SysEx messages. Those have the same concerns as WebUSB. From the text in the specification, these appear to grant unrestricted access to the device. Simply asking for permission isn't a good answer to this class of problem: we can't expect someone to understand the full implications of this if the potential extent of capabilities they are extending to the origin includes rewriting firmware.

The mitigations doc says:

No firmware overwrite reports related to the Chrome implementation of WebMIDI have been mentioned in public so far.

That's not relevant. The same applies to the language assessing likelihood or difficulty of attack. What is relevant is that the possibility exists. And that includes rewriting the MIDI device to be a (remote controlled) keyboard, which has implications for not just browser security, but system security.

It would be irresponsible of us to ship this without addressing this concern. As I see it, the safe options are: disable SysEx, whitelist devices for SysEx, and don't ship. I don't see a huge amount of harm in shipping without SysEx or with a whitelist.

I'll let others speak to the benefits of the API. I don't do MIDI or know anyone who does, so don't have any investment.

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

commented Feb 28, 2018

I'm also not a MIDI person, so don't really know the implications of not including SysEx. The doc says the consequences are "severe" with respect to limiting functionality.

@qdot, should we ask some MIDI folks for opinions (e.g., Chris Wilson)?

I'll let others speak to the benefits of the API. I don't do MIDI or know anyone who does, so don't have any investment.

5 years ago, I spent a lot of time helping with editing, implementing a polyfill, and testing this specification. I've personally seen some pretty amazing things done with it at conferences and events I've attended: like, whole parties DJ'ed realtime using the API, and really impressive controller software written specifically for the API.

While I was looking into Web MIDI, I also investigated the iOS MIDI ecosystem... it's pretty vibrant (see example native apps). I mention iOS here because I believe we have an opportunity to tap into that community through the Web.

From the perspective that this allows the creation of really amazing musical experiences (and it makes the web a creative outlet for talented musicians) - I'd strongly support shipping this API. It would make a lot of people happy - and make more events pretty awesome 🎹💃🕺.

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

commented Feb 28, 2018

Loop Drop was the software I saw being used by @mmckegg at an event. Matt is a good person to talk to from a developer perspective, as he probably knows Web MIDI as well as anyone.

@stpeter

This comment has been minimized.

Copy link

commented Feb 28, 2018

I agree with @marcoscaceres on the possibilities here. I'm pretty sure @obensource & friends have used the Web MIDI API in the https://github.com/websound project - I'll check with Ben for details.

@stpeter

This comment has been minimized.

Copy link

commented Feb 28, 2018

@qdot With respect to whitelisting, is this something that we could co-own with Google or crowdsource with the MIDI community (including device vendors)?

@mmckegg

This comment has been minimized.

Copy link

commented Feb 28, 2018

Thanks for letting me know about this issue @marcoscaceres.

Some random thoughts about SysEx and Web Audio off the top of my head:

I think that (security issues aside), rewriting the firmware of a midi device is probably one of the coolest potential use cases for Web MIDI. Also a lot of devices use sysex to backup and restore presets (yet another potentially great web midi use case).

Besides system level stuff, SysEx can be vital for certain midi controllers to access advanced functionality. I use it personally in Loop Drop with the Launchpad MK2 for setting the colors of the RGB lights. Another case is for updating the LCD screen on the Ableton Push (original).

I'm not sure how standard this is, but I have noticed that it is quite common for devices to only accept firmware updates when they are booted in a special mode. Most likely exactly to avoid the case where some random software pushes malicious firmware updates to a device. Unfortunately this is not the case with all midi controllers.

So I think in combination with a security prompt "Would you like to allow full access to this midi device (SysEx)", this should be good enough. Maybe a warning in the message that this might allow the web page to update the firmware of the connected device?


We need to find a way to support sysex safely in Web Midi, otherwise we'll be missing out on a tonne of possibilities.

Still, I'd much prefer Web Midi API without SysEx than no Web Midi API at all!

@qdot

This comment has been minimized.

Copy link
Author

commented Feb 28, 2018

@marcoscaceres I've already pinged Chris Wilson, Paul Adenot, and a couple of vendors who've implemented applications using WebMIDI that are currently running on Chrome. I hope that we'll hear from them over the next few days.

@stpeter Possibly! I'll let Chris Wilson speak to that, though I may try to loop in other Chrome engineers working on WebMIDI also.

@qdot

This comment has been minimized.

Copy link
Author

commented Feb 28, 2018

@mmckegg In that gdocs file in the top comment, I listed firmware reflash instructions from a few devices from different manufacturers. From the instructions, it looks like some require user gesture to reflash, while others it appears can be reflashed by just having them connected. It's that second set that are the worrisome ones, unfortunately.

I should say that these firmware attack issues really only apply to USB MIDI devices too. If a device uses actual 5-pin MIDI, that'll be going through an adapter that most likely cannot be reflashed, so the potential there is less security and more annoyance.

@mmckegg

This comment has been minimized.

Copy link

commented Feb 28, 2018

Ah, thanks @qdot. That document is a good analysis!

The only addition I have would be to the Blacklist approach. Rather than blacklisting SysEx entirely on an device, could blacklist certain SysEx prefixes.

For example, the Launchpad MK2 is one of the devices that can be updated without being put into a special mode. Instead this mode is achieved by sending a particular sysex message (F0h 00h 20h 29h 00h 71h 00h 69h F7h). See Launchpad MK2 Programmers Reference Guide under "Other SysEx Messages" (page 16).

If the SysEx message itself was blacklisted for that device, there would no longer be a risk of the firmware being updated, and we can still have access to updating the LED colors, and scrolling text etc.

@dvhdr

This comment has been minimized.

Copy link

commented Feb 28, 2018

Thanks @qdot & co for the hard work and commentary! I just wanted to raise that sysex firmware upgrades are the reason we built our Components app. It's the single most important use case for our customers - getting new content onto their hardware with a minimum of fuss. Yes, this means firmware upgrades without gestural input, as @mmckegg describes above.

In fact, writing new third-party firmware to our devices is something we encourage (e.g. with open firmware development tools like https://github.com/dvhdr/launchpad-pro).

I'm no security expert and don't wish to downplay the concerns raised. I'd happily support any initiative that gets sysex-capable WebMIDI out into the wider world, even if that does compromise the user experience. But please - it's got to have sysex!

@ekr

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2018

A few notes:
It's useful to have people explain why they want this, but ultimately our obligation is to the security of our users, so no matter how useful it is, if we can't make it secure we can't do it.

"So I think in combination with a security prompt "Would you like to allow full access to this midi device (SysEx)", this should be good enough. Maybe a warning in the message that this might allow the web page to update the firmware of the connected device?"

The problem here is that it's not obvious to users that this allows the site to quite likely take control of the user's computer.

The initial framing of this was: how do we avoid this mechanism being used for firmware updates, but if that's actually a feature you are trying to enable, I don't see how to make it safe.

@qdot

This comment has been minimized.

Copy link
Author

commented Feb 28, 2018

There's still different levels of security inside of firmware updates too. For instance, are we /just/ worried about USB descriptor rewrite, which is what's required for the HID attack referenced? If so, there's nothing saying firmware rewrite would always enable that. Firmware is sometimes but not always responsible for USB descriptor handling.

If manufacturers are specifically open to third party firmware, it doesn't seem like the not-security-but-annoying issue of bricking is a thing we can reasonably worry about stopping. We'd have to expect the manufacturer to put in a way to always boot to bootloader, and to make sure the bootloader can't be overwritten by USB.

Not sure if this level of nuance matters in the argument or not, though, since we're mostly trying to cover unwanted firmware reflashes period.

@adamroach

This comment has been minimized.

Copy link
Collaborator

commented Feb 28, 2018

@ekr --

The initial framing of this was: how do we avoid this mechanism being used for firmware updates, but if that's actually a feature you are trying to enable, I don't see how to make it safe.

I think I'm reading that as "how do we avoid this mechanism being used for unwanted firmware updates?" For those devices that require the user to physically manipulate the device to initiate such an update, this seems to provide the right level of agency (unless I've overlooked something important). So whitelisting SysEx those devices that are known to have such a property would seem to get us to "safe," right?

@ekr

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2018

@adamroach: again, I think the user has a lot of trouble meaningfully consenting to a firmware update, so "unwanted" seems difficult.

@martinthomson

This comment has been minimized.

Copy link
Member

commented Feb 28, 2018

Is there any reason why SysEx access needs to be raw? Is it possible to identify common functions that are enabled by SysEx and build APIs specific to those functions?

My intuition is that the breadth of applications are large and the use of SysEx is sufficiently non-uniform as to make this untenable.

Thus, I might conclude that whitelisting would need to be contingent on some guarantee that either the device can't do bad things. Bad things definitely includes firmware updates, unless we have other guarantees that (for instance) this extends to a guarantee that a firmware update can't cause a device to change type or enable other new bad functions. That's a hard guarantee to extract, and a lot of effort to police effectively. I'm fairly sure that we don't want to be in that position.

@toyoshim

This comment has been minimized.

Copy link

commented Mar 1, 2018

Hi, I'm working on Chrome Web MIDI implementation. I'm happy to discuss better permission handling to improve Web MIDI security.

So, here are our mitigation approaches we already do for Web MIDI:

  • Permission is allowed only for secure origins such as https
  • Feature Policy - Powerful features including Web MIDI are disabled by default in cross-origin iframes, and the top frame needs to allow it explicitly.
  • Kill switch - Have a server-managed emergency switch to kill the feature against zero-days

All three approaches are also used for other newly added device APIs that have similar concerns.

For common discussion around device APIs' security, Web USB implements a device chooser prompt that is believed to be better than usual permission prompts. It's considerable to introduce a similar approach to Web MIDI.

Some more information about SysEx that may be an answer for the question by @martinthomson .
SysEx is a mechanism to define vendor specific commands. That's the reason why we need to allow raw SysEx message passing rather than providing abstracted API set.

Major use case of SysEx is to edit sound parameters on synthesizers. Sound librarian or editing applications need it. Since such application can be developed by third-party, whitelisting does not work. Such third-party often develop an editor for retro synthesizers because original native application does not run on recent versions of Windows/Mac, or just such old devices do not have good applications.

Firmware update is another major usage, and first parties really want this in Web MIDI. If SysEx is only for firmware update, whitelisting would work well.
Since updating process heavily depends on device specific command and sequence, it will be hard to find a way to update the firmware, and need per-device investigation and need to develop per-device modified firmware. So attacking MIDI devices over SysEx firmware update is very expensive.

Unfortunately, just playing back Standard MIDI File (aka, .mid files) needs SysEx because it's very often used in most data to modify sound colors.

@martinthomson

This comment has been minimized.

Copy link
Member

commented Mar 1, 2018

Thanks for the extra info @toyoshim. I'm hearing that MIDI without SysEx is virtually useless and MIDI with SysEx is a security nightmare.

Are there a common set of SysEx commands that would allow us to enable common use cases without exposing us to the possibility of things we don't want like firmware updates? For instance, if modifying sound colors is something that is common across multiple devices with the same commands, could we provide access to those commands only? Or is that too constraining? Or do certain commands have different interpretations when sent to different devices?

Is it possible to develop whitelists for completely safe devices and for other devices whitelists of safe commands? That's a pretty big exercise, but it might be the only way that this could be shipped safely.

I don't consider the measures that Chrome have deployed to be adequate against this level of threat. Obviously this is where Firefox and Chrome differ. Firefox doesn't ship WebUSB either, for almost precisely the same reasons.

@dvhdr

This comment has been minimized.

Copy link

commented Mar 1, 2018

Sysex messages are supposed to work by having a manufacturer-specific header (Novation's is 0x00 0x20 0x29). Most vendors stick to this, but it's not enforced in any technical way. I expect some smaller vendors don't, as you need to pay the MIDI Manufacturers Association to register the ID.

So you could whitelist by MMA registered vendors, and then as @mmckegg suggested, blacklist the small number of messages that can flip a device into bootloader mode without user input. I'd be surprised if there's more than a handful of devices that do this - ours do.

You'd always have the possibility of tricking a user into doing a firmware update - but that possibility exists with raw *.syx files too. An attacker could disguise malicious firmware as feature update, and trick users into installing it using software they already have. But if you're going to do that, you may as well just trick them into downloading an executable.

@canuckistani

This comment has been minimized.

Copy link

commented Mar 1, 2018

A couple of thoughts:

It's totally fine to ship initially without sysex. Sysex is something most consumer use cases do not need, eg you can still send note, sync and control data without sysex. I would be fine eliminating sysex from the MVP.

sysex is most commonly used for updating firmware of user data on midi devices and as was hinted at in other parts of this thread this functionality is very device-dependent. The most common workflow is something like:

  1. physically engage sysex receive mode on the midi hardware usually by hitting actual buttons.

You need physical access to the device, and midi hardware varies hugely in terms of how this actually works. Also, while it may be true that I personally have a midi device or two connected to my system at all times, most people do. The potential attack surface is small and diverse.

  1. send sysex via a midi connection to the device from some sort of software that supports sending midi data, in our case a web browser.

I think to initiate sending sysex from the web to hardware a permission prompt might be reasonable. If the user is in this mode, they are typically already doing a bunch of manual steps on the hardware as well as in the midi app to make this happen, and extra click isn't the end of the world.

@73rhodes

This comment has been minimized.

Copy link

commented Mar 1, 2018

SysEx is really useful in a lot of scenarios like triggering patch changes during live performances. It would be a shame to disable it and I think it it should be the responsibility of the device to take measures against things like unilateral firmware modification. I seem to recall my keyboards requiring confirmation for things like things that overwrite memory. This situation exists with any native midi sequencer already.

@ekr

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2018

While I think that SysEx is the main area of threat, I don't want to lose the fact that anything is a threat here. It seems pretty clear that these devices were generally not intended to operate in an environment where the computer they are connected to them is controlled by the attacker. That means that there are quite likely defects in the processing of the non-SysEx messages that could lead to vulnerabilities and RCE, at which point we have the same problems.

@stpeter

This comment has been minimized.

Copy link

commented Mar 1, 2018

MIDI (standardized in 1983) assumes trusted communication among physically connected devices. Grafting that trust model onto the Web seems challenging...

@qdot

This comment has been minimized.

Copy link
Author

commented Mar 2, 2018

@ekr If we're at the point of arguing that any MIDI hardware period is vulnerable, what does that mean for our ship/don't ship criteria for this? I'm not quite sure how I'm supposed to work with that.

If we're looking at it that way, GPUs were/are vulnerable too, we've seen sandbox escapes with them, yet WebGL shipped and continues to ship, and we sometimes blacklist drivers there as needed as part of that mitigation. The attack surface there is huge in terms of the user base, since video cards are kind of a requirement for computing. How is that different than what's being proposed here, between whitelisting/blacklisting/etc?

I realize no one can expect full security guarantees, nor can we just hand out access everywhere and trust the world, but I'm personally not feeling like we're moving toward any middle ground in this thread so far. I'd like to poke this in that direction more, or else understand what might be missing.

@qdot

This comment has been minimized.

Copy link
Author

commented Mar 2, 2018

Also, in general for this thread, I'd say that I see WebMIDI as sort of a small litmus test for hardware API integration in Firefox in general. MIDI is a smaller use-case compared to things like Bluetooth and Sensors (WebUSB is still so new and contentious that I don't really want to bring it in to consideration quite yet for sake of not derailing completely), and those are also APIs that I'd like to maybe see happen at some point, so I'm hoping to take some points and lessons from this discussion to apply to those, if/when they come along.

@ekr

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2018

@qdot: I don't think that moving to a middle ground is necessarily a virtue here. The question is whether we think that this feature can be safely shipped to our users, and either it can or it can't, but it's not like if it's half-safe then it's OK to ship.

WRT to the general security of MIDI hardware, my experience with embedded software is that it tends to be especially bad about defending against this class of attack, so absent either some research that suggests its generally safe or some representation from the manufacturers that it is, then it really needs to be presumed to be unsafe. Are the manufacturers willing to make that representation? I don't get the impression that they are.

Now, maybe on balance that's a risk we're willing to take, but my point above is that we need to be taking that risk into account, not just assuming that !SysEx == safe.

@cwilso

This comment has been minimized.

Copy link

commented Mar 2, 2018

@ekr

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2018

Second, I think the concern over the scope of potential damage via sysex is a bit out of kilter, and the user opt-in and secure origin not being considered as any protection at all. Trust is important; but just as you need to gain the user's trust for permission to access the camera, I don't see this as much different.

I think it's pretty clear from upthread why it's different: the threat here is compromise of the device leading to compromise of the user's computer. Not only does no such threat exist from access to the camera (though of course USB access to the camera would present such a threat), but the user is easily able to apprehend the threat from the camera, whereas this threat is almost entirely unobvious (and in fact the discovery of the threat in other settings such as VMs lead to several academic papers). It's worth noting that we delayed releasing screen sharing for a very long time for a threat that was a lot less severe but similarly unobvious (as compared to the camera).

I don't think a secure origin is relevant here. It's trivial for an attacker to get a certificate.

we've been shipping sysex - requiring a permission prompt and secure origin - for a couple of years now without any concerns raised.

Hmm... I'm not sure what you mean by "without any concerns being raised". I'm pretty sure I expressed these concerns to several people at Chrome. I know I did for WebUSB and WebBT.

@ekr

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2018

While we're on the topic of WebUSB, https://www.wired.com/story/chrome-yubikey-phishing-webusb/

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

commented Mar 2, 2018

Hmm... I'm not sure what you mean by "without any concerns being raised". I'm pretty sure I expressed these concerns to several people at Chrome. I know I did for WebUSB and WebBT.

I'm going to guess @cwilso means "no reports of compromised devices or sites maliciously taking advantage of SysEx" (yet!). But that only holds until there is one such attack (and the severity of such an attack), which, if history is anything to go by, we can be fairly certain will happen.

Reading over the arguments, it seems like MIDI devices are different from USB devices, in that there is a at least some expectation from MIDI device owners that their devices will be "patched" and/or have their firmware rewritten.

Would that be a fair assessment? And would a sufficiently informative/scary permission prompt, like "You do understand that by enabling SysEx your MIDI device could be destroyed by this website? You really want to do this??!" be sufficient?

In a sense... it's similar to allowing users to proceed on sites with invalid SSL certs, where we put up a bunch of roadblocks and try to get them back to safety... but if they really want to go there, they can.

@adamroach

This comment has been minimized.

Copy link
Collaborator

commented Mar 2, 2018

Would that be a fair assessment? And would a sufficiently informative/scary permission prompt, like "You do understand that by enabling SysEx your MIDI device could be destroyed by this website? You really want to do this??!" be sufficient?

If I read the preceding comments correctly about the capabilities of SysEx, it's more like "this website could reprogram your MIDI device to act like a keyboard, and then use keyboard commands to do literally anything it wants to your machine, including uploading sensitive information -- such as your passwords, tax returns, or basically anything else of value on your machine -- to a hostile remote server."

That's a lot for a dialog box, and it really only captures one dimension of the possible harm.

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

commented Feb 7, 2019

And to be clear, per https://www.w3.org/2018/Process-20180201/#recs-and-notes WebMidi is currently at step 2 of a process where step 5 would be "a standard".

@hires

This comment has been minimized.

Copy link

commented Feb 7, 2019

Okay, thanks for the clarification on Mozilla's position and the explanation of how the standard process works. At least we won't be hoping anymore. :)

One final question... would it be possible to make a simple extension to add WebMidi? I know there is the Jazz Soft solution but it requires installing the Extension plus two other plugins which seems a bit cumbersome.

Would it be possible to implement this in a single Extension add-on?

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

commented Feb 7, 2019

Ignoring for the moment whether that's technically possible, please note https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/AMO/Policy/Reviews#Security_Vulnerabilities and https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/AMO/Policy/Reviews#No_Surprises

That is, such an addon would have to at minimum clearly explain the risks involved to users, though even that may not be sufficient. At least if the addon is to be allowed on addons.mozilla.org.

All of which comes back to the question this thread is supposed to be about: do we feel that the security issues are sufficiently mitigated in the spec that we think it's OK?

@J0nKn1ght

This comment has been minimized.

Copy link

commented Feb 7, 2019

Seeing the flurry of comments today, I'd just like to add that I support @cpenny42's position - currently our only use of WebMIDI is for firmware updates and sending patch data, so SysEx is essential.

The MIDI 2.0 spec is still only in the prototype stage, and it's taken 36 years to get there, so I don't think waiting for MIDI v3.0 is an option. This isn't a criticism of MMA, by the way - I think that it is a testament to the MIDI 1.0 spec that it was engineered in such a way that it has stayed relevant for this long.

Finally, I concur with @hires, that it seems like the only option for the foreseeable future is to continue to tell our customers that they should use Chrome if they want to be able to use MIDI features through the browser. I was hoping that that we could have a bit of competition in the browser sphere, but as this thread has made no progress in almost a year (and there seems to be some reticence to push it forward), it seems that we will have to wait a considerable time before anything of substance happens.

@bome

This comment has been minimized.

Copy link

commented Feb 7, 2019

@marcoscaceres thanks for the constructive ideas.
MIDI 2.0 has more type safety for sending firmware data, but it still has MIDI 1.0 style Sys Ex.
I will bring up your idea of a "safe" MIDI 2.0 or 3.0 in the MMA.
Meanwhile, as said, we don't see a security concern for implementing Web MIDI with support for message types 1) to 4) as outlined here. Especially in combination with a user confirmation for allowing MIDI support in the web page.
If there is anything else the MMA can do to advance progress in Firefox, please let us know.

@Pomax Pomax referenced this issue Feb 7, 2019
@cpenny42

This comment has been minimized.

Copy link

commented Feb 7, 2019

It is such a shame because the lack of a standard MIDI implementation across browsers is actually holding an entire industry back. And let us be clear, the only reason there seems to be apprehension to implementing this is because some MIDI devices allow firmware updates via SysEx, and that opens up the possibility of that MIDI device being compromised.

I absolutely understand the security risks involved, but I don't think the Mozilla team understands the opportunity cost of dragging their feet on this. I would argue the cost of not having cross-browser MIDI implementations greatly outweighs the very small potential attack vector over MIDI via sysex.

Perhaps we could have an MIDI implementation for everything except sysex, and then later maintain a whitelist of devices & manufacturers who demonstrate their device does not have these attack vectors. It is not difficult to make a MIDI device that can safely use Sysex (or MIDI 2.0+) that does not have the security risks in question here.

@bome Perhaps the MMA could issue some guidelines for safely using SysEx in a way that would satisfy Mozilla? The MIDI Association already maintain a list of SysEx Manufacturer IDs, I imagine there could be some compliance process to whitelist certain IDs for web use.

I don't think the folks at Mozilla realize how important this actually is to those of us in the digital music world. We could be building some amazing apps, but we're stuck here for years waiting on people who don't seem to have any desire to move the ball forward. Telling users to use Chrome just isn't good enough! We are all happy to contribute in any way we can to achieve our goal of making music in the browser! Please let us just start the process.

@stripcycle

This comment has been minimized.

Copy link

commented Feb 7, 2019

It is such a shame because the lack of a standard MIDI implementation across browsers is actually holding an entire industry back. And let us be clear, the only reason there seems to be apprehension to implementing this is because some MIDI devices allow firmware updates via SysEx, and that opens up the possibility of that MIDI device being compromised.

This is only a lack in principle - Firefox's market share compared to other desktop browsers is small enough that it doesn't really matter, especially given Microsoft's move to chromium in the next year or so. The reality is that most desktop users have WebMIDI available to them via Opera and Chrome. If you're using Firefox and really want WebMIDI without having to stoop so low as launching chrome, you can install the Jazz Soft plugins and get what you want done.

I absolutely understand the security risks involved, but I don't think the Mozilla team understands the opportunity cost of dragging their feet on this. I would argue the cost of not having cross-browser MIDI implementations greatly outweighs the very small potential attack vector over MIDI via sysex.

I agree, their position seems to be entrenched in security theater - if they just followed the web permissions approach chrome has they might have landed something by now. Meanwhile, @qdot has patches that have bitrotted. If dangerous sysex needs to be approved by user interaction every time, the potential for monetizing the threat model goes away. Mozilla instead wants the spec to be "perfect" before any work is committed.

Perhaps we could have an MIDI implementation for everything except sysex, and then later maintain a whitelist of devices & manufacturers who demonstrate their device does not have these attack vectors. It is not difficult to make a MIDI device that can safely use Sysex (or MIDI 2.0+) that does not have the security risks in question here.
...
I don't think the folks at Mozilla realize how important this actually is to those of us in the digital music world. We could be building some amazing apps, but we're stuck here for years waiting on people who don't seem to have any desire to move the ball forward. Telling users to use Chrome just isn't good enough! We are all happy to contribute in any way we can to achieve our goal of making music in the browser! Please let us just start the process.

I don't think it matters much what Mozilla's opinion is here - manufacturers should just focus on influencing the chrome / chromium team's implementation and supporting MIDI 2.0 in Chrome and Opera and ( if you have customer requests for this ) testing with or even supporting development of Jazz-soft's Firefox extension and helper, or something similar. To the rest of the industry I'd say, don't wait for Mozilla, they aren't really holding you back, just themselves. Mozilla's views on this spec would be much more important if they had more market share but they don't. You should be lobbying Apple ( for iOS ) and Microsoft ( for future chromium-based versions of Edge ) instead.

@73rhodes

This comment has been minimized.

Copy link

commented Feb 7, 2019

I've been following this matter for several years as a long-time MIDI user and former security researcher with malware presented at Blackhat, etc. At the risk of stating the obvious, Mozilla choosing not to implement WebMIDI due to supposed security concerns, does nothing to mitigate any such security risk. Users will simply use Chrome, a plugin, or DAW based MIDI sequencer to play back web-sourced MIDI files to their connected devices. Nobody is expecting Firefox to be an antivirus scanner for MIDI files, or go above and beyond what any other MIDI implementation has done in terms of handling SysEx. With all due respect, the SysEx concerns are a simple case of FUD, in my opinion. In the nearly 40-year history of MIDI, SysEx has existed and been supported by an untold number of devices and programs, including at one time, Netscape Navigator. I've never once heard of SysEx being used as an attack vector. Do we even know of any device that blindly accepts firmware updates via SysEx? Even if we could identify some, the attack surface is so small it's really only interesting academically.

I've got nothing but respect for the Mozilla developers, especially Kyle M. who put a lot of work into implementing this already. But it seems wrong to say the reason there's been little progress is due to some unsolved security risk. Developers know all about trotting out the old chestnut of "security" when pushed for a feature. It's fine to admit that Mozilla doesn't have the same resources as Google, and has had other higher priorities. But dealing with unilateral SysEx firmware updates seems like a very solvable problem using any one of the many suggestions offered here or in Bugzilla where the discussion started. I'm glad to see the discussion and enthusiasm, and hope some of the offers to collaborate will be acted on.

@cwilso

This comment has been minimized.

Copy link

commented Feb 11, 2019

Hi there. I'm the Web MIDI spec author. Longtime champion of MIDI on the web. I work for Google; I'm not a Mozillan. Let me take a stab at explaining Mozilla's position, and maybe a couple of ways out of this conundrum.

I've repeatedly found across the web platform that many people DON'T understand how important MIDI is, and will continue to be for the foreseeable future in music production; so please, don't paint Mozilla as unique, or Mozillans as particularly obstructive. There were a few of us at Google that pushed really hard at the right time and got lucky. As an overall segment of the web market, MIDI usage is still really low.

Mozilla tends to be more conservative about adding new surface area to the Web platform. Exposing MIDI devices to the Web is definitely new surface area, so let me take a stab at explaining the concern they have.

The problem is not that the MMA needs to issue guidelines, or that MIDI manufacturers need to just protect new devices. The concern is that if you have an OLD MIDI device connected, particularly an old USB-MIDI device connected, that supports firmware updating via sysex, it might enable a malicious firmware update to reprogram the device entirely to attack the hardware locally - e.g., by supporting USB-HID class and emulating a keyboard, letting the hardware device try to guess passwords or the like. The attack may seem far-fetched, but the concern is a valid one, and the problem is that it concerns old devices not new ones. Unless there was a validation policy on USB-MIDI devices of a future version that ensured they cannot be reprogrammed in this way, no unknown MIDI device could be used. (Note that some devices allow firmware updates, but the firmware updates can't reprogram the USB interface on the device, preventing this attack vector. I suspect most modern devices are like this.)

I expect the only way Mozilla is going to be convinced to support WebMIDI (and please keep in mind, I DO NOT speak for them) is:

  1. Secure-context only, permission-prompted non-sysex MIDI, and
  2. As above + whitelisted-devices-only for sysex. To get on the whitelist, device manufacturers would have to provide assurance the device does not enable reprogramming of the USB interface on the device.

Even that is going to require some strong evidence of demand, I suspect.

@Pomax

This comment has been minimized.

Copy link

commented Feb 12, 2019

There's no reason for manufacturers to spend cycles on getting their devices whitelisted if at worst their products can't get used with a browser, which is already the case. If they do nothing, nothing changes. If they do spend money and employee hours to get their product whitelisted, there's only downsides as far as I can see from a business perspective: they have to opt into suddenly become responsible for people's devices, needing to do add a security review pass to their product design, manufacturing, and QA phases to see whether everything clears webmidi spec safety guidelines, plus they'd be taking on the legal responsibility around security claims: by claiming their device is secure enough to whitelist, someone getting their device hacked means the manufacturer may suddenly be culpable. I'm not a lawyer, but that sounds like a reason to stay far away from the webmidi spec if I were a manufacturer, instead of embracing it.

Instead, this still feels like a situation where the user should be in control: per-profile browser device whitelists, with the user in full control, and no devices whitelisted by default at all. When a new device is seen, the user should get asked whether they want to whitelist that device, with non-sys-ex and safe sys-ex (realtime clock, etc) being allowed through the standard UI, but the potentially dangerous sys-ex channels only clearable through the webmidi settings that would be part of the browser's option menu system. That would be the place where users can curate that list and indicate whether and to what degree to whitelist their devices.

And then in order to put the user in control, permissions should be grantable on multiple timescales when prompted during normal browser use: either per activity call, for the duration of a session, or permanently.

E.g.

A new MIDI device has been found. Whitelist for use by the browser?

                     (allow) (allow once) (deny) open midi settings

And

A script on the page wants to change an internal setting on midi device "...".
instruction: ...../....:...

                                (allow) (allow once) (deny) open midi settings

etc.

The security concerns are absolutely real, but it feels like we should be able to trust MIDI device owners to make the right decision, as long as we as browser makers can provide them with the information necessary to make an informed decision.

(Which includes saying what their actions do, of course. If "allow" turns on almost every midi operation except for half of the sys-ex, codes, then the user should be told that up front, or after clicking "allow")

@canuckistani

This comment has been minimized.

Copy link

commented Feb 12, 2019

...

Instead, this still feels like a situation where the user should be in control: per-profile browser device whitelists, with the user in full control, and no devices whitelisted by default at all. When a new device is seen, the user should get asked whether they want to whitelist that device, with non-sys-ex and safe sys-ex (realtime clock, etc) being allowed through the standard UI, but the potentially dangerous sys-ex channels only clearable through the webmidi settings that would be part of the browser's option menu system. That would be the place where users can curate that list and indicate whether and to what degree to whitelist their devices.

And then in order to put the user in control, permissions should be grantable on multiple timescales when prompted during normal browser use: either per activity call, for the duration of a session, or permanently.

This seems to be a lot better than the effective security model we have right now - obviously you'd need to prototype and test the experience for actual users. Worth re-stating because it's the bottom of the thread, right now users have two choices:

  1. use chrome and have less granular security than this proposal.
  2. use Firefox and Jazz-soft and have no security prompts at all.

The irony of Mozilla's reticence to support WebMIDI is that the extension ecosystem can step in ( yay? ) and provide the same functionality, albeit with less security assurances. The good thing ( I guess ) about this is Jazzsoft's webmidi extension is not widely deployed and therefore does not represent a widely monetizable exploit.

I do think discussing the user experience should be within the scope of the spec discussions for WebMIDI, and I do think given the enormous number and variety of legacy MIDI devices and other implementations in the wild, the legacy hardware connection experience is very important. I think this for two related reasons:

  1. WebMIDI / WebAudio has the potential to revolutionize and democratize ( apply Web dynamics ) the Music Tech industry, and
  2. if we limit this to only new/expensive hardware, we really aren't democratizing the means of production of music and culture, we are instead creating a financial barrier for participants, and there are already enough financial barriers we place in the way of people in their participation on the web.

DISCLAIMER: when I previously commented on this discussion I worked for Mozilla - this is no longer the case so please take my comments here instead as those of an interested music tech enthusiast who also has a little experience shipping browsers.

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

commented Feb 12, 2019

as long as we as browser makers can provide them with the information necessary to make an informed decision

I think there is pretty strong historical evidence that we will have trouble doing this. Most users (and I suspect this includes users of MIDI devices that may want to use them with WebMIDI) are not experts on security and have no idea how USB works. I would expect that they largely have no idea what SysEx is.

Browsers have had a hard time communicating much simpler security information and security decisions to users....

So yes, I agree that this setup would arguably remove liability from the device manufacturers and the browser, but it then places an undue burden on users. Imo.

That said, I would love to be proved wrong and for us to come up with effective ways to let users make informed decisions here!

@cwilso

This comment has been minimized.

Copy link

commented Feb 12, 2019

Again, I want to start by underscoring that no one wants Web MIDI everywhere across browsers than me.

That said, I'd like to strongly back up @bzbarsky's position here: I don't believe it's possible to properly educate users so they can make an informed decision here. Even users who DO understand what sysex is and does would likely be utterly surprised by the possibility of the "USB class reprogramming" attack I mentioned earlier.

That said, I disagree with @Pomax: I think it's entirely possible to provide adequate value for manufacturers to get their devices whitelisted. Will this happen for all devices? Certainly not - but most devices are going to be useful with only short message support, and there is strong evidence that manufacturers see incredible value in building web-based sysex tools that they would definitely like to see -for example, the excellent tools for the Novation Circuit sitting next to me.

@karmatics

This comment has been minimized.

Copy link

commented May 12, 2019

My understanding after reading (most) of the above is that this has been shelved indefinitely by Mozilla... is this a correct understanding?

My further understanding is that SysEx is the problem, not more "basic" or mainstream use cases.

My own use case is as mainstream as it gets: to simply use a digital piano / MIDI keyboard as an input device. Think "piano karaoke synchronized with YouTube videos," it is in beta but here is a quick demo video that captures a bit of the potential: https://www.youtube.com/watch?v=viTPHMDuZCc

There are presumably middle ground uses, i.e. using the MIDI device as output (such as sending note on/off messages from the web page to the MIDI device such as an analogue synth, which is the opposite of my own use case).

I am curious (and forgive me if this has been discussed and I just couldn't find it), but couldn't Firefox allow this sort of "safe" interaction for now, while work proceeds (or doesn't) on the SysEx etc? It seems like it would be fairly straightforward and perfectly safe to use MIDI this way. Is there a reason it doesn't seem to be getting considered? (I am aware there is the possibility of sending "sysex: false" when requesting MIDI access, and I'll admit I don't understand why that doesn't do the trick. I'd think "output: false" could be an additional option, such as my own use case)

Is it a case of those who want/need SysEx (e.g. cpenny42 says: "I care about SysEx, it is vital to the functionality of my device.") thinking that if more basic uses are addressed, their use case will be ignored? If so I think this is incredibly unfortunate. There are a ton of potential web apps that could use pianos and drum pads as input and I certainly hope there is a way to make that possible.

@Pomax

This comment has been minimized.

Copy link

commented May 13, 2019

To be clear: as much as I want MIDI to be built into the browser, and am of the school of thought that if you're technically competent enough to want to connect a MIDI device to your browser, then you're smart enough to understand that SysEx is a thing (or you're at least smart enough to understand a one time warning, with all-time controls), Jazz MIDI does work perfectly fine in the mean time, so if you're developing a product that relies on MIDI in the browser, then whether or not Firefox adds it as built-in functionality is basically irrelevant to you: your product is probably good enough to survive having to tell your users that they need a MIDI plugin installed.

@jazz-soft

This comment has been minimized.

Copy link

commented May 13, 2019

Well, to be more precise, there is a web-extension to enable WebMIDI API in Firefox:
https://github.com/jazz-soft/web-midi
And there is a bunch of related workarounds:
https://github.com/jazz-soft/JZZ etc...

@Pomax

This comment has been minimized.

Copy link

commented May 13, 2019

Right, that.

@karmatics

This comment has been minimized.

Copy link

commented May 13, 2019

"I am of the school of thought that if you're technically competent enough to want to connect a MIDI device to your browser, then you're smart enough to understand that SysEx is a thing "

I admit I can't understand that school of thought. The whole beauty of the web browser is you don't have to install anything, you just go to a link and it works. And an electronic keyboard/piano that has a USB port isn't exactly some kind of geek-only device, its an extremely common thing for the non-technical as well as young kids to use.

Here's some kids ranging from 5-12 enthusiastically using a browser MIDI app a couple weeks ago. https://www.youtube.com/watch?v=iiZMayenylU I'm pretty sure none of them know what SysEx is, and I doubt any of their parents do (even though many have electronic pianos at home). Requiring them to install plug ins would dramatically limit the reach of this sort of product and completely defeats the value of running things in a browser. Honestly, saying "You can run it in Firefox if you install a plug in" would simply be shortened to "Chrome browser only" for this kind of mainstream use case.

@Pomax

This comment has been minimized.

Copy link

commented May 13, 2019

Those are two different things: SyEx is the thing that's holding up building full MIDI support into Firefox (because it's one of the message types that can be used to reprogram a midi device, if it has support for that baked in). So my idea is "if you use a MIDI device, you should know what SysEx is." Which means either you already know what it is (which is unlikely) or you should be able to plug your device in, and get a warning that you want to use MIDI, but there is something called SysEx messages, and malicious sites might try to send those kind of messages to your device, either for security exploits or because they just want to brick your device. And then a bit that explains that you'll be asked to grant sysex permission separately if and when a site actually does use the sysex opcode. You know how to use a browser and a MIDI device (or you have someone who got you to that point, like in your example, in which case they take on that responsibility), and you should be off to races.

However, that is currently not the case, and telling people they need to install some extra software is perfectly fine, as long as it's not bloatware/adware/malware and has a clear reason to be installed. If we can tell kids they need to install python for a kids learning code day (which is super common), or install "sublime" or some other text or code editor so they can follow along during a website building day (also super common), they will have no problem with their instructor or mentor explaining that we're going to install some software that lets the browser and the MIDI thing talk to each other.

And yes, as you point out, the other option is to say "we're going to use Chrome, let's make sure we all have that installed", and now you're still in the situation where someone will have to install something before everyone can get to doing the cool thing we'll be doing.

@cpenny42

This comment has been minimized.

Copy link

commented May 13, 2019

I'd be very happy with a non-SysEx only implementation of MIDI in Firefox, I'd be happy with any kind of indication that it's even being seriously considered. Forcing users to install extra software is very limiting in terms of the broader ecosystem of apps that are developed, even though it might not be that hard to work around for any specific user. I'll add my use case because it might add to the discussion:

I'm using SysEx to send over sensor values for a breath instrument that has a sliding mouthpiece and a few other moving components. It's very important that the current position of these sensors is shown on screen in real-time, and so SysEx is essential for real-time feedback of the state of the device. I also use SysEx to read and write to the device's memory where presets, etc are stored.

Of course, you can still use the device without SysEx and play just fine, and I have been able to encode the sensors as Controller values instead of SysEx, so if a non-SysEx implementation of WebMIDI will actually happen then I am all for it. At the same time, SysEx is a major part of MIDI and we shouldn't have to sacrifice it for an issue that is absolutely solvable.

I personally like the idea of user-side whitelisting of devices, and I would even go so far as to have a whitelist for specific SysEx messages. Most "safe" SysEx messages will have common patterns you'd expect for exchanging settings or sensor values, so it would also be useful for a user to see a master list of SysEx messages and only let certain types through (say only messages that start with a certain sequence of bytes). This would also give the pro users an option while being acceptably safe for non-technical users.

Whatever the best solution ends up being, I hope we can get the ball rolling.

@adamroach

This comment has been minimized.

Copy link
Collaborator

commented May 13, 2019

My understanding after reading (most) of the above is that this has been shelved indefinitely by Mozilla... is this a correct understanding?

To help level-set things a bit: this repository is for discussion of Mozilla's position on specific standards or proposed standards, not Firefox's product plans. While the outcome of this discussion informs Firefox's plans, it is not about the plans themselves. The outcome of this conversation could be that something is a perfectly fine specification, and Firefox might never implement it. It is also possible that we could conclude that a specification is irreparably bad, and Firefox might implement it anyway, due to extenuating circumstances.

Please limit the discussion here to the WebMIDI specification rather than Firefox's plans.

@Pomax

This comment has been minimized.

Copy link

commented May 13, 2019

To add to that (and remind anyone who makes it to the end of the thread): the master issue for Firefox-specific implementation and discussion can be found over on https://bugzilla.mozilla.org/show_bug.cgi?id=836897, and the very first comment in this github issue has a bunch more useful links to bugzilla tickets related to WebMIDI.

@karmatics

This comment has been minimized.

Copy link

commented May 13, 2019

I'm sorry if my comments seemed Firefox specific, I didn't mean them that way, but at the very beginning of this thread it says "WebMIDI has been in development in Firefox since 2015." etc, and there are discussions of how Google is approaching it in Chromium, and how people are affected by glacial pace of getting this into Firefox. I believe that that slow pace is mostly due to exactly what the core issue of this thread is.

My comments apply to all browsers, but as the developer of a very mainstream, kid friendly app, I still think it is relevant that I am in a position of simply telling people "only Chrome for now."

My point is, I would hope that basic MIDI (such as using a digital piano as an input device to a web app) is not be held back by the desire to accommodate much more specific, technical and potentially dangerous operations, such as updating firmware and the like. I don't agree that if all the user is trying to do is use a piano tutorial app (as one of many examples), it makes sense to confront them with stuff about SysEx, which is completely irrelevant to their use, will not serve any security purpose (assuming the web page isn't interested in doing any SysEx), and will only lead to poor experience.

A couple things from above:
"However, that is currently not the case, and telling people they need to install some extra software is perfectly fine, "

Not for my business model (casual, nontechnical users who tend to give something less than a minute before clicking the back button if they don't get some level of satisfaction), but it doesn't matter. The point of this discussion is what should be the case. And I'd further argue that if you are trying to protect users from danger, asking them to install software (rather than just do something entirely using browser functionality) is diametrically opposed to that.

"Whatever the best solution ends up being, I hope we can get the ball rolling."

Please.

What can I do to help? I would hope that, if nothing else, my app could serve as a good, mainstream, non-technical use case. ( https://pianop.ly )

@chr15m

This comment has been minimized.

Copy link

commented May 15, 2019

@cwilso what is the appropriate place to suggest/discuss updates to the Web MIDI API?

The purpose of this thread is to determine Mozilla's position on the spec, and we can help with that by addressing their concerns with the current spec.

Updates we can make to the spec to address the security concerns of @ekr and @marcoscaceres and others:

  • Add mention of "upload firmware" security risk. Currently only "download firmware" is mentioned in the spec.
  • Make a distinction between non-dangerous and potentially-dangerous SysEx requests. The latter potentially-dangerous messages being those that start with the byte 0xF0 only. The other "System Common Messages" and "System Real-Time Messages" are as safe as note-on, control-change, etc.
  • Add a suggestion that browsers prompt the user when SysEx access is requested, specifically where 0xF0 type messages are asked for, and that the user is shown a prompt such as:

Will you allow SITE to send custom MIDI SysEx messages?

This presents a security risk for attached MIDI devices which allow firmware reprogramming via SysEx. Please check your device before enabling this option.

It seems that the vast majority of SysEx use-cases are going to be safe: a user on a website they trust with a modern device which does not allow firmware upload. The above changes to the spec would allow Firefox to warn its users in those instances you outlined where the user has an insecure device attached and who have visited a site which wants SysEx access. Perhaps these changes would be enough to convince Mozilla to adopt the spec.

PS as an indie MIDI device builder I find the talk of black/white lists alarming.

@toyoshim

This comment has been minimized.

Copy link

commented May 15, 2019

Web MIDI API is discussed in the audio working group, and here is the GitHub repository and issues to discuss spec details.
https://github.com/WebAudio/web-midi-api/issues

@src-ableton

This comment has been minimized.

Copy link

commented May 21, 2019

For what it's worth, I would be very interested to see this implemented in Firefox! Even if it is only a partial implementation (no SysEx), though SysEx support (with a permission popup, like what Chromium does) would be ideal.

I'm building https://synth.kitchen/beta which uses the Web Audio API as an engine for in-browser modular synthesis. I'm currently only targetting Chrome because Firefox is lacking in the MIDI area. The purpose of Web MIDI in this app is to enable integration of the browser-based synth with external software/hardware MIDI devices.

@wyatt8740

This comment has been minimized.

Copy link

commented Jul 14, 2019

My Roland MT-32 basically requires SysEx messages to operate sanely. They're used for programming the voices on the device, since it's not GM compliant in its default configuration.

I understand it's an ancient device by now (1987), and I'd support this API whether I could use SysEx or not, but I'd really much prefer having the ability to configure the browser to allow all SysEx messages to go through for a given Midi device/port (e.g., my USB adapter).

@cpenny42

This comment has been minimized.

Copy link

commented Jul 23, 2019

Google Chrome is becoming more and more anti-privacy so this issue is becoming more important than ever. Because of that, I just switched to Firefox, but now I cannot even run my own apps with a MIDI device I created myself without needing to rely on a 3rd party developer's plugin (JazzMIDI).

There are many suitable solutions proposed here, but this is still looking just as dead in the water as it was years ago.

This is especially difficult because I am working on a medical application that incorporates musical instruments. Medical tech companies like Epic and Cerner feature streamlined deployments within their medical system that rely on standards like HL7 and SMART on FHIR. This lets you easily deploy your app within a hospital's login/authorization flow while ensuring HIPAA compliance, and in the vast majority of cases these apps are deployed as embedded web apps within a browser. It can sometimes be difficult and costly to get a native application (connected to the network) approved for use within a hospital, but if you have a web app, it is much simpler to get it approved with one of these large companies and deploy it within their system, which is browser-based. This situation also has some parallels at college campuses, though usually those systems are a little more lenient.

It would add an immense amount of value to all of our projects to be able to deploy them on the web. Right now, if you want to make a web-based MIDI app, you will probably also need to make a native app to actually reach all your potential users, because asking people to download 3rd party software cuts off everyone in an IT system where that is impossible, let alone the many who pass because it's inconvenient. Depending on the business model, this could have a real impact on a small business. If we could just write a single app that runs in the browser, we can reach those extra customers without needing to repeat the work in a native app if necessary (since we could just wrap the browser in a native iOS or Android app). In reality, when faced with this choice most people will just skip implementing their app on the web, leading to this extremely frustrating musical desert that is WebMIDI in real life.

For some reason non-musicians always seem to overlook the value in music software and music standards. It isn't just for people making music. It's for therapists, health professionals, educators, and researchers. The value isn't just in the software available, but what the people exposed to that creative software will create. We're years behind where we should be in terms of music technology. It's only slowly starting to come around, and Mozilla is the main roadblock holding us back right now.

The fact that WebMIDI is not implemented in one of the major browsers is really holding back potential economic growth in multiple areas. It's stifling innovation in both music, computer science, and business. It's frustrating that it is not a higher priority to whoever is making the decision to hold back on implementing a web standard that has been around for years. I don't think the people doing the cost/benefit analysis on whether to implement this really know the actual cost of not having this in Firefox.

@karmatics

This comment has been minimized.

Copy link

commented Jul 23, 2019

Chris I share your frustration with Firefox's pace on this, but have you considered running the Brave browser? It uses Chrome's core (and therefore gets web MIDI), but should protect you from Googles "anti-privacy" issue.

Side benefit, unlike Chrome or Firefox, you can read the New York Times etc without hitting a paywall. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.