I recently flashed GrapheneOS on a Pixel for a friend. I was very surprised that you can do this entire process from the browser using WebUSB - the only downside being that it required me to launch Chromium.
I recently flashed GrapheneOS on a Pixel for a friend. I was very surprised that you can do this entire process from the browser using WebUSB - the only downside being that it required me to launch Chromium.
You can flash GrapheneOS on a Pixel from another pixel, no pc required at all. I've done it several times, this is what sold me on the utility of WebUSB. You can use GOS' own distribution of chromium, Vanadium, if you have a GOS device and you want to avoid Chrome.
Is there something specific in that process that required WebUSB vs just normal USB? Sounds like phone makers could have done this since forever if they wanted to, what makes WebUSB particularly useful for this?
Native android apps can talk to regular USB devices, if granted the necessary permissions. But it's exposed through a Java api (and Kotlin I suppose, these days), which is fine, but it means you need to write your client logic twice. If you target the web, you can do it once.
(Yes, you could try to bulid some common interface, libusb-style, but I think you'll have a bad time with minor behavioural differences. libusb itself does ostensibly support Android but there are several caveats: https://github.com/libusb/libusb/wiki/Android#does-libusb-su... )
Web USB and Web Bluetooth are amazing. I've used the former for the excellent Web MiniDisc [1], and the latter to flash custom firmware [2] on cheap Xiaomi Bluetooth LE thermometer/hygrometer devices that Home Assistant can pick up.
Truly opening new possibilities, since I wouldn't have been comfortable running some sketchy script or local binary.
[1] https://web.minidisc.wiki/ [2] https://github.com/pvvx/ATC_MiThermometer
> Web USB and Web Bluetooth are amazing.
Comments like this scare me. Things look amazing when people with benevolent intentions are making interesting things, but as soon as someone with malevolent intentions does something that becomes the reason we can't have nice things people will start asking if this is something we should have actually done.
I just have no faith in humanity, and do not understand why we think this is a good idea to give a browser this much access to local system resources.
> Comments like this scare me.
Sorry to hear that. I thought this was a safe space for hackers to express enthusiasm about pushing their own hardware and software further (and in this case even in a comparatively safe way).
> I just have no faith in humanity, and do not understand why we think this is a good idea to give a browser this much access to local system resources.
The browser already has all that access, it's just further granting it to web apps, and on a page-by-page, device-by-device, explicitly user opt-in basis at that.
And as I've mentioned, the alternative here is to install a potentially untrusted native application that gets the same access and so much more.
If that's what the Github page tells users to do, many of them will just do it without thinking twice. Is that better?
> I thought this was a safe space for hackers to express enthusiasm about pushing their own hardware and software further (and in this case even in a comparatively safe way).
Nothing is preventing said experimentation nor discussion of it. I am merely offering my more conservative views of the situation as a contrast to the echo chamber gungho nature of the experimentation. Just because we can doesn't mean we should is often left out of the conversation. At some point, the net negative that comes from the use of something "cool" is never contemplated by those creating the something "cool" simply because they would never fathom using the "cool" for "uncool" purposes. Sadly, someone else will and weaponize it in an uncontrollable manner. If the creators can't think of how it can happen, it is vital that those not so involved in the creation speak up when there are potential issues.
What if we implement them but hide them deep in the settings or as experimental feature inside the hidden developer menu, behind multiple warning messages and password prompts? Only the very determined developers and advanced users would be able to unlock them. Then it's safe enough?
Users will unfortunately click on absolutely anything that a trusted (deservedly or otherwise) source tells them to, and you won’t be able to reliable convince them otherwise with UX alone. This includes all “developers only”, “click 5 times” etc. UX interventions.
You have to decide whether the feature warrants the remaining risk after all mitigations, or at least exceeds other, simpler attack vectors.
I think in this case it does, but it’s not an easy decision and I can understand most opposing positions as well.
I've used Firefox successfully twice. I have nextdns on my router, not sure if that helped.