Comment by Rohansi
13 hours ago
> Wanting a website to access your USB stack directly (or Bluetooth, which has a similar standard) is such an extremely niche use case that it’s probably better for it to be available only as an opt-in extension.
It doesn't give direct access. You go through the browser which restricts what you can use it to touch (eg. can't access USB drives). The user also needs to choose which USB device to allow access to before you can do anything.
> More of the enormous bloated JS web API specs should be implemented as browser plugins.
Then you'll get one of two outcomes: 1. Users install extensions without caring about what they do. I don't see why we should train people to install more extensions when there are already a lot of malicious extensions! 2. Hardware manufacturers decide to not adopt these standards and continue shipping executables for everything, which are not sandboxed at all and don't support all platforms
I think there is still a problem.
Let me give a concrete example. Hardware "passkeys" - FIDO2 authenticators - are designed such that their credentials are bound to a particular Relying Party (web site). Browsers enforce this by sending the current web domain the user is on to the authenticator when Javascript tries to list, create, or use a credential.
This would be completely broken if Javascript talked directory to a FIDO2 USB device, because the JS could send a Relying Party that is NOT the web site on which the user currently lands.
So Chrome blocks WebUSB from communicating with USB devices whose USB HID descriptor "looks like" a FIDO one, by some hardcoded "not this device" blacklist code in Chrome itself.
But what if what you have connected to your computer is a USB NFC card reader, and the user taps their FIDO authenticator on that? Letting the Javascript communicate directly with the card reader breaks the FIDO security model exactly the same way... but Chrome allows it!
The problem with WebUSB is that it exposes devices that were built under the threat model that only trusted code would be able to access them to untrusted code. The set of devices acceptable for WebUSB use should have been a whitelist instead of a blacklist to be secure. Letting the user choose the device to grant access doesn't solve the problem, because the user doesn't have a way to understand what will happen when the site is granted access, per the FIDO example I gave above.
> But what if what you have connected to your computer is a USB NFC card reader, and the user taps their FIDO authenticator on that?
So the user would need to: 1. Keep the malicious page open, or install a malicious extension 2. Grant access to the card reader from a list of USB devices 3. Then tap their card on that reader
IMO a bad actor is going to have more success getting people to run an executable they made the browser download. There's only so much you can do to protect people from themselves. Not everyone needs software to be locked down like a padded room.
> The problem with WebUSB is that it exposes devices that were built under the threat model that only trusted code would be able to access them to untrusted code.
Which platforms have USB devices locked down to "trusted code" only?