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
It's an issue even without WebUSB because plugging in a USB device doesn't mean you completely trust that computer. Users will also happily install an application. It's not much harder to download and install an application compared to selecting a USB device for a site to access.
1
5
For devices not explicitly designed for WebUSB, it could show a scary, generic explanation of what access can provide. For devices designed for it, they could provide their own explanation with the semantics they've implemented. I think that'd be a good approach for it.
1
2
The only real issue that I see is users have a much better collective knowledge about what installing an application provides vs. what granting access to a USB device provides. It's missing a nice 1 sentence + bullet point explanation of what granting access is going to provide.
2
2
I meant the other way around here: websites could trivially abuse any FX2 they have WebUSB access for to reprogram it into HID. it's simple enough for script kiddies (do people still even use that term)
3
5
so I would have perhaps liked to expose Glasgow via WebUSB but I cannot in good faith advertise that because of how trivial it is to abuse
2
5
For a Pixel, you can brick the device but you can't install arbitrary firmware that's not correctly signed. You can install an arbitrary OS but the device informs the user each boot that the device is unlocked + not verifying or locked + verifying with a custom verified boot key.
yep, done that quite a few times while learning how dm-verity works!
So, it's not like you can actually reprogram it in a stealthy way without exploiting something with insignificant attack surface compared to the APIs a web browser already provides. The user also has to have enabled OEM unlocking in the OS and has to confirm the unlock command.