Some USB devices can be firmware-flashed over USB. They expose secret commands or additional descriptors for doing this. A popular method is to expose an HID endpoint that is actually used for uploading firmware.
If the implementation allows access to these endpoints in a way that allows them to upload firmware, this is very bad for security.
If you accidentally plug your USB device into an unknown computer on a webpage, it's reasonable to expect that the device could have been reprogrammed. And a reprogrammed USB device may very well expose any descriptor(s) it wants to - HID keyboard, mass storage device, ethernet connection...
Section 2 of the spec names and addresses exactly this concern:
> USB hosts and devices historically trust each other. There are published attacks against USB devices that will accept unsigned firmware updates. These vulnerabilities permit an attacker to gain a foothold in the device and attack the original host or any other host to which they are later connected. For this reason WebUSB does not attempt to provide a mechanism for any web page to connect to arbitrary devices.
...
> For this reason this specification outlines two mechanisms that can be combined by the UA before a site is granted access to a device. First, so that the device can protect itself from malicious sites it can provide a set of origins that are allowed to connect to it. These are similar to the [CORS] mechanism and can conceptually be thought of as treating USB devices as their own origins in the "usb" scheme. For devices manufacturered before this specificiation is adopted information about allowed origins and landing pages can also be provided out of band by being published in a public registry. Second, so that the user's privacy is protected the UA may prompt the user for authorization to allow a site to detect the presense of a device and connect to it.
> USB hosts and devices historically trust each other...
We've seen this exact recipe for years of pain play out again and again. C was designed when programmers wrote code for themselves and other people who weren't trying to break that code; if you manage to overflow a buffer in some command-line utility that uses "gets()", you're basically punching yourself in the face. SMTP was designed to send messages between non-commercial entities who wanted to communicate; then the people who stuffed your mailbox with ads realized they could stuff your internet mailbox with ads almost for free. In both cases, a system built for a trusting environment was used in an untrusting one, and there was much pain.
A public registry and an optional nag about an on-by-default feature won't come close to addressing the problem. With thousands of types of USB devices out there, who will go through and audit them all, and keep the registry up to date? And how many users will see the nag and just do the easiest thing to make it go away, or even have the knowledge to make the decision? It seems like browsers need an "annoying/harmful Web 3.0 features" tab with an ever-growing list of check boxes for WebGL, notifications, geolocation, USB, etc., with all of them set by default to "deny without asking."
This doesn't really fix the problem though.
If WebUSB exists in peoples' browsers, and if a game on a web page asks to connect to your joystick, or some other peripheral, people are going to do it anyway, regardless of the risks.
And plenty of USB devices already exist that will never be maintained by their manufacturers again. There are huge quantities of USB devices in existence where software support is completely limited to the driver CD that comes in the box - those manufacturers don't care about adding their devices to a public registry, or controlling how firmware is updated.
Furthermore, this public registry idea also implies that a USB VID/PID directly correlates with a device. There are USB devices in existence that emulate another USB device in order to utilize built-in drivers (inbox drivers) and maintain compatibility with existing software. There are also different USB devices that use the same VID/PID to identify themselves, because in order to obtain a VID/PID, you have to pay a licensing fee, which is not always feasible to everyone.
If this public registry is used, it may create conflicts.
If the CORS-like public registry entries are always trusted by the browser, it could even create security concerns where remote computers are allowed to seize control of local USB devices.
It would certainly be concerning if USB devices were firmware updated without users' consent, simply by going to the website of the manufacturer. Or even a web advertisement that connects to USB devices...
In the future we may even see some kind of attack on web servers in order to gain access to the USB devices of unsuspecting users...
If the implementation allows access to these endpoints in a way that allows them to upload firmware, this is very bad for security.
If you accidentally plug your USB device into an unknown computer on a webpage, it's reasonable to expect that the device could have been reprogrammed. And a reprogrammed USB device may very well expose any descriptor(s) it wants to - HID keyboard, mass storage device, ethernet connection...