Change description:
Implement a framework to allow site owners to selectively enable and disable web platform features on their pages. By setting a response HTTP header, site owners can disable parts of the web platform on their pages, including in embedded third party content.
Changes to API surface:
- New HTTP header: Feature-Policy
- Optionally disabled features: (Completely removed, or permission denied, as necessary. This list is subject to change as the spec settles)
- document.cookie
- document.domain
- document.write/writeln
- geolocation
- MIDI
- notifications
- push
- synchronous scripts
- synchronous XHR
- WebRTC
Links:
Draft Spec: https://igrigorik.github.io/feature-policy/
Public standards discussion: All discussions are currently at https://github.com/igrigorik/feature-policy/issuesSupport in other browsers:Internet Explorer: No
Firefox: No
Safari: No
No current support, but other browser vendors have been positive towards the idea.
Change description:
Implement a framework to allow site owners to selectively enable and disable web platform features on their pages. By setting a response HTTP header, site owners can disable parts of the web platform on their pages, including in embedded third party content.
Changes to API surface:
- New HTTP header: Feature-Policy
- Optionally disabled features: (Completely removed, or permission denied, as necessary. This list is subject to change as the spec settles)
- document.cookie
- document.domain
- document.write/writeln
- geolocation
- MIDI
- notifications
- push
- synchronous scripts
- synchronous XHR
- WebRTC
Links:
Draft Spec: https://wicg.github.io/feature-policy/
Public standards discussion: All discussions are currently at https://github.com/igrigorik/feature-policy/issues
Support in other browsers:
Internet Explorer: No
Firefox: No
Safari: No
No current support, but other browser vendors have been positive towards the idea.
> Implement a framework to allow site owners to selectively enable and disable web platform features
I do not see any wording in the referenced spec that would also allow opting in for features - the spec seems to only referencing disabling features.
This is essentially feature complete -- there is still some ongoing engineering, but I think this is the time I'm supposed to request X-Functional review.
This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues.
We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate.
For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit
For any questions, please contact owencm, sshruthi, larforge
Now that feature policy has shipped, can we call this bug fixed (in the milestone it launched) and please file new bugs for any new policies or other work? It's hard to track work for various features when their CLs are all glommed into this one master bug...
Not yet.
I'm not a Chrome developer, but I keep an eye on the list of Feature Policy directives that can be used at:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/feature_policy/feature_policy.cc?q=GetDefaultFeatureNameMap&sq=package:chromium&dr=CSs&l=138
As of the 16th July 2018, that list includes...
- camera
- encrypted-media
- fullscreen
- geolocation
- microphone
- midi
- speaker
- sync-xhr
- vr
if (ExperimentalProductivityFeaturesEnabled) {
- animations
- document-write
- image-compression
- legacy-image-formats
- max-downscaling-image
- unsized-media
- vertical-scroll
}
if (FeaturePolicyAutoplayFeatureEnabled) {
- autoplay
}
if (PaymentRequestEnabled) {
- payment
}
if (PictureInPictureAPIEnabled) {
- picture-in-picture
}
if (SensorEnabled) {
- accelerometer
- ambient-light-sensor
- gyroscope
- magnetometer
}
if (WebUSBEnabled) {
- usb
}
@acmesqua ... Historically document-write was never supported in XHTML (application/xhtml+xml), so what you are seeing is a result of that, rather than the Feature Policy being applied (for reference, I create websites locally in XML mode, to ensure it works to the higher standard, but will relax on Demo and Live):
<?php
header('Content-Type: application/xhtml+xml; charset=UTF-8');
?>
<!DOCTYPE html>
<html lang="en-GB" xml:lang="en-GB" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="UTF-8" />
<title>Document Write</title>
</head>
<body>
<script type="text/javascript">
//<![CDATA[
document.write('hi');
//]]>
</script>
</body>
</html>
Chrome Console: Uncaught DOMException: Failed to execute 'write' on 'Document': Only HTML documents support write().
Firefox Console: InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable.
As to why the Feature Policy is not disabling document.write in plain HTML documents is presumably because it needs "ExperimentalProductivityFeaturesEnabled".
Thanks for chiming in, craig.fr... -- you're right that the list of features is not final by any means. Feature policy is more of a framework for the web platform, that spec authors and browser vendors can choose to use to enable consistent control over different features.
Re #57, that *is* the list of enabled features for Chrome 68, with the understanding that the FeaturePolicyAutoplayFeature, Sensor, WebUSB, (and PaymentRequest on Android) features are all enabled by default.
There have been more features using the framework with each release since Chrome 60.
sscar..., re: WebRTC -- WebRTC itself is *not* currently controlled by feature policy, but access to the device media streams which it is often used with *is* controlled by the "camera" and "microphone" features.
And this isn't a policy which is set in stone; there's lots of room for discussion still. This launch bug probably isn't the place for it, since it was just tracking all of the bits and pieces that needed to be in place for feature policy to be shipped as part of Chrome in the first place. A better forum would be the issues on GitHub, at https://github.com/WICG/feature-policy/issues, or with the WebRTC standards folks -- I think they maintain their issue lists at https://github.com/w3c/webrtc-pc/issues and https://github.com/w3c/mediacapture-main/issues.
Comment 1 by l.gom...@samsung.com
, Jul 8 2016