Intent to Deprecate and Remove: Comma separator in iframe allow attribute

[Ian Clelland]

Contact emails icle...@chromium.org Design docs/spec Specification: https://w3c.github.io/webappsec-feature-policy TAG review None Summary This deprecation removes the ability to use "," as a separator between items in a permissions policy declaration (feature policy declaration) in an iframe tag. Developers should switch to ";" as the correct separator.

Chrome currently recognizes a non-standard "," as a separator between items in an iframe "allow" attribute. This behaviour is an accidental side effect of the way that we parse the attribute using the same parser as the 'Feature-Policy' header. (Commas were allowed by the header parser to support concatenating multiple headers together, but the attribute was always specced to contain a single serialized policy.)
Interoperability and Compatibity Risks:

This deprecation improves interoperability, by aligning with the specification and with the implementation in Gecko.

The compatibility risk is that sites are currently relying on the behaviour, and features which are currently enabled in subframes would stop being enabled until the markup is corrected.

UMA was added to Chrome in M77 to track the use of commas as separators, and although it does not distinguish between commas inserted by concatenating headers from those in HTML markup, it does show that usage is very low: 0.02% of page visits, compared to 8% of visits for overall usage of the allow attribute.

Additionally, an analysis of HTTPArchive data shows just 247 instances of commas in allow attributes out of 190M resources (analyzing static markup).

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes. Or rather no, it will be uniformly removed from all six Blink platforms. Is this feature fully tested by web-platform-tests? Yes, its absence will be tested. Web platform tests will be added to ensure consistent behaviour when the disallowed comma is encountered by the parser. Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/5740835259809792

This intent message was mostly generated by Chrome Platform Status. I had to modify it quite a bit.

[Mounir Lamouri]

Do we have an idea of which websites are still using the deprecated list formatting? Based on the numbers, I assume it may be the long tail. Also, are we currently showing a warning? If no, is the plan to show a warning before removing support entirely?

--
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_TSXJP7jEXah_e8isRP6H%3DwyJhff%2BCgyWhn9NpRmO0VO2%3Dww%40mail.gmail.com.

[Ian Clelland]

We have the URLs from HTTPArchive, and the Alexa rank for some of those, but that's currently all. I can share the queries and/or results; HTTPArchive is a public dataset. Most of the sites are certainly long-tail. There are 5 domains represented which are ranked in the top 10000 (by top-level domain only, which skews the results):

• <single-blog>.blogspot.com
• <single-site>.github.io
• cdn.shopify.com
• www.mediaworld.it
• utlo.ukzn.ac.za

Additionally, about 25% of the results (56 observed resources) come from a JS file served by visitwidget.com, which could be worth reaching out to.

My plan currently is to show a warning in M86-M87, and remove in M88, but that timeline isn't fixed at all.

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

[Frédéric Wang]

On 17/07/2020 20:08, Ian Clelland wrote:

Interoperability and Compatibity Risks:

This deprecation improves interoperability, by aligning with the specification and with the implementation in Gecko.

Hi, can you please indicate what's the status / plan for WebKit ?

-- 
Frédéric Wang

[Ian Clelland]

I haven't tested it manually, but my understanding from skimming the source there (Source/WebCore/html/FeaturePolicy.cpp and Source/WebCore/html/HTMLIFrameElement.cpp) is that this aligns with WebKit's implementation as well. I believe that the comma-separator is only supported in Blink.

--
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/3bece5be-d94c-8054-e5b9-5c164517f9ba%40igalia.com.

[Mounir Lamouri]

This looks good to me. Reaching out to visitwidget.com and shopify.com may be a good idea but it's likely this will pop into their radar when a warning is added.

[Ian Clelland]

Thanks, Mounir -- I'll reach out to let them know what's going on.

This still needs an API_OWNER LGTM to proceed, I believe; I'm just waiting on that.

Ian

[Daniel Bratell]

0.02% of page visits affected is quite a bit higher than we would quickly approve. What will the effect be in general for those using the comma if its no longer supported. Will it be noticed? Will it be fatal?

Maybe you got an idea when looking at those sites you analyzed?

/Daniel

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

[Ian Clelland]

0.02% is an upper bound; unfortunately we don't currently distinguish between a comma created by concatenating HTTP headers and a comma in the text of an iframe allow attribute. The deprecation CL does add such a use counter. (WIP at https://chromium-review.googlesource.com/c/chromium/src/+/2313298)

In general, the attribute is used to grant features to cross-origin subframes which would normally be blocked. If we stop accepting the comma as a separator, then those frames will no longer be able to use those features, or to request permission to use those features. They will act like any other third-party embedded frame, with no extra privileges. For a feature like fullscreen, the embedded site will see that window.fullscreenEnabled is always false. For permission-based features, they will see that permission is always denied when requested (exactly as if the user always declined, although this will be invisible to the user).

Looking through HTTPArchive, out of the 225 pages which include a static allow attribute with a comma, we see this distribution of features:

fullscreen: 181 mentions

autoplay: 97

accelerometer: 79

gyroscope: 76

geolocation: 64

vr: 54

encrypted-media: 34

microphone: 18

camera: 17

picture-in-picture: 15

payment: 6

midi: 1

I'll take a look at the pages themselves to see what the impact would likely be.

[Yoav Weiss]

On Wed, Jul 22, 2020 at 8:58 PM Ian Clelland <icle...@chromium.org> wrote:

0.02% is an upper bound; unfortunately we don't currently distinguish between a comma created by concatenating HTTP headers and a comma in the text of an iframe allow attribute. The deprecation CL does add such a use counter. (WIP at https://chromium-review.googlesource.com/c/chromium/src/+/2313298)

I'd expect concatenated HTTP headers to be quite common, so it would be good to get data on the distinction between headers and attributes.

 

In general, the attribute is used to grant features to cross-origin subframes which would normally be blocked. If we stop accepting the comma as a separator, then those frames will no longer be able to use those features, or to request permission to use those features. They will act like any other third-party embedded frame, with no extra privileges. For a feature like fullscreen, the embedded site will see that window.fullscreenEnabled is always false. For permission-based features, they will see that permission is always denied when requested (exactly as if the user always declined, although this will be invisible to the user).

Looking through HTTPArchive, out of the 225 pages which include a static allow attribute with a comma, we see this distribution of features:

fullscreen: 181 mentions

autoplay: 97

accelerometer: 79

gyroscope: 76

geolocation: 64

vr: 54

encrypted-media: 34

microphone: 18

camera: 17

picture-in-picture: 15

payment: 6

midi: 1

My rough math says that from a page perspective, 225/5M gives us ~0.0045%

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

[Ian Clelland]

On Tue, Jul 28, 2020 at 2:48 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Wed, Jul 22, 2020 at 8:58 PM Ian Clelland <icle...@chromium.org> wrote:

0.02% is an upper bound; unfortunately we don't currently distinguish between a comma created by concatenating HTTP headers and a comma in the text of an iframe allow attribute. The deprecation CL does add such a use counter. (WIP at https://chromium-review.googlesource.com/c/chromium/src/+/2313298)

I'd expect concatenated HTTP headers to be quite common, so it would be good to get data on the distinction between headers and attributes.

I've added a UseCounter for just that (thanks for the quick review). It'll take a while to start getting meaningful data out of that; I"ll see if I can get it backported to M85, but otherwise it won't hit stable until October at this point. 

 

In general, the attribute is used to grant features to cross-origin subframes which would normally be blocked. If we stop accepting the comma as a separator, then those frames will no longer be able to use those features, or to request permission to use those features. They will act like any other third-party embedded frame, with no extra privileges. For a feature like fullscreen, the embedded site will see that window.fullscreenEnabled is always false. For permission-based features, they will see that permission is always denied when requested (exactly as if the user always declined, although this will be invisible to the user).

Looking through HTTPArchive, out of the 225 pages which include a static allow attribute with a comma, we see this distribution of features:

fullscreen: 181 mentions

autoplay: 97

accelerometer: 79

gyroscope: 76

geolocation: 64

vr: 54

encrypted-media: 34

microphone: 18

camera: 17

picture-in-picture: 15

payment: 6

midi: 1

My rough math says that from a page perspective, 225/5M gives us ~0.0045%

That's true, though it's .0045% of a biased sample of pages, and the HTTPArchive search can only catch those which have the allow attribute specified in static markup, not dynamically added by scripts.

Ian. 

[Ian Clelland]

As a quick update here, the data that we're seeing from Canary shows some different usage patterns than stable, with only 0.008% of page views triggering the "was there a comma anywhere" counter (compared to 0.02% on stable), but approximately 75% of that is triggered by the allow attribute. The numbers on Canary are very low in absolute terms, though, so this should be taken with a statistically-significant grain of salt.

If we were to extrapolate that to stable usage today, we could expect 0.015% of page visits to trigger the counter.

[Ian Clelland]

I've merged the use counter back to M85, so we should hopefully be able to get a better understanding of the actual usage once that hits stable. In the meantime, I'll try to contact some of the larger contributors, to see if I can start driving down usage through outreach.

[Mike West]

Hey Ian!

M85 shipped. Would you mind taking a look at the numbers and helping us understand actual usage?

-mike

[Ian Clelland]

With the last week or so of data, looking at samples restricted to M85 stable, it looks like ~80% of the instances of "," are within an allow attribute, for about 0.02% of page visits (out of 0.027% total). So the proportions we were seeing on Canary were roughly correct, although the percentage of visits which trigger the counter at all is much lower.

--

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/ab354a5d-1f15-498d-baa9-f21d3e40f901o%40chromium.org.

[Ian Clelland]

I would still like to move ahead with a deprecation and eventual removal here, so I'll summarize the results so far:

From UMA, we see the allow attribute being used on about 8% of page visits, on Chrome M85 stable, across all platforms. Of these, about 0.25% use the non-standard comma as a separator (or in error; the use counter just looks for a "," anywhere inside of the attribute value), for a combined fraction of 0.02% of page visits.

Looking at HTTP Archive data through a regular expression filter, I saw ~250 instances in static markup of an allow attribute with a comma, out of 5M archived requests. Many of those could not be confirmed in a live browser. This is 0.005%, or 20% of what we would expect to see based on UMA data, which indicates that a large percentage of usage is either in the very long tail, not on home pages, or inserted dynamically by script.

Analysing the results that we could see there, via a combination of embedding domain and iframe src URL (where available), it can be broken up into a few large targets:

 - kuula.co, which provides embedding code to customers for embedding VR photos (29% of instances)

 - visitwidget.com, which serves JS which generates the attribute (20%)

 - nix.ru, which seems to host a minified jquery file which includes it once for a video gallery widget (17%)

 - YouTube, but only in cases where customers have copy/pasted embedding code that must have used the old syntax. Currently-provided embedding code uses the new syntax. (11%)

 - Vimeo, in exactly the same situation as YouTube, where old embedding code that has been pasted into customer's pages needs to be updated, and new code is correct. (3%)

 - Randstad, which includes "fullscreen,autoplay" in a JS file. (6%)

I have reached out to VisitWidget and Kuula, and both of them should be changing the code they supply in the near future. That won't automatically fix sites who have pasted the embed code statically, but it also means that the largest providers are aware of the issue and could provide support to those customers.

To check for dynamic insertion, I also ran a custom Cluster Telemetry run on the top 100K pages, to look for any sites which trigger the use counter by any means, and found four sites, only one of which I could reproduce live. This roughly matches the HTTPArchive results (0.005%), and again shows that about 80% of usage is not seen at load time on popular home pages.

From what we can see, most sites are using this for video or other media embeds, where the change will likely reduce the quality of the user experience (by revoking fullscreen or autoplay permission, for instance) but not break it completely. In most cases, the site will see the same behaviour on Chrome after this change as it currently does on Safari or Firefox. 

As a way to move forward, I'd propose running this as a deprecation for two Chrome releases (likely M87 and M88), with appropriate console messages and deprecation reports, and then removing the syntax for M89. If it seems warranted, we can add UKM to the counter for M86, and attempt to identify the sources of the remaining usage, but that may not be necessary to drive usage down.

WDYT?

[Daniel Bratell]

LGTM1 on the final plan with a two release deprecation period. 

[Yoav Weiss]

LGTM2

Usage is a bit high, but at the same time, the breakage itself doesn't seem awful and this aligns behavior with Firefox and Safari (already suffering from that breakage).

Please reach out to YouTube as well as the other embedders and make them aware that this is happening.

[Chris Harrelson]

LGTM3 to remove after two milestones.

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

[Ian Clelland]

Thanks, all!