What if your unsandboxed native USB utility has an RCE vulnerability?
It comes down to this: if you ever found yourself in a situation where you needed to connect a USB device to a remote service, would you prefer to download that service's unsandboxed native code to your PC and execute it? Or execute some JS in the browser sandbox and grant it limited access to that one specific device?
I have never found myself in that situation. That sounds like a really silly idea.
For those that _do_ require [such use cases][1] though; they can now do so without needing to expose their system to an unsandboxed native app.
The web is a disaster and WebUSB is a prime piece of evidence supporting this.
While obviously we want to do as much as we can to discourage users from shooting themselves in the foot, there are limits. At some point, eventually you _do_ have to trust that the user knows what he's doing.
Giving users a choice on when to allow a page access to one specific USB device is not a "disaster".
I think WebUSB will enable a lot of cool things, though it will definitely be hard to sandbox.
I want to program an Arduino from a web IDE. I want to control a 3d printer or pen plotter from a web application. I want to store things on a flash drive on my iPhone using a web-based file explorer? This last one sounds strange.
On a tangent, I see application runtimes moving into the browser by default with very few performance-critical applications remaining outside that stack. Photoshop and AAA games might be exceptions. Services like databases and web browsers would not have a need to be in Chrome.
(don't hurt me, I know I'm strange.. ~)
I see nearly no good reason for any of those uses to be web-based, and certainly not with hardware control! If you want to store files on your flash drive, the browser should handle that, not give out direct usb access...
Hearing this exists was a shock, like when the first Android 'Instant' load app showed up on my phone (apps that you don't install, but run themselves if you goto a website or a physical store, and without asking you)
EG, take a few seconds to turn on a flag in configuration, or add a plugin.
Getting 400 students up and running with python is painful alone - without USB. For projects, some small fraction of those used USB, and we again had a pretty good chunk of time spent getting them all working.
Originally the scale was connected via serial port to the desktop. A little Perl service we called "the scale daemon" exposed the current weight on some localhost port. The backend would constantly poll that service and the web browser would poll the backend to keep the value on the page up to date. It was a nifty solution albeit a bit clumsy and it meant running an extra piece of software on 50+ machines in a warehouse.
At some point our scale vendor stopped selling scales with serial connections or maybe it was that the PC vendor stopped including serial ports. It was 10+ years ago and I can't recall exactly. What I do remember is that the guy that wrote the scale daemon had moved on and I had to figure out how to make it work with USB. It was fun and probably not as hard as it seemed at the time, but wow, being able to get at that scale from inside the browser would have massively simplified things.