Intent to Implement: New referrer policy default of strict-origin-when-cross-origin

[David Van Cleve]

Intent to Implement: New referrer policy default of  strict-origin-when-cross-origin

Contact emails

dav...@chromium.org, kaust...@chromium.org

Summary

Web developers may specify a referrer policy on their documents, which impacts the Referer header sent on outgoing requests and navigations. When no such policy is specified, Chrome will now use strict-origin-when-cross-origin as the default policy, instead of no-referrer-when-downgrade. When navigating across origins (or making cross-origin subresource requests) from initiating environments without alternate referrer policies specified, this will reduce the provided referrer to the initiating origin: this affects both the HTTP Referer headers sent with requests and, for document requests, the value of document.referrer exposed in the destination document.

Motivation

By default in Chrome, the HTTP Referer header provides the full URL of the initiating document alongside every navigation and subresource request (except on requests from HTTPS origins to non-HTTPS origins). In the wild, a substantial majority of links and images follow this default. Referrers silently reveal users’ browsing habits, identities (for instance, when websites place user IDs in URLs), and credentials (via capability-granting URLs). 

While developers have the option to limit the amount of information that is sent—by setting referrer policies at the page level (using meta tags or the HTTP Referrer-Policy header) and at the element level (with the referrerpolicy attribute)—this requires an explicit opt-in effort, leading to low adoption.

Standardization

We’ve opened pull requests on the Referrer Policy and Fetch standards.

Interoperability and Compatibility

General 

We expect that this change entails low risk: other browsers implement similar, but not directly comparable, policies. We intend to run an experiment in Chrome to gauge impact, and will also monitor feedback on this thread. In a Firefox UX study, users opted into a referrer cap to origin-on-cross-origin—overriding element- and page-level policies, in contrast to this proposal, which just sets a new default; the study found no statistically significant increase in visible breakage.

Firefox compatibility: As of Firefox 70 (Oct 2019), the default referrer policy is set to strict-origin-when-cross-origin, but only for requests to tracking domains.

Safari compatibility: As of Safari 11 (Sep 2018), referrers are capped to the source’s origin on requests to prevalent/tracking domains. A September 2019 update caps referrers to source eTLD+1 in some cases; recent patches extend this cap to all cross-origin navigations and some cross-origin subresource requests.

Security

Changing the default could lead some developers to react by setting the (more permissive) "unsafe-url" policy on some elements which previously had defaulted to no-referrer-when-downgrade. We will monitor this. 

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,

Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

The WPT referrer-policy test suite checks that implementations match the baseline behavior defined in the W3C webappsec-referrer-policy spec. 

Chrome's wpt.fyi results will reflect this change once it is enabled by default, but will not change during the time that it is behind a flag.

Link to entry on the Chrome Platform Status

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

[EricLaw-MSFT]

Exciting times! 

Does the proposed implementation here involve new code, or is it just changing the default for the existing chrome://flags/#reduced-referrer-granularity flag (and presumably eventually removing the flag control)?

Vis-a-vis the security concern: Is there any technical limitation that precludes an author from setting "no-referrer-when-downgrade" instead of changing to something less safe?

Any plans for an Enterprise policy control?

thanks!

[David Van Cleve]

It's just changing the default for the existing flag. No current plans regarding whether it'll be enterprise-configurable in the long term. (Of course, while the flag stays around, enterprise policies can configure the flag.)

There's no technical limitation precluding an author from setting "no-referrer-when-downgrade" explicitly (good question); the relevant code distinguishes between a "default" policy and an explicit no-referrer-when-downgrade policy, only affecting the former.

--
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/ccd010e6-ad16-4cc7-a2dd-bde87b841d27%40chromium.org.

[Eric Lawrence]

Thanks! Is this then more of an "Intent-to-Experiment" rather than an intent to implement, as it's already implemented? Is there a target milestone for the change?

> (Of course, while the flag stays around, enterprise policies can configure the flag.)

The way you've written that suggests that there's a way for enterprise policies to control any flag. I've not previously heard of such a thing-- is that the case?

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Ben Kelly]

On Wed, Oct 16, 2019 at 11:06 AM Eric Lawrence <elaw...@chromium.org> wrote:

Thanks! Is this then more of an "Intent-to-Experiment" rather than an intent to implement, as it's already implemented? Is there a target milestone for the change?

> (Of course, while the flag stays around, enterprise policies can configure the flag.)

The way you've written that suggests that there's a way for enterprise policies to control any flag. I've not previously heard of such a thing-- is that the case?

I think Eric is correct here.  There is not an easy way for enterprises to flip general feature flags.

Since this is changing a default policy it seems like it would be prudent to add an enterprise policy control as suggested in:

https://www.chromium.org/developers/enterprise-changes 

 

Thanks!

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/ccd010e6-ad16-4cc7-a2dd-bde87b841d27%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/7e348c55-4d8d-4582-8860-b470e68fa631%40chromium.org.

[Ben Kelly]

On Wed, Oct 16, 2019 at 3:52 PM David Van Cleve <dav...@google.com> wrote:

Eric: 

- I'm still new to the rollout process, but my understanding was that an I2I was the best fit since we're making a change that'll affect the default behavior of a web API.

- We're planning on rolling out to stable sometime in M79.

- Re configuring flags: whoops; reading the configuration docs, I interpreted "configurable via enterprise policy" as "easy for enterprises to configure," when it actually looks like it means "easy for a Chrome contributor to code that lets enterprises configure it"!

Ben, Eric: Are there any specific enterprise scenarios you're concerned about?

I think the issue is that there is a long tail of custom bespoke enterprise software out there and it's difficult to predict what is going to break.  Our best defense right now is to add enterprise policies with potentially breaking features like changing policy defaults.

+Brandon Heenan, what do you think of this one from the enterprise team's point of view?

 

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

[David Van Cleve]

Eric: 

- I'm still new to the rollout process, but my understanding was that an I2I was the best fit since we're making a change that'll affect the default behavior of a web API.

- We're planning on rolling out to stable sometime in M79.

- Re configuring flags: whoops; reading the configuration docs, I interpreted "configurable via enterprise policy" as "easy for enterprises to configure," when it actually looks like it means "easy for a Chrome contributor to code that lets enterprises configure it"!

Ben, Eric: Are there any specific enterprise scenarios you're concerned about?

On Wed, Oct 16, 2019 at 1:29 PM Ben Kelly <wande...@chromium.org> wrote:

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

[Brandon Heenan]

Agreed, for a potentially breaking change like this, we should follow the enterprise-friendly process:

• Communicate about it before we ship it. Since we'll be adding a policy control, we can put it in the enterprise release notes as soon as we know an approximate milestone... in reading the thread here, it sounds like that's 79?
• As suggested, have an enterprise policy for admins to opt back to the old behavior for a limited period of time

[bay...@gmail.com]

M79 is approaching rapidly, and the tracking bug doesn't have a milestone, but it does have a Target-80 label. https://bugs.chromium.org/p/chromium/issues/detail?id=1014207

Either way, I believe the ChromeStatus entry should be changed to "Behind a Flag" with the correct target milestone so that this feature shows up correctly in the https://www.chromestatus.com/features/schedule view? I think this will also help ensure that the Evangelism and TechWriting folks see it.

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ccd010e6-ad16-4cc7-a2dd-bde87b841d27%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 blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e348c55-4d8d-4582-8860-b470e68fa631%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 blin...@chromium.org.

[David Van Cleve]

- Chromestatus page updated to reflect that the change will be behind a flag in M79. (In fact, it's been behind a flag since 2014!)

- Working on an enterprise policy.

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

[Brandon Heenan]

Sounds good, thanks!

[Jeffrey Yasskin]

On Wed, Oct 16, 2019 at 3:11 PM 'David Van Cleve' via blink-dev <blin...@chromium.org> wrote:
>
> Eric:
> - I'm still new to the rollout process, but my understanding was that an I2I was the best fit since we're making a change that'll affect the default behavior of a web API.
> - We're planning on rolling out to stable sometime in M79.

Not commenting on the change itself, but if you're planning to ship in M79 (i.e. now), it seems like this should be an Intent to Ship instead of an Intent to Implement. I agree it's not an Intent to Experiment since you're not doing an origin trial.

Jeffrey

[Yoav Weiss]

Indeed

 

Jeffrey

--
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/CANh-dXnnBQB2yej2DFa%2Bm89sVV7hC1-CBiU%3DA0Avsq%2BFZLVoJw%40mail.gmail.com.

[David Van Cleve]

We were originally planning on a small percent stable experiment in M79 and, pending success, rolling out fully to stable in late M79 (via a flag flip) after the holiday freeze ends. But it seems like it makes more sense to push the latter stage (full rollout) until M80. We'll follow up with an intent to ship before then.

On Wednesday, October 23, 2019 at 4:34:27 PM UTC-4, Yoav Weiss wrote:

On Tue, Oct 22, 2019 at 7:11 PM Jeffrey Yasskin <jyas...@chromium.org> wrote:

On Wed, Oct 16, 2019 at 3:11 PM 'David Van Cleve' via blink-dev <blin...@chromium.org> wrote:
>
> Eric:
> - I'm still new to the rollout process, but my understanding was that an I2I was the best fit since we're making a change that'll affect the default behavior of a web API.
> - We're planning on rolling out to stable sometime in M79.

Not commenting on the change itself, but if you're planning to ship in M79 (i.e. now), it seems like this should be an Intent to Ship instead of an Intent to Implement. I agree it's not an Intent to Experiment since you're not doing an origin trial.

Indeed

 

Jeffrey

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

[bay...@gmail.com]

Hi, David!

In looking at Google's current Finch configuration, it appears that y'all are currently experimenting with two different policies; this I2I appears to describe the former:

       // Reduce the amount of information in the default 'referer' header for

// cross-origin requests.

const base::Feature kReducedReferrerGranularity{

    "ReducedReferrerGranularity", base::FEATURE_DISABLED_BY_DEFAULT};

 

// When kCapReferrerToOriginOnCrossOrigin is enabled, HTTP referrers on cross-

// origin requests are restricted to contain at most the source origin.

const base::Feature kCapReferrerToOriginOnCrossOrigin{

    "CapReferrerToOriginOnCrossOrigin", base::FEATURE_DISABLED_BY_DEFAULT};

I was particularly surprised to see the recent introduction of the CapReferrerToOriginOnCrossOrigin feature, as this seems not to match the I2I. As far as I can tell, it makes origin-when-cross-origin the least-restrictive supported policy, precluding a site from opting out of this change using Referrer Policy of unsafe-url.

Can you help me understand the plans for this latter feature? Is it a deprecated experiment that will be removed, or is this something that will be on track to ship at some point?

On Thursday, October 24, 2019 at 7:32:29 AM UTC-7, David Van Cleve wrote:

We were originally planning on a small percent stable experiment in M79 and, pending success, rolling out fully to stable in late M79 (via a flag flip) after the holiday freeze ends. But it seems like it makes more sense to push the latter stage (full rollout) until M80. We'll follow up with an intent to ship before then.

On Wednesday, October 23, 2019 at 4:34:27 PM UTC-4, Yoav Weiss wrote:

On Tue, Oct 22, 2019 at 7:11 PM Jeffrey Yasskin <jyas...@chromium.org> wrote:

On Wed, Oct 16, 2019 at 3:11 PM 'David Van Cleve' via blink-dev <blin...@chromium.org> wrote:
>
> Eric:
> - I'm still new to the rollout process, but my understanding was that an I2I was the best fit since we're making a change that'll affect the default behavior of a web API.
> - We're planning on rolling out to stable sometime in M79.

Not commenting on the change itself, but if you're planning to ship in M79 (i.e. now), it seems like this should be an Intent to Ship instead of an Intent to Implement. I agree it's not an Intent to Experiment since you're not doing an origin trial.

Indeed

 

Jeffrey

--
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 blin...@chromium.org.

[David Van Cleve]

As part of our compat testing for the default policy change covered in the I2I, we've experimented with a couple more stringent referrer truncation behaviors in order to get a sense of their relative user-facing impacts. Those other behaviors aren't within the scope of the current I2I. 

In general, flags for this type of short-term experimentation are ephemeral (maybe "deprecated" is technically correct); if the scope of the functionality we're planning on implementing expands, we'll be sure to send out additional intents encompassing the changes.

David

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/aBtuQUga1Tk/unsubscribe.
To unsubscribe from this group and all its topics, 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/d00ab16e-b194-431e-bfbb-585826642773%40chromium.org.