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
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.
1
5
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
(I don't remember the details but I think that was opportunism, and of course a security/privacy focused project like GrapheneOS would attract people who are more intentional..)
1
We've been getting very concerned about all the unofficial guides for installing GrapheneOS, particularly since a lot of them have been recommending that people use sketchy third party fastboot releases and Windows drivers (even though Windows Update provides the driver for you).
For some reason, Windows often automatically has a working driver, but some people need to go into Windows Update and manually install an optional update providing the fastboot driver. It doesn't help that Windows ends up considering it some arbitrary smartphone brand driver.
2
4
Google tells people to install the driver from their site, but they actually don't need to do that. When people come to our channel with this issue, we get them to install it with Windows Update. As far as I know, some users will still need that for the web-based installer.
1
2
Show replies