Intent to Implement: Feature Policy
Ian Clelland
Contact emails
icle...@chromium.org, igri...@chromium.org, mk...@chromium.org
Spec
https://igrigorik.github.io/feature-policy/
Soon moving to WICG, likely to be found at https://wicg.github.io/feature-policy/
Summary
Allows developers to selectively enable and disable use of various browser features and APIs. The list of controlled features is likely to vary over time, and has not been finalized yet, but currently includes:
document.cookie
document.domain
document.write / document.writeln
geolocation
MIDI
notifications
push
synchronous scripts
synchronous XHR
WebRTC
Motivation
[From the linked spec]
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 of 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.
Interoperability and Compatibility Risk
Because this feature allows site owners to restrict the subset of the web platform that is exposed to third party scripts they embed, there is definite potential for incompatibilities. Third-party code being embedded may have been written expecting a feature to be available, when it is being removed by policy. This removal, however, will be a result of a deliberate decision by the embedding site owner to disable those features. Site owners will likely choose to either stop embedding sites which cannot support their chosen policy, or can relax their policy. Also mitigating this is that we are planning on having Chrome advertise, through a request header, any restrictive policy which will be applied to third-party content.
Interoperability risk is minimal at this point; browsers which do not implement this feature will simply expose the entire web platform to all content, regardless of any received headers. Sites should generally not be relying on features being absent in order to function correctly.
Ongoing technical constraints
None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5694225681219584
Requesting approval to ship? No.