RFP: WebMIDI about standards-positions HOT 147 CLOSED

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 =)

from standards-positions.

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.

from standards-positions.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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).

• Here is an example of a web page for updating the firmware of the RK-002 smart midi cable.
• Here's another page for updating the settings for the CV.OCD Midi -> CV converter. This doesn't use Web Midi, but instead allows you to download the sysex file for manual use - but this would be a great potential 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!

from standards-positions.

@dvhdr --

I’d argue that this attack opportunity already exists, in a more easily exploited form.

The top-line notion of web browser security is that it shouldn't be possible to visit a site and have something bad happen to you or your computer, unless you have been clearly warned of the risk, in a way that all users can understand, and agreed to it. You're pointing out that MIDI DAWs don't follow that same philosophy; however, their less rigorous approach to security and informed consent doesn't mean that we should relax ours.

from standards-positions.

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

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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 🎹💃🕺.

from standards-positions.

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.

2. 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.

from standards-positions.

" 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.

from standards-positions.

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. :)

from standards-positions.

@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.

from standards-positions.

Hi everybody, at Keith McMillen Instruments all of our new generation product editors use Web MIDI to send sysex for preset updates and firmware updates, this includes BopPad, K-Board Pro 4, and Mallet Station which we built for Pearl Drums. It's the very core of the functionality of the editor.
https://files.keithmcmillen.com/products/boppad/editor/

Due partly to the limited availability of web MIDI, we also build a standalone web app wrapped in Electron, which the vast majority of our users use.

I understand the security conundrum and don't really have any suggestions other than what have been presented above, but for KMI and it seems Novation, shipping Web MIDI with sysex disabled would make the editors completely useless on FireFox. it's a really powerful feature that it seems a lot of MIDI manufacturers are interested in using since it allows their user base instant access to powerful product software.

I hope there is a way we can have features and security

from standards-positions.

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

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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

from standards-positions.

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 #58 (comment) 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.

from standards-positions.

@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 ).

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

and then use keyboard commands to do literally anything it wants to your machine

Yeah, this is pretty much the show stopper 😢

from standards-positions.

I’d argue that this attack opportunity already exists, in a more easily exploited form. To attack a USB MIDI device currently, you could:

1. Craft malicious firmware for a popular device
2. Embed said firmware in an enticing looking session file or synth patch dump
3. Create a malicious site - no need for HTTPS (but why bother, just use one of the existing patch or session sharing sites)
4. Wait for users to download it using their trusted browser and install it using their trusted DAW

At no point are they warned that this could be dangerous. There’s no “this file could harm your computer” at the point of download, because it’s not an executable. There's no warning from the DAW that sending sysex could be dangerous.

With sysex dumping from the browser, there is a chance to warn the user that the content may be unsafe, and the origin is verified by HTTPS. We're already in a better position!

from standards-positions.

One thing that occurred to me the other day is that we might be able to do some CORS-like consent thing. I.e., we send some well-defined SysEx message to the device to ask "are you safe for me to send WebMIDI to", and then only allow it with the proper response.

from standards-positions.

Looking at https://www.midi.org/specifications/item/table-4-universal-system-exclusive-messages, the impression is that only a small subset of SysEx messages has a potential to affect anybody but the instrument itself. Maybe only those need special permissions? Isn't it too draconian to constrain all SysEx interface just because of this subset?

from standards-positions.

To counter @svgeesus' point here, an attack on the MacBook Pro camera rewrote the firmware to perform a VM escape: https://jscholarship.library.jhu.edu/bitstream/handle/1774.2/36569/camera.pdf

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

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

@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.

from standards-positions.

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?"

from standards-positions.

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

from standards-positions.

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)

from standards-positions.

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.

from standards-positions.

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

from standards-positions.

@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.

from standards-positions.

@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.

from standards-positions.

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.

from standards-positions.

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!

from standards-positions.

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.

from standards-positions.

@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?

from standards-positions.

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

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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

from standards-positions.

@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.

from standards-positions.

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.

from standards-positions.

@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.

from standards-positions.

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.

from standards-positions.

We're going to try to pull a few more manufacturers in to get some view into their world and how this affects it. May take a day or two though.

from standards-positions.

bricking can occur as a result of legitimate update too, with higher probability. (My laptop was recently bricked by Windows update). With Web Midi, manufactures will be able to provide online interface, which, among other things, can help to un-brick it. Other possibilities like simulating keyboard commands by attacker and other scary scenarios may be implemented only with the help of device driver (please correct me if I'm wrong) - in which case the driver itself is a security threat, with Web Midi or without

from standards-positions.

"Other possibilities like simulating keyboard commands by attacker and other scary scenarios may be implemented only with the help of device driver (please correct me if I'm wrong) "

I'm not sure what you mean by "help of device driver". Many computers will treat any USB device that claims to be a keyboard as a keyboard with basically no user intervention.

from standards-positions.

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

I'm a MIDI person; and while useful work can be done without SysEx, shipping with SysEx always disabled would be a severe limitation. As an analogy, useful work can be done with just HTML and CSS, but shipping a browser with JS always disabled (because there can be security issues) would be a significant limitation.

We're going to try to pull a few more manufacturers in to get some view into their world and how this affects it.

Yes, great idea. Manufacturers of MIDI equipment are definitely folks to talk to. Consider too the Maker community, because MIDI-enabled devices are very popular there. And thus, a whitelist would be actively harmful.

from standards-positions.

See Table VIIIa in the MIDI 1.0 spec:
"CURRENTLY DEFINED UNIVERSAL SYSTEM EXCLUSIVE MESSAGES "

Universal SysEx is used for things like tuning, sample dump, and time-code related control (start, stop, cue points, sample looping ...), MIDI Show Control, and so on.

from standards-positions.

Without taking a position on whether deploying with equipment-specific SysEx limitations is okay, I have two observations to make.

The first is that, in cases like this, whitelists are fail-safe, while blacklists are fail-dangerous: unknown (and exploitable) equipment will not appear on a blacklist. For this reason, I believe that blacklists are a complete non-starter.

The second observation is regarding the interaction between the maker community and whitelists. Given the skills and hacker ethos of the maker community, I believe that all that would be required to accomodate their use cases would be allowing side-loading of equipment identifiers through a non-web-accessible mechanism (e.g., via about:prefs).

from standards-positions.

@adamroach @ekr That's something I've been meaning to ask. How do we deal with "user has to change a pref to turn something dangerous on" in this situation? Like, would "unbounded sysex behind pref" even be viable? On one hand, it's definitely a complex user gesture, while on the other, does it mean everyone that wants WebMIDI just says "Here's instructions to turn on firefox pref [x]?"

from standards-positions.

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.

from standards-positions.

@ekr if firmware is so bad that it allows update to completely override its functionality (including impersonating something else) then how "are you safe for me to send WebMIDI to" can help? Everybody will upgrade their firmware to answer 'yes', and you are back to square 1. Whitelist will do the same with less hassle :)

from standards-positions.

@resource0x: As I said at the beginning, the problem here is usually that the firmware has been written to a non-adversarial threat model. That's not necessarily an unreasonable model when the computer its talking to is under the control of the owner of the device, but WebMIDI breaks that model, which is why it's unsafe for the Web browser to just unilaterally change it out from under the device. However, if the device has to opt-in, then it's the job of the device manufacturer to harden the device before representing that it's safe (and we can document what "harden" means in this case). Of course, they can lie, but that's on them, not us, just as it's the site's fault, not the browsers, if someone breaks in and steals your credit cart number, even though it's the browser that let you send the number to the site.

With that said, a whitelist seems fine from a security perspective; I was attempting to respond to complaints it was too onerous.

from standards-positions.

Hi guys, I use MIDI for VJing with webgl and having the possibility to do it on firefox will be nice :)

MIDI Controler allow live play, they are fun and peoples who uses it focus on creating cool stuffs ( music / visual / installation / etc.. ). Make it easy plugnplay is a very important.

This said, the security issue should be taken seriously and asking the user to understand the full consequence of his act and use it only with trustfull MIDI Controller will filter a lot of troubles and make them double check, keeping the user safe.

Just my feedback as an average MIDI Controler + web technology user .

from standards-positions.

@andrejhronco Do the devices in question allow sysex firmware updates to make them look like USB keyboards?

It seems to me that the only way to have "features and security" here is to ensure that the features cannot be used in ways that compromise security. In practice it sounds like a bare minimum is placing certain limits on just how much sysex firmware updates can change about the way the device interacts with the USB host.

from standards-positions.

"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."

(Note for the MIDI folks reading, in the above 'keyboard' means a computer keyboard for entering characters, not a music keyboard for entering notes)

I have been thinking about this potential exploit and it does seem very theoretical. Look at the USB specification for a MIDI device and for a computer keyboard. The data structures are very different. Even for a generic microcontroller (like a Teensy, which has a USB MIDI and also a USB keyboard option) changing USB device type is something you do as a compiler option, which links in different libraries; 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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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?

from standards-positions.

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?

from standards-positions.

@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.

from standards-positions.

@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).

from standards-positions.

@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.

from standards-positions.

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

from standards-positions.

@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.

from standards-positions.

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.

from standards-positions.

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

from standards-positions.

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.

from standards-positions.

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 ?

from standards-positions.

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.

from standards-positions.

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!

from standards-positions.

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.

from standards-positions.