Comment by AshamedCaptain
1 day ago
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?
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.
This is untrue. Chrome's "acceptance rates" for proceeding through its bad SSL cert warnings used to be pretty high, but with a redesign they basically flipped the numbers so most people didn't proceed to connect to the site. Similarly with cookie banners, where making it more difficult to say no (by e.g. moving a decline button to a second interaction layer) meaningfully raises acceptance rates; if users were just blindly accepting everything, then there'd be no reason to make it harder to say no. Apple's App Tracking Transparency (ATT) prompt has users overwhelmingly answering no even years after introduction (though of course opt-in is increasing). A study on permission prompts in Android found that the main factor in first-use denial rates was whether users thought the app needed the permission it was requesting or not, showing some actual comprehension of what they're being asked. Another found higher denial rates if the frequency of the prompt was on every access instead of once, rather than apathetic blanket acceptance.
Design prompts for potentially dangerous actions so refusal is easy and what's being asked is legible, and people will refuse plenty.
I think Safari does this with popups & downloads. Tiny little icons that barely appear [to change]. Can annoy me when I miss them but sometimes I figure maybe it’s for The Greater Good.
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.
WebUSB has been live in Chrome for 9 years and nothing happened. Compare to all the features that result in people getting hacked every day. Your threat model is ridiculous.
2 replies →