It's simple: allowing sandboxed code to request limited access to a USB device is more secure than having users install native, unsandboxed code with access to everything on their PC.
Not every link you click. Only sites that you grant access to the necessary attack surface. The Web USB API can't be attacked by sites that you haven't granted access to it.
As opposed to native desktop apps, which get all the same permissions by default that a web app requires a zero-day sandbox escape vulnerability to achieve?
Native desktop apps are limited in number are nowhere near the dumpster fire the web is. My desktop isn't routinely downloading and executing payloads from the web. They're clearly different.
This is about the Web USB API, not the entire web in general. Are you routinely granting web pages access to your USB devices? That's not a permission that web apps get by default (unlike with native desktop apps btw).
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 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.
Just because its possible, doesn't mean we should!
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)
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.
I worked for an online retailer a long long time ago and this would have been nice to have at our packstations. The tech at each station consisted of a Linux desktop, a barcode scanner, a printer, and a scale. The commerce platform was web based and displayed the current weight on the scale on the pack page.
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.