41 comments

[ 5.7 ms ] story [ 72.1 ms ] thread
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.
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 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.
Can't Mozilla hand over Firefox to another team?
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.
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.

This brings back bad memories of the old ActiveX "safe for scripting" mechanism.
Interesting. So I could use that to install Graphene OS?
from a Graphene device!
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.
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.

It's already got access to CPU and RAM...how else do you think it works?
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.

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.
Exactly, how is an open, browser-based standard any worse than having to download an executable (often limited to mac/windows only) with opaque permissions?

The fact they have to be installed/uninstalled too is another inefficiency.

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.
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?
Will this work on Firefox Android? I recently wanted to try the printervention.app website to print from my phone over an OTG cable.
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.
WebUSB is the main way to flash GrapheneOS onto a phone.
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
> 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.

> 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.

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.
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.
Does this work with Web MiniDisc Pro?
I just did a quick test with a N920 on Windows (Zadig installed, WebUSB stub installed) and I get the popup from Firefox and see the N920 in the extension but WMDpro fails with "Transfer error"

I'm pretty sure the lead dev is a Firefox user so he may be interested in getting this to work: https://github.com/asivery/webminidisc

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.

is this satire? firefox does not implement it intentionally
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.
MeshCore also uses WebBluetooth for some very useful stuff when working with MeshCore devices. :)