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
--
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.
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.
--
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.
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.
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.
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
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.
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.
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/1112375Thanks 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?
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.