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.
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.
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. 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.
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.
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.
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’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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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
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. 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.
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.
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.
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.
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.
They can click everything away, so maybe educate them or buy an ios device for your relatives instead of breaking computing for everyone else.
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.
> 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.
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?
> They can click everything away, so maybe
So maybe don't populate the browser with dozens of features requiring permission popups?
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."
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.
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.
Are you calling WebUSB a basic feature? Because I'm willing to discuss whether we should have it, but that seems like an exaggeration.
The security implications of not having WebUSB are having to install untrustworthy native drivers every time you want to interface with a USB device.
That sounds like a Windows problem.
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.
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.)
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.
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
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.
On macOS, I think I've installed device drivers exactly once in the last decade, and they were for a weird printer.
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.
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.
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?
So what is an example use case where you'd prefer to do X without using this particular tech?
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.
What are the security implications this raises that downloading native programs (needed for example to flash my smartphone) doesn't raise?
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.
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.
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.
Then don't select the device and don't press the 'allow' button when prompted.
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.
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.
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.
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.
> 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.
Interesting. So I could use that to install Graphene OS?
Can't Mozilla hand over Firefox to another team?