They should have tested something else, like a raw H265 4K video or something.
Can't imagine "pro" users would be amazed by the battery life of watching netflix.
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.
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.
Hmm, that's probably somewhat fair. While you're using a protocol that's only intended to update the key map, it's probably not hardened against attacks.
Regardless, the real reason people use this is because it's incredibly convenient compared with using QMK and ZMK directly.
Of all the browser features I would consider disabling in the name of security, the ability to talk to my trackpad and printer is pretty much at the bottom of the list. I'd start with the JIT compiler, filesystem APIs, all of the video codecs, probably many of the image codecs, cookies and localstorage, webgl/webgpu, the crash collector, the auto updater...
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.
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.
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.
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.
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.
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.
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.
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?
> 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 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.
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.
Sounds like something that could have a standalone usb-driver-container or special chromium fork for the 0.00001% of users that need it instead of bloating every browser with yet another niche API and the inevitable security holes it will bring.
People are already doing that in the experimental embedded world, and let me tell you, it's pain. True and utter pain. You're going to fight different versions of libusb's userland being installed, Windows/macOS/Linux kernel occupying the device with a default driver (cough rtl_sdr) and a whole lot of other messes.
Or some things aren't even available made using libusb. Think control applications for RGB lights in keyboard and mice. There's a certain manufacturer all but mandating installation of its slopware. Being able to provide all of this as WebUSB has advantages.
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.
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.
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
How does the security of userspace drivers compare to having drivers within a sandboxed web environment with access to only the devices you’ve explicitly allowlisted?
It's about the same. People will blindly click allow on a webpage in the same way that they blindly run libusb binaries with `sudo` that they copied from some webpage. Security is possible in all of these scenarios, but always undermined by the users.
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).
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.
> 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.
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.
> 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.
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
> 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
> 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.
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
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!"
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.
> 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.
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.
> 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?
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 spec is still in draft because Apple refuses to let it move forward
…is simply untrue. Apple cannot stop it from being a standard by refusing to implement it. As long as anybody else is willing to produce a second implementation it can be a standard.
The thing that is preventing it from being a standard is that nobody is willing to do this.
If Apple did not even exist then WebUSB would be no closer at all to being a standard.
I didn't avoid anything. My first sentence spelled it out:
"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 prefer to let the spec die, instead of proposing anything that would help it move forward because they are using abusive business tactics to stifle innovation for their own greedy purposes.
They simply do not want the web to compete with their app store. It is that simple.
And I'll just fire up a chrome instance which I specifically keep for when my daily driver firefox decides to spazz out and not implement basics in 2026 :'(
How do you make sure that technically illiterate people don't just click away the requestDevice() popup? IMHO a browser offering device level USB access is a security nightmare and there is no way this can ever be made safe and convenient at the same time.
I 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.
You simply don't. This quest of saving idiots from themselves is not gaining anyone anything and meanwhile other people get more and more useless restrictions.
Or you can just not 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.
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.
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.
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.
> can not be expected to have enough depth of knowledge in their brain to actually talk about
What is the use of a CEO if not to have enough depth of knowledge about the different aspects of running a business?
Like what? Poor little CEO that doesn't understand anything about the world and how to run a company. Seems like helplessness is expected at every stage.
> What is the use of a CEO if not to have enough depth of knowledge about the different aspects of running a business?
Bit of a difference between “having depth of knowledge in their business” and “can speak off-the-cuff with the necessary accuracy to remain in compliance with every contract and legal jurisdiction their organisation is engaged in, without consulting the numerous domain experts they employ for just this purpose,” isn’t there.
Also, such a situation that requires the CEO’s direct attention has already gone FAR beyond your standard incidents where you can throw out a pre written statement. Do you want your organisation just cuffing it from the top down? Are you Elon Musk in disguise?
Take the lead couldn't be more different than act by themselves.
Take the lead, yes they should be able to as that's the job pretty much.
Act by themselves, sure they can make decisions in small cases. But on big things you hear everybody's input, weigh it, and only if needed, cast the deciding vote.
Yeah I found this comment to be weird. At least the XZ backdoor was found before it went live anywhere. How many companies were hit by the Solarwind supply chain attacks?
Napoleon somehow did not have very much trouble doing just that back in the day.
But it's of course not limited to small arms distributed among the population. There are many more preparations done in advance, like rocks prepared to block roads if an explosive charge is detonated. Same with various bridges and railroad choke points. There's a large network of shelters and bunkers, kept in a good shape. Etc, etc.
The point is not that a huge army (like Hitler's in 1940) would not be able to overrun Swiss resistance. The point is that the cost of such an invasion would be prohibitively high. It serves as a good deterrent.
You proved my point. Doesn't really have to do with the gun owning population but to the unique geography of the country giving them a massive advantage.
> I think just putting it on the companies is enough. If the fines are serious and can put your company out of business
They don't care. It's either never enough to make them care, or the company can just bankrupt and you go do something else.
If you or your manager has the threat of jail in the back of their mind, it's no longer just someone else's money being lost, it's personal.
> If everyone knows that messing up security gets you in real trouble and the company loses real money
There's already huge fines on paper for this, but never ever are the fines enough. It's always factored in the "cost of doing business". Also it's still someone else's money, why would an engineer care?
Please show me a GDPR fine that hit hard enough to scare companies into not fucking up? Evidently here it was not enough for Fiverr.
Edit: Just to provide an example, Takata airbags have been recalled massively (if you don't know why, look it up) but the company is now bankrupted and who is footing the bill? Their customers.
You cannot impose a fine on them, as it's bankrupt (now, but it was always the plan). They deliberately sold dangerous airbags and now what can you do so it doesn't happen again? Fine them some more? or maybe throw a few execs in jail because they knew of the problem and continued as usual.
reply