Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

should access to USB devices be controlled by device vendor or user? #49

Closed
dbaron opened this issue Mar 30, 2016 · 3 comments
Closed

Comments

@dbaron
Copy link

dbaron commented Mar 30, 2016

The TAG started to discuss (briefly) the specification at our London face-to-face, as part of the request for TAG review (w3ctag/design-reviews#108).

One issue that came up is that the specification currently uses the model where the USB device vendor decides what origins can communicate with the USB device. Some people were wondering the alternative model where the decisions are made by the user rather than the device vendor, or perhaps a model that allows both mechanisms.

We're certainly not ready to say that one model or the other was better. However, it would be interesting to hear (maybe in the explainer or the spec draft?) about whether you considered a user-mediated model, and if so, what led you to make the choices that you did.

@reillyeon
Copy link
Collaborator

The specification is actually carefully worded to make the vendor-control model recommended but not actually required. This allows compliant implementations to override the access controls specified (or not specified) by the vendor either as a user setting (for testing purposes or to allow "after-market" uses of a device) or as part of an integrated solution configuration, such as a kiosk that can only browse a restricted set of origins and has application-specific hardware attached. This is not made clear in the explainer and so I will update it with some of the points made in this reply.

The testing or kiosk configurations are likely non-controversial so the most interesting question is that of "after-market" uses of hardware devices. On the one hand I recognize that there is an incredible value provided by the community of software developers who take existing devices and provide software that enhances the capability of devices beyond those envisioned by the original vendor. On the other hand existing USB devices are not often hardened against malicious code running on the host and are in an excellent position to expose private information or provide a foothold on the system if compromised. WebUSB provides two mechanisms to protect users, the allowed origins policy and the navigator.usb.requestDevice method. In Chrome the later is implemented as a modified permission request prompt, offering the user a selection of devices to chose from.

I do not believe that such a permission prompt alone is capable of sufficiently protecting users. It protects privacy by notifying the user before a site can discover the presence of a device and extract personal information from it but does not provide security because,

  1. once permission is granted it may be revoked but changes to the device can be permanent. Unlike choosing where to download a file to, where it could easily be erased afterwards even if the user revokes permission to access the device the damage could already be done.
  2. the user may not be in a good position to understand the question being asked. Existing permissions such as location or video capture are simple concepts. Even in the context of a file chooser the user is being asked to select from a namespace they are likely to be familiar with since it's their own data. In contrast USB device names (particularly in the case of a device not designed to work with this API and thus have a friendly and descriptive name) are something the user is rarely presented with.

Take for example, a vulnerability discovered in an old model of Apple's iSight camera that allowed unsigned firmware to be installed by any application. A site may attempt to confuse the user into granting it access to the device by masquerading as a legitimate video conferencing site. In this context the text of the prompt may appear legitimate as "This site would like to connect to your Apple iSight Camera" is reasonable. However while the prompt may look similar enough to a normal navigator.getUserMedia permissions request once the site has access to the device it may install malicious firmware and use that foothold to attack the host operating system.

While it is impossible to prevent vendors from abusing this mechanism to lock out third-party developers in the explainer I outline a mechanism that works within the existing web security model to allow third-party developers access to hardware mediated through vendor code that seeks to strike a compromise on this issue.

Given the alarmist tone of my example above one might conclude that this is a capability we simply shouldn't be bringing to the web. I disagree. There are an enormous number of new devices being designed today and APIs such as this one, that take a generic approach instead of targeting a specific application, allow the web to move quickly to support them. I think we simply need to be cautious and take a more conservative approach while these capabilities are new. The current specification provides no * option as there is for the Access-Control-Allow-Origin HTTP header. If communication between local hardware and the Internet becomes more common (think of USB as just another network transport) then perhaps devices will become hardened enough to participate more freely and these restrictions can be relaxed.

@SamB
Copy link

SamB commented Oct 6, 2016

I have to say that my thought was "wait why would I trust the vendor?" And what happens if they go out of business, anyway? And this bit ...

This specification defines a way for the device to provide the UA with a set of static data structures defining a set of origins that are allowed to connect to it. For devices manufactured before this specification is adopted information about allowed origins can also be provided out of band through a public device registry.

... while presumably not intended to be normative (as it does not use requirement language), also does not give the slightest hint that the described scheme is meant to be optional. The next paragraph, encouraging vendors to provide an API from an origin they control, sounds especially naive.

(Also, you seem to have forgotten to actually designate [most of?] sections 1 and 2 as non-normative.)

reillyeon added a commit to reillyeon/webusb that referenced this issue Mar 28, 2017
The integration with the Feature Policy specification allows us to
disallow (by default) access to this feature by cross-origin iframes
with a standardized mechanism for the top-level document to grant access
to this feature to origins that it trusts.

With this mitigation in place the Allowed Origins descriptors are
removed from the specification. This resolves the question in WICG#49 of
whether access to USB devices should be controlled by the vendor or the
user in the favor of the user.

This resolves issue WICG#82 and obsoletes issues WICG#15 and WICG#38.
reillyeon added a commit to reillyeon/webusb that referenced this issue Mar 28, 2017
The integration with the Feature Policy specification allows us to
disallow (by default) access to this feature by cross-origin iframes
with a standardized mechanism for the top-level document to grant access
to this feature to origins that it trusts.

With this mitigation in place the Allowed Origins descriptors are
removed from the specification. This resolves the question in WICG#49 of
whether access to USB devices should be controlled by the vendor or the
user in the favor of the user.

This resolves issue WICG#82 and obsoletes issues WICG#15 and WICG#38.
reillyeon added a commit to reillyeon/webusb that referenced this issue Mar 29, 2017
The integration with the Feature Policy specification allows us to
disallow (by default) access to this feature by cross-origin iframes
with a standardized mechanism for the top-level document to grant access
to this feature to origins that it trusts.

With this mitigation in place the Allowed Origins descriptors are
removed from the specification. This resolves the question in WICG#49 of
whether access to USB devices should be controlled by the vendor or the
user in the favor of the user.

This resolves issue WICG#82 and obsoletes issues WICG#15 and WICG#38.
@reillyeon
Copy link
Collaborator

The commit above removes the concept of allowed origins resolving this issue in favor of user choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants