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.
Conversation
(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
The problem is you're asking "is WebUSB safer than nothing?", but that's not fair, of course nothing is safer, but using nothing is not an option. The alternative is to run an exe you found on a website. Malware *definitely* is a problem, and we have no good answers.
1
1
I think you are misunderstanding what I wrote, based on how different than summary is from what I wrote. Unless you are saying we shouldn’t try to build safer APIs and safer UX for anything WebUSB can do because WebUSB already exists.
1
1
I'm saying we shouldn't limit what WebUSB can do to devices. If vendors are restricted so they can't access any data on the device, then why wouldn't they say "We don't support WebUSB, use the EXE"? There littel benefit to them of WebUSB, most of the benefit is for the user.
1
“Do whatever you want to my USB device” doesn’t seem much better than “Do whatever you want to my computer.” If the USB device can control the PC and the PC can control the USB device, then they are effectively one system and the effect is pretty much the same.
2
2
It should tell you what you're permitting by having the device provide a simple explanation to show the user with a simple list of capabilities.
The issue of devices having vulnerabilities and not working as intended also applies to things like WebGL.
Also not only a web issue.
If the user plugs their USB flash drive into someone's laptop and it's reprogrammed into an HID device which subsequently takes over their own computer, I think that's a pretty big problem. USB devices need to do better, as do operating systems. It's an existing security problem.
2
3
Here's the issue with Firefox simply saying no to WebUSB: users are still going to do it by installing an application. That application might be Chrome. Main GrapheneOS install guide is going to be telling people that they need to switch browsers. Users will do what they have to.
2
1
Show replies