Intent to Migrate: Feature Policy
Working group decision to adopt
The Web Application Security WG has agreed to adopt this proposal. (Mailing list thread split over two months; both links provided here for completeness)
Feature Policy provides a mechanism for defining "features" on the web platform, and a uniform way for site authors to declare which of these features should be available on their pages, and on the documents they embed.
Motivation and Use Cases
From the introduction in the spec (https://wicg.github.io/feature-policy/#introduction):
The web-platform provides an ever-expanding set of features and APIs, offering richer functionality, better developer ergonomics, and improved performance. However, a missing piece is the ability for the developer to selectively enable, disable, or modify the behavior of some of these browser features and APIs within their application:
- The developer may want to selectively disable access to certain browser features and APIs to "lock down" their application, as a security or performance precaution, to prevent own and third-party content executing within their application from introducing unwanted or unexpected behaviors within their application.
- The developer may want to selectively enable access to certain browser features and APIs which may be disabled by default - e.g. some features may be disabled by default in embedded context unless explicitly enabled; some features may be subject to other policy requirements.
- The developer may want to use the policy to assert a promise to a client or an embedder about the use—or lack thereof—of certain features and APIs. For example, to enable certain types of "fast path" optimizations in the browser, or to assert a promise about conformance with some requirements set by other embedders - e.g. various social networks, search engines, and so on.
#1 is currently only possible through iframe sandboxing, and only for those features which are covered by that. Adding new features to that set is very difficult due to the opt-out nature of the sandbox.
#2 is either handled on with per-feature mechanisms (like <iframe allowfullscreen>) or through developers explicitly passing data or delegating control of features through something like postMessage. There is no standard mechanism for simply making the feature available in child frames.
#3 is currently not possible at all.
As a "meta-feature" of sorts, removing feature policy from a web which has adopted it would have different effects, depending on the features which end up relying on it. The end result would likely be a return to the current ad-hoc feature availability state that we have today.
Features with a default allowlist of
* would likely become available to all web content with no other restrictions (except for those which are also subject to iframe sandbox restrictions, which would still apply).
For permission-gated features, we would probably end up coming up with a new model for permission delegation, or reverting to a state where subframes are allowed to request permission going back to quire the specs which define features to either come up with new ways of allowing use in subframes
Other powerful features (those with a default allowlist of
'self') would likely go back to being allowed only in top-level documents, and not available in subframes at all, unless, like fullscreen, they implement their own delegation mechanism.
- Chrome: Implemented
- Firefox: Under development (Implementation at https://bugzilla.mozilla.org/show_bug.cgi?id=1390801, support as "Worth Prototyping" at https://mozilla.github.io/standards-positions/)
- Safari: Limited development (support for
<iframe allow="camera; microphone">currently)
- Edge: Public support for the spec (https://github.com/WICG/feature-policy/issues/62), no active development.
Ongoing technical constraints
What technical constraints will be added to user agents implementing this feature?
User agents will need to recognize the feature policy header and iframe attributes, and to construct policies, and check them when various features are requested by web content.
Will this feature be supported in all environments (desktop, mobile, tablets, TV, eBooks, automotive, etc.)?
Link to implementation experience and demos
- http://fullscreen.featurepolicy.rocks/ (old fullscreen demo)
- http://fullscreen.featurepolicy.rocks/allow.html (old fullscreen demo with allow attribute)
- http://xhr.featurepolicy.rocks/ (old sync-xhr demo)
YouTube embeds using this for autoplay and encrypted-media (No URL, but select "embed" after clicking "share" on any video on youtube.com):
<iframe width="560" height="315" src="https://www.youtube.com/embed/igHvSUrLqXc" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
The YouTube JS API uses this as well; instructions at https://developers.google.com/youtube/iframe_api_reference#Loading_a_Video_Player
AMP uses Feature Policy to disable synchronous XHR in ad iframes: https://github.com/ampproject/amphtml/pull/14481
As of November 2018, the iframe ‘allow’ attribute is being used in approximately 14% of all page loads, as measured by Chrome’s opt-in user metrics.
Of these, much of the usage is for the features ‘encrypted-media’ and ‘autoplay’ (roughly 35% each), with significant usage (between 1.5 and 10% each) by ‘accelerometer’, ‘camera’, ‘fullscreen’, ‘geolocation’, ‘gyroscope’, ‘microphone’, ‘midi’, ‘picture-in-picture’ and ‘sync-xhr’.
Security and Privacy
See https://wicg.github.io/feature-policy/#privacy-and-security for the more complete writeup. From that section:
"This specification standardizes a mechanism for an embedding page to set a policy which will be enforced on an embedded page. Similar to iframe sandbox, this can be done without the express permission of the embedded page, which means that behaviors of existing features can be changed in published web sites, by embedding them in another document with an appropriate container policy.
As such, the biggest privacy and security concerns are:
- Exposure of behavior in a cross-origin subframe to its embedder
- Unanticipated behavior changes in subframes controlled by the embedder
To a degree, these concerns are already present in the web platform, and this specification attempts to at least not make them needlessly worse."
This feature can be used to control access to accessibility features (see proposal at https://github.com/WICG/feature-policy/issues/175, for instance,) but does not otherwise intersect with accessibility concerns.
This feature does not impose any internationalization requirements on implementers or site authors.