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
now that I re-read what I wrote above it sounds way more pessimistic than I intended, so let me clarify that:
Quote Tweet
Replying to @taviso @analogist_net and @XMPPwocky
yes. I agree that it's often far better, too. I just think it doesn't go far enough!
basically, I want WebUSB to be more like WebAssembly: not only merely isolate previously privileged code, but advance state of the art beyond that, like WASI does with the ObjCap stuff
1
21
Replying to
dumb question, do you know how Chrome handles elevation for WebUSB? is it once only, once per origin, silently handled by a privileged helper, or just not done at all?
2
Replying to
I've never used WebUSB with Chrome on Windows but lemme just spin up a VM because I conveniently have a WebUSB native device on my desk
1
1
As far as I can tell, it uses the normal drivers for devices instead of a special one for WebUSB, so you need a working driver for it.
1
1
which makes sense really, it would be pretty concerning if it started elevating itself and self-signing INFs
1
1
It also means it depends on installing the same fastboot udev rules as usual on Linux which annoys me. I had to add that back to grapheneos.org/install/web since I'd deleted it when I copied the CLI installation guide there expecting that it wasn't going to be needed.
2
1
it would be *much* more concerning if it had a SUID binary that can talk to udev.
1
Yeah, but originally I expected that WebUSB was a special thing that would use a generic WebUSB driver. I didn't realize it was just normal USB.
For common USB devices, the udev rules already exist. It's actually quite annoying that it's not more generic. I don't really understand the point of someone having to maintain github.com/M0Rf30/android in order to authorize local users (users physically at a session) to use it.
1
1
The only reason the Debian package with the udev rules works for current Pixels despite being so out-of-date is that they've kept using the same ids from Nexus devices:
github.com/M0Rf30/android
It wouldn't work well for most other brands of devices.
1
2
Show replies
it looks like their early plans included that and then the API got progressively more, I almost want to say "aimless". the "security" section in the current draft is just insulting
1
1
not only is the proposed solution to reflashing attacks is "just sign firmware" but they do not mention ROM bootloaders at all. which is a conspicuous omission, the Twinkie WebUSB frontend has a flasher that uses ST's DFU bootloader which cannot check signatures.
1