Comment by SchemaLoad
1 day ago
This is why most of the browsers rejected these specs. They are super useful, but the security risks are incredible. Most USB devices were not designed to hold up to being exposed to the internet.
1 day ago
This is why most of the browsers rejected these specs. They are super useful, but the security risks are incredible. Most USB devices were not designed to hold up to being exposed to the internet.
I kinda remember that the counterargument Google used is that only devices with a special attribute would ever be available through WebHID, ensuring that such older devices would never be exposed.
Cue my surprise when it turns out you can use WebHID to program a Minidisc / Net-MD device [1], so.. they never did implement that filter, apparently. I mean, certainly it is useful, but ... What The F., Google?
[1] https://web.minidisc.wiki/
The user has to first specifically pick the device from the list and grant the website access. If a user is confused by a permissions prompt and has no idea what is going on, the default path is to reject the permission.
In the real world the default action for a user when presented with a permissions popup is to accept it because they get asked 20 times a day, have no idea what the implications of it are and just want to get on with their day.
So software designers need to avoid asking the users to approve potentially highly dangerous things.
2 replies →
WebHID being used to access a microphone is risky though. Microphones are already often exposed to web browsers, so asking for microphone access wouldn't be out of the ordinary.
Maybe MD drives aren't really at risk, but things like HID peripherals definitely are.
You realize that most of the time that you are giving access to an older HID device, you are giving the website permission to convert that device into a persistent backdoor forever? No matter if you later close the browser or revoke the permission -- the damage has already been done? Most devices predating WebHID and the like have almost no protection (why would they?), and you can corrupt or even entirely replace the firmware quite easily. heck, NetMD is one example (the browser can overwrite its firmware with no trouble!), as are the devices listed in TFA .
It is basically the same reason most desktops do not give the logged in user access to /dev/hidraw*, even though it makes a shitton of sense and would simplify many things greatly.
This is one of the few areas where I think Mozilla did the right thing without question.
3 replies →
Note that when you say “rejected”, Mozilla’s position has actually shifted a bit. At the end of 2022, it shipped MIDI in the form of an extension that it will prompt to install for the purpose, with more detailed information and a couple of other details that make it less unsafe. After a few years of that, consensus has grown that this seems to be working acceptably, and that the technique may be considered for other risky areas. They haven’t said anything about USB publicly, to my knowledge, which is definitely way more dangerous than MIDI (even SysEx), but I have heard one rumour (of dubious provenance) that they may cautiously proceed with USB and such too some time soon. Though this sort of thing definitely weighs against that, showing that maybe they were right the first time.