WebUSB Extension for Firefox

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.

https://get.vial.today/

This probably applies to many older (or even newer) USB devices as well.

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.

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

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?

As opposed to dodgy windows-only installable software from some weird site to flash devices instead? I’ll take my chances with webusb, thanks.

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.

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.

Nobody is going to win over browsers with an opinionated batteries included application framework.

Downloading an arbitrary executable can be made safe (via multiple avenues: trust, anti virus software, audits, artifact signing, reproducible builds, etc) and once the software is vetted, it exposes (or it should at least) little to no attack vector during daily use.

It will probably come natively one day in Firefox, and we should push back against such attack vectors.

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.

All the categories you've listed have products that require a companion application to configure things out of band, that the "universal" driver doesn't understand.

In the case of the four HID you've listed the app would be for configuring key mapping, macros, rgb, firmware updates.

Some webcams need apps to control things not exposed by the native driver (things like head tracking or more specific sensor control).

I'm not familiar with the market but I would imagine that many headsets and DACs nowadays have similar apps to tune EQs presets and the like.

My bluetooth headphones work just fine without vendor software, but apparently with an app I can adjust the audio to somehow make me better at playing computer games. I think it amplifies other players' footsteps or something? If I wanted that, I'd need the vendor's software to do it.

My PSU works just fine without vendor software, but includes a USB monitoring interface, which would let me see certain things like fan speeds, voltages and currents. Of course I can monitor most of those with my motherboard's existing sensors; and a dip in the 12v rail will power off the system before any monitoring could respond. But if I did want to use those features, I'd need the vendor's software to do it.

Despite my distrust for vendor software, I have even less trust for webusb. Partly that's because I'm a hater in general, but mostly it's because there are too many holes in the web browser's sandbox already - if things in the sandbox are re-flashing your keyboard firmware you've given up on sandboxing, you just haven't admitted it to yourself yet.

Curious what your floor is for 'trustworthy', a company with a US headquarters? Personally I feel sketched out by any silicon not made in Sweden or Japan, so, pretty much all of it.

Or some things aren't even available made using libusb. Think control applications for RGB lights in keyboard and mice. There's a certain manufacturer all but mandating installation of its slopware. Being able to provide all of this as WebUSB has advantages.

(For the rare occurences that our customer is using 7 or earlier, we tell them to use zadig and be done with it.)

Hope every time you want to interface with a USB device.

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

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.

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

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.

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.