[saagarjha]

It depends on your threat model. “A trusted party ships high-quality drivers” is a good model but bundling it with the browser, where you run all sorts of code from third parties, can be difficult from the perspective of exposed attack surface. I would expect that someone in the position that ‘ocdtrekkie probably blocks installing random third-party drivers on those machines anyways, so now there’s new a way for websites to do funny things to connected devices at best and pwn your computer because the high-quality USB implementation wasn’t that high quality after all. (I’m putting aside the conversation about phishing people into granting those permissions, because that’s a completely different, difficult discussion.) Also,

> disclaimer: I work for Google, have nothing to do with Chrome

…depends on how you’re squinting.

[taviso]

> pwn your computer because the high-quality USB implementation wasn’t that high quality after all.

You have to compare it to the options we have available today, not an implausibly perfect implementation that doesn't exist.

Let's imagine there is some bug that means if I grant access to a device, then more access than intended is actually granted. That sounds bad, but let's compare that to the non-Web USB model, where you have no option but granting unlimited unrestricted access to everything... now it doesn't sound so bad :)

Isn't "if you can find an 0day exploitable bug you can get access to everything" better than "You don't need a bug, because you already have access to everything"?

> …depends on how you’re squinting.

Umm, I know what I work on?

[saagarjha]

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".

[taviso]

> But in reality a lot of devices actually already have drivers for that class in the OS

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.

[ocdtrekkie]

This is a technical view, not a human-centric view. There is absolutely a level of warnings that will generally work. Not always, but I've found a number of people in the process of being socially engineered trip up on the UAC prompt and become more suspicious, to the point of booting a scammer out of their PC... and calling me. Likely because of the full-screen effect design and the short, but relatively scary language of the prompt.

You've posited effectively that if we cannot stop people from compromising their computer we should not bother to try. Either let them be owned with a trivial popup and a single press, or remove their agency entirely.

However, a better approach to security would be to take responsibility for designs that allow easy compromise, and build systems designed to drastically reduce the likelihood a user compromises their machines.

We can't stop people from finding a shady installer for a driver on a file sharing site hosted in Russia and running it, but we can make 99% of people less likely to do it with good design.

[taviso]

Web USB can realistically improve security for billions of people globally. It will improve security for me and my family, and we're all humans.

Sure, it's not a magic a wand that solves all problems, or makes malware disappear. I wish it did, but the fact that it doesn't is not a good reason to reject it.

It's deployed to billions of people globally, can you show me any evidence at all that there is any Web USB social engineering happening?

[dmitriid]

https://www.wired.com/story/chrome-yubikey-phishing-webusb/

Immediately after WebUSB shipped in Chrome: "security researchers Markus Vervier and Michele Orrù detailed a method that exploits a new and obscure feature of Google's Chrome browser to potentially bypass the account protections of any victim using the Yubikey Neo".

The fact that fishing (and fingerprinting etc.) isn't reported widely doesn't mean it doesn't happen. After all you trust Chrome to properly implement everything and take care of things. And yet here's an example of a different hardware standard, WebMIDI: https://twitter.com/denschub/status/1582730985778556931 (note the comment: "Chrome still allows web developers to enumerate attached MIDI devices without user consent or even a notification")