Intent to Ship: Feature Policy V1

[Ian Clelland]

Contact emails

icle...@chromium.org

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

https://crbug.com/623682

Entry on the feature dashboard

[d...@google.com]

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.

[Ian Clelland]

Thanks for the feedback! Let me see if I can address the points you've brought up --

On Fri, Mar 24, 2017 at 5:18 PM, drx via blink-dev <blin...@chromium.org> wrote:

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.
  

This is essentially the current state of the web platform -- if you can navigate the top-level page from inside of a frame, then you redirect anywhere you want, to any page you want. The spec says that the new document will have its own policy, which in that malicious case would certainly allow camera access. The only way to realistically avoid this situation is to stop the frame from being able to navigate the top-level document.

There has been talk about making top-document-navigation a controllable feature, so that a page could avoid this by not granting that power to the frame. (I believe that the current thinking is that top-doc-nav should be disallowed by default in cross-origin frames, so that the bulk of the web would get that extra security by default, and those pages which require it can add it back through the policy mechanism)

In the meantime, there have also been discussions about interventions making top-document-navigation from a cross-origin frame contingent on a user gesture. I'm not sure what the state of that effort is, though.

• The spec mentions web workers but I’m not sure if / how policy would apply to service workers.
  

That's a good question, and I also should have clarified that the current implementation only covers document contexts.

• 
  
• Can this header be supplied via a META tag?  This would enable documents on file:// URLs to set Feature Policy.
  

Currently not; we've dropped that from the spec while we figure out the best way to ensure that the policy in a meta tag has the same effect as the header. https://github.com/WICG/feature-policy/issues/55 is the open issue for that.

• 
  
• 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.
  

Yes, we'll land such tests before shipping, in Chrome as well as in the WPT. 

• 
  
• Reporting (ala CSP) could be helpful with deployment, so it’s something to consider, though maybe not a priority.
  

Reporting would be helpful, and we've talked about it at length, but it raises a large number of privacy concerns, and so we've elected not to include it in the MVP. It's still being discussed, and some kind of reporting component will likely be in the next version of the spec.

• 
  
• 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.

Thanks; I've been meaning to fill that out; I'll be sure to do that.

The TAG security review questionnaire is on the github repo, for a start, but the actual spec section will likely be more thorough.

[Rick Byers]

I'm excited to see Feature Policy getting close to shipping the first bits.  It's really important to "moving the web forward" IMHO as it'll provide the framework to give site authors more control over the issues of composition which are at the heart of the "ecosystem alignment" problem.  In particular, many of the core ideas here have come out of discussions with the AMP team and people like Tim Kadlec and Yoav Weiss who argue the web desperately needs powerful standardized mechanisms for controlling composition.  This seems like an important first step along a long path.

I have just a couple minor process issues:

Note the chromestatus URL (missing in the original post) is: https://www.chromestatus.com/feature/5694225681219584

Ian, please update the spec link there and anything else that's now out-of-date.  What's the best link to indicate there's some positive support from Mozilla here (the chromestatus page still says "no signals" for all the vendors).  If wonder if Tim or anyone else in the web dev community has commented on feature policy specifically as a step on the way to giving authors more control.  It would be great to have at least one link showing there's positive support from web developers for this.

Which of the open GitHib issues constitute a significant compat risk if we ship as-is?  Can you do a triage and mark any such issues with a label (like "mvp-blocking" or something)?  Eg. if we decide using the term "feature" is inappropriate, then presumably we'll need to change the Feature-Policy header name.  So resolving this issue is probably ship-blocking.

Please file GitHub issues for any of David's feedback which we may want to address on the spec.

Rick

[David Ross]

Just to follow up on Ian's feedback -

Re top-level navigation -- that makes sense to me & probably it would be good add this in the spec itself.

Everything else sounds good, I have nothing additional to add.

Thanks!

[Ian Clelland]

Thanks a lot for the feedback, Rick!

(And thanks for posting the chromestatus.com link -- cut-and-paste fail from my draft doc, I think)

I don't have sufficient admin access to the GitHub repo to create arbitrary labels for issues, but I've been over the outstanding issues, and the only ones I can see that we'd effectively be resolving by default through shipping this are:

- https://github.com/WICG/feature-policy/issues/51 - Specify handling of unicode characters

- https://github.com/WICG/feature-policy/issues/58 - Determine how gesture requirement interacts with FP

Regarding the first one, if we make no additional code changes, then the default behaviour will be to treat strings with non-ASCII characters as invalid origins and to ignore them. Changing that will be simple, though, and can be done fairly quickly any time before release. I'll make a note on the issue and wait to see if our default prompts any objections.

The second one is a possible issue, since it will determine the semantics of the "vibrate" feature, and shipping FP could prematurely define that behaviour to something we'd want to change later. I've proposed that we remove "vibrate" from this intent, and we'll send a separate I2S for that, once we've come to agreement on that issue.

The other issue that you mentioned specifically, https://github.com/WICG/feature-policy/issues/55, has been resolved through changing some wording in the spec.

Also worth noting is that we now have public support from Edge on this! @nolanlawson filed https://github.com/WICG/feature-policy/issues/62; I'll update the chromestatus.com entry with that as well.

[Rick Byers]

Thanks.  LGTM1

[Dimitri Glazkov]

LGTM2

[Philip Jägenstedt]

LGTM3

Can you file a bug for the introspection API that would allow this to be tested in web-platform-tests, and make it block https://crbug.com/707649?

[Ian Clelland]

Thanks, Philip!

Filed https://crbug.com/709973 for the introspection API.

[Lucas Garron]

The three features planned for this are all not behind permission prompts in Chrome. Is that intentional?

The security UI team would benefit from one of the cases where we show a prompt (geolocation, mic, camera, notifications, MIDI), but it's not a particular hurry if you have reason to avoid them for now.

»Lucas

[Ian Clelland]

As an update to this, we are (finally) planning on enabling the Feature-Policy HTTP header in Chrome 62. We pulled it back before it ever went live in M60, after many discussions about whether the JSON syntax was right.

The end result of all of those discussions (and many more in the intervening weeks) was that a syntax based roughly on CSP would work just as well in the header as JSON, with less verbosity, and would work for the <iframe allow> attribute better than JSON could ever hope to, and would additionally be a familiar syntax to developers.

Old (Proposed, never shipped) header:

Feature-Policy: { "fullscreen": ["self", "https://a.com", "https://b.com"], "payment": ["*"], "vibrate": []}

New syntax:

Feature-Policy: fullscreen 'self' https://a.com https://b.com; payment *; vibrate 'none'

See the discussion on the allow attribute and the linked spec change at https://github.com/WICG/feature-policy/issues/78

Additionally, this will allow the full feature policy syntax to be used in the 'allow' attribute. Since this is a change from the previous recognized syntax there, I'll send a separate intent to deprecate and (eventually) remove support for the old syntax. In the meantime, both are recognized and supported.

On Mon, Apr 10, 2017 at 2:32 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

[Malte Ubl]

This is great! Would be awesome to get (no) "Sync XHR" into initial feature set

--
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.

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.

[PhistucK]

I thought I read somewhere that Content Security Policy is heading toward a JSON syntax. If that is indeed the plan, this is a step backwards of some sort.

☆PhistucK

[Ian Clelland]

+mkwst

That wasn't my understanding -- especially with the inroduction of csp-embedded (https://www.w3.org/TR/csp-embedded-enforcement/), I suspect that wouldn't be a very ergonomic move, but I could just be out of the loop on that.

I know that there have been plans to re-think the structure of HTTP headers in general, and that JSON was being proposed for a while, but my understanding is that the JSON proposal isn't being considered anymore. (My hope is that, if such a change does come to pass, aligning now with an existing, established syntax like CSP will make it easier to migrate, along with other established headers, when that happens.)

Mike, do you know anything about any such plans?

[Ian Clelland]

On Thu, Aug 31, 2017 at 12:14 PM, Malte Ubl <malt...@google.com> wrote:

This is great! Would be awesome to get (no) "Sync XHR" into initial feature set

Thanks, Malte -- We're tracking SyncXHR in https://crbug.com/661283 -- I'm hoping we can get that in to M63 or M64 - it didn't make the cut for the initial set of features, just because we weren't certain that it was 100% safe to block in existing content. It's definitely on the short list of high impact features for us, though.

Ian