Intent to Implement and ship: Feature Policy JS Introspection API

[Ian Clelland]

Contact emails

icle...@chromium.org

Explainer

Link to explainer

Spec

https://wicg.github.io/webappsec-feature-policy/#introspection

(moving soon, new location likely https://w3c.github.io/webappsec-feature-policy/#introspection)

Tag review request: https://github.com/w3ctag/design-reviews/issues/292

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.

Developers can use this to ask questions like:

What features does this browser support?

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

Intent to experiment thread at https://groups.google.com/a/chromium.org/d/msg/blink-dev/pQZopKWaQIk/Z-XD1hvwBQAJ

Link to Origin Trial feedback summary

The feature was available in an origin trial between Chrome 69 and 71. There were 13 tokens issued to 9 origins.

Most of the feedback was out of band, on GitHub or through personal communication.

We had feedback that the attribute name should probably be the more specific 'featurePolicy', rather than the original generic 'policy', and we had a few requests for the ability to get a list of features supported by the user agent. Both suggestions have been implemented in the latest spec.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://feature-policy-demos.appspot.com

Debuggability

The feature provides a JS interface which can be queried from the DevTools console. Additionally, there is a chrome DevTools extension available at https://chrome.google.com/webstore/detail/feature-policy-tester-dev/pchamnkhkeokbpahnocjaeednpbpacop which makes use of the API to provide DevTools control over a document's feature policy.

Risks

Interoperability and Compatibility

Hopefully fairly low risk, Mozilla has started implementing the API already, and I expect that other browsers will follow suit once they implement the rest of Feature Policy.

Edge: Public support for Feature Policy, no signals for this specific API

Firefox: In development

Safari: No signals

Ergonomics

This will likely be used with the features controlled by feature policy -- it may make some methods of those features redundant: document.fullscreenAllowed, for instance, should be identical to document.featurePolicy.allowsFeature('fullscreen')

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)? - No.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes. (The document.featurePolicy.features() API is testable, but tests are still being completed - follow along at https://bugs.chromium.org/p/chromium/issues/detail?id=917070)

Entry on the feature dashboard

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

[Boris Zbarsky]

On 12/20/18 1:50 PM, Ian Clelland wrote:
> Firefox: In development

I'm not sure this is an accurate characterization. The correct status
is that we have prototyped Feature Policy (including the introspection
API, or at least an old version of it), discovered some serious issues
with it as it stands on the spec side, and now it's on hold at least
until those issues are resolved. After that point we will re-evaluate
where things stand.

I'm not aware of any specific plans at the moment to update the code to
the current introspection spec updates or to ship it.

For the introspection API we would likely need a privacy review on our
end at the very least, and that has not happened that I know of. So it
may well turn out that the current shape of the API is not something we
are willing to ship at all.

-Boris

[Ian Clelland]

Thanks, Boris --

I took https://bugzilla.mozilla.org/show_bug.cgi?id=1514296 to mean that the feature was in development, and at least roughly following the spec changes. I didn't mean to imply that it was actually shipping. I haven't updated chromestatus yet; I suppose I'll probably have to set that to "public skepticism", at least for this JS API?

Also, please feel free to raise any concerns, privacy or otherwise, here, or on GitHub (https://github.com/WICG/webappsec-feature-policy/issues/65 is specifically about this API, or file new issues if needed)

Ian

[Boris Zbarsky]

On 12/20/18 9:29 PM, Ian Clelland wrote:
> I took https://bugzilla.mozilla.org/show_bug.cgi?id=1514296 to mean that
> the feature was in development, and at least roughly following the spec
> changes.

I think the prototype is being updated, but it's all still pending
sorting out what we want to do about feature policy in general...

-Boris

[Yoav Weiss]

On Thu, Dec 20, 2018 at 10:50 PM Ian Clelland <icle...@chromium.org> wrote:

Contact emails

icle...@chromium.org

Explainer

Link to explainer

Spec

https://wicg.github.io/webappsec-feature-policy/#introspection

(moving soon, new location likely https://w3c.github.io/webappsec-feature-policy/#introspection)

The link was broken, so I took the liberty to put my WICG chair hat on and create a redirection repo :)

This particular section is described as "not stable". Is that still the case? How confident are we that the API shape is final?

  

Tag review request: https://github.com/w3ctag/design-reviews/issues/292

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.

Developers can use this to ask questions like:

What features does this browser support?

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?

I find the spec examples lacking feature detection advice.

IIUC, developers can find if this is supported or not by seeing if `featurePolicy()` is there, but what are they supposed to do if it's not?

I'm guessing they should just assume that those capabilities are enabled, but some official developer advice would be good on that front.

--
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_TSXLC3kUVrUivBOeA1cnByfq3rdr561_Z-nWYWco8u%3DDv1g%40mail.gmail.com.

[Yoav Weiss]

Friendly post-holidays ping! :)

[Ian Clelland]

Sorry Yoav, I was *certain* that I had responded to these. foolip brought it to my attention yesterday that somehow I hadn't.

On Thu, Jan 17, 2019 at 12:34 PM Yoav Weiss <yo...@yoav.ws> wrote:

Friendly post-holidays ping! :)

On Mon, Dec 24, 2018 at 7:53 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Dec 20, 2018 at 10:50 PM Ian Clelland <icle...@chromium.org> wrote:

Contact emails

icle...@chromium.org

Explainer

Link to explainer

Spec

https://wicg.github.io/webappsec-feature-policy/#introspection

(moving soon, new location likely https://w3c.github.io/webappsec-feature-policy/#introspection)

The link was broken, so I took the liberty to put my WICG chair hat on and create a redirection repo :)

Thanks for setting that redirect up, btw. The transition from github/WICG to github/W3C wasn't as smooth as it could have been.

This particular section is described as "not stable". Is that still the case? How confident are we that the API shape is final?

 The JS API should be marked as stable now, I'll update that in the draft spec. (I thought that I had done it already -- even said so in https://github.com/w3c/webappsec-feature-policy/issues/216#issuecomment-447361706, but apparently not :( )

I think that the API is in essentially the shape that we want it; we've taken the feedback that we received from the trial, and from our DevRel folks. I'm still waiting on TAG feedback -- that issue has been open for 6 months now, and I'm not sure how long is reasonable to wait there.

  

Tag review request: https://github.com/w3ctag/design-reviews/issues/292

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.

Developers can use this to ask questions like:

What features does this browser support?

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?

I find the spec examples lacking feature detection advice.

IIUC, developers can find if this is supported or not by seeing if `featurePolicy()` is there, but what are they supposed to do if it's not?

I'm guessing they should just assume that those capabilities are enabled, but some official developer advice would be good on that front.

Spec examples, I think, should probably be written with the assumption that the spec is actually implemented. We can probably add some guidance in an explainer as to what to do if document.featurePolicy doesn't exist.

In general, without document.featurePolicy, developers will have to go back to the ad hoc heuristics around each feature. If you can infer that feature policy itself is supported, with either HTMLIframeElement.allow or UA sniffing, then you can make correct inferences about how availability of a particular feature will be granted to subframes. Determining that feature's availability in your own frame, however, will require different methods for different features. Fullscreen, for instance, has window.fullscreenEnabled; permissions-based features have the Permissions API (although the information obtained from that is a bit different from what you get out of featurePolicy); and availability of features like 'sync-xhr' can't really be detected, only caught on failure.

[Yoav Weiss]

Apologies for the delay.

LGTM1

What concerns me is developers copy-pasting examples from the spec, which will then result in exceptions thrown in non-supporting browsers.

With that said, other specs seem to follow the same assumption, so I'm reluctant to block on that.

In general, without document.featurePolicy, developers will have to go back to the ad hoc heuristics around each feature. If you can infer that feature policy itself is supported, with either HTMLIframeElement.allow or UA sniffing, then you can make correct inferences about how availability of a particular feature will be granted to subframes. Determining that feature's availability in your own frame, however, will require different methods for different features. Fullscreen, for instance, has window.fullscreenEnabled; permissions-based features have the Permissions API (although the information obtained from that is a bit different from what you get out of featurePolicy); and availability of features like 'sync-xhr' can't really be detected, only caught on failure.

Yeah, I wasn't looking for guidance on how to polyfill this, just to make sure developers don't introduce compat issues by assuming that this API is supported everywhere.

 

 

Link to “Intent to Implement” blink-dev discussion

Intent to experiment thread at https://groups.google.com/a/chromium.org/d/msg/blink-dev/pQZopKWaQIk/Z-XD1hvwBQAJ

Link to Origin Trial feedback summary

The feature was available in an origin trial between Chrome 69 and 71. There were 13 tokens issued to 9 origins.

Most of the feedback was out of band, on GitHub or through personal communication.

We had feedback that the attribute name should probably be the more specific 'featurePolicy', rather than the original generic 'policy', and we had a few requests for the ability to get a list of features supported by the user agent. Both suggestions have been implemented in the latest spec.

Glad to see that the OT feedback was incorporated!

 

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://feature-policy-demos.appspot.com

Debuggability

The feature provides a JS interface which can be queried from the DevTools console. Additionally, there is a chrome DevTools extension available at https://chrome.google.com/webstore/detail/feature-policy-tester-dev/pchamnkhkeokbpahnocjaeednpbpacop which makes use of the API to provide DevTools control over a document's feature policy.

Risks

Interoperability and Compatibility

Hopefully fairly low risk, Mozilla has started implementing the API already, and I expect that other browsers will follow suit once they implement the rest of Feature Policy.

Edge: Public support for Feature Policy, no signals for this specific API

Firefox: In development

Safari: No signals

I'm reading the feedback on this thread as "slight skepticism" from Firefox regarding FP in general, but no signals regarding this specific addition.

So, this would mean that we're first movers here with no signals from other vendors. 

At the same time, incorporated OT feedback increases the chances that we got the API shape right. And assuming developers would use feature detection, we'd be able to modify it in the future if it'd be necessary.

 

Ergonomics

This will likely be used with the features controlled by feature policy -- it may make some methods of those features redundant: document.fullscreenAllowed, for instance, should be identical to document.featurePolicy.allowsFeature('fullscreen')

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)? - No.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes. (The document.featurePolicy.features() API is testable, but tests are still being completed - follow along at https://bugs.chromium.org/p/chromium/issues/detail?id=917070)

Can you complete the test suite before this lands? Since we're first movers, we want to make it as easy as possible for other vendors to follow along.

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiaBFF-H2x7rFwy_w3SysC2C5CN6j3zrbsnuO%2BKGFwXuw%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zwhkx1perbppqq%40cicero2.linkoping.osa.

[PhistucK]

> and we had a few requests for the ability to get a list of features supported by the user agent. Both suggestions have been implemented in the latest spec.

Having a list of supported features by the user agent can be used to mistakenly feature detect the features themselves (rather than their support in feature policy). As far as I know, after learning from past mistakes, the web platform is deliberately trying to avoid that.

A TAG review might have caught that, but I see it is still pending. Can TAG be pinged (in person maybe) for a quicker review?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8BzHJh_-ZBx78MfM2kA0iOYqx1LrG0bbzTSUp7EbgeWQ%40mail.gmail.com.