[asjfkdlf]

I am not sure I agree "browsers generally have a better permission model than desktop apps". Yes, browsers ask the user if they would like to allow, but do desktops apps have rampant XSS vulnerabilities? If you allow a site to use USB, you have to be worried that any XSS vulnerability will compromise your USB devices.

[nailer]

Weirdly enough I was talking a couple of days ago about requiring things like CSP (which would go very far in defeating XSS) for stuff like webcrypto and other sensitive bits of HTML5.

Someone working for one of the major browsers mentioned they'd considered it but decided against it - not sure on the reasons why but if they're reading this they might like to elucidate...

[asjfkdlf]

That would be a good first step. It would have to be a subset of CSP. Don't allow inline scripts or eval.. Only on https is another step I see as very important.

[nsgi]

One reason might be that developers would probably just do the minimum possible CSP rather than following the spirit of it. Unlike with HTTPS, a CSP could be created with the exact same security model as no CSP using directives like unsafe-eval.

[Navarr]

Like buffer overflow or bash injection?

[asjfkdlf]

I am not sure what you are getting at. Those don't occur on the web and are not an issue with desktop apps you install. If a desktop app wants to run a bash command, it can do it. It doesn't need to find a bash injection.

There isn't easily exploitable issues like XSS on the desktop. Meaning, if you run a desktop app you generally don't have to worry that some rogue code is injected into the app, unless the developers keys are stolen which is rare.

[ZenoArrow]

Exactly. Combine a XSS attack with USB keyboard monitoring and you've got ridiculously powerful password harvesting. That's just one potential attack of many.

[justinschuh]

That's not at all an accurate framing. I'm not aware of any implementation that plans to allow access to HID devices (keyboard, mouse, etc.) or other device classes that are already handled natively by the browser/OS. Even ignoring security, just think of what a mess the user experience would be if sites could unbind and override native devices.

[pdkl95]

Implementations are always perfect?

When - not if - someone finds an implementation bug in either the browser or the USB hardware, we will see exploits far worse than keylogging passwords. The bug could be in any USB device, not just the subset you're thinking about. Do you really want to trust your host-controller, every USB device, and the browser interface to be bug free? Are you sure there are no subtle non-bug interactions between devices? Have you even seen how USB devices are designed?

Limitations like "no HID devices" are how it's supposed to work, which is different from how it will actually work.

edit:

Also, did everyone forget about BadUSB?

[justinschuh]

Sorry, but I'm at a loss for what you believe you're responding to here. I made a clear, factual statement regarding the handling of bound USB devices for known devices and classes. Specifically, HID and other native device classes that are already bound by the OS should not be exposed to WebUSB -- the reasons for and robustness of that guarantee should be self-evident to anyone moderately familiar with USB in modern OSes.

Now, if you have a specific argument to make against my statement, then please share it. I have direct experience with the subject here, and ideally can provide context to address such arguments or clear up confusion. However, I really don't think it's productive to respond with non sequitur arguments and personal attacks.

[cm3]

The way USB devices work, they can pretend to be something else and still manage to achieve the ulterior goal. There are some very interesting USB devices on the market which look like one thing, pretend to be something else, and actually are anything but.

[justinschuh]

Mentioning BadUSB very much implies confusion about the threat models at play. That is, the threat model for BadUSB is a malicious device that attacks the host OS, drivers, or applications. Whereas, the threat model for WebUSB is concerned with malicious sites attacking or abusing physical devices attached to the system.

So, the scenario you seem to be implying would require coordination between a malicious WebUSB site and a malicious device. While I can't claim that it would be impossible, it sure seems to approach de minimis if only given the extent of user interactions and preconditions.

[erikpukinskis]

You could say all the same things about every piece of desktop software.

[ZenoArrow]

So we're limiting based on USB device type are we? What about USB keyboards with USB ports in them (which are fairly common). They could be registered as USB hubs. One of the main reasons USB security is so poor is that the barriers between device types are not strictly enforced, which has led to problems in the past (for example, USB device spoofing is trivial to do, you can probably imagine the sort of hijinks you can get up to with that).

[justinschuh]

Sorry, you seem to have misread my statement. Everything you just listed are devices that the OS already natively binds. I'm not aware of anyone considering WebUSB implementations that would unbind native devices and expose them to the Web. Rather, the device-level risks for WebUSB primarily center around devices/interfaces that are not in well-known classes or otherwise are not natively bound and may expose dangerous interfaces (e.g. security credentials, unsigned firmware flashing, etc.).

[ZenoArrow]

Every USB device that the browser has access to will have a driver that the OS uses to expose its functionality. It doesn't matter whether that driver is built into the OS or not, the OS driver would still exist. The only other option is if the browser is managing hardware outside of the control of the OS by running with lower level privileges, but that opens up an even bigger security risk.

You suggested in another comment that you had some prior background in this area, are you involved in the development of this new web API?

[pcwalton]

> You suggested in another comment that you had some prior background in this area, are you involved in the development of this new web API?

Justin Schuh is a Chrome security engineer and is one of the most knowledgeable people on the planet when it comes to browser security. He knows what he's talking about more than virtually anyone else in this thread.

[justinschuh]

This response just doesn't make sense given that modern OSes expose USB through much higher-level device management and communication APIs. Those are the APIs browsers use, and I've already explained that browsers shouldn't unbind and then expose a device that the OS or another native application has already bound. So, I really don't understand what argument you're trying to make here.