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

[David Van Cleve]

Contact emails

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

Spec

https://github.com/w3c/webappsec-referrer-policy/pull/125

TAG review requested: https://github.com/w3ctag/design-reviews/issues/538

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. On cross-origin requests made from documents without a specified referrer policy, this reduces the Referer header to the initiating origin.

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 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 of setting a referrer policy to limit the amount of information that is sent, this requires an explicit opt-in effort, leading to low adoption.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/aBtuQUga1Tk/n4BLwof4DgAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes!

Demo link 

https://site-one-dot-referrer-demo-280711.ey.r.appspot.com/stuff/detail?tag=red&p=p0 

Debuggability

You can use DevTools to look at outgoing requests’ Referer (sic) headers and referrer policies, and at documents’ document.referrer JS attributes.

Interoperability and Compatibility Risks

This change improves interoperability: it brings our behavior in line with proposed changes to the spec, and other engines (e.g. Gecko) have signalled they’re willing to make the same change once we do. 

There are some compatibility risks: we’re affecting the output of a widely-used JS API (and HTTP header), which could cause subtle server-side issues. We’re mitigating this by conducting outreach to improve developer awareness, and we’ve done limited trials of the change in pre-Stable Chrome channels without seeing significant user impact. We’ve also added a Chrome enterprise policy to enable a lengthier transition to the new behavior in environments where this is necessary.

Signals from other implementations (Gecko, WebKit): Helpfully aggregated by englehardt@ at https://github.com/privacycg/proposals/issues/13. Gecko has rolled this change out in private browsing and for requests to tracking domains would “like” to enable it everywhere. WebKit has rolled out a mostly equivalent change that caps cross-site referrers to their initiating origins regardless of the operative referrer policy; this change will make Blink’s behavior consistent with WebKit’s in more places.

Ergonomics

Since this is a default behavior change, it can be challenging to understand which behavior is active when the change is partially rolled out. This will not be an issue once we finish rolling out to 100%.

Activation

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

• Yes: we’re conducting outreach because this might affect server-side behavior in subtle ways.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

WPTs have pretty exhaustive coverage for the referrer policy spec already. We’ll eventually upgrade the “policy unset” tests to use strict-origin-when-cross-origin to form their expectations rather than (as now) no-referrer-when-downgrade. The wpt.fyi dashboard for the entire referrer-policy suite lives here, but the results are currently broken due to an infra failure.

Entry on the feature dashboard

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

[David Van Cleve]

Correction: the wpt.fyi referrer policy test suite is (happily) no longer broken!

[Mike West]

I'm abstaining from this intent, but without my owner's hat on, it seems to be both clearly a good idea and low-risk. LGTM0! :)

-mike

--
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/ff4a04ae-77f9-4e1b-ad24-13b183e90ecdn%40chromium.org.

[Yoav Weiss]

LGTM1

Seems like this aligns behavior with what Safari is doing, so that's reassuring. Happy to see y'all are also conducting outreach and keeping a close tab on related bug reports.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DfxyY8X-5H0EMvMv-zbOwQi%3DMN8c%3DrDj0MTkwpP8U7w9Q%40mail.gmail.com.

[Domenic Denicola]

> https://github.com/w3c/webappsec-referrer-policy/pull/125

Would it be possible to work on getting this merged, or at least rebased, if indeed multiple browsers are in favor? Additionally https://github.com/whatwg/fetch/pull/952, and the corresponding HTML spec change (which I don't see anywhere).

We've had a few intents recently get approved while the corresponding spec PRs languished, despite multi-implementer interest. For this one especially, which touches three specs, it'd be good to avoid that.

From: blin...@chromium.org <blin...@chromium.org> On Behalf Of Yoav Weiss

> Seems like this aligns behavior with what Safari is doing, so that's reassuring. Happy to see y'all are also conducting outreach and keeping a close tab on related bug reports.

That's not quite correct. From https://github.com/w3c/webappsec-referrer-policy/pull/125#issuecomment-619460219:

> Safari’s change is not a change of default policy. Sites can’t change it, only users can. Third-party referrers are downgraded to origin by default regardless of the referrer policy set by the website.

In practice this change means the values will be the same more often, but Safari's behavior seems more like making unsafe-url into an alias for origin-when-cross-origin, or something like that.

[Yoav Weiss]

Interesting! I think that in practice, that doesn't change the risk profile here - sites that may break with this change are already broken in Safari (so the risk for breakage seems low) 

[Dominic Farolino]

Please let me know when:

• https://github.com/w3c/webappsec-referrer-policy/pull/125 is rebased and ready for review
• https://github.com/whatwg/fetch/pull/952 is ready for review
  
• The HTML Standard PR is uploaded (I believe domenic@ mentioned this first here)

... and I'm happy to review these.

In the referrer policy spec PR, annevk has asked if we could hold off on landing the spec until one browser has successfully shipped this. In that case I'm fine holding off on actually pressing the merge button until after this has been approved / shipped, but I'd like to get all the PRs in a healthy ready-to-go state, such that the only thing blocking their merge is this.

--

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/CACj%3DBEgmLyXmF7j1hhvg66dqhjYSBrRrzWrhOx8gDOfCkcRndA%40mail.gmail.com.

[Daniel Bratell]

I'd mostly be worried about compatibility. A long time ago, in the Web's stone age, using the referrer for access control was a bad, but not uncommon, practice. That Brave claims no known sitecompat problems from using this as the default is somewhat reassuring.

/Daniel

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

[Jochen Eisinger]

I would hope that cross site referrer isn't used as access control but mostly for attribution where the origin should be enough. Wasn't the ACL pattern something like that you didn't want deep links to your image assets or something?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/294212c3-becb-8fa4-b3b2-e5d12b7c9c20%40gmail.com.

[Daniel Bratell]

Hopefully that is so, and that would explain why the sitecompat seems to be ok. I do remember one case (N=1) of a site where resources from images.example.com only loaded if you had a referrer at example.com, but we're talking loooong ago.

As this is something that can't (easily) be measured by the client, I guess that the beta channel will have to be used to catch any unforeseen objects.

/Daniel

[Dominic Farolino]

On Wed, Jul 29, 2020 at 3:50 PM Daniel Bratell <brat...@gmail.com> wrote:

Hopefully that is so, and that would explain why the sitecompat seems to be ok. I do remember one case (N=1) of a site where resources from images.example.com only loaded if you had a referrer at example.com, but we're talking loooong ago.

As this is something that can't (easily) be measured by the client, I guess that the beta channel will have to be used to catch any unforeseen objects.

I believe we have this already partially rolled out on stable currently, which if true is promising, but I could be wrong. David should have more info.

[David Van Cleve]

We've done some fairly long-running experiments on the beta channel without observing anything catastrophic. 

[Kaustubha Govind]

Dominic: FYI, I will be taking over the spec update work from Mike West, and have opened fresh PRs against the webappsec-referrer-policy, fetch, and html specs:

• https://github.com/w3c/webappsec-referrer-policy/pull/142
  
• https://github.com/whatwg/fetch/pull/1066
  
• https://github.com/whatwg/html/pull/5783
  

Update on the sitecompat front: We have now received breakage reports for two sites, and tracking them as blocking crbug.com/1112375

Also, a clarification regarding Safari's current behavior: It appears that the policy "Third-party referrers are downgraded to origin..." is only applied to subresource requests and in the DOM; but not to the `Referer` request header on navigations and redirects.

[Yoav Weiss]

At the API owner meeting yesterday, there was consensus that this can benefit from thorough TAG review, as it represents a fundamental change to the platform.

+Alice Boxhall - would it be possible to try and prioritize this review?

On Wed, Aug 5, 2020 at 12:57 AM Kaustubha Govind <kaust...@chromium.org> wrote:

Dominic: FYI, I will be taking over the spec update work from Mike West, and have opened fresh PRs against the webappsec-referrer-policy, fetch, and html specs:

• https://github.com/w3c/webappsec-referrer-policy/pull/142
  
• https://github.com/whatwg/fetch/pull/1066
  
• https://github.com/whatwg/html/pull/5783
  

Update on the sitecompat front: We have now received breakage reports for two sites, and tracking them as blocking crbug.com/1112375

Thanks for treating those issues as blocking! At least one of them seems like it is related to a 3P payment provider, which may impact more sites...

 

Also, a clarification regarding Safari's current behavior: It appears that the policy "Third-party referrers are downgraded to origin..." is only applied to subresource requests and in the DOM; but not to the `Referer` request header on navigations and redirects.

Did you verify that the difference from what Safari is doing is the source of breakage?

Do you know the reasons for Safari's behavior? Have we discussed it with them? Would it make sense to align on their behavior?

[Kaustubha Govind]

On Fri, Aug 7, 2020 at 8:23 AM Yoav Weiss <yo...@yoav.ws> wrote:

At the API owner meeting yesterday, there was consensus that this can benefit from thorough TAG review, as it represents a fundamental change to the platform.

+Alice Boxhall - would it be possible to try and prioritize this review?

On Wed, Aug 5, 2020 at 12:57 AM Kaustubha Govind <kaust...@chromium.org> wrote:

Dominic: FYI, I will be taking over the spec update work from Mike West, and have opened fresh PRs against the webappsec-referrer-policy, fetch, and html specs:

• https://github.com/w3c/webappsec-referrer-policy/pull/142
  
• https://github.com/whatwg/fetch/pull/1066
  
• https://github.com/whatwg/html/pull/5783
  

Update on the sitecompat front: We have now received breakage reports for two sites, and tracking them as blocking crbug.com/1112375

Thanks for treating those issues as blocking! At least one of them seems like it is related to a 3P payment provider, which may impact more sites...

 

We are in touch with Ingenico (the payment provider in question), and are advising them on a fix. We are also attempting to reach Omaze.

 

Also, a clarification regarding Safari's current behavior: It appears that the policy "Third-party referrers are downgraded to origin..." is only applied to subresource requests and in the DOM; but not to the `Referer` request header on navigations and redirects.

Did you verify that the difference from what Safari is doing is the source of breakage?

Yes, we verified that both known issues are not reproducible on Safari. The issue is that these sites appear to be looking for the full `Referer` on navigations/redirects; which are not impacted on Safari.

 

Do you know the reasons for Safari's behavior? Have we discussed it with them? Would it make sense to align on their behavior?

I'll wait to hear what the Safari folks have to say about their behavior on https://github.com/w3c/webappsec-referrer-policy/pull/142#issuecomment-670491156. It appears that the Safari behavior may be more aligned with ITP, but doesn't serve the primary motivation for the change we are proposing in Chrome.

Note that Firefox already ships the same behavior that we are proposing in Private Browsing windows on desktop, and expressed a desire to ship the same in all windows (https://github.com/privacycg/proposals/issues/13).

[Yoav Weiss]

It seems like there's no way to estimate breakage without going ahead with a careful roll-out, and rolling back if breakage is found to be excessive.

My LGTM stands under these conditions. 

[Chris Harrelson]

LGTM2

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

[Alex Russell]

LGTM3

[Juan Martin Enríquez]

Hello! I have a "best-practices" type of question. Don't know if it is appropiate here.

We have a SaaS solution that allows customers to implement widgets in their site. In doing so we set a javascript code that when the user reaches a certain URL it checks if it has to display the widgets we provide. For that to happen we need the current URL of the visitor. We where relying on referer header with the previously default policy. Now that this will change, you I adapt my JS Fetch function in order to enforce "no-referrer-when-downgrade" policy just for this request or should I change the way my code works in order to send the visitor's current URL in another way?

Thanks!

[Maud Nalpas]

Hi Juan!

We've just updated our guidance to outline a few ideas / alternatives.

In your case, using no-referrer-when-downgrade on your fetch request is OK. With this, your client site can continue using the privacy-preserving policy strict-origin-when-cross-origin for most resources/requests, and shares the Referer only when needed (in your requests).

One thing: make sure that the Referer isn't containing personal/sensitive/private data from your client site's users.

Does this help?