Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make strict-origin-when-cross-origin the default referrer policy #142

Merged
merged 1 commit into from
Nov 21, 2020

Conversation

krgovind
Copy link

@krgovind krgovind commented Aug 3, 2020

This is a re-do of #125 by @mikewest as I will be taking over the relevant changes to the specs.

PRs against the fetch and html specs are coming.


Preview | Diff

@annevk
Copy link
Member

annevk commented Aug 4, 2020

Are we tracking limiting the ability for sites to opt in to looser policies somewhere?

@krgovind
Copy link
Author

krgovind commented Aug 4, 2020

Are we tracking limiting the ability for sites to opt in to looser policies somewhere?

@annevk There is still some discussion that needs to happen on how to approach that correctly. I am hoping it can happen in PrivacyCG. Relevant thread: privacycg/proposals/issues/13

FYI, this was discussed on the last WebAppSec call, and it was decided that the discussion should happen in PrivacyCG. There is also an open TAG review request at w3ctag/design-reviews/issues/538.

@annevk
Copy link
Member

annevk commented Aug 6, 2020

@domfarolino just read your email on blink-dev. Note that since Safari ships a superset of this, I don't think we need to hold off here.

@annevk annevk requested a review from domfarolino August 6, 2020 07:15
@yoavweiss
Copy link

Safari's behavior seems to be slightly different that's the one described here.

I think it would be good to understand their reasoning, and see if we can converge on a single behavior.

@yoavweiss
Copy link

^^ @johnwilander

@annevk
Copy link
Member

annevk commented Aug 17, 2020

To quote:

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.

That kind of discrepancy does seem problematic and in particular would not be a superset of this PR.

@johnwilander
Copy link

I agree we should converge. Say we (WebKit) would downgrade on navigations and redirects. Would anyone else behave like us or are y’all still in the “just add a header and we’ll send full referrers again” camp? As I mentioned on a recent WebAppSec call, it seems these “change the default but with a new header/attribute you get the old behavior” changes we’re mostly creating busy work for developers. What is the goal?

@annevk
Copy link
Member

annevk commented Aug 18, 2020

If if it's web-compatible I'd be in favor of "strict-origin-when-cross-origin" and aliasing "unsafe-url" and other less strict policies to it.

@krgovind
Copy link
Author

My 2 cents:

  • Defaults matter. I think making the default referrer policy stricter is quite impactful, since a vast majority of developers don't specify a policy. Based on experience with changing the default across multiple browsers - experimentation on Chrome and Edge pre-stable channels, shipping in Firefox Private Browsing - it seems like a vast majority of sites won't need to make any changes to preserve user-visible functionality.
  • Changing the default will help suss out use-cases where a full referrer is required, and allows us to be more deliberate in our approach. Note that there are other ways to pass along the referrer URL, other than simply specifying a permissive policy, such as via URL parameters.

@johnwilander
Copy link

johnwilander commented Aug 18, 2020

My 2 cents:

  • Defaults matter. I think making the default referrer policy stricter is quite impactful, since a vast majority of developers don't specify a policy. Based on experience with changing the default across multiple browsers - experimentation on Chrome and Edge pre-stable channels, shipping in Firefox Private Browsing - it seems like a vast majority of sites won't need to make any changes to preserve user-visible functionality.

I think there's an important distinction between settings under the user's control and settings under the site's control when we talk about "defaults matter." In the case of bad TLS, the default is to block and the user can override to relax. The site can only override to get stricter treatment (HSTS). That's Safari's "default matter" view in the case of referrers – the site can get a stricter policy if it wants but it cannot relax the policy.

Take SameSite=lax cookies by default for instance. The result seems to have been a lot of site owner work and angst and then back to full cross-site tracking because all trackers have set SameSite=none. WebKit keeps getting bugs filed where developers say "I've set SameSite=none and still don't get third-party cookies." They think they did the busy work needed and I don't think they'll be happy when browsers other than Safari+Brave+Tor come around to blocking all third-party cookies, presumably just two years after the SameSite=lax change.

  • Changing the default will help suss out use-cases where a full referrer is required, and allows us to be more deliberate in our approach. Note that there are other ways to pass along the referrer URL, other than simply specifying a permissive policy, such as via URL parameters.

I think we've received 2-3 bug reports in total about downgrading referrers and they were all fixed by the site owners IIRC. Mozilla who did the original research saw very little breakage too. Maybe it would be better to treat those few cases as quirks, since they might not be able/willing to deploy an explicit referrer policy?

@krgovind
Copy link
Author

krgovind commented Aug 18, 2020

I think there's an important distinction between settings under the user's control and settings under the site's control when we talk about "defaults matter." In the case of bad TLS, the default is to block and the user can override to relax. The site can only override to get stricter treatment (HSTS). That's Safari's "default matter" view in the case of referrers – the site can get a stricter policy if it wants but it cannot relax the policy.

Sorry, I'm not sure if I made it clear in my earlier response: Chrome is interested in considering capping the referrer as a long-term measure, but I'm asking that we think about the implications to known use-cases and how we expect developers to respond. Some usecases needing the full referrer URL such as contextual advertising and brand-safety in advertising were discussed on the 7/21 WebAppSec call.

The presumable response to referrer capping is for developers working w/ these use cases to pass on the referrer as a URL parameter to the ad request, which defeats the purpose of capping. I don't think referrer capping by itself is a comprehensive measure.

Take SameSite=lax cookies by default for instance. The result seems to have been a lot of site owner work and angst and then back to full cross-site tracking because all trackers have set SameSite=none. WebKit keeps getting bugs filed where developers say "I've set SameSite=none and still don't get third-party cookies." They think they did the busy work needed and I don't think they'll be happy when browsers other than Safari+Brave+Tor come around to blocking all third-party cookies, presumably just two years after the SameSite=lax change.

SameSite-by-default has well-documented and well-understood CSRF benefits, that 3p cookie blocking doesn't provide by itself. So there absolutely is value to that feature even in a future where all browsers turn on 3p cookie blocking.

What you describe around developer confusion regarding SameSite and filing of WebKit bugs is I think due to an unfortunate coincidence of timing between the Chrome SameSite rollout and Safari ITP blocking 3p cookies by default.

I think blocking third-party cookies outright may actually be a counter-example here and is a cautionary tale to approach referrer capping more thoughtfully. In the absence of good solutions for their use-cases, developers have recommended that users disable ITP entirely, or use a different browser.

I think we've received 2-3 bug reports in total about downgrading referrers and they were all fixed by the site owners IIRC. Mozilla who did the original research saw very little breakage too. Maybe it would be better to treat those few cases as quirks, since they might not be able/willing to deploy an explicit referrer policy?

Could you clarify whether in those cases, the fix was for the site to make do with the origin? Were there any use-cases that required the full URL? We know of at least one case with a payment vendor where the referrer was being used as a fraud protection measure, but we have advised them to use the origin (from the downgraded referrer) instead.

We are also conducting developer outreach to discourage them from relying on the full referrer in cross-origin cases, via articles and online events.

Copy link
Member

@domfarolino domfarolino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes here look good but I think we'll need a PR to fetch to change https://fetch.spec.whatwg.org/#ref-for-concept-request-referrer-policy%E2%91%A3, do you agree? Also we should do a pass over the HTML Standard to see if there is any mention of historical defaults etc

I like that we consolidate the "default" in a single place, instead of having multiple specs reference what they believe is the default policy.

@domfarolino
Copy link
Member

Chrome is currently working on the WPT changes for this, so I'll hold-off on merging at least until then. I think it's OK to land this in general since from my understanding, the change adheres to the changes Firefox + Chrome aims to make. It also brings the spec closer to the non-standard behavior that Safari shipped, so discussion aimed at getting even more conformance between those impls and the spec can happen asynchronously.

Tracking bugs below:

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 9, 2020
We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 10, 2020
We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 10, 2020
We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 10, 2020
We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 10, 2020
We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 10, 2020
We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 13, 2020
We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 17, 2020
We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2429247
Reviewed-by: Charlie Reis <[email protected]>
Reviewed-by: Dominic Farolino <[email protected]>
Reviewed-by: Kunihiko Sakamoto <[email protected]>
Reviewed-by: Arthur Sonzogni <[email protected]>
Reviewed-by: Jeremy Roman <[email protected]>
Commit-Queue: David Van Cleve <[email protected]>
Cr-Commit-Position: refs/heads/master@{#828098}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 17, 2020
We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2429247
Reviewed-by: Charlie Reis <[email protected]>
Reviewed-by: Dominic Farolino <[email protected]>
Reviewed-by: Kunihiko Sakamoto <[email protected]>
Reviewed-by: Arthur Sonzogni <[email protected]>
Reviewed-by: Jeremy Roman <[email protected]>
Commit-Queue: David Van Cleve <[email protected]>
Cr-Commit-Position: refs/heads/master@{#828098}
pull bot pushed a commit to Yannic/chromium that referenced this pull request Nov 17, 2020
We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2429247
Reviewed-by: Charlie Reis <[email protected]>
Reviewed-by: Dominic Farolino <[email protected]>
Reviewed-by: Kunihiko Sakamoto <[email protected]>
Reviewed-by: Arthur Sonzogni <[email protected]>
Reviewed-by: Jeremy Roman <[email protected]>
Commit-Queue: David Van Cleve <[email protected]>
Cr-Commit-Position: refs/heads/master@{#828098}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Nov 20, 2020
…ty to enabled by default, a=testonly

Automatic update from web-platform-tests
Referrers: Flip ReducedReferrerGranularity to enabled by default

We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2429247
Reviewed-by: Charlie Reis <[email protected]>
Reviewed-by: Dominic Farolino <[email protected]>
Reviewed-by: Kunihiko Sakamoto <[email protected]>
Reviewed-by: Arthur Sonzogni <[email protected]>
Reviewed-by: Jeremy Roman <[email protected]>
Commit-Queue: David Van Cleve <[email protected]>
Cr-Commit-Position: refs/heads/master@{#828098}

--

wpt-commits: 60d6623086e10806ed0293c61cfc21ad0a0a527b
wpt-pr: 26441
@krgovind
Copy link
Author

@domfarolino Can we merge this PR now that the WPTs have landed?

@domfarolino
Copy link
Member

I think so, yes. Let me see if I can get an approval out of @annevk first if that's OK, just for extra assurance.

@domfarolino
Copy link
Member

Over IRC he's indicated he's alright landing this, so I'll go ahead and merge. Thanks for all of the work and discussion here everyone!

@domfarolino domfarolino merged commit d0582f3 into w3c:master Nov 21, 2020
aosmond pushed a commit to aosmond/gecko that referenced this pull request Nov 22, 2020
…ty to enabled by default, a=testonly

Automatic update from web-platform-tests
Referrers: Flip ReducedReferrerGranularity to enabled by default

We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2429247
Reviewed-by: Charlie Reis <[email protected]>
Reviewed-by: Dominic Farolino <[email protected]>
Reviewed-by: Kunihiko Sakamoto <[email protected]>
Reviewed-by: Arthur Sonzogni <[email protected]>
Reviewed-by: Jeremy Roman <[email protected]>
Commit-Queue: David Van Cleve <[email protected]>
Cr-Commit-Position: refs/heads/master@{#828098}

--

wpt-commits: 60d6623086e10806ed0293c61cfc21ad0a0a527b
wpt-pr: 26441
annevk pushed a commit to whatwg/fetch that referenced this pull request Nov 30, 2020
w3c/webappsec-referrer-policy#142 links tests and has the corresponding Referrer Policy change. whatwg/html#5783 has the corresponding change to HTML.
domenic pushed a commit to whatwg/html that referenced this pull request Dec 14, 2020
Follows w3c/webappsec-referrer-policy#142, which
introduces a spec-level "default referrer policy" HTML can point to.

This is a normative change since the new default referrer policy defined
in the Referrer Policy spec is "strict-origin-when-cross-origin",
instead of the previous "no-referrer-when-downgrade" set in HTML.
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this pull request Oct 14, 2022
We rolled out ReducedReferrerGranularity, which changes the default
referrer policy to strict-origin-when-cross-origin, to 100% in M85
stable. To clean up the experiment, we need to enable the behavior by
default. This will take effect in M88; we'll follow up by removing the
flag, the corresponding enterprise policy, and the corresponding field
trial testing configuration.

Changing this base::Feature's default value entails cleaning up the
remaining tests that weren't within the field trial testing config's
scope. These changes are mostly straightforward, involving updating
expectations of full-URL referrers to expectations of the corresponding
origins, but some tests require logic changes to make sure that they
still cover the desired behavior. (For instance, multiple tests
previously expected origins in order to test that a particular,
arbitrary, non-default referrer policy took effect: to achieve a similar
effect, this CL updates these tests to now expect full URLs and swaps
in non-default full-URL-generating policies for the prior non-default
origin-generating policies.)

Launch approval: crbug.com/1019930
Spec change: w3c/webappsec-referrer-policy#142

Bug: 1014207, 1131688
Change-Id: Ib575af6a858641fb1fe2c8de73941f5702d88191
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2429247
Reviewed-by: Charlie Reis <[email protected]>
Reviewed-by: Dominic Farolino <[email protected]>
Reviewed-by: Kunihiko Sakamoto <[email protected]>
Reviewed-by: Arthur Sonzogni <[email protected]>
Reviewed-by: Jeremy Roman <[email protected]>
Commit-Queue: David Van Cleve <[email protected]>
Cr-Commit-Position: refs/heads/master@{#828098}
GitOrigin-RevId: 226b67fc9bb0aee954b8f35eb4e485b310c24713
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants