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.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.
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.
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.
And you can also un-ship it whenever you want, leaving users with unusable devices they paid money for.
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.
This probably applies to many older (or even newer) USB devices as well.
It also convenient for developer, as distributing apps nowadays is a lot of hoops to jump over. Website is just a website.
Also website is cross-platform by definition, as long as API is supported across platforms and WebUSB API is supported on all platforms except iOS.
(Yes, you could try to bulid some common interface, libusb-style, but I think you'll have a bad time with minor behavioural differences, especially around permissions. libusb itself does ostensibly support Android but there are several caveats: https://github.com/libusb/libusb/wiki/Android#does-libusb-su... )
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.
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.
As opposed to dodgy windows-only installable software from some weird site to flash devices instead? I’ll take my chances with webusb, thanks.
Should we disallow clicking on anything on a webpage too?
WebUSB is no more risky than any other tech. You have to explicitly opt-in to use WebUSB on any site requesting access to it. And I'm sorry if someone's grandfather trusts a malicious website and gets hacked, but that isn't a reason to prevent the rest of us from using tech that enables functionality on non-malicious websites that serves a useful purpose.
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.
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.
https://en.wikipedia.org/wiki/Lynx_(web_browser)
It's about as stripped-down as the web can get.
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?
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
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.
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.
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).
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
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.
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.
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.
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.
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...