Rendered at 19:09:25 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ezst 1 days ago [-]
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.
QuantumNomad_ 24 hours ago [-]
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.
crote 24 hours ago [-]
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!
tredre3 23 hours ago [-]
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.
crtasm 19 hours ago [-]
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
thayne 17 hours ago [-]
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.
jasomill 20 hours ago [-]
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.
surajrmal 20 hours ago [-]
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
ocdtrekkie 18 hours ago [-]
It just can't run on any device with a security policy in place.
Someone 12 hours ago [-]
> 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.
inetknght 18 hours ago [-]
> 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.
cruffle_duffle 16 hours ago [-]
How is it any different with downloadable firmware?
darkwater 13 hours ago [-]
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?
Gander5739 21 hours ago [-]
WebUSB is the main way to flash GrapheneOS onto a phone.
DANmode 17 hours ago [-]
You can even do it from another Graphene phone!
One that’s been using Attestation, for bonus points.
vishalontheline 24 hours ago [-]
Another possible use-case: allowing your peripherals to talk to cloud gaming computers - like, a nice HOTAS setup for flight simulator on GeforceNow.
traderj0e 23 hours ago [-]
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
flexagoon 22 hours ago [-]
> 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
traderj0e 21 hours ago [-]
Yeah but still, I'd want that to only remotely be a thing. Like require enabling a developer setting for it.
Rohansi 18 hours ago [-]
That's a great way to kill adoption of a feature. But what has WebUSB done to you?
Griffinsauce 12 hours ago [-]
Why? The permission dialog is crystal clear.
traderj0e 2 hours ago [-]
It's only sorta ok right now because nothing uses it normally. If it were used mainstream for some legitimate purpose, that permission dialog would get ignored, and it'd become a security risk. USB isn't something web needs to touch unless you really know what you're doing.
somehnguy 19 hours ago [-]
Chrome has had WebUSB since 2017. I really appreciate it for one-off configurators and those types of tools.
koolala 23 hours ago [-]
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.
koolala 23 hours ago [-]
I used it to side-load Android apps onto my Quest 3 so I could try Chromium on it
nezza-_- 1 days ago [-]
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.
scottbez1 1 days ago [-]
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.
M95D 12 hours ago [-]
> 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.
circuit10 6 hours ago [-]
You can ship an offline, standalone HTML file you can open in your browser too (this might not happen often but my point is it's not inherent to the technology)
542458 10 hours ago [-]
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.
lxgr 1 days ago [-]
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.
ACCount37 1 days ago [-]
Aren't most retrocomputing USB devices running open source firmware? Adding a descriptor "WebUSB supported" is a few commits and a firmware update away.
oofdere 23 hours ago [-]
that's not going to work for use cases like the https://webmd.pro where you're interfacing with hardware from other manufacturers
lxgr 22 hours ago [-]
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.
jasomill 9 hours ago [-]
This brings back bad memories of the old ActiveX "safe for scripting" mechanism.
gear54rus 1 days ago [-]
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.
miladyincontrol 1 days ago [-]
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.
sva_ 1 days ago [-]
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.
infogulch 1 days ago [-]
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.
embedding-shape 1 days ago [-]
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?
Retr0id 1 days ago [-]
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... )
It uses libusb, so yes, modulo aforementioned documented caveats (as well as the undocumented ones)
vbezhenar 10 hours ago [-]
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.
lxgr 22 hours ago [-]
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.
lxgr 1 days ago [-]
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.
Shalomboy 1 days ago [-]
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.
lxgr 1 days ago [-]
> 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?
dylan604 1 days ago [-]
> 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.
concinds 1 days ago [-]
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.
dylan604 1 days ago [-]
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...".
lxgr 22 hours ago [-]
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?
dylan604 22 hours ago [-]
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
lxgr 21 hours ago [-]
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?
dwaite 22 hours ago [-]
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.
lxgr 22 hours ago [-]
> 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.
skydhash 22 hours ago [-]
> 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.
lxgr 22 hours ago [-]
> 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.
leptons 1 days ago [-]
>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.
bcjdjsndon 8 hours ago [-]
> The sky is not falling, and WebUSB is not going to cause it to fall.
You could always write a native app. It's always been possible that way.
DANmode 17 hours ago [-]
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.
dwaite 22 hours ago [-]
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.
lxgr 22 hours ago [-]
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?
dylan604 21 hours ago [-]
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.
lxgr 21 hours ago [-]
That would indeed be horrible, which is why storage devices are explicitly excluded from WebUSB.
dylan604 20 hours ago [-]
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.
suryajena 1 days ago [-]
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?
lxgr 1 days ago [-]
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.
skybrian 1 days ago [-]
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.
lxgr 22 hours ago [-]
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.
leptons 1 days ago [-]
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.
cruffle_duffle 16 hours ago [-]
“ 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.
I've used Firefox successfully twice. I have nextdns on my router, not sure if that helped.
uyzstvqs 20 hours ago [-]
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.
ninkendo 19 hours ago [-]
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.
Rohansi 17 hours ago [-]
> 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
Borealid 15 hours ago [-]
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.
Rohansi 14 hours ago [-]
> 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?
hulitu 13 hours ago [-]
> 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.
saagarjha 8 hours ago [-]
Web browsers, with their many CVEs, are the pinnacle of security.
bauratynov 13 hours ago [-]
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.
vbezhenar 10 hours ago [-]
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.
StingyJelly 8 hours ago [-]
You have to balance the this ease of use with increasing potential attack and fingerprinting surface. Correct approach is something in the middle - a separate off-by-default setting or recommended official extension.
vbezhenar 8 hours ago [-]
Chrome has the option to turn off APIs by default. I do it for my installs. I think that disabling that option for everyone is not a good approach as average user will never figure out how to enable it, making that technology effectively dead, so we get back to installing host software.
Sometimes security and usability contradict with each other.
bjord 9 hours ago [-]
...in your opinion. the firefox team disagrees.
vbezhenar 8 hours ago [-]
They already killed Firefox. It has 2% marketshare. Next to something called "Samsung Internet" LoL. They're not in position to force technology usage.
Hendrikto 6 hours ago [-]
> In order to use this, you need to both install the extension in your browser and install a small program (separate from the browser) on your computer. This extra program is called the "native stub".
Idk. Sure it has security advantages, but that sounds like to much of a hassle for 90% of users.
kgwxd 8 hours ago [-]
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.
Brian_K_White 1 days ago [-]
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.
vbezhenar 10 hours ago [-]
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.
Brian_K_White 7 hours ago [-]
It doesn't matter whether we like or dislike things that don't exist. The world where app makers don't ship this way doesn't exist.
colechristensen 1 days ago [-]
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.
cosmic_cheese 22 hours ago [-]
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.
colechristensen 22 hours ago [-]
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.
cosmic_cheese 22 hours ago [-]
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.
sagarm 23 hours ago [-]
There are plenty of crippled web browsers out there. Heck, on iOS, it's the default.
angra_mainyu 23 hours ago [-]
nyxt? helium? midori?
There are hundreds of browsers these days, you shouldn't have a hard time finding one that fits your needs.
hollerith 22 hours ago [-]
No offense, but you don't get it.
goodmythical 21 hours ago [-]
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?
colechristensen 20 hours ago [-]
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.
spankalee 18 hours ago [-]
What's the difference between that and a subset of what we have now, without, say WebUSB?
colechristensen 17 hours ago [-]
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.
Brian_K_White 14 hours ago [-]
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.
colechristensen 7 hours ago [-]
Ok tone it down a little.
Caching, distributed sharing, the lack of a redirect mechanism or cookies all can contribute particularly if the goal is kneecapping surveillance but not the platonic ideal of secrecy.
For example, you can't do very much surveillance with DNS or bittorrent.
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.
afavour 1 days ago [-]
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.
Orygin 1 days ago [-]
Running directly in the browser is also not how I'd want to do USB.
afavour 1 days ago [-]
When the alternative is downloading arbitrary executables I find the browser sandbox to be a reassurance.
Orygin 1 days ago [-]
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.
Buddy if your "sandbox" lets code inside it replace your keyboard's firmware you don't have a sandbox.
sagarm 23 hours ago [-]
Programming your keyboard is actually a common case! See usevia.app
michaelt 22 hours ago [-]
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.
bastawhiz 1 days ago [-]
Then don't install the extension
Orygin 10 hours ago [-]
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.
coupdejarnac 1 days ago [-]
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.
aitchnyu 24 hours ago [-]
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
coupdejarnac 23 hours ago [-]
You probably don't need any Web hardware API for that, just WebRTC.
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?
Orygin 1 days ago [-]
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.
Retr0id 1 days ago [-]
The security implications of not having WebUSB are having to install untrustworthy native drivers every time you want to interface with a USB device.
tjoff 1 days ago [-]
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?
mzmzmzm 1 days ago [-]
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.
1 days ago [-]
cosmic_cheese 22 hours ago [-]
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.
KomoD 13 hours ago [-]
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.
cosmic_cheese 3 hours ago [-]
The question is if users will consistently have the foresight to archive such web apps, especially if the manufacturer has set up their bots.txt such that The Internet Archive skips it.
Traditional programs are incedentally archived by nature of having to be downloaded. They sit in downloads folders, old backups, thumb drives, etc.
kid64 1 days ago [-]
So what is an example use case where you'd prefer to do X without using this particular tech?
rafram 1 days ago [-]
On macOS, I think I've installed device drivers exactly once in the last decade, and they were for a weird printer.
lxgr 1 days ago [-]
macOS allows USB access without installing a driver, so that's probably why. The "driver" is just part of the app.
otterley 1 days ago [-]
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.
lxgr 22 hours ago [-]
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.
vbezhenar 10 hours ago [-]
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.
kristofferR 1 days ago [-]
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.
eikenberry 24 hours ago [-]
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?
tredre3 23 hours ago [-]
> 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.
michaelt 23 hours ago [-]
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.
fhn 1 days ago [-]
why would you be using untrustworthy hardware to begin with?
jazzyjackson 1 days ago [-]
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.
1313ed01 1 days ago [-]
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.
mschuster91 1 days ago [-]
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.
xeonmc 1 days ago [-]
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.
ozgrakkurt 1 days ago [-]
Doesn't linux have the drivers already?
skydhash 1 days ago [-]
That sounds like a Windows problem.
monegator 1 days ago [-]
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.)
Retr0id 1 days ago [-]
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.
Lerc 1 days ago [-]
The Linux problem is more
Hope every time you want to interface with a USB device.
monegator 1 days ago [-]
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?
Retr0id 1 days ago [-]
I'm unfamiliar with the Windows platform but that sounds like something that still requires executing code locally.
monegator 1 days ago [-]
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.
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
PunchyHamster 1 days ago [-]
You can have userspace drivers for usb devices in Linux
scottbez1 1 days ago [-]
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?
bigfishrunning 1 days ago [-]
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.
tredre3 23 hours ago [-]
> 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).
bigfishrunning 17 hours ago [-]
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.
toraway 2 hours ago [-]
> you request webUSB access maliciously to some random device
> an unsavvy user is likely to click ok
That's not how WebUSB works, the user always has to pick the device themselves from a list. The list cannot have a device pre-selected, and the "Connect" button is greyed out until the user makes a choice themselves.
The default "wtf? get this out of my face" path for a confused user is "Cancel".
The list can be filtered with vendorId filters defined ahead of time, but even if only a single device qualifies the user still has to chose to click it to enable the "Connect" button.
Once a device has been selected, it is considered "paired" to that specific site and the site can see its presence if available on future page loads. The user can revoke access/"unpair" from the site permissions button.
What are the security implications this raises that downloading native programs (needed for example to flash my smartphone) doesn't raise?
b1temy 17 hours ago [-]
> 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.
barnabee 1 days ago [-]
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.
troupo 1 days ago [-]
> 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.
oofdere 22 hours ago [-]
> 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
troupo 21 hours ago [-]
> 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
oofdere 20 hours ago [-]
> 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.
troupo 13 hours ago [-]
> 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
toraway 2 hours ago [-]
The user has to choose a device themselves. The only enabled button when a WebUSB prompt appears is "Cancel" until they make a choice themselves.
A confused user will likely hit the only available button to "Cancel" which ends the process without granting any permissions.
By design it's a more conservatively designed approval prompt compared to e.g. accessing a camera or microphone where users get presented with a equally weighted "yes/no" decision.
Also, the website can't enumerate connected devices until access is granted individually. The API call to request a device allows filtering by pre-defined vendor IDs, but with no visibility into what's connected. Meaning an attacker has to choose between:
1. showing a list of a half dozen options, which will confuse the user and likely make them cancel, or 2. narrowly target it hoping for a single result to improve odds they blindly choose it, which increases odds no devices will appear at all.
And since they can't enumerate devices until granted access, that prevents a targeted attack with e.g. a red flashing "WARNING: Your computer is infected! Pick 'USB 10/100/1000 LAN' and click 'Connect' to erase viruses immediately!"
leptons 1 days ago [-]
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.
JimDabell 1 days ago [-]
> 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.
Until Google can convince anybody outside of Blink to implement it, it is not a standard it’s a Blink-only API.
leptons 22 hours ago [-]
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.
bcjdjsndon 8 hours ago [-]
> 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
WebUSB isn't a driver, it relies on underlying usb drivers. What is the need here for a webpage that also needs to access specific hardware not exposed generically?
leptons 2 hours ago [-]
>WebUSB isn't a driver, it relies on underlying usb drivers.
I never said WebUSB "was a driver". But it does not rely on specific usb device drivers being installed for specific devices.
>What is the need here for a webpage that also needs to access specific hardware not exposed generically?
There are already plenty. You don't need to ask me because you'll likely just shit on what I write, so here's a list compiled by someone else:
I'm more interested in WebBluetooth, which Apple is also blocking from standardization. I manufacture a bluetooth enabled device that I'd like to have a simple web application to interface with, rather than needing to pay Apple for the privledge to develop an app for their app store, where they can then extort me for $$$ for any sales made through the app.
It's no different for WebUSB, it has many, many uses, but Apple is choosing profit over progress.
gear54rus 1 days ago [-]
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 :'(
yjftsjthsd-h 1 days ago [-]
Are you calling WebUSB a basic feature? Because I'm willing to discuss whether we should have it, but that seems like an exaggeration.
lpcvoid 1 days ago [-]
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.
limagnolia 1 days ago [-]
Isn't that the same excuse Gooogle is using to lrevent folks from installing what they want on Android phones?
baby_souffle 1 days ago [-]
Essentially, yeah.
skydhash 1 days ago [-]
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.
exe34 1 days ago [-]
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."
jayd16 1 days ago [-]
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."
exe34 1 days ago [-]
hah I did think of the second one, but the first didn't occur to me.
mvdtnz 15 hours ago [-]
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.
gear54rus 1 days ago [-]
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.
Orygin 1 days ago [-]
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.
leptons 22 hours ago [-]
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.
zb3 1 days ago [-]
They can click everything away, so maybe educate them or buy an ios device for your relatives instead of breaking computing for everyone else.
Orygin 1 days ago [-]
> breaking computing for everyone else
How is not implementing a Draft spec, which may compromise security badly, breaking computing?
Overreacting much?
zb3 1 days ago [-]
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.
Orygin 1 days ago [-]
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.
skydhash 1 days ago [-]
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?
CamperBob2 1 days ago [-]
What a concept. We could call it "Personal Computing."
skydhash 1 days ago [-]
Not really that personal when every webpage is itching to put their hands on it.
lpcvoid 1 days ago [-]
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.
barnabee 1 days ago [-]
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.
troupo 1 days ago [-]
> They can click everything away, so maybe
So maybe don't populate the browser with dozens of features requiring permission popups?
chillfox 1 days ago [-]
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.
deeringc 24 hours ago [-]
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.
chillfox 12 hours ago [-]
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.
vbezhenar 10 hours ago [-]
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.
crote 24 hours ago [-]
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?
mlyle 23 hours ago [-]
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.
oofdere 23 hours ago [-]
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)
Brian_K_White 1 days ago [-]
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.
traderj0e 23 hours ago [-]
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.
lxgr 22 hours ago [-]
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.
vbezhenar 10 hours ago [-]
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.
q3k 1 days ago [-]
Then don't select the device and don't press the 'allow' button when prompted.
goodmythical 21 hours ago [-]
It's already got access to CPU and RAM...how else do you think it works?
MisterTea 1 days ago [-]
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.
charcircuit 1 days ago [-]
In 5, 10, and 15 years LLMs will make maintaining the massive amount of code trivial.
ezst 1 days ago [-]
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.
MisterTea 23 hours ago [-]
Please, lord, let this be sarcasm.
1 days ago [-]
prism56 23 hours ago [-]
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.
Zopieux 1 days ago [-]
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.
vbezhenar 10 hours ago [-]
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.
catfood 1 days ago [-]
>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.
monocasa 20 hours ago [-]
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.
troupo 1 days ago [-]
> 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.
strbean 23 hours ago [-]
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.
troupo 21 hours ago [-]
Yup, I would agree to an about:config
suryajena 1 days ago [-]
Will this work on Firefox Android? I recently wanted to try the printervention.app website to print from my phone over an OTG cable.
RunningDroid 1 days ago [-]
Firefox on Android doesn't support Native Messaging‡, so no, this extension won't work
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.
Still not quite WebUSB-easy, but a massive improvement over needing dedicated programming software!
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/
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.
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.
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.
Hope you enjoy that same sentiment is 20 years when the website to control/manage your device doesn't exist/was bought out/whatever.
One that’s been using Attestation, for bonus points.
Edit: Wait, no we didn't. Chrome added WebUSB support after all. Wtf I'm disabling that
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
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.
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.
And you can also un-ship it whenever you want, leaving users with unusable devices they paid money for.
This probably applies to many older (or even newer) USB devices as well.
(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... )
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.
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
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.
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?
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.
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.
Yes, bad actors exist, but why concede every single nice thing to them?
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.
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.
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.
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.
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.
You could always write a native app. It's always been possible that way.
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.
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.
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?
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.
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.
As opposed to dodgy windows-only installable software from some weird site to flash devices instead? I’ll take my chances with webusb, thanks.
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.
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.
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.
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?
Citation needed. Web browsers, with their many CVEs, do not look like the pinnacle of security.
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.
Sometimes security and usability contradict with each other.
Idk. Sure it has security advantages, but that sounds like to much of a hassle for 90% of users.
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.
Nobody is going to win over browsers with an opinionated batteries included application framework.
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 hundreds of browsers these days, you shouldn't have a hard time finding one that fits your needs.
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?
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.
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.
Caching, distributed sharing, the lack of a redirect mechanism or cookies all can contribute particularly if the goal is kneecapping surveillance but not the platonic ideal of secrecy.
For example, you can't do very much surveillance with DNS or bittorrent.
https://en.wikipedia.org/wiki/Lynx_(web_browser)
It's about as stripped-down as the web can get.
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.
My mom has six weather apps on her phone.
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.
It will probably come natively one day in Firefox, and we should push back against such attack vectors.
Hard to google, use "Web Bluetooth API" instead of webble
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?
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?
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.
> 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.
Traditional programs are incedentally archived by nature of having to be downloaded. They sit in downloads folders, old backups, thumb drives, etc.
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.
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 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.
but really most devices you want to interface to via webusb are CDC and DFU so.. problem solved?
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.
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).
The default "wtf? get this out of my face" path for a confused user is "Cancel".
The list can be filtered with vendorId filters defined ahead of time, but even if only a single device qualifies the user still has to chose to click it to enable the "Connect" button.
Once a device has been selected, it is considered "paired" to that specific site and the site can see its presence if available on future page loads. The user can revoke access/"unpair" from the site permissions button.
See example below of the pairing process:
https://imgur.com/a/HkpHBW5
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.
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
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
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
A confused user will likely hit the only available button to "Cancel" which ends the process without granting any permissions.
By design it's a more conservatively designed approval prompt compared to e.g. accessing a camera or microphone where users get presented with a equally weighted "yes/no" decision.
https://imgur.com/a/5glTxvh
Also, the website can't enumerate connected devices until access is granted individually. The API call to request a device allows filtering by pre-defined vendor IDs, but with no visibility into what's connected. Meaning an attacker has to choose between:
1. showing a list of a half dozen options, which will confuse the user and likely make them cancel, or 2. narrowly target it hoping for a single result to improve odds they blindly choose it, which increases odds no devices will appear at all.
And since they can't enumerate devices until granted access, that prevents a targeted attack with e.g. a red flashing "WARNING: Your computer is infected! Pick 'USB 10/100/1000 LAN' and click 'Connect' to erase viruses immediately!"
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.
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.
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.
WebUSB isn't a driver, it relies on underlying usb drivers. What is the need here for a webpage that also needs to access specific hardware not exposed generically?
I never said WebUSB "was a driver". But it does not rely on specific usb device drivers being installed for specific devices.
>What is the need here for a webpage that also needs to access specific hardware not exposed generically?
There are already plenty. You don't need to ask me because you'll likely just shit on what I write, so here's a list compiled by someone else:
https://github.com/webusb/awesome
That just scratches the surface.
I'm more interested in WebBluetooth, which Apple is also blocking from standardization. I manufacture a bluetooth enabled device that I'd like to have a simple web application to interface with, rather than needing to pay Apple for the privledge to develop an app for their app store, where they can then extort me for $$$ for any sales made through the app.
It's no different for WebUSB, it has many, many uses, but Apple is choosing profit over progress.
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 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."
How is not implementing a Draft spec, which may compromise security badly, breaking computing?
Overreacting much?
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 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.
Maybe an about:config switch to enable it would be enough to stop casuals from pwning their peripherals.
So maybe don't populate the browser with dozens of features requiring permission popups?
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
‡: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...