Intent to Experiment: Feature Policy JavaScript API

[Ian Clelland]

Contact emails

icle...@chromium.org, lun...@chromium.org

Spec

Feature policy spec is at https://wicg.github.io/feature-policy; Pull request for this API is at https://github.com/WICG/feature-policy/pull/184; Proposed spec (with this update merged) is at https://drafts.featurepolicy.rocks/add-introspection/.

Summary

This change adds an interface to inspect the current feature policy in a document, as well as to see what policy would be applied to an iframe in that document. (See overview at https://drafts.featurepolicy.rocks/add-introspection/#introspection-overview as well)

Developers can use this to ask questions like:

What features are currently enabled?

What origins will automatically inherit access to these features?

If I create an iframe, what features will it have enabled?

Link to “Intent to Implement” blink-dev discussion

Um… it looks like that wasn't sent out :(

Goals for experimentation

1. Is the .policy API the right shape, or is it awkward to use?

2. Are the arrays of strings which it returns useful for developers to understand the policies which their pages are operating under?

3. Is the iframe.policy interface intuitive enough, given its restrictions on cross-origin information leakage? Is it useful?

4. Does the API provide enough information for developers, or are there additional things we could surface to make this more useful?

Since most of these goals cannot be measured directly, we're going to be relying heavily on feedback from developers, through very specific questions on the feedback form, as well as reaching out directly to developers who will agree to be contacted.

Experimental timeline

M69 - M71 (Expected end: Late November 2018)

Any risks when the experiment finishes?

Sites which have been built to depend on this functionailty may stop working, although I expect that sites will try to detect the presence of the document.policy attribute, and assume when it is not available, that the browser just does not support feature policy. In that case, they will continue to work as well as they do on other browsers, and can continue to use traditional feature detection for the actual features they are using.

Ongoing technical constraints

None.

Debuggability

Having this feature available enables the awesome and amazing DevTools extension by Eric Bidelman for inspecting policies, which currently requires users to enable this API by flag.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5190687460950016

[Chris Harrelson]

LGTM

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXJfW_89gk0HOKgCsMUCHJOr3%2B3s0yx0%2BL9%2Bh5deo2P25A%40mail.gmail.com.

[Ian Clelland]

On Thu, Jul 19, 2018 at 4:17 PM Chris Harrelson <chri...@chromium.org> wrote:

LGTM

On Thu, Jul 19, 2018 at 8:30 AM Ian Clelland <icle...@chromium.org> wrote:

Contact emails

icle...@chromium.org, lun...@chromium.org

Spec

Feature policy spec is at https://wicg.github.io/feature-policy; Pull request for this API is at https://github.com/WICG/feature-policy/pull/184; Proposed spec (with this update merged) is at https://drafts.featurepolicy.rocks/add-introspection/.

Summary

This change adds an interface to inspect the current feature policy in a document, as well as to see what policy would be applied to an iframe in that document. (See overview at https://drafts.featurepolicy.rocks/add-introspection/#introspection-overview as well)

Developers can use this to ask questions like:

What features are currently enabled?

What origins will automatically inherit access to these features?

If I create an iframe, what features will it have enabled?

Link to “Intent to Implement” blink-dev discussion

Um… it looks like that wasn't sent out :(

Goals for experimentation

1. Is the .policy API the right shape, or is it awkward to use?

2. Are the arrays of strings which it returns useful for developers to understand the policies which their pages are operating under?

3. Is the iframe.policy interface intuitive enough, given its restrictions on cross-origin information leakage? Is it useful?

4. Does the API provide enough information for developers, or are there additional things we could surface to make this more useful?

Since most of these goals cannot be measured directly, we're going to be relying heavily on feedback from developers, through very specific questions on the feedback form, as well as reaching out directly to developers who will agree to be contacted.

Experimental timeline

M69 - M71 (Expected end: Late November 2018)

Oops -- I estimated the schedule for the wrong release. An M69 - M71 timeline would actually end about a week before M72 goes live, which would be mid-late January 2019.

[a...@google.com]

On Thursday, July 19, 2018 at 5:30:04 PM UTC+2, Ian Clelland wrote:

Contact emails

icle...@chromium.org, lun...@chromium.org

Spec

Feature policy spec is at https://wicg.github.io/feature-policy; Pull request for this API is at https://github.com/WICG/feature-policy/pull/184; Proposed spec (with this update merged) is at https://drafts.featurepolicy.rocks/add-introspection/.

Summary

This change adds an interface to inspect the current feature policy in a document, as well as to see what policy would be applied to an iframe in that document. (See overview at https://drafts.featurepolicy.rocks/add-introspection/#introspection-overview as well)

Developers can use this to ask questions like:

What features are currently enabled?

What origins will automatically inherit access to these features?

If I create an iframe, what features will it have enabled?

Link to “Intent to Implement” blink-dev discussion

Um… it looks like that wasn't sent out :(

Goals for experimentation

1. Is the .policy API the right shape, or is it awkward to use?

2. Are the arrays of strings which it returns useful for developers to understand the policies which their pages are operating under?

I'm a little worried that getAllowlistForFeature() introduces a source of data which can be controlled by cross-origin windows in a way that's not obvious to the developer. That is, usually the allowlist will contain expected domains (in the FP served with the document or its parent), but I believe that if an attacker frames the window with her own FP, the allowlist may then include arbitrary hosts included in the Feature Policy of the top, attacker-controlled window. There's a chance that this may include HTML metacharacters which could lead to XSS if the developer later uses the value in an unsafe DOM API such as Element.innerHTML (this could be prevented if host serialization strips non-alphanumeric characters, but does it?)

It's not really a big deal, but it may make sense to add a note in the spec that explains that the values returned by the API may potentially be influenced by an attacker (in particular the string arrays). 

[Boris Zbarsky]

On 7/26/18 2:32 PM, aaj via blink-dev wrote:
> but I believe that if an attacker frames the window with her
> own FP, the allowlist may then include arbitrary hosts included in the
> Feature Policy of the top, attacker-controlled window.

Turning this around, doesn't this leak information about the parts of
"good" site's feature policy that don't apply to the subframe to the
subframe? That seems like a cross-origin information leak which is also
undesirable.

-Boris

[Artur Janc]

My guess is that the underlying assumption here is that the Feature Policy value is not meant to be secret. This may not be true in general -- for example if sites modify the FP based on some aspect of the user's session -- but I couldn't think of a compelling use case where this would lead to significant problems. (FWIW the policy value can already be inferred by the subframe without an explicit API by attempting to do things that would be banned by FP and observing if they succeeded.)

Overall, the underlying issue -- which we've touched upon in previous discussions -- is that Feature Policy is inherited cross-origin without an opt-out. I'm particularly worried about frames inheriting FP restrictions that would affect their state in unpredictable ways (e.g. blocking sync scripts), but I think your concern also makes sense. Perhaps requiring opt-in from the child frame (Jochen recently mentioned parallels to CSP Embedded Enforcement: https://www.w3.org/TR/csp-embedded-enforcement/) and a switch to allow sites to prevent their FP from being inherited to cross-origin child frames would be a reasonable thing to explore?

-Boris

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/pQZopKWaQIk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eee7a9db-d7ee-3a23-31b6-7595bb078b67%40mit.edu.

[Artur Janc]

For posterity, I just found that this is mentioned at https://wicg.github.io/feature-policy/#privacy-expose-policy 

[Boris Zbarsky]

On 7/26/18 3:04 PM, 'Artur Janc' via blink-dev wrote:
> (FWIW the policy value can already
> be inferred by the subframe without an explicit API by attempting to do
> things that would be banned by FP and observing if they succeeded.)

The subframe can infer the FP for itself. It can't infer the FP for
other unrelated hostnames that might get loaded into the same frame, right?

Or am I misunderstanding the concern here? It sounded like the new API
would provide information about which hostnames are involved in the
feature policy in general, not just what the values are for the hostname
inside the iframe.

-Boris

[Artur Janc]

Hm, the way I understood it is that subframe A could learn the FP of its embedding document, but not the FP of its sibling subframe B embedded in the same document. But maybe Ian can clarify.

[Ian Clelland]

The only thing that should be observable to any subframe is whether the embedder granted or denied it access to particular features (the 'inherited policy', essentially). It can't see what other hosts might have access to the features in other frames, or whether a feature would be available at another origin if it were to navigate to it.

The inherited policy is just a boolean (allowed or not) for each feature, and it comes from applying the parent's FP (and any iframe attributes) to the origin of the framed document. The subframe shouldn't be able to use that to deduce anything about any other origins or other frames.

The only thing the subframe can infer, I think, is that if it has access to a feature, then the parent frame *also* had access to it. If a feature is disabled, then you can suspect that the parent may have deliberately chosen not to grant the subframe access, but it might have been disabled in the parent as well, and the subframe can't tell whether or not that is the case.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPYVjqoXLXjqkZjO%2BjHnoJxgERYdnnmAq7baooSg5ZDKGJYSiA%40mail.gmail.com.

[Boris Zbarsky]

On 7/27/18 11:43 AM, Ian Clelland wrote:
> The only thing that should be observable to any subframe is whether the
> embedder granted or denied it access to particular features

Just to make sure we're on the same page, we're talking about the
Policy.getAllowlistForFeature API right?

> It can't see what other hosts might
> have access to the features in other frames, or whether a feature would
> be available at another origin if it were to navigate to it.

In that case, what exactly is the list of origins that
getAllowlistForFeature() returns? Is that just looking at the origins
in the feature policy the site is applying to itself, not the ones from
the parent? The term "declared policy" it's using in
https://drafts.featurepolicy.rocks/add-introspection/#ref-for-dom-policy-getallowlistforfeature
step 5 isn't linked to a definition, so I'm not sure what it really
means there.

Similarly, what exactly are the restrictions on origins you can pass to
allowsFeature
(<https://drafts.featurepolicy.rocks/add-introspection/#ref-for-dom-policy-allowsfeature>)
to get information out?

-Boris

[Ian Clelland]

On Fri, Jul 27, 2018, 12:02 PM Boris Zbarsky <bzba...@mit.edu> wrote:

On 7/27/18 11:43 AM, Ian Clelland wrote:
> The only thing that should be observable to any subframe is whether the
> embedder granted or denied it access to particular features

Just to make sure we're on the same page, we're talking about the
Policy.getAllowlistForFeature API right?

In general, I was talking about the observable policy, which is what all of the APIs query, but I think everything I said applies to that specifically as well, yes.

> It can't see what other hosts might
> have access to the features in other frames, or whether a feature would
> be available at another origin if it were to navigate to it.

In that case, what exactly is the list of origins that
getAllowlistForFeature() returns?  Is that just looking at the origins
in the feature policy the site is applying to itself, not the ones from
the parent?

If we're talking about document.policy, then yes. If the document is allowed to use the feature, then that should return all of the origins in the allowlist that it applied to itself (or whatever the default for the feature would be, if it didn't specify it's own header). And if not, then the list should be empty.

  The term "declared policy" it's using in
https://drafts.featurepolicy.rocks/add-introspection/#ref-for-dom-policy-getallowlistforfeature
step 5 isn't linked to a definition, so I'm not sure what it really
means there.

That should be linked, I'll have to fix that when I get back from vacation. The declared policy should be the policy specified in the header.