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 🤷♂️
Conversation
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.
1
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.
And that's why we consider providing this important: we need to stop people from installing sketchy software and following sketchy third party guides. WebUSB is actually a really good way for us to do this, and whatever problems it has aren't really relevant to our use case.
1
2
Every user on Windows 10 starts out with Microsoft Edge and can now use that to install GrapheneOS. It can also now be installed on ChromeOS. It's quite possible you can even flash GrapheneOS from another GrapheneOS device now. I haven't tried that to see if it that can work.
2
There have been make cases where Firefox said no and the result turned out better than what was originally proposed. Unauthenticated TLS for HTTP/2 was one I was directly involved in. Pepper plugin API is another; WebAssembly is the result of Firefox saying no.
3
3
Kinda feel like the difference for both of those was "no, but...", and work continued.
The hardware access talk usually ended in "no". Some of that was Moz not having the resources to discuss otherwise, and it was post FirefoxOS, so there wasn't as much of a value prop.
2