It's an issue even without WebUSB because plugging in a USB device doesn't mean you completely trust that computer. Users will also happily install an application. It's not much harder to download and install an application compared to selecting a USB device for a site to access.
Conversation
For devices not explicitly designed for WebUSB, it could show a scary, generic explanation of what access can provide. For devices designed for it, they could provide their own explanation with the semantics they've implemented. I think that'd be a good approach for it.
1
2
The only real issue that I see is users have a much better collective knowledge about what installing an application provides vs. what granting access to a USB device provides. It's missing a nice 1 sentence + bullet point explanation of what granting access is going to provide.
2
2
I meant the other way around here: websites could trivially abuse any FX2 they have WebUSB access for to reprogram it into HID. it's simple enough for script kiddies (do people still even use that term)
3
5
so I would have perhaps liked to expose Glasgow via WebUSB but I cannot in good faith advertise that because of how trivial it is to abuse
2
5
I will say this is a general problem of trust. Most people already implicitly trust the version of adb or openocd without verifying the code, yet each of those programs could do similar things.
I will agree that it easy harder to verify the code that gets run via the web.
1
1
this problem isn't theoretical--I believe that there have been instances of "user-friendly" fastboot with a malicious implant caught in the wild already
2
1
And that just goes to show you how danger normal downloads are that people are already not verifying the code (or where they got it from).
1
Out of the 5 operating systems we officially support, only Arch Linux gives users a working fastboot and signify package. Debian and Ubuntu have broken packages for all the Android SDK stuff. They made their own build system, use their own versioning and don't use the right tags.
1
1
2
On Arch, users are told to do `pacman -S android-tools signify`, download the release and verify it with our signify key. Links are given for confirming the public key across several locations. In theory, it should work that way on Debian and Ubuntu, but their fastboot is broken.
1
They also have some ancient signify script made by a Debian developer 20 years ago so the ed25519 signature tool is called signify-openbsd, which, by the way, is not actually the OpenBSD signify codebase but rather the portable fork from github.com/aperezdc/signi. It's annoying.
The signify script they ship didn't even have a real upstream. In theory, signify.sourceforge.net was the upstream project, but the developer was the Debian package maintainer. Last release via sourceforge was 1.11 but Debian has 1.14 because they made releases via the package.
1
2
Either way, it's some obscure script that hasn't had an update for 16 years and it makes it harder for Debian users to use signify. They install the wrong package and then they get a confusing error when it rejects the arguments because it's some quirky script for email footers.
1
3
Show replies