Contact emails
Spec
https://wicg.github.io/feature-policy/
TAG review: https://github.com/w3ctag/spec-reviews/issues/159
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:
usermedia (camera, microphone, speaker)
eme
fullscreen
geolocation
midi
payments
vibration
vr
With this initial version of feature policy, we intend to ship only three of these:
fullscreen
payments
vibration
The additional features in the spec which are not covered by this I2S will have their own intents, as we implement them. This intent is to ship feature policy control of those three features, allowing policies to be set through either the "Feature-Policy" HTTP header or the <iframe> "allow" attribute.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/rBYR3Xd6Skw/oddIWad6AgAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Debuggability
There are plans to spec and expose a JavaScript interface to inspect the enforced policy on a document; that will have a separate intent, once there is agreement over the shape of that web-facing API.
Interoperability and Compatibility Risk
For Feature Policy in general:
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.
For this MVP intent:
The scope of the MVP is such that compatibility risk is minimized -- Sites which do not use feature policy will work roughly as before (the specific changes to behaviour in Fullscreen have had a separate intent to ship).
This API does expose a new method of controlling the Fullscreen API -- using <iframe allow="fullscreen"> rather than <iframe allowfullscreen> (This new syntax is provided for completeness, as all features can be controlled through the "allow" attribute. There is some risk that sites move en masse to adopt the new syntax exclusively, which would leave us in a position of having to support that attribute even if we un-ship feature policy. This move, however, seems unlikely until there is wide browser support for the new attribute.
Web Platform Test Status
There are currently no web platform tests for Feature Policy specifically, independent of any actual features. Web platform tests for individual features are being added and updated (see https://github.com/w3c/web-platform-tests/pull/5055, for instance) to cover the feature-policy-specced behaviour and new methods of controlling feature availability. Once there is an introspection interface (see Debuggability, above), we will be able to easily add tests for the core Feature Policy mechanisms.
Signals from other vendors
Browser vendor response to the spec has generally been positive (or silence), although it has fallen short of an explicit "We think this is a great idea and are committed to shipping in our engine" - We have received thoughtful, helpful feedback on the API from Firefox developers, and contributors to a number of other existing and planned specs have filed their own issues to integrate with Feature Policy, once it is available.
Edge: No signals
Firefox: Public support
Safari:No signals
Web developers:No signals
OWP launch tracking bug
Entry on the feature dashboard
Hi Ian,I'm on this week's intent to implement security triage and I had a few minor bits of feedback on Feature Policy v1:
- If the camera is blocked in a frame, that frame can simply navigate the top level away to use the camera. I’m not sure what the spec’s opinion on this is.
- The spec mentions web workers but I’m not sure if / how policy would apply to service workers.
- Can this header be supplied via a META tag? This would enable documents on file:// URLs to set Feature Policy.
- Presumably there will be test cases to ensure that, for example, “allow” policy specified in a frame doesn’t somehow override “deny” policy specified by its parent.
- Reporting (ala CSP) could be helpful with deployment, so it’s something to consider, though maybe not a priority.
- It's worth filling out the Privacy and Security section of the spec. There's enough here that's security relevant that it would be worthwhile time spent.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXJ0qHCGcFZD_YKG8UpzUp9zNcPjdJQgwFsb%2BzuzqW4JrA%40mail.gmail.com.--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
This is great! Would be awesome to get (no) "Sync XHR" into initial feature set