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.
Hope every time you want to interface with a USB device.
(For the rare occurences that our customer is using 7 or earlier, we tell them to use zadig and be done with it.)
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).
> you request webUSB access maliciously to some random device
> an unsavvy user is likely to click ok
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:
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.
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.
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.
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.
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.
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.
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.
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 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.
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 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.
"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.
Maybe an about:config switch to enable it would be enough to stop casuals from pwning their peripherals.
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.
So maybe don't populate the browser with dozens of features requiring permission popups?
"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."
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.