To see all potential security issues, you need to look at the whole tech stack. A single USB device can have multiple drivers, and although only one is active at any given time the decision over which one to use can be influenced by applications.
"A USB configuration defines the capabilities and features of a device, mainly its power capabilities and interfaces. The device can have multiple configurations, but only one is active at a time. The active configuration isn't chosen by the USB driver stack, but might be initiated by an application, a driver, the device driver. The device driver selects an active configuration.
A configuration can have one or more USB interfaces that define the functionality of the device. Typically, there is a one-to-one correlation between a function and an interface. However, certain devices expose multiple interfaces related to one function."
So let's say I want to exploit this new WebUSB API. If I infect your computer with malware that installs a second USB driver for the hardware I want access to, and this second driver has support for WebUSB, I could theoretically control the driver being used by making a WebUSB request for the device, thereby exposing the hardware for further exploits.
This is what Raymond Chen calls "being on the other side of the airtight hatchway". If you can install an USB driver on my machine, it's because you can run native code on my machine, and so you can use that to talk to the USB device without requiring WebUSB.
The difference between using the malware itself to communicate via the web and using WebUSB to do so would be in malware detection. If an unidentified EXE hidden in your Windows partition is communicating via the web that's going to look a lot more suspect than a driver which is trusted by the system. The malware that installed the driver could remove itself after installing the driver, taking out another way to track it down.
An unidentified process talking to the 'net is more suspicious than one installing drivers?
But fine, let's say the malware installs the driver and deletes itself. What then? How are they going to get the browser to navigate to their site, and the user to click the authorization button?
> "But fine, let's say the malware installs the driver and deletes itself. What then? How are they going to get the browser to navigate to their site, and the user to click the authorization button?"
You could do it a number of different ways. For example, could edit the hosts file (a.k.a. etc/hosts) to point to an amended site for a popular website address, could configure proxy settings on default web browser, could alter the browser shortcut to run a script in the background when the browser starts that scans for WebUSB-enabled devices, could set the driver up to check for updates and disguise the authorisation as the driver update confirmation, etc...
So this antivirus lets the malware install drivers, edit system files and/or replace shortcuts created by other applications, but not talk to the web, when nowadays almost every program connects to the web to check for updates. Do you know how far-fetched that sounds?
The reality is that if this malware gets enough permissions to install drivers, it can certainly talk to a regular device driver and communicate with the web. It doesn't need WebUSB for anything.
https://msdn.microsoft.com/en-gb/library/windows/hardware/hh...
"A USB configuration defines the capabilities and features of a device, mainly its power capabilities and interfaces. The device can have multiple configurations, but only one is active at a time. The active configuration isn't chosen by the USB driver stack, but might be initiated by an application, a driver, the device driver. The device driver selects an active configuration.
A configuration can have one or more USB interfaces that define the functionality of the device. Typically, there is a one-to-one correlation between a function and an interface. However, certain devices expose multiple interfaces related to one function."
So let's say I want to exploit this new WebUSB API. If I infect your computer with malware that installs a second USB driver for the hardware I want access to, and this second driver has support for WebUSB, I could theoretically control the driver being used by making a WebUSB request for the device, thereby exposing the hardware for further exploits.