I don't buy the security concern is any worse than a website being able to maliciously make requests against your bank website and drain all your accounts. We've spent decades engineering cross site request security to mitigate those issues. This is no different of a trust problem, just with a physical device. I'm confident if we can build things that give users enough trust to type in their bank account website, enter credentials, and send/transfer funds while knowing it is secure, then we can do the same for making sure the widget you plugged into your device is being controlled by the site you expect and allowed.
Access to online banking requires two-factor authentication, a one-time password or a challenge-response mechanism with a secret key on a smartcard.
Connecting to a USB device requires only a single click. That just requires an attacker making the user believe what he wants, by stressing the user or by misleading or conditioning the user about what it is.
It is not a more secure design than the UAC boxes in Windows Vista that users learned to "click be gone" by routine because they were annoying.
I was thrilled when I first heard about WebUSB because I had been looking for a way to configure USB device firmware using a web browser.
However, I learned that it has glaring security flaws:
* The web page bypasses the operating system's driver infrastructure, where VendorID/ProductID pair is used to look up only valid drivers. Some operating systems require USB device drivers to be signed. A web page requires only a click from the user.
* WebUSB allows web access even to devices that don't have explicit support for it. Older devices can have been designed under other pretences of security. Not all hardware engineers even know about WebUSB, so this applies to newer designs too.
This is already serious, because there are devices used for 2FA that connect via USB that could be exploited this way.
* A device can not control which of its interfaces that a web page can claim or not claim.
* WebUSB contains no authentication of the web page on the device's behalf. (There was some idea that it should have, but that was removed for convenience )
It was both surreal and concerning when I plugged in my new Launchpad X, went to Novation's website for their hardware tool, and got a firmware update directly from the page. I wish I had your confidence in the security practices of hardware companies. The growing IoT botnet swarm suggests it's misplaced.
How is it different from you downloading an executable binary from their site and running it? You're taking the same leaps of faith that the exe hasn't been tampered with, you haven't been man-in-the-middled, the developers of the exe wrote correct code, etc.
It's not Novation or the domain I distrust. It's the fact that it didn't have to ask for permission to connect. It just did it. I don't know if another site could just swoop in and drop a little firmware that makes my Launchpad show adorably profane things in a 64x64 grid. I can change permissions to require it to ask, but why isn't that default? It seems to be enabled now, but I don't know if that was me or a browser update.
If it didn't even ask for permission, most likely it didn't use WebUSB, but connected via HTTP to a crappy local executable preinstalled by the vendor.
Such implementations exposing all sorts of critical stuff over local HTTP servers are often highly insecure, and are the very reason why WebUSB and other device APIs are being pushed as part of the browser.
You need to explicitly allow a site to access a device, it should pop up a dialog and ask the first time you initiate it: https://web.dev/usb/
You've got the same trust problem for any other exe you download and run though. Any steam game you play could reprogram your device to show profanity for example.
And as a side benefit, also makes it extremely easy to maliciously control hardware. A win for Google on two fronts here.