Intent to Deprecate and Remove: Support for space-separated tokens in Feature Policy 'allow' attribute

50 views
Skip to first unread message

Ian Clelland

unread,
Aug 31, 2017, 11:42:48 AM8/31/17
to blink-dev

Primary eng (and PM) emails

icle...@chromium.org, loon...@chromium.org


Summary

The <iframe allow> attribute was introduced with Feature Policy in M60 as a way to give developers fine-grained control over feature exposure in frames. It was originally specified as a DOMTokenList so that multiple features could be specified, like


<iframe allow="usb vr fullscreen">


as well as single features:


<iframe allow="usb">


The spec has been extended to allow a complete policy to be declared for frames, rather than just feature names, and the syntax which was eventually settled on was based heavily on CSP directives, which are separated from each other with semicolons. In this case, the first example would now be expressed as


<iframe allow="usb; vr; fullscreen">


while the second would be unchanged.


This intent is to remove support for the first example, and to require the semicolons as separators.


Motivation

In the updated syntax, a space separator is used to separate a feature name from the origins on which it is allowed. For example, this would be a valid policy directive


<iframe allow="fullscreen https://example.com https://example.org">


This matches the "directive-name source source..." syntax of CSP directives, but is incompatible with the previous DOMTokenList implementation. We have added an exception to the feature policy parser which tries to detect when the old syntax is being used, and falls back to that interpretation, but this is intended to be short-lived, and we'd like to remove that code eventually. Deprecating the old syntax early, before there is a lot of adoption of FP, will be easier than doing it later.


Interoperability and Compatibility Risk

When only a single feature is enabled through the allow attribute, there is no compatibility risk. The old and new syntaxes are identical in that situation.


When multiple features are enabled, the two syntaxes are incompatible, and so the plan is to support both during the deprecation period. After the old syntax is deprecated, some features which were previously enabled in frames may be disabled (the second and subsequent named features in the list) until the site is updated.

This feature is not yet supported in any other engine.


Alternative implementation suggestion for web developers

Switch to the new syntax, use semicolons between feature names. The deprecation message should include a link to a page which explains how to do this.


Usage information from UseCounter

How much of the web are you going to break? How seriously would the removal break sites?

If possible, please link to usage details on chromestatus.com/metrics (example link)

If you haven’t instrumented this feature yet, say so.

The usage of the allow attribute itself is being tracked with https://www.chromestatus.com/metrics/feature/timeline/popularity/2028, but this does not track the cases where multiple features are being specified, so a new counter is being introduced for that situation in M62. That will give us concrete data about the safety of removing the old syntax.

OWP launch tracking bug

https://crbug.com/761009


Entry on the feature dashboard

This is a small change to a recently introduced part of the FP API which I suspect doesn't need it's own entry on the feature dashboard.


Requesting approval to remove too?

Yes. After a short deprecation period -- two or three releases, which would mean removal in M65 -- we would like to remove the code which detects and interprets the old syntax.


PhistucK

unread,
Aug 31, 2017, 12:35:53 PM8/31/17
to Ian Clelland, blink-dev
Since feature policy is used in 0.006% (which is very low) and because Chrome is the only browser that supports it at the moment, I am not sure a deprecation period is even needed. The usage could just spread as long as it is available.
Developers that implemented that feature in their properties so quickly are probably up to date with the recent developments, so a ChromeStatus entry plus a blog post mention should probably be enough. Plus, it does not really break anything or causes any real security issue at the moment (especially since only Chrome supports it).
Is it possible to merge this to Chrome 61 before it goes stable?


☆PhistucK

--
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_TSX%2BqSSnsmTdSZW7ryZ7fCa_0cXL%3DHHLDpy%3DwjOF6WXHP0w%40mail.gmail.com.

Philip Jägenstedt

unread,
Sep 4, 2017, 11:38:13 AM9/4/17
to PhistucK, Ian Clelland, blink-dev
It looks like FP was first shipped in M60, and M61 is so close than I'm pretty sure a merge request for this would be denied.

Given the "exception to the feature policy parser which tries to detect when the old syntax is being used" I think this is a case where the deprecation message could remain after the removal, or at least some other helpful console message. This reduces the need to have developers see and react to the deprecation message before removal.

Ian, I guess this also includes a change to the IDL, to reflect this as a plain DOMString? (The risk of that is more work to measure, requiring extra bookkeeping on DOMTokenList instances. I'm skeptical that it's worth doing.)

So, given that speedy removal would reduce the risk that new sites come to depend on the old behavior, and that the feature policy also won't apply in any other browser, I think it's fine to do the removal as early as you would like.

LGTM1 to deprecate in M62, and to remove in M62 or as early as you're comfortable with.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

PhistucK

unread,
Sep 6, 2017, 3:13:14 AM9/6/17
to Philip Jägenstedt, Ian Clelland, blink-dev
https://groups.google.com/d/msg/discuss-webrtc/32natnrbP6U/xykBGw9gAgAJ states that Chrome 63 accepts comma separated tokens. This intent mentions semicolon separated tokens. Is this intentional?


☆PhistucK

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_TSX%2BqSSnsmTdSZW7ryZ7fCa_0cXL%3DHHLDpy%3DwjOF6WXHP0w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

--
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/CAARdPYchgPN1yDG9Q9oFonk3s_znEx3dez2vKDMWQwCM0yPq5Q%40mail.gmail.com.

Ian Clelland

unread,
Sep 6, 2017, 10:14:20 AM9/6/17
to PhistucK, Philip Jägenstedt, Ian Clelland, blink-dev
Semicolons are the intended separators, though it appears that the deprecation message doesn't actually give any guidance -- that should be fixed. It turns out that we *do* support comma-separated, but as a side-effect of using the same parser for the HTTP header that we do for the allow attribute. (Commas are always allowed to separate duplicate HTTP headers, so we end up handling them just like semicolons.

(CSP does this slightly differently, I think -- in that spec, commas separate distinct policies, which are each enforced separately. In FP, that doesn't really make sense; later declarations for the same feature are simply ignored.)

Rick Byers

unread,
Sep 6, 2017, 10:32:05 AM9/6/17
to Ian Clelland, PhistucK, Philip Jägenstedt, blink-dev
LGTM2 to deprecate in M62 and remove whenever you're comfortable with (including M62 if the warning remains).


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

Dimitri Glazkov

unread,
Sep 6, 2017, 10:54:34 AM9/6/17
to Rick Byers, Ian Clelland, PhistucK, Philip Jägenstedt, blink-dev
LGTM3



☆PhistucK

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_TSX%2BqSSnsmTdSZW7ryZ7fCa_0cXL%3DHHLDpy%3DwjOF6WXHP0w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

--
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/CAK_TSXLPDEC6O52x8Qvc2qZHsUc_Do84guH6H92_Jxdxhpj9Fw%40mail.gmail.com.

--
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/CAFUtAY9aZ%3DPkRa7TMZPyMBYttAiNSejGO-ZviBc07bhm8D7mSw%40mail.gmail.com.

PhistucK

unread,
Sep 6, 2017, 3:38:48 PM9/6/17
to Ian Clelland, Philip Jägenstedt, blink-dev
That sounds like a future interoperability problem (or weird things like <meta name=viewport content="foo, bar"> with a deprecation message that says that it should be foo; bar yet accepts it for a long time).
Can you add web platform tests that test that it accepts , as well as ;? Otherwise (probably preferred), please, drop this feature.


☆PhistucK
Reply all
Reply to author
Forward
0 new messages