Conversation

Replying to

now that I re-read what I wrote above it sounds way more pessimistic than I intended, so let me clarify that:

Quote Tweet

Jan 24, 2021

Replying to @taviso @analogist_net and @XMPPwocky

yes. I agree that it's often far better, too. I just think it doesn't go far enough! basically, I want WebUSB to be more like WebAssembly: not only merely isolate previously privileged code, but advance state of the art beyond that, like WASI does with the ObjCap stuff

Replying to

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?

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

Replying to

and

... it... doesn't work on Windows

Replying to

and

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.

Replying to

and

which makes sense really, it would be pretty concerning if it started elevating itself and self-signing INFs

Replying to

and

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.

grapheneos.org

GrapheneOS web installer

Web-based installer for GrapheneOS, a security and privacy focused mobile OS with Android app compatibility.

Replying to

and

it would be *much* more concerning if it had a SUID binary that can talk to udev.

Replying to

and

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.

Replying to

and

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.

github.com

GitHub - M0Rf30/android-udev-rules: Android udev rules list aimed to be the most comprehensive on...

Android udev rules list aimed to be the most comprehensive on the net - GitHub - M0Rf30/android-udev-rules: Android udev rules list aimed to be the most comprehensive on the net

Replying to

and

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.

github.com

android-udev-rules/51-android.rules at main · M0Rf30/android-udev-rules

Android udev rules list aimed to be the most comprehensive on the net - android-udev-rules/51-android.rules at main · M0Rf30/android-udev-rules

4:02 AM · Jan 25, 2021Twitter Web App

Replying to

and

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.

Replying to

and

are there any USB devices that would be unwise to expose to anyone in `plugdev`?

Show replies