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
something really does rub me the wrong way about "simple"-seeming Danger Buttons
like the single, boring-seeming prompt in Android that grants *raw APDU-level access to your phone's SIM* to a paired Bluetooth device
1
12
Sure, we need security UX experts to make sure it's being adequately communicated. The answer isn't "Just make them install an EXE, then it's not our problem"!
2
8
The first step to understanding whether the UX is correct is to survey the current non-malicious uses of WebUSB and understand whether to support each use case, whether a different API should be exposed for it instead, and whether users can navigate the UI to stop harmful uses.
2
1
So, what about this use case?
twitter.com/GrapheneOS/sta
In theory, the browser could have a fastboot API and could explicitly hard-wire a list of devices with a proper OEM unlocking toggle, user confirmation for `fastboot unlock` and verified boot. Can't really see it happening.
Quote Tweet
An experimental version of our web-based installer for GrapheneOS is now available:
grapheneos.org/install/web
This can be used from browsers with WebUSB support. Most Chromium-based browsers are supported including Chrome, Edge and Brave. No need to run any additional software.
Show this thread
1
Updating firmware on other kinds of USB devices seems like a legitimate use case. It would be pretty cool if I could go the Logitech website and update the firmware for my mouse on an arbitrary OS rather than installing their software on Windows. What if I don't have Windows?
What if I don't want to install / run Logitech's sketchy software on my Windows installation? By the way, I really don't want to do that. That means I don't update the firmware on my wireless mouse. That seems like a bad thing. I would assume there are security updates for it.
2
1
I guess I could install Windows in a VM, forward the USB device to it, install the Logitech bloatware and update my mouse that way. I'd prefer going to their site and installing the firmware from there, and trusting the combination of their site + firmware signature verification.
1
Show replies