Comment by jamesgeck0
4 years ago
> Web MIDI API - Allows websites to enumerate, manipulate and access MIDI devices.
This API is actually a bit horrifying from a security perspective. In addition to allowing you to use MIDI keyboards as input devices on websites, it also allows websites to send binary firmware updates to MIDI devices. The reason is that it's common to use custom firmware to backup/restore settings and enable neat effects and functionality on MIDI devices.
Mozilla's engineers have reasonably pointed out that an attacker utilizing Web MIDI could use MIDI devices as a stepping stone to launch an attack against the user's PC outside of the web sandbox. One such attack might be by reprogramming the device to appear as a standard USB computer keyboard and "typing" commands to the host.
At least one well known manufacturer has vouched for the technical safety of their musical instruments, noting that they're physically designed in such a way that the MIDI firmware can't alter USB firmware. But there's no way to know that every MIDI device has been similarly well designed.
As neat as Web MIDI is, I think Mozilla and Apple probably made the right security call here.
Fun fact: for quite a long time Chrome skipped over the user permission step in the Web MIDI spec, always allowing access and silently giving ad networks a list of connected USB MIDI devices with no user consent:
https://www.obsessivefacts.com/blog/2018-10-20-chrome-allows...
Here's what appeared on porn site xhamster.com once newer versions of Chromium got around to implementing the permission check (SFW-ish):
https://www.obsessivefacts.com/images/blog/2020-04-04-the-ja...
Guessing it was for additional browser fingerprinting.
That seems a bit far fetched.
15 replies →
Besides, I know they want to turn the browser into an os, but it's not one.
It's sandboxed from the os and limited to some use cases, which is the point. I don't want something capable of hot loading code from any web site to have the capabilities of my OS.
The browser is indeed an application platform. Even HackerNews is an app, although it uses a minimum of browser functionality.
Maybe you don't want things like videochat or paint programs or music learning apps to run in a browser, but lots of people do.
Imagine if Firefox said "we're not going to let any web page access the camera"... their market share would probably drop in half overnight.
I wonder if and when the splitup will happen between the "text" web and "app" web.
I know you can disable Javascript, but this is still different.
I am have dreamed of a browser that lets me create desktop shortcuts to webapps and then pretend as if the webapp is its own fully independent application but all webapps would still run in the same browser instance.
1 reply →
What would Hacker News be? How about email apps such as Gmail or Yahoo mail?
12 replies →
Then disable those permissions.
Average users won't do it.
1 reply →
Manual security = no security
It's kind of sad though because it's still 10X easier to build a browser app than a native app simply because of the wealth of highly-usable stuff written for JS.
Every time I have to build a GUI in Linux I just build a webapp that connects to a TCP backend on localhost because that way I can just build a beautiful UI in HTML/JS/CSS and I don't have to deal with the mess that is GTK, QT, TCL, TK, and all that crap.
Android programming is another can of worms and I'm frankly fed up with Gradle updates breaking my project every update and needing 79+ files, multiple cludgy steps for signing APKs, zipalign (wtf) and other crap just for a Hello World.
What would be nice to have is "installable" apps that use the webkit rendering engine but have full access to the system including directly opening TCP ports and direct access to /dev. These would have to be trusted apps obviously. Websites that load code without consent should be restricted, of course.
> Every time I have to build a GUI in Linux I just build a webapp that connects to a TCP backend on localhost because that way I can just build a beautiful UI in HTML/JS/CSS and I don't have to deal with the mess that is GTK, QT, TCL, TK, and all that crap.
I suspect this has more to do with the state of native Linux development tools versus Javascript dev tools then it has to do with the general case. Dev tools for Windows and iOS/ MacOs are fairly straight forward. Not sure about Android, since my burning hatred of Java has removed my desire to mess with that platform entirely. (I know Kotlin exists, still not interested)
Update: I'm basing my comment of what it's like based on the quoted comment, not making an assertion about how good/ bad it is.
8 replies →
Why not just use GTK or Qt?
2 replies →
What is the problem if the user give the permission to do so?
I don't get this let's not allow this web api because it's dangerous, well you only move the problem to an application that the user installs on his PC.
If the permission mechanism is correct there is no danger, a web applcation wants to access my MIDI interface or my USB or Bluetooth or whatever and it can. Isn't the same for mobile applications and permission?
So maybe and I say maybe we could stop having to ship an entire Chromium engine with Elecron just for a web application to access devices or files on the computer.
Because people don't expect their web browser to be able to brick their hardware.
Then change the expectations. Native apps aren't much better as far as privacy goes. Users should absolutely verify everything they use.
5 replies →
Not only brick the attached device, but also potentially fully compromise either the attached device or the device you are on. It doesn't seem responsible to put that kind of tis behind a permission dialog. Users are not in a position to make the judgment. The web should have a higher standard of security and privacy.
Because users are users and they win inevitably do the wrong thing. Normally not such a big deal, but with the interconnected world a compromised user is a big problem. It's used as a stepping stone to compromise others, cause problems to other systems by using them as slaves in a botnet or simply using them to send spam.
Users need to be protected against themselves as long as they can't take responsibility for their actions.
If the user is going to be tricked on the web, they can be tricked in other ways. If the web doesn't support MIDI, users will just download MIDI malware as an app.
By your logic, the web should not have video support either, because users are users and it will inevitably be misused.
If you were serious about addressing this: We need clear and robust and granular permission dialogs on web and native apps. Ideally they'd be consistent across web/native, which would help users trust their software, and understand the permissions they give.
2 replies →
One point not discussed here is by relying so much on app store and apple's walled garden, what do you do when china or other country ask apple to remove certain apps?
Bypassing geo block on websites is easy and there isn't a single source of truth on the web like app store is for the users. Can apple explain why they took down apps on the request of china in HK and how do you think that will play out when no web apps can work reliably on apple devices?
Censorship is a huge problem for app stores. They censor anything sexual but sexuality is part of human nature. They censor anything politically charged but it's part of human nature too. I hope the anti trust fine plays out.
Apple can protect the privacy of people by making it harder for them to be vulnerable by choice. People here point towards stupid users when saying that a normal user won't be able to connect usb and enable a feature. Why can't the same happen with browsers or apps on ios? Why the $99 fee just to side load apps? Why the need for a mac?
Just admit it's for profit seeking reasons. Ads in your app store are a proof of that.
It's still possible to partially implement it while keeping it safe by excluding sysex messages. Probably more than 90% of the end users will never need sysex messages so why bother?
> so why bother?
maybe 10% is enticing for those who create botnets
I’m pretty sure GP meant why bother implementing sysex messages.
Personally, I think that’s the solution. Provide access to the most common and safe features while disallowing the unsafe one. You’d still get far more functionality than you have now and only sacrifice a little in exchange for safety (vs not having any at all).
1 reply →
I'm curious now that I read this, this means that web midi can access the virtual midi devices created under alsa on linux also? Which means if you have it routed to other software using Jack or aconnect, websites could send midi notes directly into whatever software your midi device is routed through?
So theoretically then, could a Jack aware payload be created that runs in the background, say disguised as a vst or ladspa plugin and when a user browses a malicious site, this site could, recognize the malicious midi device, create connections to other software and gain access through possible buffer overflows or other things?
It seems like a stream of midi notes could itself possibly cause a buffer overflow in certain programs. Muse and rosegarden are a bit buggy as is and frequently crash for me. From what i can tell there's a lot of midi aware audio software that likely contains a bunch of avenues for exploits and when you throw virtual midi devices into the mix capable of doing far more than hardware midi devices...
Why not just limit allowed midi status to: Note On, Note Off, CC, Aftertouch, and Pitch Bend? Or maybe be readonly?
Is there a way to escalate that I'm not seeing? AFAI remember, all programming is done through status messages 11110000 and above.
https://www.midi.org/specifications-old/item/table-2-expande...
Full Disclosure: I made a web synth and really want to be able to use midi to play with it.
I don't see why the API should even allow enumerating devices. Put that behind a browser dialog. Webpages don't get to enumerate directories/files on your system - they pop up a file picker dialog. The same should happen with device selection. Once you've granted the site access to a device, it can ask you to associate a name with the handle, and provide whatever shiny device selection / device management UI it wants.
Better yet, reasonably abstract the raw MIDI protocol away with something that has suitable security and privacy properties for the web, and translate it to MIDI on the host. In any case, the current proposal does not seem to cut it.
I agree that it would be nice to have a limited amount of the Web MIDI spec, but bear in mind the staggering few people who actually have MIDI devices, and the even more staggering few of those people who want to use whatever website has midi support for its features.
To answer your question about why not to just limit the API: because that would be another data point to use to fingerprint users, and because the amount of engineering time that would have to go into Web MIDI support (including testing, security auditing, etc.) would never be worthwhile compared to putting those same developers on something that might be beneficial to vastly more users.
(Also note that Firefox made the same decision to implement nothing at all.)
This is just a philosophical standpoint, but I think supporting the interests a small group of experimental pioneers is generally more useful than their numbers would imply.
The idea that "staggering few" is a negative disappoints, given it has almost always been the "staggering few" who've progressed humanity.
Yeah. It's crazy to me that they haven't decided to create some abstract virtual midi instrument. That you can instruct the browser to pass through to your devices.
Exactly. Apple can choose to implement what they consider to be a safe interface for WebMIDI. Instead, they refuse all of it?
In my opinion, Apple has an incentive to keep the web crippled in some aspects, and this is just another symptom of that deeper underlying cause.
Well, I guess if I ever need WebMIDI features, I'll put a banner for Safari users to switch to Firefox.
(Or.. Maybe Firefox on iOS is forced to use the same engine as Safari..?)
It's a shame, but it proves just what a futile affair it is to retrofit ancient protocols that never had to consider host security. Especially because MIDI is so elegantly simple!
Sending binary firmware updates (sysex) is not a necessary part of the API... they don't have to implement that, and if they do, they can ask for additional permissions.
Allowing you to use a keyboard as an input device is incredibly powerful, and even that can be handled much as camera and microphone is: you give the site permission.
If you get the MIDI device to act as a keyboard it’s not for typing things in the browser but in the OS... you are out of the sandbox so it’s possible to download and install any payload.
I don't understand what you mean. We're talking about a piano keyboard by the way, not a typing keyboard. The browser uses it via the MIDIAccess API, and simply sets up a callback for MIDI codes, such as noteOn, noteOff, etc. I have used it extensively.
The alternative is that users download executable to apply firmware updates. Then the attacker doesn't even need to find a hardware vulnerability!