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.
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
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!
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.
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.
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?
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.
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
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.
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.
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.
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?
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
>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 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.
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
1 reply →
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!
1 reply →
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 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?
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.
I used it to side-load Android apps onto my Quest 3 so I could try Chromium on it
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
2 replies →
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.
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.
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.
2 replies →
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?
4 replies →
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.
25 replies →
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
2 replies →
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.
2 replies →
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.
7 replies →
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.
5 replies →
Then don't install the extension
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.
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?
2 replies →
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?
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.
4 replies →
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?
4 replies →
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?
2 replies →
why would you be using untrustworthy hardware to begin with?
1 reply →
Doesn't linux have the drivers already?
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.
2 replies →
That sounds like a Windows problem.
3 replies →
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?
4 replies →
You can have userspace drivers for usb devices in Linux
4 replies →
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.
3 replies →
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.
1 reply →
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.
20 replies →
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.
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.
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.
>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.
1 reply →
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
[dead]
Can't Mozilla hand over Firefox to another team?