Right now that isn't the case and I can't remember last the time I had to uninstall untrustworthy native drivers.
A lot to lose, very little to gain?
What product categories exist where all entries only work (over USB) with native drivers?
but really most devices you want to interface to via webusb are CDC and DFU so.. problem solved?
It increases attack surface area on the browser. Even if you do need to "accept" a connection for a device, this isn't foolproof. I imagine adding WebUSB is a non-insignificant amount of code, who's to say there isn't a bug/exploit introduced there somewhere, or a bypass for accepting device connections?
This would still be better than downloading random native programs since it's under the browser's sandbox, but not everyone would _ever_ need to do something that requires WebUSB/USB, so this is just adding attack surface area for a feature only a small percentage of people would ever use.
The solution is to use a smaller separate _trusted_ native program instead of bloating the web with everything just for convenience. But I understand that most are proprietary.
I say all this, but a part of me does think it's pretty cool I can distribute a web-app to people and communicate via WebUSB without having the user go through the process of downloading a native app. I felt the same way when I made a page on my website using WebBluetooth to connect to my fitness watch and make a graph of my heart rate solely with HTML and Javascript (and no Electron).
I'm just not too happy about the implications. Or maybe I'm just a cynic, and this is all fine.
1. Permission popups fatigue
2. Usually users select the apps they install, most sites are ephemeral. And yes, even with apps, especially on Android, people click through permission dialogs without looking because they are often too broad and confusing. With expected results such as exfiltrating user data.
It has nothing to do with security, as WebUSB has no ability to interact with any device unless the user explicitly allows each and every website that requests access to do so. It's the same security as any other browser API that requests access.
This is untrue. Web standards need two independent implementations. Google can’t convince any other rendering engine besides their own to implement it.
It doesn't take a single no from Apple to veto it; it takes a single yes from anybody outside of Blink to move it forward. Nobody is doing that.
Here is what Mozilla have to say about WebUSB:
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
— https://mozilla.github.io/standards-positions/#webusb
Until Google can convince anybody outside of Blink to implement it, it is not a standard it’s a Blink-only API.
Even before WebUSB, I was using ZSA Oryx to create my keyboard layout for my first ZSA keyboard. But back then I had to download the file and then flash it using a dedicated program on the computer. Now with WebUSB I could both create the layout for my new ZSA keyboard there, and flash it from there without any additional software other than a Chromium based desktop web browser.
Still not quite WebUSB-easy, but a massive improvement over needing dedicated programming software!
I'm not even criticizing ZMK, btw, this is just an unbelievably obnoxious workflow. Please, nobody do this. The anger is short-circuiting my brain.
I have many expensive USB devices (cameras, musical instruments, audio and MIDI interfaces, a spectrometer) that are still useful despite being over a decade old; most will remain useful until the hardware fails. It'd be a shame if they required a long-lost web app to configure or control.
Hope you enjoy that same sentiment is 20 years when the website to control/manage your device doesn't exist/was bought out/whatever.
So, basically, you got seduced to loosen up your ideology a bit. You’re not alone. I likely would, too. What I would like to see instead of WebUSB is something akin to SOAP (https://en.wikipedia.org/wiki/SOAP), but for USB, where device manufacturers provide a downloadable file that describes the interface of their device, and tools, including third party ones, can generate apps from those descriptions.
I think that would give us an easy way to talk to USB devices without having to rely on the forever presence and good intentions of a third party web service.
One thing that it wouldn’t allow is for a remote server to talk to a local USB device. That may be unfortunate for a few use cases, but I think overall that’s for the better.
One that’s been using Attestation, for bonus points.
Edit: Wait, no we didn't. Chrome added WebUSB support after all. Wtf I'm disabling that
The browser opens a popup asking you if you want to grant access to a specific device for a specific website, it's not like random websites can just run adb commands on your phone
To be honest I think that's the most compelling case for webUSB today. If desktop OSes had sandboxing tools (or more granular permissions in general) that are easily usable be everyday users, there would be no need to put webUSB in a browser sandbox. The cross-pltaform nature of it is nice, but that alone is not enough IMO. I think it would be interesting to see a Linux distribution where software that is not explicitly trusted (i.e. not installed by the system package manager) has no permissions by default. Interpreters make this more complicated but for binaries it could work.
I could understand it if you were trying to do realtime configuration of or interaction with some device like a printer or a Stream Deck, but something as trivial as firmware flashing?
It's making a niche rarely done use case safer at the cost of making the common case (browsing the web) less safe.
And yes, I am fully aware that I can not press the button that give random sites access... But the issue is it increases the attack surface and is yet another thing that I could get tricked by on a bad day.
The OS should really be able to run code like a firmware flash utility in a sandbox that only has access to one USB device... But instead of improving the OS we keep adding features to the browser which increases the attack surface.
I have a very long list of things I am unhappy about the OS allowing just any app to do, especially app installers/uninstallers should not be a thing.
Even for local apps it's starting to become common to ship the app in an interpreted language where the interpreter is a browser instead of say python & qt.
But please don't tell other people what they should and shouldn't do on their own hardware.
The world has enough corporate walled gardens. I even enjoy using some of them sometimes, but the world would be a strictly worse place if these were the only remaining way to use computers.
With WebUSB implemented in major browser, you can be sure that they took extraordinary attention to all security implications.
With some random application from tiny developer, can you be sure about that?
I know for sure, that I prefer a webpage isolated in the browser for anything that could be done in a browser. I'm very hesitant to install anything locally.
I can ship a cross-platform application that accesses a hardware device without having to deal with all the platform specifics, and with decent sandboxing of my driver.
I think one way to make it more "secure" against unwitting users would be to only support WebUSB for devices that have a WebUSB descriptor - would allow "origin" checking.
It was also nice trying out some RTL-SDR apps as soon as I got it without having to figure out how to build and install the Debian packages from source first.
It drives me nuts every time I have to switch from Firefox to Chrome to use webusb or webserial.
And you can also un-ship it whenever you want, leaving users with unusable devices they paid money for.
Whether we like the idea of the browser having access to usb or not, I at least like even less the idea of being forced to install and use Chrome for the same reasons as the bad old days of being forced to use IE.
The fact they have to be installed/uninstalled too is another inefficiency.
There are hundreds of browsers these days, you shouldn't have a hard time finding one that fits your needs.
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
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.
I've used WebUSB for flashing keyboard firmware and it's genuinely better than downloading random executables from GitHub.
The permission model is more transparent than a native app that silently gets full USB access.If I need to install a program, browser extension, just to work with a given tool, I probably would just prefer an ordinary program without browser at all.
Chrome approach is correct. It allows user to work with USB devices without exposing computer to the risks of installing a host software.
Idk. Sure it has security advantages, but that sounds like to much of a hassle for 90% of users.
I hope Mozilla can eventually stop playing their silly role in the security theater of “but what if our users are dumb” and actually deliver those "power-user" features that would allow me to uninstall Chrome for good. Oh, and also, --app= flag please.
That's good news. I wish FF wasn't so conservative... they're missing a lot of cool APIs. Sometimes I wonder who they think their audience is. I suppose they would know better than I would.
It's not security theater. If you go to Chromium settings -> Site settings -> permissions, and expand "additional permissions", you will see a total of 26 different permissions, each gated by the same generic "you want to use this" popup.
Permission popup fatigue is quite real, and not a security theater. And that's on top of the usual questions of implementation complexity etc.
Short of crippling capabilities to save dumb users, the best we can do is make the process scary enough that Grandma won't do it without calling her grandson first.
It's an incredibly useful API, and it's secure. You have to explicitly pick a device to give access to. Mozilla's attitude in refusing to natively implement it seems neither reasonable nor rational. Though that is unfortunately on-par with what I've come to expect from them over the past ten or so years.
On iOS, there’s a “Bluetooth browser” app which is basically a simple WebView-based browser, but with the Bluetooth JS spec implemented so that you can use it to configure whatever Bluetooth device you have that wants to use a webapp for configuration. And you know what? That’s fine. It’s perfect, actually. A separate app I can use for the 0.0001% of the time I actually need to interact with some random IoT device’s Bluetooth configuration UI, and my normal web browser doesn’t need the bloat and increased attack surface. It just seems like good engineering to me to do it this way.
More of the enormous bloated JS web API specs should be implemented as browser plugins. Let’s make the default footprint even smaller.
It doesn't give direct access. You go through the browser which restricts what you can use it to touch (eg. can't access USB drives). The user also needs to choose which USB device to allow access to before you can do anything.
> More of the enormous bloated JS web API specs should be implemented as browser plugins.
Then you'll get one of two outcomes: 1. Users install extensions without caring about what they do. I don't see why we should train people to install more extensions when there are already a lot of malicious extensions! 2. Hardware manufacturers decide to not adopt these standards and continue shipping executables for everything, which are not sandboxed at all and don't support all platforms
Hard to google, use "Web Bluetooth API" instead of webble
‡: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
I'm pretty sure the lead dev is a Firefox user so he may be interested in getting this to work: https://github.com/asivery/webminidisc
It would be even greater if it were possible to avoid the two-step installation. It certainly used to be possible to ship a binary inside a Firefox extension (I did that here: https://mackerron.com/zot2bib/), but I guess they may have shut that capability down for security reasons?