Intent to Deprecate and Remove: <meta name=referrer content=list,of,policies>

[David Van Cleve]

Contact

dav...@chromium.org

Summary

Deprecate and remove <meta name=referrer content=list,of,policies>  

Chromium allows <meta name=referrer> tags, which specify referrer policies, that contain values with comma-separated lists of policies. We plan to remove this functionality, so that <meta name=referrer>'s content attribute will need to be a single policy.

The HTML spec, which specifies the tag's behavior, only allows single-policy values in the tag. Gecko and WebKit both only allow single-policy values, too, consistent with the spec. We plan to deprecate and remove Chromium's out-of-spec functionality to improve interoperability.

Comments

0.01% on UseCounter for <meta name=referrer content=something,with,a,comma> is significantly above the principles of web compatibility's threshold for trivial removals; we expect the change would not be very visible to users (for instance, a Firefox analysis of a substantially larger related change didn't find an increase in user-reported breakage), but it could result in hard-to-debug changes in server-side behavior.

We've added a more granular metric that counts the frequency of behavior differences relative to a counterfactual where we start disregarding these meta tags, and will come back with results once it's had time to bake in.

Specification: Editor's draft

Status in Chromium: Implemented, removal proposed (tracking bug)

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

• Gecko: implementation is consistent with the (less permissive) standardized behavior
• WebKit: implementation is consistent with the (less permissive) standardized behavior 
• Web Developers:No signals

[Dominic Farolino]

Non-OWNER 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/771a7008-b869-4d06-aaae-4f1f7f26ad20n%40chromium.org.

[David Van Cleve]

(Chrome Platform Status link: https://www.chromestatus.com/feature/5222897150853120.)

[Jeremy Roman]

On Thu, Jul 16, 2020 at 7:21 PM David Van Cleve <dav...@chromium.org> wrote:

(Chrome Platform Status link: https://www.chromestatus.com/feature/5222897150853120.)

On Thursday, July 16, 2020 at 4:17:37 PM UTC-7 Dominic Farolino wrote:

Non-OWNER LGTM

On Thu, Jul 16, 2020 at 5:03 PM David Van Cleve <dav...@chromium.org> wrote:

Contact

dav...@chromium.org

Summary

Deprecate and remove <meta name=referrer content=list,of,policies>  

Chromium allows <meta name=referrer> tags, which specify referrer policies, that contain values with comma-separated lists of policies. We plan to remove this functionality, so that <meta name=referrer>'s content attribute will need to be a single policy.

The HTML spec, which specifies the tag's behavior, only allows single-policy values in the tag. Gecko and WebKit both only allow single-policy values, too, consistent with the spec. We plan to deprecate and remove Chromium's out-of-spec functionality to improve interoperability.

Comments

0.01% on UseCounter for <meta name=referrer content=something,with,a,comma> is significantly above the principles of web compatibility's threshold for trivial removals; we expect the change would not be very visible to users (for instance, a Firefox analysis of a substantially larger related change didn't find an increase in user-reported breakage), but it could result in hard-to-debug changes in server-side behavior.

We've added a more granular metric that counts the frequency of behavior differences relative to a counterfactual where we start disregarding these meta tags, and will come back with results once it's had time to bake in.

Specification: Editor's draft

More specific spec link, since I looked it up. :)

 

Status in Chromium: Implemented, removal proposed (tracking bug)

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

• Gecko: implementation is consistent with the (less permissive) standardized behavior
• WebKit: implementation is consistent with the (less permissive) standardized behavior 
• Web Developers:No signals

--
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/771a7008-b869-4d06-aaae-4f1f7f26ad20n%40chromium.org.

--
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/6ef02393-7947-4e07-9eb4-cc9dad01afc4n%40chromium.org.

[Mike West]

I think the behavior we'd end up with is that Blink would ignore `<meta name=referrer content="same-origin,no-referrer-when-downgrade">`, as `same-origin,no-referrer-when-downgrade` is not a referrer policy. If this is the only referrer policy on the page, the page will default back to `no-referrer-when-downgrade` (or `origin-when-cross-origin`, assuming we ship that default). If it's not the only policy on the page, then there's no impact, as subsequent policies would have overridden it anyway. Is that correct?

I think https://chromestatus.com/metrics/feature/timeline/popularity/3315 is the use counter you're pointing to, but I'm not sure it's even hit beta yet. My intuition is that this will be safe to ship, but I'd like us to do a bit more legwork to verify that. For example, we could estimate the impact by sifting through HTTP Archive, which would give you some data without needing to wait for the counter to hit stable. 

-mike

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

[David Van Cleve]

> Is that correct?

Yep.

[Mike West]

Were you able to gather any anecdotal information from HTTP Archive, one way or the other?

-mike

[David Van Cleve]

I haven't yet checked HTTP Archive. 

In other news, we added a finer-grained use counter (attempting to measure the number of requests that actually see different policies due to the presence of these meta tags); unfortunately it might be buggy and I haven't yet investigated why.

[Yoav Weiss]

Any progress on use counters or HA data? 

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

[David Van Cleve]

Chromestatus reports 0.0026% usage on HTMLMetaElementReferrerPolicyMultipleTokens, which is now in M85 beta.

No progress on debugging on the more fine-grained counter that is supposed to measure when multiple-token meta referrer attributes actually affect outgoing requests' policies. 

[Yoav Weiss]

On Tue, Aug 18, 2020 at 6:10 PM David Van Cleve <dav...@chromium.org> wrote:

Chromestatus reports 0.0026% usage on HTMLMetaElementReferrerPolicyMultipleTokens, which is now in M85 beta.

Is this an upper bound? If so, it might be worthwhile to take a second look when M85 is in stable (supposedly soon). That may be low enough to go ahead with removal.

[David Van Cleve]

> Is this an upper bound? 

It is, in the sense that processing a <meta name=referrer> tag containing a comma-separated list of policies does not necessarily yield an effective policy different from the policy that would have taken place had we ignored the tag.

[Yoav Weiss]

In that case, maybe report back once results from M85 stable start to come in?

[Mike West]

`HTMLMetaElementReferrerPolicyMultipleTokens` spiked to +40% (https://www.chromestatus.com/metrics/feature/timeline/popularity/3348), which seems unlikely to be trustworthy. Perhaps we can wait a bit to see if it stabilizes at some lower value? And/or look at the code again to see if it's measuring what we hope it's measuring?

-mike

[David Van Cleve]

Mike -

You linked a different metric, HTMLMetaElementReferrerPolicyMultipleTokensAffectingRequest, which is the (sadly known broken) attempt to make a finer-grained metric of when the referrer policy of an outgoing request would be different if we were disregarding values containing commas.

[David Van Cleve]

M85's now been on stable for a couple weeks and the use counters are showing 0.002%, putting this in the principles of web compatibility's "small but nontrivial" category.

Doesn't look like 20200901 data is available yet in the httparchive.blink_features.usage table. I'll set a reminder to check back later in the month to see if that data's been populated.

[Yoav Weiss]

Thanks for gathering those numbers!

Given low enough usage - LGTM1

[Chris Harrelson]

LGTM2

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

[Tom Jones]

this is really weird - getting rid of policies here and adding them back in via the web id. Is there anybody looking at the larger picture? It seems like this is just a bunch of initiatives that don't even try to work together.

Peace ..tom

On Mon, Sep 14, 2020 at 8:57 PM Yoav Weiss <yo...@yoav.ws> wrote:

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

[Daniel Bratell]

LGTM3

/Daniel

[yo...@yoav.ws]

Note that we're not getting rid of any policies here. This intent is about removing the comma based syntax to define multiple policies in a single meta tag.

[Eric Lawrence]

This change has landed for M89. 

https://chromium.googlesource.com/chromium/src.git/+/abf76d0d5ebfcd4be715a53b914512156d524c60