WebUSB as an extension is the right approach. The security concern isn't the API itself — it's the default-on expectation that Chrome created. Firefox's model of "opt-in via extension" gives power users what they need without expanding the
attack surface for everyone else.
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.
The whole point of WebUSB is to create a tool that works with USB device, without all the risks and issues of installing external programs.
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.
Everything should be an extension for a browser. AI, telemetry, and other universally hated features. Let the user choose. No one has to worry if a toggle will always be respected in code, or if an update will undo it. Beholden to the same security isolations other extensions are forced to abide by. It's just the right way to do things.
I was rather hostile towards WebUSB/Bluetooth for ideological reasons, until I came across some cool apps like a climbing board control app (Bluetooth) or a netMD (to transfer to minidisks, via USB), which I would have found overkill to install a "hard App" for. I'm glad that there's an option for Firefox at last.
Same here, was skeptical at first but then I used a web app that supports WebUSB to configure my mechanical keyboard and it lets you flash the firmware right there from the browser and that’s pretty nice and convenient.
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.
The whole dance has been made significantly easier by the adoption of UF2 flashing by large parts of the custom keyboard hobby: the device temporarily pretends to be a USB storage device, so you can now download the file and drag&drop it to your device.
Still not quite WebUSB-easy, but a massive improvement over needing dedicated programming software!
Firmware updates with UF2 over the emulated mass storage aren't bad, I agree.
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.
is anyone making backups of these webapps? my keyboard uses one for everything, I've been meaning to learn how to host a local copy for when the website inevitably gets shut down
Oryx is proprietary, but vial[1] is open source and has similar functionality. It still uses web technology though, so you either need a chromium based browser, or electron to use it (or maybe Firefox with this extension).
Ugh, I hate this trend. I'm using ZMK on a wireless split Corne and I have to clone the ZMK config repo, edit the config, push to GitHub, use some GH Action to compile the firmware, download it, unpack it, and then flash it. WTF happened? This is a terrible workflow, and I was not able to get this done locally after spending an entire day on it. Why can't this shit just compile on my machine? How about I edit a text file...and then compile it without all the bullshit, like installing Docker, about three or four language-specific package managers which install things not vetted by my distro's maintainers and probably run some bash scripts fetched with curl? And honestly I'm not really comfortable running firmware compiled by the Microsoft, the company known for their stellar software quality and security. Really though, I'm surprised, this was my first time being exposed to this kind of insanity. House of fucking cards.
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.
That's the exact scenario I first found it useful as well, earlier this month. It's especially nice as someone used to there not being Linux options for stuff like this.
This, more than ideology or security, is one of the main reasons I don't want WebUSB: fear that many hardware vendors will only support updates and configuration through a web app, that isn't guaranteed to remain online forever, may not be available to download and run locally, and may require installing otherwise undesirable firmware updates to maintain compatibility with available versions of the web app.
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.
> I was rather hostile towards WebUSB/Bluetooth for ideological reasons, until I came across some cool apps […] which I would have found overkill to install a "hard App" for.
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.
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
Well it's a stand-alone program too, not just an extension. I kinda wish extensions could act as full programs too but computers need better sandboxing.
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.
That was always the case. Lots of “flasher” applications have had web dependencies where they’d download the latest firmware to a temp directory before flashing.
Yep, I’ve bought a few thermal printers recently and webusb support (marketed as Chromebook support) was a major deciding factor. Thermal printers aren’t well supported by built in printer drivers, so it’s nice to not have to install some questionable driver software with access to my whole computer and instead have a sandboxed chrome extension with enumerated permissions. I’ve also poked around the extensions’ minified js source out of curiosity and as a basic security audit
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.
Aren't most retrocomputing USB devices running open source firmware? Adding a descriptor "WebUSB supported" is a few commits and a firmware update away.
Yep. FlipperZero, Android, now some random chinese handheld radio - just some of the things I didn't have to install some crap unsandboxed app to flash in the last 3 months. Absolutely revolutionary.
This right here is the reason I like it and web bluetooth too, with them 'just working' regardless of platform I'm using.
Miss me with some unsigned questionable app that only runs on windows as admin.
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, especially around permissions. libusb itself does ostensibly support Android but there are several caveats: https://github.com/libusb/libusb/wiki/Android#does-libusb-su... )
Cross-platform compatibility comes to mind. WebUSB is available on macOS, Windows, and Android; a native Android app would pose a bootstrapping problem for a probably not insubstantial fraction of all potential users.
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.
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.
There isn't much to fear here. Web Bluetooth has been around nearly ten years now and nothing monumental has sprung forth from it. It is wonderfully convenient to have at your fingertips, especially in the ChromeOS world, but it's not gonna turn everyone's devices into Flipper Zero targets.
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.
I wouldn't describe it as "conservative" but as "pro-native-apps and anti-web-apps", which seems irrational in this day and age where "native apps" means platform lock-in by monopolies, less sandboxing and user-control than on the web, much more gatekeeping and control over published binaries, and these days the web app is usually a more private/secure alternative to the native app (which also bundles a marketing SDK, now, and fingerprints you invisibly via iCloud Keychain, tracks you with various identifiers, and more).
If native platforms removed USB or Bluetooth, the "control over my own hardware" crowd would flip a table. I just wish they also understood the benefits of the web compared to native. The Chrome/Project Fugu team's dream of making the web platform as powerful as native platforms is the correct one from a user freedom standpoint, or at bare minimum a "user choice" standpoint.
I'm not saying pro-native-apps outright even if that might be what it gets boiled down as. I'm saying I do not trust anything that runs in a browser. I actively block as much nonsense as possible. I do not trust devs that write code to run in browsers. There's a lot of devs getting taken out in the blast radius, but the only way to be sure is to take off and nuke it from orbit. There are devs out there hell bent on writing malicious code. I am willing to take a stand and refuse to use things when the net result is negative. I do not use social media. I do not shop at Walmart. These are the decisions I'm willing to live with even if it makes life slightly less "easy" because I've made a moral decision to not open myself up to nonsense just to later ask "what happened...".
Sure, you do what works for you. But why advocate for even more limits to how other people use their computers? One person's nonsense is another person's treasured hobby.
Yes, bad actors exist, but why concede every single nice thing to them?
again, net negative is being glossed over. whatever good and nice things there might be, if it is being used more for negative purposes, you need to consider is it worth it at all or was it rushed and needing more thought before the PoC was pushed to prod
How can you tell that the negatives were glossed over? Just by WebUSB's eventual launch? Have you considered that different people might have different value preferences than you?
The web and native app platforms have very different security models.
Nobody is vetting websites for you. There is no guarantee the same company operates a website today that did yesterday. There is no obvious distribution or regulatory authority instituting penalties for illegal actions (and often is no legal presence in a country when illegal actions take place).
That means for the web, every consent prompt has a large, sometimes even unbounded amount of harm behind it if the user picks incorrectly, and browsers have limited capacity to help them pick correctly outside of reactive block lists once substantial harm has been done and recognized.
This is why, for example, the major browsers have all moved to restricting web extensions behind their own review processes/stores, and put restrictions that make unaudited web extensions difficult to install outside of development workflows. The risk is just too great.
Chrome pushed many of these API early in the Chromebook product cycle, because their idea was that you would only build apps using web technologies. I somewhat doubt they would have pushed for WebUSB themselves if Chromebook started in its current state, where it primarily runs android apps and is about to transition to be android-based.
> The web and native app platforms have very different security models.
Yes, and as a result, the web is much more sandboxed than native app stores (which are mostly based on the illusion that vetting apps can somehow achieve better security than minimizing what resources apps can access in the first place and making access more fine grained).
This is exactly why I'd rather run e.g. shady USB aftermarket firmware flashing apps in my browser (where I know they can at most compromise the device I'm flashing) than as a native app (where USB access is the default and requires zero permissions to be approved).
> This is why, for example, the major browsers have all moved to restricting web extensions behind their own review processes/stores, and put restrictions that make unaudited web extensions difficult to install outside of development workflows. The risk is just too great.
Web extensions very often have access to your complete browsing data, including all cookies. That's orders of magnitude more risky than access to an explicitly selected USB device, in my view.
> I somewhat doubt they would have pushed for WebUSB themselves if Chromebook started in its current state, where it primarily runs android apps and is about to transition to be android-based.
Android has an USB API as well, and if Google only wanted "apps" to have USB access, nothing was stopping them from making Web USB "Chrome App Store" only.
> where "native apps" means platform lock-in by monopolies, less sandboxing and user-control than on the web, much more gatekeeping and control over published binaries, and these days the web app is usually a more private/secure alternative to the native app
Please add “mobile and/or proprietary” before “native apps”. Linux and BSD on PC are still very much free. The web as a platform is just a NIH effort.
> those creating the something "cool" simply because they would never fathom using the "cool" for "uncool" purposes
I can definitely imagine a ton of things going wrong with Web USB, and I think the spec authors did a pretty good job at bolting everything down that can be, while still shipping something actually capable at providing USB access.
And that's my point: Sure, fewer capabilities are always safer than more capabilities. But some capabilities are nice and arguably worth the risk, especially if the obvious alternative (blindly installing native applications) isn't much safer.
>Sadly, someone else will and weaponize it in an uncontrollable manner.
Except it isn't "uncontrollable". You have to explicitly allow every single website to use WebUSB. Without that explicit allowance, the website can't access anything.
Plenty of things can be weaponized, even household utensils. Should we ban all forks?
The sky is not falling, and WebUSB is not going to cause it to fall.
Sure, but some people are concerned about any website being one confirmation prompt away from being able to have full access to hardware in the user's physical environment, and being able to permanently change the behavior of that hardware.
A hacker may think such things are convenient for them, but an end user does not know the ramification of a random website (WebUSB IIRC still does not have origin restrictions) getting hardware access - nor can we categorize the risk in order to protect them.
What physical access and what permanent behavior changes in particular are you concerned about? Most common "dangerous" USB device classes are explicitly excluded in Web USB.
I've heard about rogue keyboard firmware, but that requires having a programmable/updatable firmware keyboard in the first place. And that closes the loop of my argument: People that want to update the firmware in their keyboard will do so, whether it's in the browser or by installing a potentially shady and not at all sandboxed third party application.
At least in the browser, permissions are time limited and scoped to explicitly granted devices.
> WebUSB IIRC still does not have origin restrictions
The most important USB thing I have are storage devices. Keyboards/mice/etc are much less of a concern. If something rogue happens to a drive, that's a "major problem in Australia. Please help us stop it" situation.
It's a good thing that history has shown us that things have never happened that were designed not to happen. Sure, my tinfoil hat is securely fashioned, but I've been around long enough to see things get subverted even if it's not until long after release.
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 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”
As opposed to dodgy windows-only installable software from
some weird site to flash devices instead? I’ll take my chances with webusb, thanks.
You can press a simple button on a webpage and it will install malware on your iPhone. Plenty of exploits have been out there for a long time.
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.
WebUSB has been used by projects like GrapheneOS, ESPHome, and Meshtastic. Google has used WebUSB to let users convert Stadia controllers to regular bluetooth input devices. Some manufacturers of keyboards use WebUSB for their configuration utilities.
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.
Honestly, an extension seems like the perfect solution for this. Wanting a website to access your USB stack directly (or Bluetooth, which has a similar standard) is such an extremely niche use case that it’s probably better for it to be available only as an opt-in extension. They can still standardize it, but… let me just not have it by default please.
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.
> Wanting a website to access your USB stack directly (or Bluetooth, which has a similar standard) is such an extremely niche use case that it’s probably better for it to be available only as an opt-in extension.
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
Let me give a concrete example. Hardware "passkeys" - FIDO2 authenticators - are designed such that their credentials are bound to a particular Relying Party (web site). Browsers enforce this by sending the current web domain the user is on to the authenticator when Javascript tries to list, create, or use a credential.
This would be completely broken if Javascript talked directory to a FIDO2 USB device, because the JS could send a Relying Party that is NOT the web site on which the user currently lands.
So Chrome blocks WebUSB from communicating with USB devices whose USB HID descriptor "looks like" a FIDO one, by some hardcoded "not this device" blacklist code in Chrome itself.
But what if what you have connected to your computer is a USB NFC card reader, and the user taps their FIDO authenticator on that? Letting the Javascript communicate directly with the card reader breaks the FIDO security model exactly the same way... but Chrome allows it!
The problem with WebUSB is that it exposes devices that were built under the threat model that only trusted code would be able to access them to untrusted code. The set of devices acceptable for WebUSB use should have been a whitelist instead of a blacklist to be secure. Letting the user choose the device to grant access doesn't solve the problem, because the user doesn't have a way to understand what will happen when the site is granted access, per the FIDO example I gave above.
> But what if what you have connected to your computer is a USB NFC card reader, and the user taps their FIDO authenticator on that?
So the user would need to:
1. Keep the malicious page open, or install a malicious extension
2. Grant access to the card reader from a list of USB devices
3. Then tap their card on that reader
IMO a bad actor is going to have more success getting people to run an executable they made the browser download. There's only so much you can do to protect people from themselves. Not everyone needs software to be locked down like a padded room.
> The problem with WebUSB is that it exposes devices that were built under the threat model that only trusted code would be able to access them to untrusted code.
Which platforms have USB devices locked down to "trusted code" only?
People are starting to ship even local apps only in the form of some html & js that only works on Chrome because only Chrome has webusb.
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.
I still want to reinvent the web with a hypertext document reader that doesn't include the kitchen sink. I suppose with LLMs these days this is actually an achievable prototype.
Conversely, a web app platform that includes all the primitives that are needed to build a decent web app (as opposed to bring your own everything/building castles from grains of sand model) would be nice. It doesn't necessarily have to be a browser, though.
Those all had major issues. All of them were constrained to a browser environment, the first two were proprietary and full of security holes, and all of them had a reputation for causing browser or even full OS crashes.
I wouldn't say that any of them were particularly "batteries included", either. Flash was probably closest but still left a lot of legwork to the developer.
I'm talking about no javascript, no additional requests besides the bare document, no sending any information back home. Dynamic behavior only by a simple declarative language.
You are trying to express something that is logically impossible. Not technically difficult or socio-economically difficult to get companies to agree to or get users to care about, simply not a valid string of words.
There is no way not to send information back to the host.
Merely requesting a document is sending information to a host.
I don't mean all the extra metadata in the request header or cookies let alone the all the functionality in javascript or wasm or plugins, I mean nothing more than the name of a document, the bare minimum info required to get something you want it to give you.
If you want me to give you an apple, at the very least you have to tell me to give you an apple.
It all started with nothing more than that bare function, and we don't even want any less than that.
You do need to be able to request a document, and there is no way for a client to prevent a server from replacing a simple static document with a cgi script that performs logic based on the file name. Even without the extra cgi query string, just a document name itself.
But about query strings... there is no way to make a typical query string illegal anyway. It's all just strings of characters. Anything can be encoded within anything else. If you try to make a system that makes say the & and ? characters illegal, that accomplishes exactly nothing.
You just pick any sequence of legal charaters and interpret those in place of the old ? and &, and = and % and anything else you want that doesn't look like part of a legal file or document name.
The special encoded charaters can even be different for each document, even different for each request. It's not possible to make a rule that prevents it.
Let's go totally off the deep end and say that you aren't even allowed to make up your own file names any more. All documents on earth have known names in a whitelist. You can't encode anything because every valid document has a known name and known content. Then you can still encode information in the pattern of access. Requesting file A followed by file F means something extra to you and the server.
But don't take my naysayer defeatist lack of imagination word for it. Go ahead and try to actually explain how the system should work.
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?
BBC Microbit kids hardware platform uses WebUSB. It’s a game changer for introducing hardware to students. Just works.
Makecode.microbit.org is the web IDE. Reference URLs for the code make sharing and debugging easy.
Looks to be a great proof of concept. No, running a standalone executable alongside the browser is not the way you'd want to do WebUSB. But it's great to see someone working on it.
Except the sandbox is a huge target already, and breaking it means any website can now access and mess with your usb devices. If you can develop an exploit for Chrome's WebUSB system, you potentially have millions upon millions of targets available.
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.
But a keyboard flashed with malicious firmware becomes an undetectable keylogger, a USB rubber ducky, and a virus-laden USB stick all in one.
The concept that someone would want to reflash their keyboard firmware, but wants a sandbox because they don't trust the firmware programmer makes no sense.
Having WebUSB and WebBle everywhere would allow me to ship my IoT application via web only. That would be a win for my productivity, no more messing about with app store shenanigans.
That’s how most operating systems have worked for over two decades. Most OSes support USB devices that present themselves as HID, mass storage, audio, etc. without any dedicated drivers needed. It’s only specialized devices or functionality that tends to need additional drivers.
It's not even just USB classes that the OS provides a native driver for. I believe that on both iOS and macOS (not sure about newer Windows versions), you can essentially access USB as a byte streaming device.
If your app is the only one expected to communicate with a given device, you can then just directly embed the logic speaking that protocol in it. A driver is only needed if you want to provide a shared high-level abstraction to other applications as well.
Modern Windows also allows raw USB access for devices exposing specific WinUSB descriptor. So it's not just any device, but if it's yours device and your skills are sufficient to alter USB descriptors that device presents to the host, it's pretty painless.
Most device drivers nowadays aint necessary to solely get the device working, but to get it working well. All keyboards will work out of the box without any drivers/webusb-pages, but good luck configuring rapid triggers on your Wooting keyboard or a DPI-switching macro on your Logitech mouse without it.
I felt that way too, but having used it a few devices as an end user I enjoy being able to close the browser and have the whole stack disappear. Instead of having to install a creepy Logitech tool to pair a mouse with a receiver, as soon as that task is done, goodbye Logitech. I guess a real concern is manufacturers stop offering native drivers, but for the majority of hardware the PnP or the Linux kernel just handle it.
There's a real risk of losing the ability to control your device if the manufacturer stops hosting their propertiary WebUSB app, too.
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.
The nice thing about USB devices is that they don't need native drivers. Hardware that requires native drivers for USB is pretty rare, at least for many common cases (keyboard, mice, controllers, joysticks, printers, dacs, headsets, cameras, ..), and are easy to avoid.
What product categories exist where all entries only work (over USB) with native drivers?
> 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 USB wireless keyboard and mouse work just fine without vendor software, but if I ever lost the dongle and had to re-pair them with a different dongle, I'd need the vendor's software to do it.
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.
everyone has a different threshold at which they would consider something 'untrustworthy'
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.
Sounds like something that could have a standalone usb-driver-container or special chromium fork for the 0.00001% of users that need it instead of bloating every browser with yet another niche API and the inevitable security holes it will bring.
People are already doing that in the experimental embedded world, and let me tell you, it's pain. True and utter pain. You're going to fight different versions of libusb's userland being installed, Windows/macOS/Linux kernel occupying the device with a default driver (cough rtl_sdr) and a whole lot of other messes.
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.
Let me guess, Razer which is known for auto-downloading kernel rootkits as soon you plug in your mouse? They’re basically the Riot Games of gaming peripherals.
I'm not familiar with the Windows platform but although you can have userspace USB drivers on linux, you still need to be able to run code that can talk to the sysfs interface.
Anyway OS 2.0 descriptors are a custom USB descriptor that basically tells the device to use WinUSB as the driver. The burden then is in the application that will have to implement the read/writes to the endpoints instead of using higher level functions provided by the custom driver.
If you ever developed software with libUSB, using WinUSB on the windows side makes things super easy for cross platform development, and you don't have to go through all the pain to have a signed driver. Win-win in my book.
yes, you can always use some nasty protocol over HID for your devices. But really most of what i do is one or multiple bulk endpoints so i can achieve full bandwidth (downloading firmware, streaming data, ...)
OS2.0 made it possible to do it without having to write and sign a driver
How does the security of userspace drivers compare to having drivers within a sandboxed web environment with access to only the devices you’ve explicitly allowlisted?
It's about the same. People will blindly click allow on a webpage in the same way that they blindly run libusb binaries with `sudo` that they copied from some webpage. Security is possible in all of these scenarios, but always undermined by the users.
It's absolutely not the same. If I go to a WebUSB page to make my device work, it won't magically have access to all my private files and be able to upload them god knows where or to destroy them. Or access to my entire LAN. Or access to my other peripherals.
Any local driver/software will be able to. (Yes I am familiar with sandboxing technologies, they still aren't the default way to distribute apps outside of iOS/Android).
Yeah, but if you request webUSB access maliciously to some random device, an unsavvy user is likely to click ok without thinking about it. Its still very much a viable attack vector.
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.
> What are the security implications this raises that downloading native programs (needed for example to flash my smartphone) doesn't raise?
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
> Native apps also have this, and it's worse because they usually just ask for sweeping admin access on windows
On iOS they only pop up the menu when they try to access the required functionality, and there's a limited number of things they can do.
> unlike WebUSB which just brings up a device selection menu
So the user has to contend with permissions on phones, in desktop OSes, but 26 more potential permissions [1] from a browser are fine because a) it's just a single permission window and b) the browser exists in total vacuum from all other user experiences.
[1] Counted in Chrome settings -> Site settings -> permissions. Why Chrome? Because they are the ones pushing all the hardware APIs, among others
> On iOS they only pop up the menu when they try to access the required functionality, and there's a limited number of things they can do.
great! your web browser does the exact same thing!
> 26 more potential permissions [1] from a browser are fine because a) it's just a single permission window and b) the browser exists in total vacuum from all other user experiences.
your argument is a non-sequitur; if I go install a firmware flasher, it is going to ask for permission to access the device I am flashing no matter what. on macos it will ask for "full disk access" for all your disks! on windows it will ask me "Do you want to allow this app to make changes to your device?" (what changes????). and then after that the app has to look at all of your devices and ask you which you want to use, and if there's a bug in the code, it might operate on the wrong one.
those OS permissions are confusing and obtuse, dare I say useless, and yet they still exist, and of course they cause fatigue!
whereas if you go to a webusb tool, the browser presents you a list of devices, with only the ones the app can use visible, and the app never gets more permission than it needs. it is simply a better UX and DX than the "permissions" cloud you're yelling at.
Browsers don't exist in a vacuum. And yet everyone treats "yet another security pop up" as it does.
> those OS permissions are confusing and obtuse, dare I say useless, and yet they still exist, and of course they cause fatigue!
So let's add more?
> whereas if you go to a webusb tool
And yet you continue to pretend that it's only WebUSB that exists, or that users haven't been conditioned to give any and all permissions to any and all popups
The spec is still in draft because Apple refuses to let it move forward - because WebUSB, WebBluetooth and other APIs would compete with their app store, where they can make money from purchases made through apps. They prioritize profits over progress.
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.
> The spec is still in draft because Apple refuses to let it move forward
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.
Apple has provided no alternative, and no suggestions for how to improve the draft. They are not helping advance the draft only for selfish reasons.
They also won't allow any other browser on iOS for the same selfish reasons.
Apple continues to use abusive business tactics, and it's why they are being sued by the DOJ in an antitrust lawsuit. Them not implementing and not even suggesting changes to WebUSB and WebBluetooth are just further examples of it.
>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
So the alternative is installing questionable drivers from questionable websites that give an attacker full-access to the entire computer. This is far less good for security, and is unfortunately the norm right now.
>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.
So is every other browser API that's currently implemented that requires explicit approval from a user. It's nonsense to single out WebUSB specifically.
> It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
Bullshit. You have to explicitly allow WebUSB to interact with any website that requests it. It does NOT allow arbitrary tracking, and this sentence proves that whatever Mozilla writes about it is disingenuous, trying to incite hysteria about an API.
And I'll just fire up a chrome instance which I specifically keep for when my daily driver firefox decides to spazz out and not implement basics in 2026 :'(
How do you make sure that technically illiterate people don't just click away the requestDevice() popup? IMHO a browser offering device level USB access is a security nightmare and there is no way this can ever be made safe and convenient at the same time.
I do not agree with Google on preventing apk installation. But unknown apk is a different risk profile than letting unknown entities to access local usb devices.
The main issue in the former case is that google is posing itself as a gatekeeper instead of following a repo model like Debian or FreeBSD. That’s wanting control over people’s device.
Allowing USB access is just asking to break the browser sandbox, by equating the browser with the operating system.
You simply don't. This quest of saving idiots from themselves is not gaining anyone anything and meanwhile other people get more and more useless restrictions.
Or you can just not use the web at all. If you're so scared of it, why are you using it with browsers that have implemented all kinds of APIs that probably already scare you? You may as well just use the Lynx browser if you really want want to put your money where your (security) mouth is. It doesn't do anything, not even display images or CSS or run Javascript.
This is not just an isolated incident, it's the whole trend of limiting capabilities in the name of security and that's what I was referring to.
However in this particular case, even the security argument doesn't hold, either I:
a) know that I want to use USB - in that case I'll switch browsers or download a native binary (even more unsafe), it's not that I'd decide that I no longer want to flash my smartphone
b) I don't understand what's happening but I follow arbitrary instructions anyway - WebUSB changes nothing.
A native binary can be verified by anti malware systems, and once installed and working, poses no security risk.
A 0day in a browser for the WebUSB system would allow any website to mess with arbitrary USB devices connected to your computer.
While the browser sandbox is generally safe, it is also a huge target, and with a security risk like that, it wouldn't surprise me if it's a prime target for black hats.
I’d be ok with an about:config switch, but given that many people will install anything, paste arbitrary text into terminals, and share their password/pin code with complete strangers for almost no reason, I think we need to stop making our tools less powerful in pursuit of an impossible goal.
I see this slightly differently. Before, if I wanted to be able to do something like flash firmware onto some device I would have to download some random C++ application and install and run it on my local machine. As well as having access to all of my USB devices, it also had access to everything else on my system's user context. I didn't have a way of running that code and only giving it access to a single USB device and nothing else. Now, I can avoid installing anything at all. I visit the project page and opt-in to some flashing flow that's running in a sandboxed env. When the app requests it, the browser asks me for permission and I get to choose exactly which USB device I want to give it access too. That's picking exactly the minimum "outside" access I want to give it, nothing more. It doesnt get to read/write other USB devices I didnt choose. I doesnt get to read/write to my filesystem. It doesnt get to call system APIs. It doesnt get to set itself to start at startup. It doesnt get to install an auto-updater. For me, this is a better security posture than installing random win32 apps.
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.
If you're worried about that, you can just disable WebUSB in the chrome settings. Any website will be denied access to that API from now on. And what's even better: you can selectively enable WebUSB for some websites.
That's what I do and that's what I suggest for any security-conscious user to do. Just explore Chromium settings, there are dozens of various APIs that could be disabled. Do you need Web MIDI? I don't. Disable.
Won't work as a default setting for average user for sure, but if you consider yourself an advanced user, do that.
Flashing was already solved by UF2, where the device-to-flash temporarily pretends to be a USB storage device. Giving raw USB access to to random websites for that is massively overkill.
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?
trivial for you maybe but many people don't know how and where to find the right firmware for their specific device, and can be in environments where the UF2 volume isn't as obvious (e.g. using a phone)
Are you more comfortable with installing native apps to control your hardware? Or you are more comfortable with opening a webpage to control your hardware?
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.
Whether we like it or not, the distinction between an app and a web page has already eroded, and is, and only will be, eroding more.
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.
They're converging towards the middle, which is good, but it's not going to be the same thing. Apps use web tech for convenience and native APIs for things you can't do in web. You're expected to trust apps and extensions more than websites.
That's fortunately easily fixed: Don't grant them access!
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.
As much as I understand the ease of deployment this brings people, it puts a massive amount of code between the device and the user. Will webusb software written today work in 5, 10, 15 years? Personally, I think webusb is a giant contraption.
If history is a lesson (of going from lower level to higher level programming languages), the exact opposite will happen: there'll just be so much stuff out there that any eventual gain in efficiency will be dwarfed in the grand scheme of things.
And Web Serial reached mainline Firefox last week.
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.
The issue with Web Serial is it's not available for Android. Because for some dumb reason, android apps can't access /dev/ttyUSBx, even if kernel exposes them. But then can access raw USB devices. That's really weird. But if you need to access USB serial device in an android, you need to implement FTDI proprietary protocol or whatever adapter you're using by hand.
>And Web Serial reached mainline Firefox last week.
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.
I think they see privacy as one of their primary valueadds, and are concerned about the privacy implications with exposing a (PAN) network to the internet that probably wasn't designed to be exposed to such an adversarial environment.
> their silly role in the security theater of “but what if our users are dumb”
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.
They should just add a "Security Console", with black background and green text, and a simple shell interface for enabling/disabling flags that gate whether these requests are automatically denied or create a permissions popup. Anything dangerous starts disable by default.
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.
I keep chrome installed just to flash my meshcore devices... I doubt i'll try this but it's a nice step, hopefully we can get something akin to native adoption.
WebUSB as an extension is the right approach. The security concern isn't the API itself — it's the default-on expectation that Chrome created. Firefox's model of "opt-in via extension" gives power users what they need without expanding the attack surface for everyone else.
The whole point of WebUSB is to create a tool that works with USB device, without all the risks and issues of installing external programs.
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.
...in your opinion. the firefox team disagrees.
Everything should be an extension for a browser. AI, telemetry, and other universally hated features. Let the user choose. No one has to worry if a toggle will always be respected in code, or if an update will undo it. Beholden to the same security isolations other extensions are forced to abide by. It's just the right way to do things.
I was rather hostile towards WebUSB/Bluetooth for ideological reasons, until I came across some cool apps like a climbing board control app (Bluetooth) or a netMD (to transfer to minidisks, via USB), which I would have found overkill to install a "hard App" for. I'm glad that there's an option for Firefox at last.
Same here, was skeptical at first but then I used a web app that supports WebUSB to configure my mechanical keyboard and it lets you flash the firmware right there from the browser and that’s pretty nice and convenient.
https://www.zsa.io/flash
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.
The whole dance has been made significantly easier by the adoption of UF2 flashing by large parts of the custom keyboard hobby: the device temporarily pretends to be a USB storage device, so you can now download the file and drag&drop it to your device.
Still not quite WebUSB-easy, but a massive improvement over needing dedicated programming software!
Firmware updates with UF2 over the emulated mass storage aren't bad, I agree.
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.
is anyone making backups of these webapps? my keyboard uses one for everything, I've been meaning to learn how to host a local copy for when the website inevitably gets shut down
Oryx is proprietary, but vial[1] is open source and has similar functionality. It still uses web technology though, so you either need a chromium based browser, or electron to use it (or maybe Firefox with this extension).
https://get.vial.today/
Ugh, I hate this trend. I'm using ZMK on a wireless split Corne and I have to clone the ZMK config repo, edit the config, push to GitHub, use some GH Action to compile the firmware, download it, unpack it, and then flash it. WTF happened? This is a terrible workflow, and I was not able to get this done locally after spending an entire day on it. Why can't this shit just compile on my machine? How about I edit a text file...and then compile it without all the bullshit, like installing Docker, about three or four language-specific package managers which install things not vetted by my distro's maintainers and probably run some bash scripts fetched with curl? And honestly I'm not really comfortable running firmware compiled by the Microsoft, the company known for their stellar software quality and security. Really though, I'm surprised, this was my first time being exposed to this kind of insanity. House of fucking cards.
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.
If you use nix, building locally is as easy as running a single command once it's setup with https://github.com/lilyinstarlight/zmk-nix
That's the exact scenario I first found it useful as well, earlier this month. It's especially nice as someone used to there not being Linux options for stuff like this.
This, more than ideology or security, is one of the main reasons I don't want WebUSB: fear that many hardware vendors will only support updates and configuration through a web app, that isn't guaranteed to remain online forever, may not be available to download and run locally, and may require installing otherwise undesirable firmware updates to maintain compatibility with available versions of the web app.
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.
There is a host of software that only runs on Windows which can now run on any os with webusb. It's a glorious improvement
It just can't run on any device with a security policy in place.
> I was rather hostile towards WebUSB/Bluetooth for ideological reasons, until I came across some cool apps […] which I would have found overkill to install a "hard App" for.
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.
> I would have found overkill to install a "hard App" for
Hope you enjoy that same sentiment is 20 years when the website to control/manage your device doesn't exist/was bought out/whatever.
How is it any different with downloadable firmware?
That you can keep the firmware, the program to install it and a snapshot of the whole operating system in your drawer, if you want?
WebUSB is the main way to flash GrapheneOS onto a phone.
You can even do it from another Graphene phone!
One that’s been using Attestation, for bonus points.
Another possible use-case: allowing your peripherals to talk to cloud gaming computers - like, a nice HOTAS setup for flight simulator on GeforceNow.
It's fine as an extension, not so much as a default-enabled feature. We got the best outcome here.
Edit: Wait, no we didn't. Chrome added WebUSB support after all. Wtf I'm disabling that
> not so much as a default-enabled feature.
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
Yeah but still, I'd want that to only remotely be a thing. Like require enabling a developer setting for it.
That's a great way to kill adoption of a feature. But what has WebUSB done to you?
Why? The permission dialog is crystal clear.
Chrome has had WebUSB since 2017. I really appreciate it for one-off configurators and those types of tools.
Well it's a stand-alone program too, not just an extension. I kinda wish extensions could act as full programs too but computers need better sandboxing.
I used it to side-load Android apps onto my Quest 3 so I could try Chromium on it
WebUSB is so great.
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.
> I can ship a cross-platform application
And you can also un-ship it whenever you want, leaving users with unusable devices they paid money for.
That was always the case. Lots of “flasher” applications have had web dependencies where they’d download the latest firmware to a temp directory before flashing.
This brings back bad memories of the old ActiveX "safe for scripting" mechanism.
Yep, I’ve bought a few thermal printers recently and webusb support (marketed as Chromebook support) was a major deciding factor. Thermal printers aren’t well supported by built in printer drivers, so it’s nice to not have to install some questionable driver software with access to my whole computer and instead have a sandboxed chrome extension with enumerated permissions. I’ve also poked around the extensions’ minified js source out of curiosity and as a basic security audit
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.
Let's please not (or at most, add a scary warning for non-tagged devices), as this would break the use case for at least all retrocomputing.
Aren't most retrocomputing USB devices running open source firmware? Adding a descriptor "WebUSB supported" is a few commits and a firmware update away.
that's not going to work for use cases like the https://webmd.pro where you're interfacing with hardware from other manufacturers
Definitely not most MiniDisc players. I doubt mine even has updatable firmware!
This probably applies to many older (or even newer) USB devices as well.
Yep. FlipperZero, Android, now some random chinese handheld radio - just some of the things I didn't have to install some crap unsandboxed app to flash in the last 3 months. Absolutely revolutionary.
This right here is the reason I like it and web bluetooth too, with them 'just working' regardless of platform I'm using. Miss me with some unsigned questionable app that only runs on windows as admin.
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?
WebUSB is particularly useful for this, because it allows you to just open a website. You don't need to install an app.
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.
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, especially around permissions. libusb itself does ostensibly support Android but there are several caveats: https://github.com/libusb/libusb/wiki/Android#does-libusb-su... )
So you can't just use fastboot in termux, with https://github.com/nohajc/termux-adb, then?
It uses libusb, so yes, modulo aforementioned documented caveats (as well as the undocumented ones)
Cross-platform compatibility comes to mind. WebUSB is available on macOS, Windows, and Android; a native Android app would pose a bootstrapping problem for a probably not insubstantial fraction of all potential users.
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.
There isn't much to fear here. Web Bluetooth has been around nearly ten years now and nothing monumental has sprung forth from it. It is wonderfully convenient to have at your fingertips, especially in the ChromeOS world, but it's not gonna turn everyone's devices into Flipper Zero targets.
> 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.
I wouldn't describe it as "conservative" but as "pro-native-apps and anti-web-apps", which seems irrational in this day and age where "native apps" means platform lock-in by monopolies, less sandboxing and user-control than on the web, much more gatekeeping and control over published binaries, and these days the web app is usually a more private/secure alternative to the native app (which also bundles a marketing SDK, now, and fingerprints you invisibly via iCloud Keychain, tracks you with various identifiers, and more).
If native platforms removed USB or Bluetooth, the "control over my own hardware" crowd would flip a table. I just wish they also understood the benefits of the web compared to native. The Chrome/Project Fugu team's dream of making the web platform as powerful as native platforms is the correct one from a user freedom standpoint, or at bare minimum a "user choice" standpoint.
I'm not saying pro-native-apps outright even if that might be what it gets boiled down as. I'm saying I do not trust anything that runs in a browser. I actively block as much nonsense as possible. I do not trust devs that write code to run in browsers. There's a lot of devs getting taken out in the blast radius, but the only way to be sure is to take off and nuke it from orbit. There are devs out there hell bent on writing malicious code. I am willing to take a stand and refuse to use things when the net result is negative. I do not use social media. I do not shop at Walmart. These are the decisions I'm willing to live with even if it makes life slightly less "easy" because I've made a moral decision to not open myself up to nonsense just to later ask "what happened...".
Sure, you do what works for you. But why advocate for even more limits to how other people use their computers? One person's nonsense is another person's treasured hobby.
Yes, bad actors exist, but why concede every single nice thing to them?
again, net negative is being glossed over. whatever good and nice things there might be, if it is being used more for negative purposes, you need to consider is it worth it at all or was it rushed and needing more thought before the PoC was pushed to prod
How can you tell that the negatives were glossed over? Just by WebUSB's eventual launch? Have you considered that different people might have different value preferences than you?
The web and native app platforms have very different security models.
Nobody is vetting websites for you. There is no guarantee the same company operates a website today that did yesterday. There is no obvious distribution or regulatory authority instituting penalties for illegal actions (and often is no legal presence in a country when illegal actions take place).
That means for the web, every consent prompt has a large, sometimes even unbounded amount of harm behind it if the user picks incorrectly, and browsers have limited capacity to help them pick correctly outside of reactive block lists once substantial harm has been done and recognized.
This is why, for example, the major browsers have all moved to restricting web extensions behind their own review processes/stores, and put restrictions that make unaudited web extensions difficult to install outside of development workflows. The risk is just too great.
Chrome pushed many of these API early in the Chromebook product cycle, because their idea was that you would only build apps using web technologies. I somewhat doubt they would have pushed for WebUSB themselves if Chromebook started in its current state, where it primarily runs android apps and is about to transition to be android-based.
> The web and native app platforms have very different security models.
Yes, and as a result, the web is much more sandboxed than native app stores (which are mostly based on the illusion that vetting apps can somehow achieve better security than minimizing what resources apps can access in the first place and making access more fine grained).
This is exactly why I'd rather run e.g. shady USB aftermarket firmware flashing apps in my browser (where I know they can at most compromise the device I'm flashing) than as a native app (where USB access is the default and requires zero permissions to be approved).
> This is why, for example, the major browsers have all moved to restricting web extensions behind their own review processes/stores, and put restrictions that make unaudited web extensions difficult to install outside of development workflows. The risk is just too great.
Web extensions very often have access to your complete browsing data, including all cookies. That's orders of magnitude more risky than access to an explicitly selected USB device, in my view.
> I somewhat doubt they would have pushed for WebUSB themselves if Chromebook started in its current state, where it primarily runs android apps and is about to transition to be android-based.
Android has an USB API as well, and if Google only wanted "apps" to have USB access, nothing was stopping them from making Web USB "Chrome App Store" only.
> where "native apps" means platform lock-in by monopolies, less sandboxing and user-control than on the web, much more gatekeeping and control over published binaries, and these days the web app is usually a more private/secure alternative to the native app
Please add “mobile and/or proprietary” before “native apps”. Linux and BSD on PC are still very much free. The web as a platform is just a NIH effort.
> those creating the something "cool" simply because they would never fathom using the "cool" for "uncool" purposes
I can definitely imagine a ton of things going wrong with Web USB, and I think the spec authors did a pretty good job at bolting everything down that can be, while still shipping something actually capable at providing USB access.
And that's my point: Sure, fewer capabilities are always safer than more capabilities. But some capabilities are nice and arguably worth the risk, especially if the obvious alternative (blindly installing native applications) isn't much safer.
>Sadly, someone else will and weaponize it in an uncontrollable manner.
Except it isn't "uncontrollable". You have to explicitly allow every single website to use WebUSB. Without that explicit allowance, the website can't access anything.
Plenty of things can be weaponized, even household utensils. Should we ban all forks?
The sky is not falling, and WebUSB is not going to cause it to fall.
Honest question, dude:
have you used the thing in the wild?
Much like the Location API, it’s explicitly opt-in, and isolated.
How is it going to be weaponized?
That’s what to talk about here. I’d love to take part.
Sure, but some people are concerned about any website being one confirmation prompt away from being able to have full access to hardware in the user's physical environment, and being able to permanently change the behavior of that hardware.
A hacker may think such things are convenient for them, but an end user does not know the ramification of a random website (WebUSB IIRC still does not have origin restrictions) getting hardware access - nor can we categorize the risk in order to protect them.
What physical access and what permanent behavior changes in particular are you concerned about? Most common "dangerous" USB device classes are explicitly excluded in Web USB.
I've heard about rogue keyboard firmware, but that requires having a programmable/updatable firmware keyboard in the first place. And that closes the loop of my argument: People that want to update the firmware in their keyboard will do so, whether it's in the browser or by installing a potentially shady and not at all sandboxed third party application.
At least in the browser, permissions are time limited and scoped to explicitly granted devices.
> WebUSB IIRC still does not have origin restrictions
How would you even enforce these on the open web?
The most important USB thing I have are storage devices. Keyboards/mice/etc are much less of a concern. If something rogue happens to a drive, that's a "major problem in Australia. Please help us stop it" situation.
That would indeed be horrible, which is why storage devices are explicitly excluded from WebUSB.
It's a good thing that history has shown us that things have never happened that were designed not to happen. Sure, my tinfoil hat is securely fashioned, but I've been around long enough to see things get subverted even if it's not until long after release.
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 suppose if it’s being actively exploited, the next step would be to make users wait a day, like the plan to change how Android side loading works.
I'd be absolutely livid if my browser asked me to wait for a day before letting me firmware flash whatever new USB gadget just arrived in the mail.
“ 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”
As opposed to dodgy windows-only installable software from some weird site to flash devices instead? I’ll take my chances with webusb, thanks.
You can press a simple button on a webpage and it will install malware on your iPhone. Plenty of exploits have been out there for a long time.
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.
You can also flash Android from the browser: https://flash.android.com/.
I've used Firefox successfully twice. I have nextdns on my router, not sure if that helped.
WebUSB has been used by projects like GrapheneOS, ESPHome, and Meshtastic. Google has used WebUSB to let users convert Stadia controllers to regular bluetooth input devices. Some manufacturers of keyboards use WebUSB for their configuration utilities.
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.
Honestly, an extension seems like the perfect solution for this. Wanting a website to access your USB stack directly (or Bluetooth, which has a similar standard) is such an extremely niche use case that it’s probably better for it to be available only as an opt-in extension. They can still standardize it, but… let me just not have it by default please.
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.
> Wanting a website to access your USB stack directly (or Bluetooth, which has a similar standard) is such an extremely niche use case that it’s probably better for it to be available only as an opt-in extension.
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
I think there is still a problem.
Let me give a concrete example. Hardware "passkeys" - FIDO2 authenticators - are designed such that their credentials are bound to a particular Relying Party (web site). Browsers enforce this by sending the current web domain the user is on to the authenticator when Javascript tries to list, create, or use a credential.
This would be completely broken if Javascript talked directory to a FIDO2 USB device, because the JS could send a Relying Party that is NOT the web site on which the user currently lands.
So Chrome blocks WebUSB from communicating with USB devices whose USB HID descriptor "looks like" a FIDO one, by some hardcoded "not this device" blacklist code in Chrome itself.
But what if what you have connected to your computer is a USB NFC card reader, and the user taps their FIDO authenticator on that? Letting the Javascript communicate directly with the card reader breaks the FIDO security model exactly the same way... but Chrome allows it!
The problem with WebUSB is that it exposes devices that were built under the threat model that only trusted code would be able to access them to untrusted code. The set of devices acceptable for WebUSB use should have been a whitelist instead of a blacklist to be secure. Letting the user choose the device to grant access doesn't solve the problem, because the user doesn't have a way to understand what will happen when the site is granted access, per the FIDO example I gave above.
> But what if what you have connected to your computer is a USB NFC card reader, and the user taps their FIDO authenticator on that?
So the user would need to: 1. Keep the malicious page open, or install a malicious extension 2. Grant access to the card reader from a list of USB devices 3. Then tap their card on that reader
IMO a bad actor is going to have more success getting people to run an executable they made the browser download. There's only so much you can do to protect people from themselves. Not everyone needs software to be locked down like a padded room.
> The problem with WebUSB is that it exposes devices that were built under the threat model that only trusted code would be able to access them to untrusted code.
Which platforms have USB devices locked down to "trusted code" only?
> It's an incredibly useful API, and it's secure.
Citation needed. Web browsers, with their many CVEs, do not look like the pinnacle of security.
People are starting to ship even local apps only in the form of some html & js that only works on Chrome because only Chrome has webusb.
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.
Do you like the idea of installing Windows and installing some chinese drivers and some weird tool instead? Because that's the alternative to WebUSB.
I still want to reinvent the web with a hypertext document reader that doesn't include the kitchen sink. I suppose with LLMs these days this is actually an achievable prototype.
Conversely, a web app platform that includes all the primitives that are needed to build a decent web app (as opposed to bring your own everything/building castles from grains of sand model) would be nice. It doesn't necessarily have to be a browser, though.
We had those (Flash, Shockwave, Java Applets, etc.), the browser won.
Nobody is going to win over browsers with an opinionated batteries included application framework.
Those all had major issues. All of them were constrained to a browser environment, the first two were proprietary and full of security holes, and all of them had a reputation for causing browser or even full OS crashes.
I wouldn't say that any of them were particularly "batteries included", either. Flash was probably closest but still left a lot of legwork to the developer.
There are plenty of crippled web browsers out there. Heck, on iOS, it's the default.
nyxt? helium? midori?
There are hundreds of browsers these days, you shouldn't have a hard time finding one that fits your needs.
No offense, but you don't get it.
w3m, lynks, elinks? falkon?
I'm not sure what you mean given that JS and CSS account for at least half of the kitchen sink.
Hell, wasn't there someone that implemented an entire OS stack in CSS?
My point is a new standard, document format, and browser that doesn't have the capabilities which limits publishers to ... not what we have now.
The existence of elinks which is marginally useful on the modern web doesn't make the cut nor do tools to un-shitify the existing web.
What's the difference between that and a subset of what we have now, without, say WebUSB?
I'm talking about no javascript, no additional requests besides the bare document, no sending any information back home. Dynamic behavior only by a simple declarative language.
You are trying to express something that is logically impossible. Not technically difficult or socio-economically difficult to get companies to agree to or get users to care about, simply not a valid string of words.
There is no way not to send information back to the host.
Merely requesting a document is sending information to a host.
I don't mean all the extra metadata in the request header or cookies let alone the all the functionality in javascript or wasm or plugins, I mean nothing more than the name of a document, the bare minimum info required to get something you want it to give you.
If you want me to give you an apple, at the very least you have to tell me to give you an apple.
It all started with nothing more than that bare function, and we don't even want any less than that.
You do need to be able to request a document, and there is no way for a client to prevent a server from replacing a simple static document with a cgi script that performs logic based on the file name. Even without the extra cgi query string, just a document name itself.
But about query strings... there is no way to make a typical query string illegal anyway. It's all just strings of characters. Anything can be encoded within anything else. If you try to make a system that makes say the & and ? characters illegal, that accomplishes exactly nothing.
You just pick any sequence of legal charaters and interpret those in place of the old ? and &, and = and % and anything else you want that doesn't look like part of a legal file or document name.
The special encoded charaters can even be different for each document, even different for each request. It's not possible to make a rule that prevents it.
Let's go totally off the deep end and say that you aren't even allowed to make up your own file names any more. All documents on earth have known names in a whitelist. You can't encode anything because every valid document has a known name and known content. Then you can still encode information in the pattern of access. Requesting file A followed by file F means something extra to you and the server.
But don't take my naysayer defeatist lack of imagination word for it. Go ahead and try to actually explain how the system should work.
I started using this web browser in 1992...
https://en.wikipedia.org/wiki/Lynx_(web_browser)
It's about as stripped-down as the web can get.
This is great. It makes https://printervention.app (https://news.ycombinator.com/item?id=47677885) and the soon-to-be-released https://yes-we-scan.app work on Firefox.
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?
BBC Microbit kids hardware platform uses WebUSB. It’s a game changer for introducing hardware to students. Just works. Makecode.microbit.org is the web IDE. Reference URLs for the code make sharing and debugging easy.
Looks to be a great proof of concept. No, running a standalone executable alongside the browser is not the way you'd want to do WebUSB. But it's great to see someone working on it.
Running directly in the browser is also not how I'd want to do USB.
When the alternative is downloading arbitrary executables I find the browser sandbox to be a reassurance.
Except the sandbox is a huge target already, and breaking it means any website can now access and mess with your usb devices. If you can develop an exploit for Chrome's WebUSB system, you potentially have millions upon millions of targets available.
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.
> trust, anti virus software, audits, artifact signing, reproducible builds, etc
My mom has six weather apps on her phone.
Buddy if your "sandbox" lets code inside it replace your keyboard's firmware you don't have a sandbox.
Programming your keyboard is actually a common case! See usevia.app
It is indeed common!
But a keyboard flashed with malicious firmware becomes an undetectable keylogger, a USB rubber ducky, and a virus-laden USB stick all in one.
The concept that someone would want to reflash their keyboard firmware, but wants a sandbox because they don't trust the firmware programmer makes no sense.
Then don't install the extension
It is enabled without extension in Chrome browsers. This is a common complain about Firefox is that they don't implement the Google draft spec.
It will probably come natively one day in Firefox, and we should push back against such attack vectors.
Having WebUSB and WebBle everywhere would allow me to ship my IoT application via web only. That would be a win for my productivity, no more messing about with app store shenanigans.
Just heard of this. Still wondering if my fantasy CCTV DVR can serve a web app to my phone and stream the feed.
Hard to google, use "Web Bluetooth API" instead of webble
You probably don't need any Web hardware API for that, just WebRTC.
No thanks. I'll accept it in my browser when they fix the security implications this raises, and when the Spec is no longer in draft.
The security implications of not having WebUSB are having to install untrustworthy native drivers every time you want to interface with a USB device.
On macOS, I think I've installed device drivers exactly once in the last decade, and they were for a weird printer.
macOS allows USB access without installing a driver, so that's probably why. The "driver" is just part of the app.
That’s how most operating systems have worked for over two decades. Most OSes support USB devices that present themselves as HID, mass storage, audio, etc. without any dedicated drivers needed. It’s only specialized devices or functionality that tends to need additional drivers.
It's not even just USB classes that the OS provides a native driver for. I believe that on both iOS and macOS (not sure about newer Windows versions), you can essentially access USB as a byte streaming device.
If your app is the only one expected to communicate with a given device, you can then just directly embed the logic speaking that protocol in it. A driver is only needed if you want to provide a shared high-level abstraction to other applications as well.
Modern Windows also allows raw USB access for devices exposing specific WinUSB descriptor. So it's not just any device, but if it's yours device and your skills are sufficient to alter USB descriptors that device presents to the host, it's pretty painless.
Most device drivers nowadays aint necessary to solely get the device working, but to get it working well. All keyboards will work out of the box without any drivers/webusb-pages, but good luck configuring rapid triggers on your Wooting keyboard or a DPI-switching macro on your Logitech mouse without it.
The security implications if this goes mainstream is that you are expected to do this for all kinds of hardware.
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?
I felt that way too, but having used it a few devices as an end user I enjoy being able to close the browser and have the whole stack disappear. Instead of having to install a creepy Logitech tool to pair a mouse with a receiver, as soon as that task is done, goodbye Logitech. I guess a real concern is manufacturers stop offering native drivers, but for the majority of hardware the PnP or the Linux kernel just handle it.
There's a real risk of losing the ability to control your device if the manufacturer stops hosting their propertiary WebUSB app, too.
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.
My mouse uses a WebUSB app to configure stuff. I just downloaded all the files that it uses, and now I can use it offline.
> and can be reverse engineered long after its manufacturer has dropped support or gone under
Nothing really stops you from reverse-engineering a WebUSB app either.
So what is an example use case where you'd prefer to do X without using this particular tech?
The nice thing about USB devices is that they don't need native drivers. Hardware that requires native drivers for USB is pretty rare, at least for many common cases (keyboard, mice, controllers, joysticks, printers, dacs, headsets, cameras, ..), and are easy to avoid.
What product categories exist where all entries only work (over USB) with native drivers?
> 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 USB wireless keyboard and mouse work just fine without vendor software, but if I ever lost the dongle and had to re-pair them with a different dongle, I'd need the vendor's software to do it.
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.
why would you be using untrustworthy hardware to begin with?
everyone has a different threshold at which they would consider something 'untrustworthy'
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.
Sounds like something that could have a standalone usb-driver-container or special chromium fork for the 0.00001% of users that need it instead of bloating every browser with yet another niche API and the inevitable security holes it will bring.
People are already doing that in the experimental embedded world, and let me tell you, it's pain. True and utter pain. You're going to fight different versions of libusb's userland being installed, Windows/macOS/Linux kernel occupying the device with a default driver (cough rtl_sdr) and a whole lot of other messes.
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.
Let me guess, Razer which is known for auto-downloading kernel rootkits as soon you plug in your mouse? They’re basically the Riot Games of gaming peripherals.
Doesn't linux have the drivers already?
That sounds like a Windows problem.
Not really, as long as the firmware developers used OS 2.0 descriptors
(For the rare occurences that our customer is using 7 or earlier, we tell them to use zadig and be done with it.)
I'm not familiar with the Windows platform but although you can have userspace USB drivers on linux, you still need to be able to run code that can talk to the sysfs interface.
The Linux problem is more
Hope every time you want to interface with a USB device.
you do know microsoft OS 2.0 descriptors are a thing, right? or that you can force the unknown device to use WinUSB
but really most devices you want to interface to via webusb are CDC and DFU so.. problem solved?
I'm unfamiliar with the Windows platform but that sounds like something that still requires executing code locally.
Not sure what you mean.
Anyway OS 2.0 descriptors are a custom USB descriptor that basically tells the device to use WinUSB as the driver. The burden then is in the application that will have to implement the read/writes to the endpoints instead of using higher level functions provided by the custom driver.
If you ever developed software with libUSB, using WinUSB on the windows side makes things super easy for cross platform development, and you don't have to go through all the pain to have a signed driver. Win-win in my book.
.. or HID ( https://usevia.app/ , for programmable keyboards)
yes, you can always use some nasty protocol over HID for your devices. But really most of what i do is one or multiple bulk endpoints so i can achieve full bandwidth (downloading firmware, streaming data, ...) OS2.0 made it possible to do it without having to write and sign a driver
You can have userspace drivers for usb devices in Linux
How does the security of userspace drivers compare to having drivers within a sandboxed web environment with access to only the devices you’ve explicitly allowlisted?
It's about the same. People will blindly click allow on a webpage in the same way that they blindly run libusb binaries with `sudo` that they copied from some webpage. Security is possible in all of these scenarios, but always undermined by the users.
> It's about the same.
It's absolutely not the same. If I go to a WebUSB page to make my device work, it won't magically have access to all my private files and be able to upload them god knows where or to destroy them. Or access to my entire LAN. Or access to my other peripherals.
Any local driver/software will be able to. (Yes I am familiar with sandboxing technologies, they still aren't the default way to distribute apps outside of iOS/Android).
Yeah, but if you request webUSB access maliciously to some random device, an unsavvy user is likely to click ok without thinking about it. Its still very much a viable attack vector.
What are the security implications this raises that downloading native programs (needed for example to flash my smartphone) doesn't raise?
> What are the security implications this raises
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.
None. People will follow any instruction presented to them when they think it will get them something they want. Mozilla’s stance here is infuriating.
> What are the security implications this raises that downloading native programs (needed for example to flash my smartphone) doesn't raise?
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.
> Permission popups fatigue
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
> Native apps also have this, and it's worse because they usually just ask for sweeping admin access on windows
On iOS they only pop up the menu when they try to access the required functionality, and there's a limited number of things they can do.
> unlike WebUSB which just brings up a device selection menu
So the user has to contend with permissions on phones, in desktop OSes, but 26 more potential permissions [1] from a browser are fine because a) it's just a single permission window and b) the browser exists in total vacuum from all other user experiences.
[1] Counted in Chrome settings -> Site settings -> permissions. Why Chrome? Because they are the ones pushing all the hardware APIs, among others
> On iOS they only pop up the menu when they try to access the required functionality, and there's a limited number of things they can do.
great! your web browser does the exact same thing!
> 26 more potential permissions [1] from a browser are fine because a) it's just a single permission window and b) the browser exists in total vacuum from all other user experiences.
your argument is a non-sequitur; if I go install a firmware flasher, it is going to ask for permission to access the device I am flashing no matter what. on macos it will ask for "full disk access" for all your disks! on windows it will ask me "Do you want to allow this app to make changes to your device?" (what changes????). and then after that the app has to look at all of your devices and ask you which you want to use, and if there's a bug in the code, it might operate on the wrong one.
those OS permissions are confusing and obtuse, dare I say useless, and yet they still exist, and of course they cause fatigue!
whereas if you go to a webusb tool, the browser presents you a list of devices, with only the ones the app can use visible, and the app never gets more permission than it needs. it is simply a better UX and DX than the "permissions" cloud you're yelling at.
> your argument is a non-sequitur
Browsers don't exist in a vacuum. And yet everyone treats "yet another security pop up" as it does.
> those OS permissions are confusing and obtuse, dare I say useless, and yet they still exist, and of course they cause fatigue!
So let's add more?
> whereas if you go to a webusb tool
And yet you continue to pretend that it's only WebUSB that exists, or that users haven't been conditioned to give any and all permissions to any and all popups
The spec is still in draft because Apple refuses to let it move forward - because WebUSB, WebBluetooth and other APIs would compete with their app store, where they can make money from purchases made through apps. They prioritize profits over progress.
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.
> The spec is still in draft because Apple refuses to let it move forward
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.
Apple has provided no alternative, and no suggestions for how to improve the draft. They are not helping advance the draft only for selfish reasons.
They also won't allow any other browser on iOS for the same selfish reasons.
Apple continues to use abusive business tactics, and it's why they are being sued by the DOJ in an antitrust lawsuit. Them not implementing and not even suggesting changes to WebUSB and WebBluetooth are just further examples of it.
https://www.justice.gov/archives/opa/media/1344546/dl?inline
>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
So the alternative is installing questionable drivers from questionable websites that give an attacker full-access to the entire computer. This is far less good for security, and is unfortunately the norm right now.
>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.
So is every other browser API that's currently implemented that requires explicit approval from a user. It's nonsense to single out WebUSB specifically.
> It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
Bullshit. You have to explicitly allow WebUSB to interact with any website that requests it. It does NOT allow arbitrary tracking, and this sentence proves that whatever Mozilla writes about it is disingenuous, trying to incite hysteria about an API.
And I'll just fire up a chrome instance which I specifically keep for when my daily driver firefox decides to spazz out and not implement basics in 2026 :'(
Are you calling WebUSB a basic feature? Because I'm willing to discuss whether we should have it, but that seems like an exaggeration.
How do you make sure that technically illiterate people don't just click away the requestDevice() popup? IMHO a browser offering device level USB access is a security nightmare and there is no way this can ever be made safe and convenient at the same time.
Isn't that the same excuse Gooogle is using to lrevent folks from installing what they want on Android phones?
Essentially, yeah.
I do not agree with Google on preventing apk installation. But unknown apk is a different risk profile than letting unknown entities to access local usb devices.
The main issue in the former case is that google is posing itself as a gatekeeper instead of following a repo model like Debian or FreeBSD. That’s wanting control over people’s device.
Allowing USB access is just asking to break the browser sandbox, by equating the browser with the operating system.
You can ask them to type one of the following sentences:
"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."
I love this because the idiots would type out that they know what they're doing and the pros would save time by typing "I'm an idiot."
hah I did think of the second one, but the first didn't occur to me.
You simply don't. This quest of saving idiots from themselves is not gaining anyone anything and meanwhile other people get more and more useless restrictions.
Or you can just not give a loaded shotgun to every browser user on the off chance they need to interact with 1 (one) usb device per year.
Or you can just not use the web at all. If you're so scared of it, why are you using it with browsers that have implemented all kinds of APIs that probably already scare you? You may as well just use the Lynx browser if you really want want to put your money where your (security) mouth is. It doesn't do anything, not even display images or CSS or run Javascript.
I'm tired of my computing being kneecapped in service of incompetent boomers. Enough is enough. If they're going to fall for dumb scams let them.
They can click everything away, so maybe educate them or buy an ios device for your relatives instead of breaking computing for everyone else.
> breaking computing for everyone else
How is not implementing a Draft spec, which may compromise security badly, breaking computing?
Overreacting much?
This is not just an isolated incident, it's the whole trend of limiting capabilities in the name of security and that's what I was referring to.
However in this particular case, even the security argument doesn't hold, either I:
a) know that I want to use USB - in that case I'll switch browsers or download a native binary (even more unsafe), it's not that I'd decide that I no longer want to flash my smartphone
b) I don't understand what's happening but I follow arbitrary instructions anyway - WebUSB changes nothing.
A native binary can be verified by anti malware systems, and once installed and working, poses no security risk.
A 0day in a browser for the WebUSB system would allow any website to mess with arbitrary USB devices connected to your computer.
While the browser sandbox is generally safe, it is also a huge target, and with a security risk like that, it wouldn't surprise me if it's a prime target for black hats.
So instead of using trusted vendors or requiring tools with auditable code, we just allow everyone to be able to access the user’s devices?
What a concept. We could call it "Personal Computing."
Not really that personal when every webpage is itching to put their hands on it.
Fair, but remember that we are the <~1% of people who even know what webusb is. I'm not sure I share your view on this.
Maybe an about:config switch to enable it would be enough to stop casuals from pwning their peripherals.
I’d be ok with an about:config switch, but given that many people will install anything, paste arbitrary text into terminals, and share their password/pin code with complete strangers for almost no reason, I think we need to stop making our tools less powerful in pursuit of an impossible goal.
> They can click everything away, so maybe
So maybe don't populate the browser with dozens of features requiring permission popups?
Well, this seems like a terrible idea. I really don't want websites to be able to access hardware. I am already uncomfortable with the webcam access.
I see this slightly differently. Before, if I wanted to be able to do something like flash firmware onto some device I would have to download some random C++ application and install and run it on my local machine. As well as having access to all of my USB devices, it also had access to everything else on my system's user context. I didn't have a way of running that code and only giving it access to a single USB device and nothing else. Now, I can avoid installing anything at all. I visit the project page and opt-in to some flashing flow that's running in a sandboxed env. When the app requests it, the browser asks me for permission and I get to choose exactly which USB device I want to give it access too. That's picking exactly the minimum "outside" access I want to give it, nothing more. It doesnt get to read/write other USB devices I didnt choose. I doesnt get to read/write to my filesystem. It doesnt get to call system APIs. It doesnt get to set itself to start at startup. It doesnt get to install an auto-updater. For me, this is a better security posture than installing random win32 apps.
ok, let me expand on why I don't like it...
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.
If you're worried about that, you can just disable WebUSB in the chrome settings. Any website will be denied access to that API from now on. And what's even better: you can selectively enable WebUSB for some websites.
That's what I do and that's what I suggest for any security-conscious user to do. Just explore Chromium settings, there are dozens of various APIs that could be disabled. Do you need Web MIDI? I don't. Disable.
Won't work as a default setting for average user for sure, but if you consider yourself an advanced user, do that.
Flashing was already solved by UF2, where the device-to-flash temporarily pretends to be a USB storage device. Giving raw USB access to to random websites for that is massively overkill.
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 pretty common to pick a few config parameters, click, and flash a firmware that does the things you want.
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.
trivial for you maybe but many people don't know how and where to find the right firmware for their specific device, and can be in environments where the UF2 volume isn't as obvious (e.g. using a phone)
Are you more comfortable with installing native apps to control your hardware? Or you are more comfortable with opening a webpage to control your hardware?
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.
Whether we like it or not, the distinction between an app and a web page has already eroded, and is, and only will be, eroding more.
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.
They're converging towards the middle, which is good, but it's not going to be the same thing. Apps use web tech for convenience and native APIs for things you can't do in web. You're expected to trust apps and extensions more than websites.
That's fortunately easily fixed: Don't grant them access!
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.
Then don't select the device and don't press the 'allow' button when prompted.
It's already got access to CPU and RAM...how else do you think it works?
As much as I understand the ease of deployment this brings people, it puts a massive amount of code between the device and the user. Will webusb software written today work in 5, 10, 15 years? Personally, I think webusb is a giant contraption.
In 5, 10, and 15 years LLMs will make maintaining the massive amount of code trivial.
If history is a lesson (of going from lower level to higher level programming languages), the exact opposite will happen: there'll just be so much stuff out there that any eventual gain in efficiency will be dwarfed in the grand scheme of things.
Please, lord, let this be sarcasm.
And Web Serial reached mainline Firefox last week.
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.
The issue with Web Serial is it's not available for Android. Because for some dumb reason, android apps can't access /dev/ttyUSBx, even if kernel exposes them. But then can access raw USB devices. That's really weird. But if you need to access USB serial device in an android, you need to implement FTDI proprietary protocol or whatever adapter you're using by hand.
>And Web Serial reached mainline Firefox last week.
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.
I think they see privacy as one of their primary valueadds, and are concerned about the privacy implications with exposing a (PAN) network to the internet that probably wasn't designed to be exposed to such an adversarial environment.
> their silly role in the security theater of “but what if our users are dumb”
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.
They should just add a "Security Console", with black background and green text, and a simple shell interface for enabling/disabling flags that gate whether these requests are automatically denied or create a permissions popup. Anything dangerous starts disable by default.
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.
Yup, I would agree to an about:config
I keep chrome installed just to flash my meshcore devices... I doubt i'll try this but it's a nice step, hopefully we can get something akin to native adoption.
Will this work on Firefox Android? I recently wanted to try the printervention.app website to print from my phone over an OTG cable.
Firefox on Android doesn't support Native Messaging‡, so no, this extension won't work
‡: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Does this work with Web MiniDisc Pro?
So we can’t trust simple things like back-button hijacking, so let’s open up access to all attached hardware. Sounds stupid.
I really don't understand the use case. Why would I want hardware that I own to be managed by a web app that could disappear?
Interesting. So I could use that to install Graphene OS?
from a Graphene device!
is this satire? firefox does not implement it intentionally
Can't Mozilla hand over Firefox to another team?