|
|
|
|
|
by saagarjha
1239 days ago
|
|
I think we're talking past each other. If the two alternatives are "I need to use a random native USB driver to talk to this" and "I can use WebUSB" then WebUSB is probably better. But in reality a lot of devices actually already have drivers for that class in the OS, or there's a way to write some sort of restricted driver on that platform doesn't require loading things into the kernel. In that case I'm now using a browser where random websites can either trick me into giving them access to my USB devices with a click, or forcefully access them via an exploit on a surface that is generally amenable to such things. Put another way, I see WebUSB as being an attempt at writing userspace USB drivers by doing it in Chrome instead of the OS, and considering the entire point of using Chrome is so people can run code on your device it might be better to actually not put this capability here. > Umm, I know what I work on? As do I, and it would probably be more accurate to write "I work for Google, but not on Chrome". |
|
Great, then you don't need to install anything or use Web USB, it's a no-op!
Still, until we can get Microsoft to ship every driver for every device, we still need a solution that works today.
> In that case I'm now using a browser where random websites can either trick me into giving them access to my USB devices with a click,
You can already be tricked into granting complete access to your machine with a few clicks, that's malware. It's a huge ongoing problem that can only be solved by limiting the ability to run third party code. That's a really high price to pay.
Sure, you could be socially engineered into granting an attacker access to a USB device. The only solution is to have no way for you to grant access to USB devices. There is no amount of confirmation or warning you couldn't be tricked into dismissing by a social engineer.
You will also need to uninstall Remote Desktop and OpenSSH, because you could also be socially engineered into configuring them to allow access. It's a common scam to trick people into downloading TeamViewer, so we will also need to remove your Administrator access and setup AppLocker with a strict policy.
> or forcefully access them via an exploit on a surface that is generally amenable to such things
That's not how it works. When a vulnerability is described as "arbitrary code execution", that means the code can do anything, not just access functionality that exists in the browser. If you were to use a browser without WebUSB support, an arbitrary code execution exploit would still be able to interact with USB devices.
The only added complexity here is after you've granted access to a device, otherwise the attack surface is entirely tractable.