Key takeaway:

> And the existence of WebUSB, WebHID, and WebBluetooth mean that for some devices, depending on the specifics of which classes are used, a moment of user indiscretion in accepting a permissions prompt could permanently backdoor one of their attached devices.

▲

_kb 2 hours ago | parent | next [-]

The preceding sentence is equally prescient:

> Operating systems aren’t really equipped to work with the user to ensure that a microphone stays a microphone, and doesn’t spontaneously turn into a keyboard that hits Win+R and drops a payload to steal all your data when the room is quiet enough that it can assume you aren’t watching.

In a world of USB-C everything we no longer have power supplies that are physically bound to power delivery, HDMI or DP display connections that have constrained data channels, or analogue mics, headphones, and speakers. Any device can dynamically change what it senses, does, or emits.

▲

SchemaLoad 3 hours ago | parent | prev | next [-]

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.

▲

AshamedCaptain 3 hours ago | parent [-]

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/

▲

qlte 2 hours ago | parent [-]

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.

▲

SchemaLoad 2 hours ago | parent | next [-]

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.

	▲	Barbing 8 minutes ago \| parent [-]
		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.

▲

AshamedCaptain 2 hours ago | parent | prev [-]

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.

▲

NavinF 2 hours ago | parent [-]

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.

	▲	AshamedCaptain an hour ago \| parent [-]
		Look, I find it funny that I find myself arguing on the other side of the discussion that I'm frequently on, but here is where I draw the line, and I think what is ridiculous is to think otherwise. How many hoops Google asks you to go to install an Android app ? (Androids amounts to basically the most sandboxed environment one can have today; malware installed there can practically do _nothing_) MANY. Centralized register of apps and remote blacklisting, a lot of permission prompts, password check, and they are even literally pushing to even have a physical 24h cool-off period if you skip the centralized register. How many hoops does Google ask you to go an allow a random website unfettered access to destroy your hardware? One. Permission. Prompt. In a bubble prompt, that barely registers above noise compared to other permission prompts browsers ask. Of course these are two ridiculous extremes, but they exemplify the point. There is a reason a browser won't allow a random website to write over random sectors of your hard disk just because you said "accept" to a bubble-style permission prompt about wanting to "save files to your hard disk". The line has to be drawn somewhere, and allowing what basically amounts to raw access to IO ports just after a single permission prompt listing the device name is where I draw it. Any user, even knowledgeable ones, is simply going to be _incapable_ of truly understanding the risks behind allowing this access. I would be much more in favor of allowing random IPC to services in your local computer (after a permission prompt) than this., something that is equally useful if not more than allow raw access to HID. Devices need to be hidden behind drivers that multiplex and control access to the device at the OS level. A bus that was never meant to be exposed to user-level access should not be exposed to random programs much less websites. This is not security, this is "mistake prevention" level, in the same way operating systems disallow a random user-level program from overwriting the hard disk. And do not read this as "devices should sign their firmwares and what not". That is (for me) definitely the wrong take but literally the only take that is left on the table due to Google's stupid behavior.

▲

pudgywalsh 3 hours ago | parent | prev [-]

The key takeaway for me was he bought a $300 microphone and is acting indignant that he has full access to his own hardware via — gasp — a command shell.

Do we live in a bizarro world now where we expect — no, demand — our hardware be locked down?

It's worth mentioning all USB mics are toys anyway. Analog interfaces have gone away — artificially so — now they cram them into the device.

All mics are analog.

	▲	3 hours ago \| parent [-]
		[deleted]