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.
Conversation
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
Right. There should be a standard for firmware update over USB (and Bluetooth, etc.) where there can be an OTS (and open source) solution on the device side that takes into consideration that device makers probably aren’t going to spend much engineering time or BoM to secure it.
2
if the device runs on something like a 8051, there is very little you can do to secure it to the bar we have for hosted software. the most optimized implementation of ChaCha20 I could come up with for nRF24LE1 is practically worthless
1
1
That’s encryption. What is probably needed is signature verification. Signature verification is expensive but could be mostly offloaded to the host using techniques from verifiable third-party computation. I hope to demonstrate this when I have time to show a demo.
2
1
Is sha256 + ed25519 really that expensive for this kind of hardware?
modern low-end (think Cortex-M0) devices might not be able to do it for normal communication but they can definitely check firmware signatures.
on old low-end (think 8051) devices, even md5 is a lot to ask. I think sha256+ed25519 on nRF24LE1 might take half the flash.
2
3
I don't quite remember it in detail but they also were so low on RAM that buffering an entire flash page *and* keeping a state of a signature algorithm required carefully picking the latter.
1