dumb question, do you know how Chrome handles elevation for WebUSB? is it once only, once per origin, silently handled by a privileged helper, or just not done at all?
Conversation
Replying to
I've never used WebUSB with Chrome on Windows but lemme just spin up a VM because I conveniently have a WebUSB native device on my desk
1
1
As far as I can tell, it uses the normal drivers for devices instead of a special one for WebUSB, so you need a working driver for it.
1
1
which makes sense really, it would be pretty concerning if it started elevating itself and self-signing INFs
1
1
It also means it depends on installing the same fastboot udev rules as usual on Linux which annoys me. I had to add that back to grapheneos.org/install/web since I'd deleted it when I copied the CLI installation guide there expecting that it wasn't going to be needed.
2
1
it would be *much* more concerning if it had a SUID binary that can talk to udev.
1
Yeah, but originally I expected that WebUSB was a special thing that would use a generic WebUSB driver. I didn't realize it was just normal USB.
2
1
For common USB devices, the udev rules already exist. It's actually quite annoying that it's not more generic. I don't really understand the point of someone having to maintain github.com/M0Rf30/android in order to authorize local users (users physically at a session) to use it.
1
1
The only reason the Debian package with the udev rules works for current Pixels despite being so out-of-date is that they've kept using the same ids from Nexus devices:
github.com/M0Rf30/android
It wouldn't work well for most other brands of devices.
1
2
Needing to teach people to put a file in /etc/udev/rules.d/ is a pretty bad usability issue. It really doesn't make any sense. Needing to authorize a sandboxed app to use a device actually makes sense. The user themselves should be able to use local USB devices... sigh.
are there any USB devices that would be unwise to expose to anyone in `plugdev`?
2
I don't really think it ever makes sense to disallow a user at a physical session from accessing USB devices. Disallowing apps from doing it without authorization actually makes sense but it's not what they're doing.
2
Show replies