-
Notifications
You must be signed in to change notification settings - Fork 131
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
Comments
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 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,
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 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 |
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 ...
... 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.) |
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.
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.
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.
The commit above removes the concept of allowed origins resolving this issue in favor of user choice. |
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.
The text was updated successfully, but these errors were encountered: