Integrate with the Feature Policy specification #86
Conversation
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
force-pushed
the
feature_policy
branch
from
27ad1f4
to
c964613
Compare
|
|
||
| ## Feature Policy ## {#feature-policy} | ||
|
|
||
| This specification defines a <a>feature</a> that controls whether the |
There was a problem hiding this comment.
I think that the outcome of w3c/webappsec-permissions-policy#60 is that I'm going to find a more precise term than "feature" for use in specs outside of Feature Policy. This is great now, but I'd expect it to change to something like "Feature Policy-controlled feature" in the next couple of days.
| ## Feature Policy ## {#feature-policy} | ||
|
|
||
| This specification defines a <a>feature</a> that controls whether the | ||
| {{Navigator/usb}} attribute is exposed on the {{Navigator}} object. |
There was a problem hiding this comment.
For the pre-existing permission-based features being controlled by policy, we've generally tried to suggest disabling them by rejecting permission/usage requests, rather than restricting attribute exposure.
If exposure is the best fit for a new API, then we can definitely do that (We'll have to reinstate the IDL section in the Feature Policy spec) -- I don't think that FP should be prescribing the exact mechanism for any particular feature. There's something to be said for consistency within the overall platform, though.
There was a problem hiding this comment.
Since WebUSB is a new API I would prefer to restrict attribute exposure unless that isn't considered to be a good practice.
The argument against restricting attribute exposure is that it makes it harder for developers to discover why code is not working because we don't have the opportunity to throw a SecurityError with a helpful message.
There was a problem hiding this comment.
Can we make navigator.usb print a warning to the console in addition to returning undefined?
reillyeon
changed the title
| ## Feature Policy ## {#feature-policy} | ||
|
|
||
| This specification defines a <a>feature</a> that controls whether the | ||
| {{Navigator/usb}} attribute is exposed on the {{Navigator}} object. |
There was a problem hiding this comment.
Can we make navigator.usb print a warning to the console in addition to returning undefined?
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 #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 #82 and obsoletes issues #15 and #38.