it's beneficial because flashing is hard and most people rightfully don't want learn how fastboot, adb, etc work, and seek out convenience. they'll find it either with the first party, GrapheneOS, or a potentially malicious or negligent third party.
here, WebUSB is harm reduction
Conversation
I'm not sure if WebUSB could have been designed in a way that makes harm negligible. I know that it could have been designed to minimize potential harm, and it clearly wasn't (Chrome just lets you do ~anything to ~any device), and I find that unfortunate.
3
5
59
Replying to
If I remember correctly, There was originally supposed to be a marker value in usb descriptors to say whether a device was fit for webusb. That got tossed out early.
1
6
I don't think there's much point in that. The issue isn't really that granting access to devices can be harmful but that there's no explanation of what access provides. Granting access to fastboot after enabling OEM unlocking can clearly be used maliciously, but it's very useful.
2
11
(I think there needs to be some sort of request whitelist, because without one you'll be able to flip all sorts of random junk built on popular ICs into DFU mode and wreak havoc.)
2
10
The counterargument would be that right now, users are told to download a driver and run it as Administrator, giving it access to not just the device - but literally everything forever. With WebUSB, access can be limited to a device you choose. I think it's great 🤷♂️
6
1
25
Why would the downloaded executable require driver install and UAC prompt when web browser with WebUSB would not? I’d rather see the OS corrected to handle the security properly than making the web browser a gatekeeper to your devices.
2
On an OS like Android with an actual application security model, the OS does get to act as a gatekeeper for WebUSB. The web browser can't simply access the USB device without being granted the access so the OS is involved in permitting access to the device.
1
Permitting the site to access the USB device vs. downloading and installing an app via the site (whether or not it comes from the app store) and granting that access to the device isn't much different. Native app MAY have the advantage of updates signed with offline signing key.
1
If the app store controls your signing key, which is mandatory for Apple's store and encouraged by Google's store, it's an online signing key usable by their centralized servers arbitrarily. Also, the web *could* support signed application delivery rather than just TLS.
1
In fact, there's a standard for that, and it's another one where Mozilla's possible is that it's harmful so they don't implement it.
GrapheneOS also DANE TLSA records for all our TLS services pinning our public keys. Browsers choose not to check it. It's there to use though.