[RFC] Unrestricted access on URL descriptor domain

[SuibianP]

As per the current description of claimInterface procedure, devices under protected classes are denied access unless in IWP context. This currently precludes regular website from accessing protected device classes, even though such websites may belong to or at least be sanctioned by the device manufacturer.

It would be a nice addition if usb-unrestricted is specially granted to the domain at the URL Descriptor if bScheme is https, so that vendors of protected class devices such as keyboards and mice could use WebUSB for various purposes. Unlike #127, this proposal aims to add a special case to existing permissions, and follows #49 in that no otherwise granted access is taken away from users.

Security wise, since device communication behaviour and the Get URL request belong to the same security domain of the manufacturer, no additional threat is introduced by this change. To further guard against the case where the manufacturer loses control of the domain (#121), the blocklist mechanism can also be extended to cover domains on top of VID/PIDs, in case domains in the descriptor gets compromised.

Any comments?

[reillyeon]

While the manufacturer site can be considered "same-origin" with the device it is still vulnerable to the same kinds of XSS and hijacking attacks that any other site is. This is what the isolated context requirement is designed to mitigate. A blocklist would partially mitigate this but requires browsers to react, while an isolated context provides protection by default.

[SuibianP]

I am unsure why it qualifies under https://www.chromium.org/blink/launching-features/isolated-web-apps/#might-be-iwa-specific-if or https://w3ctag.github.io/design-principles/#safe-to-browse. In the case of old school XSS such as those that deface websites/capture passwords, it has not been deemed the browser's responsibility to enforce signatures/strict CSP for all of JavaScript, even though doing so would safeguard against those attacks as well. Is it deemed that in a security breach, possible hijacking of mouse is of greater severity than possible theft of passwords?

A huge selling point of WebUSB is that it does not require installing things up front, otherwise users of desktop systems (also the majority of mouse/keyboard users that may benefit from zero-install WebUSB access of protected devices) might as well download a portable native executable which they have been more familiar with.

And just random passing thoughts, would it be viable for the vendor to bake some sort of cryptographic cert into the hardware descriptor as well, and somehow sign the scripts using the cert, in place of full IWP requirement?

[reillyeon]

It is true that a device vendor can also provide an interface with an unprotected class (e.g. "vendor specific") that provides the same functionality as the protected interface and so in practice it's just as easy to work around the protected interface restrictions with that modification as it would be to add a URL descriptor as suggested here.

Concerns about vendor lock-in still apply until Isolated Web Apps are more broadly available to developers, as at the moment they are only available in enterprise scenarios.