WebMIDI

[qdot]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: WebMIDI
• Specification or proposal URL: https://webaudio.github.io/web-midi-api/
• Caniuse.com URL (optional): https://caniuse.com/#feat=midi
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=webmidi

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:

• Mac: https://bugzilla.mozilla.org/show_bug.cgi?id=1201593
• Windows: https://bugzilla.mozilla.org/show_bug.cgi?id=1201596
• Linux: https://bugzilla.mozilla.org/show_bug.cgi?id=1201598

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

[qdot]

it is not something one could do on-the-fly by reading SysEx data and then doing something with it, even if that was the intent of the firmware writer.

@svgeesus That's not quite the point of the attack being mentioned here. The problem is that, for a device that stores its USB descriptors in firmware, you could write your own firmware with a HID class descriptor instead of MIDI, compiled with the HID libraries you mentioned, then upload that firmware over SysEx on permissions grant. For many MIDI devices, this doesn't require user gesture to do outside of the permission grant, and as has been said in this thread, some manufacturers want people to upload their own firmware, which usually means things like bootloader signing (which still has problems in its own right but is out of scope for this discussion) probably aren't on the device.

It might be possible, though it might need operating system assistance, to pin the device type down somehow, such that its type couldn't change, but that's likely beyond what we are currently capable of.

@martinthomson That would possibly be hard to do even with OS support. If you can rewrite VID/PID pairs, then without some other sort of identifier, it would just look like someone plugged a new device in.

[svgeesus]

That paper references other examples. You can't assume that this is not possible just because it is hard.

I think we are in agreement. I asserted that it was hard, not that it was impossible.

[cwilso]

I also wouldn't assert that it is impossible; it is hard, but it's more important that 1) it would require the user's permission to have "full control" of the MIDI devices in question, 2) it would require the MIDI device in question to be able to have its firmware rewritten with a firmware that would turn it into a HID device (again, hard but not impossible, but also not necessarily possible for any given piece of hardware, and DEFINITELY not the same firmware and update mechanism for different pieces of hardware, and 3) it would only be applicable to systems that have one of those specific devices currently attached to the computer (most of my MIDI devices are not attached 24/7). To compare with the Macbook Pro camera attack that @martinthomson pointed to - that attack, IIUC, worked on every Macbook with an iSight camera, and of course most users could not remove the camera from their computer.

[ekr]

OTOH, those cameras were not accessible from the browser at the USB level

[ryoyakawai]

I made lite investigation on how to update firmware in the case of KORG, Roland and Yamaha with manufacturer's and AMEI(Association of Musical Electronics Industry)'s big help.

The result are bellow:

• Most of the devices are not able to updated those firmware with SysEx message in MIDI connection directly. -- Uploading new firmware file to the devices: using USB Mass Storage Class -- Updating firmware: the device must be turned into Firmware Update mode by user action (This investigation in under recent products as well as old products by those three manufacturer.)

So I think in the most of the case there are not big security risks on letting browser to have ability both to send and to receive SysEx. However, I have heard that there are some devices that accept firmware update by receiving SysEx message through MIDI(USB, 5 PIN-DIN) connection without any user actions on device side, so I think it is good to have blacklist somewhere to prevent of malicious silent firmware update.

[resource0x]

I have heard that there are some devices that accept firmware update by receiving SysEx message through MIDI

Do they use some standard sub-code of SysEx? If everybody is using same sub-code, then maybe ONLY this sub-code should be guarded? User can be asked for permission, and the permission will only be valid for the current session. Because for Yamaha/Roland/Korg etc this sub-command is not supposed to come in in the first place, the issue will never occur on these devices (if it does occur, permission will not have any effect anyway - the device will reject the command).

I'm speculating, no idea whether there's a single standard sub-command for this, but it seems plausible. But my point is that most of SysEx sub-commands are not exploitable, unless the firmware is buggy.

[ryoyakawai]

Do they use some standard sub-code of SysEx? If everybody is using same sub-code, then maybe ONLY this sub-code should be guarded?

I am not sure exactly, however I do not think that certain standard sub-code of SysEx is used for SysEx message that allow to update firmware by receiving SysEx. I think it is hardware dependent, is even not vendor dependent.

I'm speculating, no idea whether there's a single standard sub-command for this, but it seems plausible.

It sounds good idea for the future products to me. To define one(some?) specific ID or sequence that is always rejected by browser to prevent to apply malicious command. I think this sound one of a feasible solution.

[toyoshim]

There are some products that accept firmware updates over a specific sysex sequence today. But it's by design so that the products can be updated over the Web MIDI, that says known such products are designed to be used over Web MIDI from the beginning. But it would be nice if MIDI standards recommend that sysex-based firmware update requires a user action on device side.

Let me invite some developers to this thread.

[hsivonen]

Well, Firefox is full of crazily dangerous prefs, so I'm not worried about creating another one, but that shouldn't be our authorized mechanism to enable a feature.

I think there's a huge difference between a dangerous pref that gets flipped e.g. for testing automation and a dangerous pref that would get flipped once by users who have a certain need (in this case, own a MIDI device) and then the users would continue to browse random Web sites with the pref flipped.

So I think putting WebMIDI behind a pref (even an about:config-only one) isn't a solution to the problem.

Wait for users to download it using their trusted browser and install it using their trusted DAW

The observation that Web browsers allow users to save files of arbitrary type into their "Downloads" folder without a "This could be a total system compromise." permission prompt is technically correct. That is a massive loophole. Still, we shouldn't take a security nihilism position and conclude that therefore everything else is OK to add to the Web Platform. At least users have some understanding that when they open Downloaded files, the browser isn't there to protect them anymore.

[resource0x]

At least users have some understanding that when they open Downloaded files, the browser isn't there to protect them anymore.

Haha. Typical non-technical user (even educated one) doesn't know the difference between browser and OS, window and tab etc. And the annoying message like "This could be a total system compromise." won't help, b/c everyone will just mechanically press OK, or else he won't be able to do just anything. That's why it's important to request permission only when browser is reasonably sure something dangerous is going on. Asking for no particular reason might be counterproductive IMO, by creating a habit of pressing OK.

[AthanBillias]

Hello,  I would like to weigh in on Web MIDI representing one of the world's largest MIDI manufacturers (Yamaha) and also as a long time Executive Board member of the MIDI Manufacturers Association (MMA). I am following up on the previous comments from my colleague Ryoya Kawai.

Yamaha has been using Web MIDI on https://soundmondo.yamahasynth.com/voices for several years and has not encountered any issues.  There are a number of misconceptions on this thread as to exactly how MIDI SysEx works and what it can and more importantly what it cannot do.  Yamaha is an extremely risk adverse company and we looked at these issues in our Web MIDI discussions with Google several years ago and are convinced that the security risks are minimal (nothing is 100% secure) and well worth the benefits that Web MIDI provides to our customers.

Yamaha devices that allow firmware updates via MIDI file require the user to power on the device in a special firmware update mode so they are not susceptible to random attacks. 

The risk of reprogramming a MIDI device to become a keyboard (the other type, the typing type) or some other snooping type of device is very low, at least over 5pinDIN, USB, or BLE. The vast majority of MIDI devices ( including Yamaha products) use separate memory for the USB functionality firmware, built into or directly attached to the off-the-shelf silicon available for USB MIDI. That memory space is most often not field programmable, let alone accessible by Sys.Ex. It is not in the same memory as the MIDI function. So it is not possible to hack it.

Our Soundmondo site uses SysEx to identify which Yamaha keyboard is attached so we do need support for SysEx.

Yamaha would support a user opt-in for SysEx because there are simply so many MIDI devices on the market and some do allow firmware updates via a MIDI file, but the vast majority of devices from the major suppliers represented have little risk for even that.

For example, this would be an appropriate message.  "Do you want to allow this web page to send System Exclusive messages to your MIDI devices? You should only allow this if this is a web page you trust to work with your MIDI devices."   Yamaha believes that Web MIDI is important and strongly requests Mozilla’s support of Web MIDI in the near future.

By the way, the MMA Technical Standards Board is drafting a response that should be posted here in the near future. 

Thanks, and if you have further questions, please reach out here.

Athan Billias Director of Strategic Product Planning Yamaha Executive Board MIDI Manufacturers Association

[kaizhu256]

stupid question from a non-midi-knowledgeable person:

1. is it feasible for the MIDI Manufacturers Association to self-police themselves with a white-list of midi-hardware that are hardened for SysEx?

2. is it feasible for browsers to auto-opt-in devices in the white-list? or would this open a can-of-worms where people began requesting white-lists for other hardware-related proposals, which browsers would not want to burden themselves with?

On 3/9/18, Athan Billias notifications@github.com wrote:

Hello, I would like to weigh in on Web MIDI representing one of the world's largest MIDI manufacturers (Yamaha) and also as a long time Executive Board member of the MIDI Manufacturers Association (MMA). I am following up on the previous comments from my colleague Ryoya Kawai.

Yamaha has been using Web MIDI on https://soundmondo.yamahasynth.com/voices for several years and has not encountered any issues.  There are a number of misconceptions on this thread as to exactly how MIDI SysEx works and what it can and more importantly what it cannot do.  Yamaha is an extremely risk adverse company and we looked at these issues in our Web MIDI discussions with Google several years ago and are convinced that the security risks are minimal (nothing is 100% secure) and well worth the benefits that Web MIDI provides to our customers.

Yamaha devices that allow firmware updates via MIDI file require the user to power on the device in a special firmware update mode so they are not susceptible to random attacks.

The risk of reprogramming a MIDI device to become a keyboard (the other type, the typing type) or some other snooping type of device is very low, at least over 5pinDIN, USB, or BLE. The vast majority of MIDI devices ( including Yamaha products) use separate memory for the USB functionality firmware, built into or directly attached to the off-the-shelf silicon available for USB MIDI. That memory space is most often not field programmable, let alone accessible by Sys.Ex. It is not in the same memory as the MIDI function. So it is not possible to hack it.

Our Soundmondo site uses SysEx to identify which Yamaha keyboard is attached so we do need support for SysEx.

Yamaha would support a user opt-in for SysEx because there are simply so many MIDI devices on the market and some do allow firmware updates via a MIDI file, but the vast majority of devices from the major suppliers represented have little risk for even that.

For example, this would be an appropriate message.  "Do you want to allow this web page to send System Exclusive messages to your MIDI devices? You should only allow this if this is a web page you trust to work with your MIDI devices."

Yamaha believes that Web MIDI is important and strongly requests Mozilla’s support of Web MIDI in the near future.

By the way, the MMA Technical Standards Board is drafting a response that should be posted here in the near future.

Thanks, and if you have further questions, please reach out here.

Athan Billias Director of Strategic Product Planning Yamaha Executive Board MIDI Manufacturers Association

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/mozilla/standards-positions/issues/58#issuecomment-371723815

[toyoshim]

IMO, whitelist is a bad idea because:

1. users will miss a chance to create applications for vintage synth that original manufacturers already stoppped supporting.

2. secure things today may be no more secure things tomorrow. to protect users from unknown security risks, blacklist is better than whitelist if we need to choose one of two lists, or want to have both.

community based whitelist may solve the issue 1, but it is no more secure than blacklist is.

also both list does not work for legacy non-USB MIDI or USB to MIDI converters. maybe it's ok because it's also hard for attackers to identify the device and to attack it automatically.

[hires]

I make hardware synthesizer products and most use MIDI.

I've been porting some native apps to WebMidi so that I can keep tools updated and help my customers get more from their products. Full SYSEX is precisely what I need. Sending channel messages is actually not very useful for apps like preset editors, firmware loaders and stuff where a webapp would make the most sense to me anyway.

Please consider adopting the security model from Chrome. I'd hate to have to tell all my customers to use Chrome instead of Firefox, but currently it's the only cross-platform way to do this. (other than Opera, but I only know one person that uses that)

• SYSEX access should be disabled by default
• If the user enables SYSEX, a pop-up should allow them to authorize a site. For instance, I'm the manufacturer, so I assume they would trust my site.
• Chrome seems to enforce a rule that SYSEX is only allowed if the page was served over HTTPS... this seems like a good idea.

Please don't "get creative" about trying to filter SYSEX. The whole meaning of it is System Exclusive. In fact as manufacturers we pay every year for the privilege of being able to craft our own SYSEX messages with any content we need.

WebMidi REALLY helps hardware makers and small overworked teams make good, cross-platform tools for users. Most of these tools are not profit-oriented and are done "on the weekend" to add extra functionality.

To me WebMidi is the single most exciting thing to happen to MIDI in a very long time. As a Linux user, targeting multiple platforms with a single app, and making sure users are always using the latest one is awesome. And honestly, as much as security is important, some basic pop-up warnings are fine.

[AthanBillias]

I agree with what Andrew Kilpatrick said.

The Web MIDI API addresses security concerns in section 4.11 and the security implementation in Chrome has proved sufficient for several years. Yamaha has over 100,000 sessions on Soundmondo with no security issues.

Yamaha encourages Mozilla to use the same model of end-user whitelisting of specific SSL certified domains as Chrome has used.

Chrome implemented a Permission window based on the Web MIDI API.

I think Mozilla should review what has already been successfully implemented and use that as a model for implementing Web MIDI.

In Chrome, a security window is displayed when an application declares to use SysEx and the application is able to declare the use of SysEx only when the content is served by HTTPS.

The protection works something like this:

(1) The document that requires the use of SysEx must be served as HTTPS.

(2) To make the server serve HTTPS content, the server must have an SSL certificate.

(3) To obtain SSL certificate, the owner of a server must provide personal information and the domain name which the certificate is applied to.

(4) Because the SSL certificate is limited only one domain, the web app provider can be determined if something occurs.

Essentially this allows end users to whitelist specific SSL certified domains for use of Web MIDI SysEx.

[annevk]

To be clear, Mozillians involved in this thread know what Chrome has implemented and deem it insufficient. HTTPS and a permission prompt are table stakes for more sensitive APIs, but they don't make something secure.

I'd personally be interested to see manufacturers address https://github.com/mozilla/standards-positions/issues/58#issuecomment-370178612 by @ekr. If devices can self-identify as being safe and such a check always fails on devices today, that would reduce the attack surface quite significantly.

[toyoshim]

Actually, as a Web MIDI owner in Chromium project, I think more diversified security features are still needed for continuous support of the Web MIDI, and other device APIs. What the web platform really need is not MIDI specific ad-hoc features or workarounds, but common security infrastructures to implement powerful APIs on the top of them.

Feature Policy is one of such infrastructure that I love and think it mitigates security risk drastically since the most malicious attacks will be injected from a third-party iframe that is out of control for site authors. With the HTTP-only support, Feature Policy, and a host black list, we can realize a Store Apps level security that Chrome Extensions/Apps, or FireFox OS apps realized to allow non-standard powerful device APIs.

Another improvement idea is to use the device chooser UI that we already have for Web USB. It could be a better replacement of the permission prompt, but I still need to consider how it can work with the firmware update use-case that the device appears as a different device in the middle of the update process. If Firefox people are also interested in this, I'd spend more time to investigate this approach.

For self-identifying approach, I think it does not have enough power to ensure the device is secure in terms of the web level security since what browser vendors really concern is firmware bugs that allow attackers to hijack the device. As discussed, the most devices were already designed to be safe for exposing the sysex surface. But bugs are always there, as we saw MS synth caused a kernel driver crash over Web MIDI and blacklisted. In terms of that, we also need to be careful about handling non-sysex messages. Chrome implements message validation and try sending messages in a simple form as possible, e.g. does not use running status, does not insert real time messages into another message, etc. Also, we will change the prompt to be shown even for non-sysex use case.

Also I have a big concern about a scenario it may happen if we hesitate to support sysex in Web MIDI. If we allows sysex only for certificated devices, what happens? Some new companies or personal developers may develop a device that can allow firmware update over a secret sequence of non-sysex messages. That will break what we have believed on MIDI until today. I think self-identifying does not work for the same reason, developers may bake the sign blindly.

It could not be perfect, but we need to keep cost efficiency to break security walls low enough to avoid attackers are interested in. E.g. Web MIDI should not be more dangerous than WebGL, etc.

[annevk]

Feature Policy, like HTTPS and the permission prompt, is a red herring in this discussion as it doesn't address the security concern. (And none of that makes it on par with stores either as stores have a direct relationship with the app's vendor, can perform code inspection, can revoke, etc.)

As discussed, the most devices were already designed to be safe for exposing the sysex surface.

I think the main issue is that we cannot be sure about the long tail. Having an explicit opt-in (and lots of tests, presumably), gives the browser some guarantee that the user is connecting to a USB device that it cannot compromise. A USB device whose USB protocol is "browser safe". It sounds like manufacturers could still release a USB device that circumvents those guarantees, at which point we have to decide whether that's an acceptable risk and whether any kind of additional block/safelisting is warranted.

[toyoshim]

I think Feature Policy wasn't discussed enough here. Can you elaborate the reason why you think it can not mitigate security risks? It helps site authors to manage Web MIDI accessible contents in a reliable way. Though we still need a way to trust site authors.

For long tail devices, I think it does not worth considering because of low cost-efficiency for attackers. If an attacker even can find a way to hijack a long tail device, the attack works only e.g. hundreds of browsers in the world (for people who own the device, connect it to PC, and have it powered-on), and once the attack was found, it would be blacklisted. Since most attackers do as a sort of business, they focus on finding cost-efficient attacks, and this scenario does not pay to attack. (I may be optimistic here, and needs inputs from security experts)

On the other hand, MS synth is installed by default. It was assumed as trust-worthy as you know Outlook automatically played MIDI files, and web browsers also did it in old school days. But once we find a security bug, this could be a good target for attackers today. I can say the same thing if we have a defacto Web MIDI ready device that explicitly opted-in in the future.

This is the reason why I think opt-in approach does not work.

Managing organization to certificate it does not sound a realistic plan, and it would even encourage hobby or cloud funding projects to invent sysex over control-change message hack or something like that.

[annevk]

Though we still need a way to trust site authors.

And we don't. The security model of the web is build around distrusting all sites.

Before Feature Policy we also have had features that are same-origin and top-level browsing context bound. It doesn't meaningfully address the security question, which is about whether these USB devices can be compromised in such a way that they end up attacking the user's computer.

That's the question Mozillians are interested in addressing. Measures that solely raise the bar before an attacker gets to that point are assumed to be in place and rehashing them won't help this thread progress.

[bzbarsky]

Can you elaborate the reason why you think it can not mitigate security risks?

It does mitigate them.

What it doesn't do is address the fundamental problem of a malicious site that the user trusts to "do sound stuff" (this is the user's thought process here, in quotes) but doesn't trust to have "arbitrary access to my machine, including full user-privilege read and write". To solve that problem, we either need to ensure that WebMIDI does not provide said arbitrary access or clearly communicate to the user what potential privileges are being granted. And if the latter, that needs to be done in way that's hard to bypass commensurate with the threat involved. I'd think at least the level of bad-certificate warning pages, since this is a bigger potential threat.

The current prompt in Chrome does not do the latter, and I'm not sure anyone actually wants to do the latter, because it would involve making users jump through serious hoops to do WebMIDI things. So we're looking at ways we can do the former.

[AthanBillias]

" It doesn't meaningfully address the security question, which is about whether these USB devices can be compromised in such a way that they end up attacking the user's computer."

I would like to reiterate what I posted before that the risk of reprogramming a MIDI device to become a keyboard (the other type, the typing type) or some other snooping type of device is very, very low and device specific. The vast majority of MIDI devices (including Yamaha products) use separate memory for the USB functionality firmware, built into or directly attached to the off-the-shelf silicon available for USB MIDI. That memory space is most often not field programmable, let alone accessible by Sys.Ex. It is also not in the same memory as the MIDI functionality so it cannot be hacked via SysEx.

To be clear, for the vast majority of MIDI devices, a hack that would allow the MIDI device to be reprogrammed via SysEx to snoop and/or access the user's computer is technically impossible.

Also regarding comment #58, if there was a specific recommendation for a set of SysEx messages that would provide the level of security that Mozilla would like to see, the MMA (and AMEI, the Japanese MIDI organization) would be happy to cooperate with Mozilla to help define those messages.

We shouldn't downplay the security risks, but it is important to understand how embedded MIDI products are designed and the scale of the potential threats.

[hires]

Another important thing to consider is that if a user decides to authorize a particular HTTPS site to control their MIDI devices, they would probably also download an executable binary from that same site and run it directly on their computer. I see WebMidi as a safer alternative to shipping native binaries to perform various functions that users want to do with their MIDI devices.

I do believe it would be technically possible for a device to be maliciously reprogrammed via MIDI under some rare circumstances. But other than actually knowing a particular device exists, this would also require that the device can be put into firmware loading mode which is often restricted in hardware. Our USB-connected MIDI devices cannot be put into programming mode without a user physically holding down buttons while they plug in the device.

So overall I would say that when comparing users downloading binary apps, vs. using WebMidi, the latter is a safer and better choice for users and developers alike. By not supporting WebMidi, it's actually encouraging people to continue using binary app downloads to get the functionality they want.

There must be some kind of reasonable opt-in solution like what Chrome is doing that would be okay. Honestly I don't see how their model is bad... to me it feels safe enough and definitely requires a user to make a decision before the page starts. Please just do it this way. :)

[tealdev]

Random reader here, but I had a thought.

Instead of seeking assurances from Manufacturers or websites, etc., is it possible just to ask the hardware for the truth of the issue?

I.e., when a WebMIDI request is made, check the available MIDI devices and see if they can be placed into Typing Keyboard mode, or in some other way have their USB signature altered? If they fail that pre-check, refuse the connection.

I realise that there is no guarantee that someone might not be able to code a different way to modify the USB data, but it seems like it might reduce the window of vulnerability if you could weed out devices that you determine are at risk.

I don't know if this is technically possible to set up as a quick pre-test, or if there are too many variations?

[cwilso]

@tealdev This is not possible, no.

The general concern is that enabling access to MIDI devices enables access (prompting the user, yes, but still enables access) to hardware devices that may not have been designed (hardened) to be exposed to web pages.

There is also a very specific attack that's been described, which would work like this:

1. User would need to have a specific USB-MIDI device, attached and powered on.
2. Attacker would ask (in script in page) for system exclusive access to MIDI devices
3. User would approve sysex access. (In Chrome, we describe this as "full control of MIDI devices.")
4. Specific USB-MIDI device would need to allow firmware updates of device WITHOUT user intervention.
5. Specific USB-MIDI device would need to allow the firmware of the USB port on the device to be rewritten in this way. (As per Yamaha's comments, this is not true for Yamaha devices - you can rewrite the device's system, but not the firmware for the USB port itself.)
6. If #5 enables this, the attack would send a custom-written (i.e. specific to that specific type and model of device) sysex code block in order to rewrite the USB driver on the device to expose itself as a USB HID device - e.g. a keyboard.
7. Attacker would then use their code in the firmware to attempt any kind of attack that one could perform if one could plug a virtual keyboard into a web browser's computer - e.g. spawn processes, attack local resources via shell, whatever.

This isn't about "typing keyboard" mode - it's about devices that allow their firmware to be rewritten. An element of Yamaha's suggestion is that their devices do NOT enable the USB firmware to be rewritten over sysex, even though updating the synth firmware in a Yamaha Reface keyboard, e.g., is a core scenario that is critical to them.

I would suggest that there are multiple levels here (organized roughly by concern - for each of these, prompting the user may be in place, but not everyone considers that a useful protection):

1. whether any non-system-exclusive access to MIDI devices should be allowed. This covers concerns such as fingerprinting via device enumeration as well as possible side effects like turning on/off lights driven over MIDI via note on/off and continuous controller (CC) messages.
2. whether specific well-known sysex should be enabled (e.g. MTC, SDS).
3. whether sysex should be enabled for devices that do not allow firmware updates
4. whether sysex should be enabled for devices that allow non-USB firmware updates with user intervention required on the device (e.g. accepting an on-device "update firmware (y/n)?" prompt on the device)
5. whether sysex should be enabled for devices that allow non-USB firmware updates WITHOUT user intervention on the device
6. whether sysex should be enabled for devices that allow any firmware updates, with user intervention on the device
7. whether all sysex should be enabled

Note that items 3-6 would require whitelisting (or blacklisting) specific devices.

[bome]

This is Florian Bomers, writing on behalf of the Technical Standards Board (TSB) of the MIDI Manufacturers Association (MMA).

We have followed this thread with great interest. Many of the MMA member companies are increasingly interested in using WebMIDI for all kinds of different applications. Consequently, we would welcome Mozilla to make the WebMIDI API publicly available in their web browser(s). We would like to offer our assistance in assessing the risks and mitigation for the concerns that have been raised about Manufacturer Specific System Exclusive Messages.

We have added a more detailed MIDI message classification to the WebMIDI Security Analysis Document. It seems clear to everyone that there is no known way for exploiting categories 1-3 ("short" MIDI messages).

Category 4 ("Universal System Exclusive") is using the System Exclusive message format, but consists of well defined messages which cannot be used for firmware uploads or any manufacturer specific data exchange. Therefore, Universal System Exclusive messages are just as safe as categories 1 to 3. Universal System Exclusive messages are clearly identified by their header, using IDs 0x7E and 0x7F.

We recognize the concerns raised that the 5th category, Manufacturer System Exclusive using IDs other than 0x7E and 0x7F, might be a potential security risk for the host and may need some measures to protect the user. To us, it seems that such an attack would hardly be worth the trouble -- given that a) very few models are vulnerable at all, b) an exploit only works for one model, and c) the absolute total number of MIDI devices is relatively small compared to other potentially vulnerable components/attached devices of a computer.

Manufacturer System Exclusive Messages have useful and legitimate use cases that are important to the MIDI industry. The vast majority of uses and devices are not vulnerable to the type of concerns raised. We would like to help define ways to identify and use Manufacturer System Exclusive Messages when the risk does not exist or other uses where risk can be minimized.

We would welcome Mozilla to add support for the WebMIDI API now, even if just for categories 1-4, which allow many useful web applications. Then let’s continue to discuss ways to mitigate any potential risks of Manufacturer System Exclusive Messages.

[qdot]

Finally spent some time updating the document in the original issues to include more MIDI message types (thanks for those updates, @bome), as well as comments from @cwilso and others on the Chrome team.

It feels to me like the subdivision of SysEx messages between Universal/Manufacturer (Category 4 vs Category 5, as @bome laid out) specific changes the boundaries of the conversation somewhat, since we could then either stratify permissions or only allows non-Manufacturer Specific SysEx if need be.

@ekr @martinthomson Any input on this?

[martinthomson]

@qdot, if the distinction between categories 4 and 5 is indeed as stated (no potential for abuse on 4), and we can verify that this is certain, then I don't see a reason not to enable categories 1 through 4. If the distinction is as distinct as stated, then we should be OK.

The question about utility likely remains. I see a lot of comments here asking for capabilities that are clearly category 5.

[jeffgca]

@martinthomson @qdot I think starting with 1-4. We shouldn't block on 5 to ship initially. I think we need to support 5 in some way, perhaps with a per-session permissions model that would mitigate the sort of drive-by scenario various people have described. I would even suggest shipping everything but preffing off support for 5) in release ( assuming that is technically possible ).

[qdot]

@canuckistani Web MIDI is generic enough that it's not really much work to implement everything then filter as needed from there. So we can just get everything stood up, then pref-scalpel from there as need me.

[ekr]

@canuckistani @qdot: this isn't really the fourm to discuss our product plans. The question at hand is what Mozilla's position on the spec is (though of course if we don't like the spec, we probably also won't ship).

[qdot]

@ekr We have a better definition of what can and can't be implemented within the range of SysEx messages. Would that be worth proposing to add to the spec? I feel like we're getting a better idea of functionality range, partially addressing the firmware issue.

[cwilso]

I'm interested to start the discussion on what spec changes you'd want to see. Two different levels of sysex? Specific mention that "some implementers may whitelist/blacklist devices?"

[qdot]

@ekr Pinging again to see if you have any opinions/updates?

[jazz-soft]

@qdot just FYI: please have a look at https://addons.mozilla.org/en-US/firefox/addon/web-midi-api/

[toyoshim]

@jazz-soft how did you make it work without NPAPI? I'm afraid that you are making a new escape hatch that bypasses web browser's security infrastructure, and introduce another security hole for people who installs jazz-plugin.

[padenot]

Jazz requires having a piece of software installed on the host computer, and uses messaging to communicate between the browser and the software.

I don't know what kind of IPC that is, probably native messenging, or maybe websockets, or something.

[jazz-soft]

Thanks for your interest guys! :) It uses native messaging as specified in Mozilla's manual: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging

[jas-ableton]

As far as Ableton is concerned, we'd be in support of an initial implementation, even if it didn't support SysEx. For now, we're mostly interested in allowing people to use standard MIDI controllers to control browser-based instruments like the ones you might find at https://learningmusic.ableton.com/. We would definitely use an implementation of Web Midi that allowed for the transfer of standard MIDI messages (note on/off, control change, pitch bend, channel pressure, etc.) even if the implementation didn't initially allow for the sending of SysEx. Put another way, categories 1-3 in the Security Analysis document would already be quite beneficial for us, as well as for other creative web developers looking to incorporate hardware devices into their apps.

That said, we also see the benefit of having SysEx available for web developers, and it would be great to see this work its way into the implementation. Ableton's Push instrument would not be susceptible to the sorts of catastrophic attacks mentioned in this thread, but it would be possible for an attacker to alter the calibration of the device (pad sensitivities and brightness settings) in a way that would require a factory reset for the device to be rendered usable again. For that reason, we agree that a strong warning before the code is granted SysEx access would be prudent.

Here's some more information on our instruments. You can see that an initial implementation allowing only standard MIDI messages would already be really valuable.

Standard MIDI messages (Note on/off, control change, pitch bend, channel pressure, etc.) are used for basic functions like illuminating pads, setting a pad's color, and illuminating the touch strip.

A list of available commands is given here: https://github.com/Ableton/push-interface/blob/master/doc/AbletonPush2MIDIDisplayInterface.asc#midi-interface

SysEx commands are used to update certain calibration and configuration settings. Using SysEx, a developer can do things like change the color palette, brightness, and white balance settings assigned to particular LEDs. SysEx also allows a developer to - among other things - change the calibration of Push's pad sensitivities.

A complete list of available commands is given here: https://github.com/Ableton/push-interface/blob/master/doc/AbletonPush2MIDIDisplayInterface.asc#24-sysex-commands

[cpenny42]

It’s been years since the web midi api has been introduced and this is now a pretty critical feature for most MIDI device manufacturers. Is Mozilla still dragging its feet on this?

I don’t think scrapping all of web midi because a few devices allow firmware upgrades over sysex (while the vast majority don’t) is misguided. Recommending chrome to customers is less than ideal.

[Pomax]

Would it be possible to approve the core at least? It's very strange that we've been able to add gamepad support to Firefox for years now (since v29!), but somehow MIDI support --the core of which is no harder to work with than HIDs like gamepads-- never got added. Not even experimentally.

Yes, sysex messages can be a terribly insecure concept, but thankfully they're also really easy to filter: say "we will only implement the secure parts of this spec" and let's move this forward? The important part is that the user finally gets the ability to drive their browser interaction with a MIDI controller. Press key, make JavaScript do things. Combine with the Audio API for truly mind bendingly amazing things. While you might be thinking "music", MIDI control surfaces (e.g. the Korg NanoKontrol/NanoPad or the Ableton Push) have long been the instrument of choice for richer interaction than just a keyboard and mouse offer. That's a richness the web deserves to play with in a way that isn't "Only supported in Chrome".

Worst case, we turn off sysex command handling in the initial implementation, with users still thankful that they can finally use their MIDI devices to do things with in the browser. Even if we mark full compat as "under consideration due to security concerns", and then never actually implement sysex handling, users would still be thankful: we've been waiting for this to actually get done in firefox for at least six years now, we don't need an all-or-nothing solution, we just need any kind of MIDI interaction at all =)

[annevk]

It was pointed out to me that at some point Web USB did have an origin-safelist feature, very similar to CORS: https://gitcdn.link/cdn/WICG/webusb/e8315043dba44fbd3d1efc275bb6c4ad068df6f7/index.html#webusb-descriptors. Though rather than an origin safelist, which feels a little bit like a DRM scheme in this context, it'd be better if it was simply a signature indicating "I know about the web and I'm fine with it accessing me provided the user consented". From discussing this with Reilly Grant from Google if that approach would work for Mozilla, they would be willing to specify and implement it in Chrome as well.

[Pomax]

Would that be a separate permissions from "this page is trying to use MIDI, allow Y/N?" that was raised over on https://bugzilla.mozilla.org/show_bug.cgi?id=836897#c57 ?

[annevk]

Yeah, my comment is about the USB device granting permission over the USB protocol to be connected to a browser, enforced by the browser. It doesn't involve the user.

[Sakari369]

Hello. Developer of OmniGeometry (https://OmniGeometry.com) here. Would be very happy to use MIDI -controllers with our software and the excellent performance Firefox is delivering with Quantum these days. Unfortunately I have to stick to Chrome, which doesn't stand with the performance with Firefox.

Just adding my 5 cents here, hoping that WebMIDI support will be added and focused on Firefox. I can even donate towards it's development if that's an issue. Thank you!

[paradajz]

Haven't read the entire thread, although I do think security implications here are hugely overblown. You either buy MIDI device from reputable manufacturer, you build the app with SysEx yourself (such as I did) or you download some random firmware off the Web, which you shouldn't trust anyways. It could be naive way of viewing things, but seriously, this is MIDI we're talking about. My app uses custom SysEx protocol designed to configure the device, so WebMIDI without SysEx isn't just reduced functionality - in my case it's useless. Also, splitting the SysEx support to various categories defeats the entire purpose of SysEx which is designed to be, well, not designed at all (implementer should do that).

Given all this, my users must use Chrome to access my app, but it works just fine for almost 2 years without issues. It would be really great if Firefox would support the spec as some people really don't want to use Chrome.

[klesun]

Gosh, who cares about SysEx, just give us the support for standard MIDI messages already, then continue discussing security concerns of SysEx for however many years you wish.

[cpenny42]

I care about SysEx, it is vital to the functionality of my device. SysEx lets users change hardware parameters like calibration info.

This whole discussion is ridiculous - we should have MIDI in Firefox now. MIDI includes sysex. Sysex is not a security risk for 99% of devices, and it should be the reponsibility of the device manufacturer to ensure their device is secure.

The MIDI standards committee is already rolling out MIDI 2.0. Funny that by the time 2.0 comes out Firefox can’t even roll out 1.0, which chrome has had for YEARS.

[marcoscaceres]

Kindly please refrain from advocating and using provocative language or we will be forced to close commenting on the issue.

Does MIDI 2.0 address the security issues? It might be a better implementation option if it does.

[bome]

Hi, thanks for bringing this up. MIDI 2.0 is 100% backwards compatible, so it does not address the security issues. And as long as you can transport raw data via MIDI, there is no way to address them on MIDI layer. IMHO, the problem is not an unsafe protocol (MIDI), but unsafe MIDI devices (few of them).

We (MIDI Manufacturers Association) would still be very interested in seeing MIDI support in Firefox. Has there been any progress?

Thanks! Florian (member of the Technical Standards Board of the MIDI Manufacturers Association)