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?
Standard USB drivers aren't going to disappear from my disk and can be reverse engineered long after its manufacturer has dropped support or gone under.
What product categories exist where all entries only work (over USB) with native drivers?
All the categories you've listed have products that require a companion application to configure things out of band, that the "universal" driver doesn't understand.
In the case of the four HID you've listed the app would be for configuring key mapping, macros, rgb, firmware updates.
Some webcams need apps to control things not exposed by the native driver (things like head tracking or more specific sensor control).
I'm not familiar with the market but I would imagine that many headsets and DACs nowadays have similar apps to tune EQs presets and the like.
My bluetooth headphones work just fine without vendor software, but apparently with an app I can adjust the audio to somehow make me better at playing computer games. I think it amplifies other players' footsteps or something? If I wanted that, I'd need the vendor's software to do it.
My PSU works just fine without vendor software, but includes a USB monitoring interface, which would let me see certain things like fan speeds, voltages and currents. Of course I can monitor most of those with my motherboard's existing sensors; and a dip in the 12v rail will power off the system before any monitoring could respond. But if I did want to use those features, I'd need the vendor's software to do it.
Despite my distrust for vendor software, I have even less trust for webusb. Partly that's because I'm a hater in general, but mostly it's because there are too many holes in the web browser's sandbox already - if things in the sandbox are re-flashing your keyboard firmware you've given up on sandboxing, you just haven't admitted it to yourself yet.
Curious what your floor is for 'trustworthy', a company with a US headquarters? Personally I feel sketched out by any silicon not made in Sweden or Japan, so, pretty much all of it.
Or some things aren't even available made using libusb. Think control applications for RGB lights in keyboard and mice. There's a certain manufacturer all but mandating installation of its slopware. Being able to provide all of this as WebUSB has advantages.
(For the rare occurences that our customer is using 7 or earlier, we tell them to use zadig and be done with it.)
Hope every time you want to interface with a USB device.
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.
Native apps also have this, and it's worse because they usually just ask for sweeping admin access on windows, unlike WebUSB which just brings up a device selection menu
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.
"I know what I'm doing, and giving a random website access to my USB host is the right thing to do."
"I'm an idiot."
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!
But config updates that way still suck. The best implementation I've seen will present you with an empty drive with a README explaining how to drop a uf2 + an editable config file that contains all options with comments.
That's definitely workable for us tech people, but it absolutely sucks for the vast majority of users (including us tech people). Just think about having to learn the syntax, or simple things like picking a color or mapping keys on a keyboard.
IMHO Mozilla should have at least adopted WebSerial. It wouldn't give the entire USB freedom, but it has fewer privacy and security concerns and devices would have make it work. But now it's too late, WebUSB has been adopted widely and Mozilla will eventually have to adopt it or perish.
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
(Yes, you could try to bulid some common interface, libusb-style, but I think you'll have a bad time with minor behavioural differences, especially around permissions. libusb itself does ostensibly support Android but there are several caveats: https://github.com/libusb/libusb/wiki/Android#does-libusb-su... )
It also convenient for developer, as distributing apps nowadays is a lot of hoops to jump over. Website is just a website.
Also website is cross-platform by definition, as long as API is supported across platforms and WebUSB API is supported on all platforms except iOS.
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.
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?
Should we disallow clicking on anything on a webpage too?
WebUSB is no more risky than any other tech. You have to explicitly opt-in to use WebUSB on any site requesting access to it. And I'm sorry if someone's grandfather trusts a malicious website and gets hacked, but that isn't a reason to prevent the rest of us from using tech that enables functionality on non-malicious websites that serves a useful purpose.
As opposed to dodgy windows-only installable software from some weird site to flash devices instead? I’ll take my chances with webusb, thanks.
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?
Yes, you could make the configuration into a separate uf2 object that overwrites other bytes, but that's yucky.
The access is explicitly per device. Even for plain flashing, it's safer and simpler than to download and shuffle random files.
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.
This probably applies to many older (or even newer) USB devices as well.
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.
Nobody is going to win over browsers with an opinionated batteries included application framework.
There are hundreds of browsers these days, you shouldn't have a hard time finding one that fits your needs.
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.
Downloading an arbitrary executable can be made safe (via multiple avenues: trust, anti virus software, audits, artifact signing, reproducible builds, etc) and once the software is vetted, it exposes (or it should at least) little to no attack vector during daily use.
It will probably come natively one day in Firefox, and we should push back against such attack vectors.
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?