Reconsider URL whitelist (optional?)

[karelbilek]

Originally, WebUSB had mandatory whitelist for USB devices

While I sort-of understand the motivation for removing the mandatory descriptor whitelist, please reconsider adding at least an optional whitelist (optional for the HW, but enforced by the browser if present). When a device already implements WebUSB Platform Capability Descriptor with welcome page, the implementer can easily add other domains.

---

Access to raw USB device is perhaps more crucial than cross-origin requesting, that is nowadays restricted by CORS headers etc, and can lead to unintended consequences, as has been noted (https://github.com/WICG/webusb/issues/50). We are using WebUSB for our devices that we are now shipping, and while we do like the technology (the API is nice!), we would like to be able to restrict websites, that access the device.

Even when the security model of our device assumes that the computer might be compromised (it is the entire point of a hardware wallet), it is still good to have additional checks, as has been highlighted by some recent attacks.

[prusnak]

@reillyeon @krockot @odejesush Is this still preferred way how to comment the WebUSB standard?

We are producing a hardware that is used by several hundred thousand people all around the world and we are considering switching to WebUSB exclusively. Actually, everything is done on our side of things, we are just re-evaluating our decision, because of the removed whitelist interface. (It was part of the spec when we started to implement WebUSB).

Because our device is security oriented, we don't want any website to be able to communicate with it and we don't want to leave the competence of choosing the correct origin solely to the user. Having a whitelist would be certainly great! Please reconsider adding it back. Having it optional is perfectly fine.

[reillyeon]

There's a legitimate conflict between the rights of users/developers to build applications that work with a device and the interest of the manufacturer to control what software can interact with the device (perhaps for the user's own benefit). This was what was captured in #49.

Adding an optional whitelist could solve this problem for the subset of high-security devices that need it however I'm concerned that it offers a false sense of security. While it prevents a web browser from allowing an unauthorized origin to connect to the device it does nothing to protect the user against other potentially malicious applications on the system. Have you considered a transaction authentication scheme so that the hardware wallet rejects a request that has not come from an application it has been previously paired with? This kind of scheme is how Android phones prevent malicious software from compromising them over the USB debug interface.

[prusnak]

I think that authentication pairing is orthogonal to origin whitelist. Pairing again puts an extra burden on user, becase they need to know against which app the pairing is happening. From user's perspective it's almost the same as current state. From phishing we know, users are not very good at telling the difference between legit and malicious origins.

If vendor going out of business is an issue (I understood that's one of the main concern in #49), it might be worth to introduce an advanced-setting flag in browser, which can turn off this origin check for particular device. Sacrificing this security feature completely just for the hypothetical case of vendor going out of business behind is bad IMHO.

[prusnak]

Ping?

[reillyeon]

If a device manufacturer is concerned about phishing the pairing mechanism it can be made more and more difficult to perform accidentally. At the extreme pairing could be burned into the firmware and not available as a user option at all. An "advanced" setting in the browser seems no less vulnerable to phishing than the pairing mechanism.

As I think about how to make the original allowed origins list opt-in it also occurs to me that there is risk in having the lack of a list imply no policy at all. In the original design if the browser failed to read the allowed origins descriptor access would be denied. In an opt-in model failure would imply open access however we know that at the moment our ability to read device descriptors, at least on initial enumeration, is flaky due to external factors. I worry that this could make the security mechanism itself unreliable.

In blocklist.txt we have a listing of devices for which the manufacturer has requested no WebUSB access at all because the design of the device is insecure when untrusted clients are allowed to connect. The original design had a "public device registry" that allowed legacy devices to be opted-in to WebUSB access by their manufacturer. I think that rather than mandating all devices be in such a registry the incentives around a list of devices for which access is more restrictive than the default are a little better. This idea is worth exploring.

Mapping vendor IDs to requests for entries in such a registry is still an open question but at least if the manufacturer's site went down permanently the entry could be removed to grant open access once again.

[prusnak]

At the extreme pairing could be burned into the firmware

How? WebUSB hardware does not know the URI of the website it's communicating with. Or are you suggesting we should come up with our own authentication scheme (and thus requiring the server to store some kind of secret)?

[reillyeon]

How? WebUSB hardware does not know the URI of the website it's communicating with.

The website would need to send some kind of signed message to the device that it could verify. See my previous reference to the key-based mechanism used for the Android debug interface. The key here is crafting a mechanism that is not only useful for WebUSB but protects the device against any potentially malicious host.

[prusnak]

This implies non-trivial requirements on the device - it needs to support asymmetric cryptography. It's not a problem for our token, but for others, it might be a problem.

Another issue is that the server needs to keep some kind of a secret and have an active signer component, which makes it much harder to deploy such service (e.g. you can't host your website from static hosting such as Github pages). Or one could solve that via SSL certs and PKI, but having complete PKI implemented in the device is almost impossible.

[travisleithead]

Note: potentially related proposal at: https://github.com/WICG/proposals/issues/7