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

249 views
Skip to first unread message

David Van Cleve

unread,
Jul 16, 2020, 7:02:51 PM7/16/20
to blink-dev
Contact

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

unread,
Jul 16, 2020, 7:17:37 PM7/16/20
to David Van Cleve, blink-dev
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

unread,
Jul 16, 2020, 7:21:00 PM7/16/20
to blink-dev, Dominic Farolino, blink-dev, David Van Cleve

Jeremy Roman

unread,
Jul 17, 2020, 11:01:54 AM7/17/20
to David Van Cleve, blink-dev, Dominic Farolino
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

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.

Mike West

unread,
Jul 21, 2020, 8:20:52 AM7/21/20
to Jeremy Roman, David Van Cleve, blink-dev, Dominic Farolino
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


David Van Cleve

unread,
Jul 21, 2020, 4:46:47 PM7/21/20
to blink-dev, Mike West, David Van Cleve, blink-dev, Dominic Farolino, Jeremy Roman
> Is that correct?

Yep.

Mike West

unread,
Jul 30, 2020, 2:14:41 PM7/30/20
to blink-dev, David Van Cleve, Mike West, blink-dev, Dominic Farolino, Jeremy Roman
Were you able to gather any anecdotal information from HTTP Archive, one way or the other?

-mike

David Van Cleve

unread,
Jul 30, 2020, 2:27:53 PM7/30/20
to Mike West, blink-dev, Dominic Farolino, Jeremy Roman
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

unread,
Aug 18, 2020, 8:28:38 AM8/18/20
to David Van Cleve, Mike West, blink-dev, Dominic Farolino, Jeremy Roman
Any progress on use counters or HA data? 

David Van Cleve

unread,
Aug 18, 2020, 12:10:07 PM8/18/20
to Yoav Weiss, Mike West, blink-dev, Dominic Farolino, Jeremy Roman
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

unread,
Aug 18, 2020, 12:22:10 PM8/18/20
to David Van Cleve, Mike West, blink-dev, Dominic Farolino, Jeremy Roman
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

unread,
Aug 18, 2020, 12:24:29 PM8/18/20
to Yoav Weiss, Mike West, blink-dev, Dominic Farolino, Jeremy Roman
> 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

unread,
Aug 19, 2020, 4:45:07 AM8/19/20
to David Van Cleve, Mike West, blink-dev, Dominic Farolino, Jeremy Roman
In that case, maybe report back once results from M85 stable start to come in?

Mike West

unread,
Aug 20, 2020, 3:40:54 PM8/20/20
to blink-dev, yo...@yoav.ws, Mike West, blink-dev, Dominic Farolino, Jeremy Roman, David Van Cleve
`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

unread,
Aug 20, 2020, 3:43:25 PM8/20/20
to Mike West, blink-dev, yo...@yoav.ws, Dominic Farolino, Jeremy Roman
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

unread,
Sep 14, 2020, 12:30:24 PM9/14/20
to blink-dev, mk...@chromium.org, yo...@yoav.ws, d...@chromium.org, jbr...@chromium.org
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

unread,
Sep 14, 2020, 11:57:36 PM9/14/20
to David Van Cleve, blink-dev, Mike West, d...@chromium.org, jbr...@chromium.org
Thanks for gathering those numbers!
Given low enough usage - LGTM1

Chris Harrelson

unread,
Sep 15, 2020, 1:07:56 AM9/15/20
to Yoav Weiss, David Van Cleve, blink-dev, Mike West, Dominic Farolino, Jeremy Roman

Tom Jones

unread,
Sep 15, 2020, 3:40:18 PM9/15/20
to Yoav Weiss, David Van Cleve, blink-dev, Mike West, d...@chromium.org, jbr...@chromium.org
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:

Daniel Bratell

unread,
Sep 17, 2020, 3:04:53 PM9/17/20
to blink-dev, thomascli...@gmail.com, dav...@chromium.org, blink-dev, mk...@chromium.org, d...@chromium.org, Jeremy Roman, yo...@yoav.ws
LGTM3

/Daniel

yo...@yoav.ws

unread,
Sep 17, 2020, 3:06:16 PM9/17/20
to blink-dev, thomascli...@gmail.com, dav...@chromium.org, blink-dev, mk...@chromium.org, d...@chromium.org, Jeremy Roman, 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

unread,
Dec 5, 2020, 2:43:37 PM12/5/20
to blink-dev, yo...@yoav.ws, thomascli...@gmail.com, David Van Cleve, blink-dev, Mike West, Dominic Farolino, Jeremy Roman
Reply all
Reply to author
Forward
0 new messages