search

privacycg / proposals

New proposals in the Privacy Community Group
https://privacycg.github.io
122 stars 5 forks source link

Referrer trimming #13

Open englehardt opened 4 years ago

englehardt commented 4 years ago

Referrers leak information about a user's browsing activity cross-site. Browser vendors have deployed a variety of mitigations to this vulnerability, ranging from spoofing the referrer to be same-origin to changing the default referrer policy.

Current status (please correct or add to this):

Last update: 2021-04-12

Firefox

Chrome

Referrers default to strict-origin-when-cross-origin.

Safari

Brave

From this doc: Referrer values default to strict-origin-when-cross-origin and can only be tightened via referrer policy, not weakened.

Edge

Referrers default to strict-origin-when-cross-origin.

Future path

At the very least it seems like we can align on defaulting to strict-origin-when-cross-origin (see also: https://github.com/w3c/webappsec-referrer-policy/pull/125). But even this default can still be overwritten by motivated adversaries. This leads to the question of why only change the default, and not permanently trim cross-site referrers with no way to override?

johnwilander commented 4 years ago

Safari

  • All cross-site referrers are trimmed to the page's origin. I assume this matches the strict-origin-when-cross-origin, but Apple's blog post is not specific. From what I can tell, sites can not override this setting.

This is correct. However, ITP also detects if link decoration tracking is potentially happening and in that case downgrades document.referrer to eTLD+1.

englehardt commented 4 years ago

Safari

  • All cross-site referrers are trimmed to the page's origin. I assume this matches the strict-origin-when-cross-origin, but Apple's blog post is not specific. From what I can tell, sites can not override this setting.

This is correct. However, ITP also detects if link decoration tracking is potentially happening and in that case downgrades document.referrer to eTLD+1.

Thanks! I've updated the original post with a link to https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/.

krgovind commented 4 years ago

Chrome

  • Has experimented with setting the default referrer policy to strict-origin-when-cross-origin. Not sure of the current status here.

Correct, we have experimented with strict-origin-when-cross-origin as the default referrer policy on canary, dev, and beta channels. We did not receive reports of breakage during the experiment period. However, we have currently paused plans to gradually roll out to the stable channel due to the ongoing global pandemic. This is because there is still the possibility that this will break some sites. We are tentatively planning a roll-out in M84, and will keep our status page updated.

  • Do we expect to see a lot of breakage?
  • Are there legitimate uses of full cross-site referrers that we want to continue to support?
  • Can we somehow prevent abuse but still allow some parties to receive full referrer?

We are also interested in the answers to these questions.

erik-anderson commented 4 years ago

The Edge team has been experimenting with defaulting to strict-origin-when-cross-origin in our Dev and Canary channels. We haven't seen a large amount of breakage, but we have found some.

Examples:

  1. A payment processing service which reviews the referrer info to decide if it wants to allow a transaction. It is apparently using the path component as well in its current check. The Edge team has notified the payment processor to ask them to fix it ahead of a broader rollout.
  2. A Microsoft-owned iframe-embeddable video player that does some configuration of the response based on the referrer info. When it doesn't see a path component, it falls back to an invalid base URL. We've engaged with the site owner to ask them to address it.
  3. A site that uses links from a github repo markdown file to a different domain that they own which then turns around and load resources from a https://raw.githubusercontent.com/ URL which has a path component based on the referrer info from the github page.

These issues are often subtle and, in many cases, the site can be changed to adjust to the fact that it's not seeing the same info in the referrer. Of the list above, the first two are legitimate uses of referrer but potentially don't need the same level of detail. For the third, given the developer presumably won't be able to change github's referrer policy, it may be more challenging for them to develop a workaround independently.

pes10k commented 4 years ago

FWIW here, Brave is now shipping a modified referrer policy, similar to the above. The flow-chart is in our wiki, but basically (simplified):

  1. never send referrer on cross origin GET navigations
  2. otherwise, default to strict-origin-when-cross-origin. Treat strict-origin-when-cross-origin as a floor. We respect site requests for more ~permissive~ restrictive policies, but modify more permissive policies to strict-origin-when-cross-origin.

If the brave desc in the issue text could be updated, that'd be appreciated :)

annevk commented 4 years ago

cc @domfarolino

krgovind commented 3 years ago
  1. otherwise, default to strict-origin-when-cross-origin. Treat strict-origin-when-cross-origin as a floor. We respect site requests for more permissive policies, but modify more permissive policies to strict-origin-when-cross-origin.

@pes10k - Did you mean to say "We respect site requests for more restrictive policies"?

pes10k commented 3 years ago

@krgovind ah yes, of course, fixed . Thank you for catching that :)

atjn commented 3 years ago

Safari

  • All cross-site referrers are trimmed to the page's origin. I assume this matches the strict-origin-when-cross-origin, but Apple's blog post is not specific. From what I can tell, sites can not override this setting.

This is correct. However, ITP also detects if link decoration tracking is potentially happening and in that case downgrades document.referrer to eTLD+1.

@johnwilander but Safari does not trim the referrer header when navigating to an external site. I don't think this description makes that clear. The blog post is not super explicit either, and had me confused for quite a while.

krgovind commented 3 years ago

Safari

  • All cross-site referrers are trimmed to the page's origin. I assume this matches the strict-origin-when-cross-origin, but Apple's blog post is not specific. From what I can tell, sites can not override this setting.

This is correct. However, ITP also detects if link decoration tracking is potentially happening and in that case downgrades document.referrer to eTLD+1.

@johnwilander but Safari does not trim the referrer header when navigating to an external site. I don't think this description makes that clear. The blog post is not super explicit either, and had me confused for quite a while.

@johnwilander - Could you clarify what referrers are trimmed by Safari? In addition to the navigations mentioned by the previous post, we found some inconsistencies with subresources.

@maudnals found the following by testing with Safari on desktop and iOS, with ITP enabled:

renebaudisch commented 3 years ago

Hi everybody. I was wondering how this will affect HTML5 creatives as they use link decoration for transporting clickurl and maybe clicktarget as defined in an official IAB doc under point 3.10.

krgovind commented 3 years ago

Hi everybody. I was wondering how this will affect HTML5 creatives as they use link decoration for transporting clickurl and maybe clicktarget as defined in an official IAB doc under point 3.10.

@renebaudisch Thanks for asking! For those of us not familiar with the document, could you explain what clickurl and clicktarget are? Is clickurl the content page that the ad is embedded on, and clicktarget the advertiser/destination page that the user goes to when they click on the ad?

I'm guessing clickurl is more relevant to this discussion, since it is equivalent to the Referer header that is sent to the embedded ad?

Could you help us understand the use-cases that need the full page URL?

renebaudisch commented 3 years ago

@krgovind sure I will, but it seems I also have to clarify the ecosystem of HTML5 ad distribution.

To deliver ads on publisher websites an adserver is used. Besides GoogleAdManager aka DFP there are some more like Xandr, SmartAdServer and others. These adservers are used to deliver ads and when render them also count them in their system to be able to bill the advertiser.

Counting deliveries therefore is easy, but adservers also count clicks. An HTML5 creative is computed at some creative agency and shall be used by the advertiser to provide it to different publisher/marketers and theirfore surely to different adserver that all uses different counting urls.

Because of this there is a need to an option to pass the delivering adservers counting url to the creative. The creative itself then can read that information and use it. The information is meant to be used in an a-tag or window.open, where clicktag is the href and target the a-tags target like "_blank".

As we use Xandr I can provide you an example url of a hosted creative that uses that feature.

https://vcdn.adnxs.com/p/creative-html/b0/68/91/99/b0689199-f8cc-4cc0-93c9-32ed670ba7bb/index.html?clicktag=https%3A%2F%2Fams1-ib.adnxs.com%2Fclick%3FUTHO30RbjUBRMc7fRFuNQAAAAAAAAOA_UTHO30RbjUBRMc7fRFuNQI1cIjU0qdsJ_ozZZWnK0A0h2HZfAAAAAKd0sACPHgAAjx4AAAIAAACR_QoHPhQUAAAAAABVU0QARVVSAOgD6ANKpgAAAAABAQMCAAAAALMAtyPPMAAAAAA.%2Fbcr%3DAAAAAAAA8D8%3D%2Fcnd%3D%2521VhJKtgiEyO4TEJH7qzgYvqhQIAQoADEAAAAAAACJQDoJQU1TMTo0MzIyQO4lSVXBqKROQOs_UQAAAAAAAAAAWQAAAAAAAAAAYQAAAAAAAAAAaQAAAAAAAAAAcQAAAAAAAAAAeAA.%2Fcca%3DNzgyMyNBTVMxOjQzMjI%3D%2Fbn%3D83983%2Ftest%3D1%2Fclickenc%3Dhttps%3A%2F%2Fwww.partnerdesfussballs.de&target=_blank&frameId=sky_rlSlot_frame1

When the user clicks that ad, the ad will take the clicktag from the decoration and invoke it. It will open a Xandr page for counting and then redirect to the value after the encoded clickenc param.

Sure this can be changed and adopted to be done by postMessage, but since the IAB standard is not designed to use postMessage I'm afraid that this change will break the click counting for all HTML5 creatives designed that way including those we host.

krgovind commented 3 years ago

@renebaudisch Thanks for the details! It sounds like your use-case is to measure click conversions. There a couple of ideas being discussed to perform such measurement in a privacy-preserving way on the web. I would recommend that you review those proposals and provide feedback:

Ideally, you would use such an API, instead of using link decoration.

renebaudisch commented 3 years ago

Yes to the use-case and yes, ideally, you would use such an API, instead of using link decoration, I agree, but the ecosystem isn't setup like this right now and if you release "Referer trimming" now you would break the ecosystem out there, right?

So "referer triming" seems to has to depend on a living standard of these measurement proposals and shouldn't be released standalone to not break the industries actual standard?

krgovind commented 3 years ago

The term "referrer trimming" for the purpose of this thread is narrowly scoped to the use of the HTTP Referer header and the document.referrer JS API. Releasing the changes being discussed here won't break the ecosystem usage of link decoration.

Having said that, the privacy principles we use here should generally apply to "navigational tracking", which does include link decoration.

johnwilander commented 3 years ago

@johnwilander - Could you clarify what referrers are trimmed by Safari? In addition to the navigations mentioned by the previous post, we found some inconsistencies with subresources.

I did see a bug filed. I don't know if it was from you/your team. The intention is to 1) trim all cross-site subresource HTTP referrers to the origin, and 2) trim cross-site document.referrer to the origin. There is also the special case of trimming cross-site document.referrer to the registrable domain when the page was navigated to with potential link decoration.

krgovind commented 3 years ago

I did see a bug filed. I don't know if it was from you/your team.

I don't think the bug you mentioned was my team, but we created one today to capture the issue with element-level referrerpolicy specifications not being consistently honored.

The intention is to 1) trim all cross-site subresource HTTP referrers to the origin, and 2) trim cross-site document.referrer to the origin.

Re: 1) we see that <iframe> referrers are capped, but not on all kinds of sub-resources (e.g. cross-site referrers to <img> elements are not capped). So I was asking if that was intentional or not.

maudnals commented 3 years ago

For reference: we've updated the bug in question with a few more observations regarding Safari 14. -- maud, from @krgovind's team, Chromium

pes10k commented 3 years ago

Just to update, Brave's policy has changed to:

englehardt commented 3 years ago

FYI I've updated the original comment to reflect the current status of all of the browsers listed. Pretty much everyone has aligned on setting strict-origin-when-cross-origin as the default, with Brave and Safari restricting the ability of sites to override that setting to something more permissive. If you see any issues please tag me and I'll update.

fmarier commented 3 years ago

Some of the breakage that Brave has seen, while using a stricter policy, can be seen in the list of exceptions we used to carry.

johannhof commented 2 years ago

FYI, Firefox is currently testing the same restrictions that Safari applies (cross-site referrers are origin at most) in Nightly, with plans to release to all users eventually, unless we see massive breakage in pre-release.

https://groups.google.com/a/mozilla.org/g/dev-platform/c/yGbc5I4wd6U

Given that two implementers are now (close to) shipping this restriction there may be value in standardizing it.

johannhof commented 2 years ago

Update: Firefox shipped this restriction in Strict and Private Mode, with plans to go to default within the next few releases. No breakage observed so far.

krgovind commented 2 years ago

Thanks for the update on your progress, @johannhof.

One case to test out may be Heroku/Cloud Run buttons on GitHub (breakage report from when Chrome rolled out strict-origin-when-cross-origin as the default referrer policy last year). GitHub fixed this by specifying no-referrer-when-downgrade as the referrer-policy on README files.

Also, we found that the full referrer URL was being used by some sites such as third-party payments providers to run security checks (we blogged about this here). Our recommendation was to rely on the origin portion of the referrer; but I believe some folks may instead have passed the referrer as a URL parameter to minimize churn to their existing systems.

I think capping referrers even where the originating site opted-in to sending the destination site the full referrer by specifying a referrer-policy of no-referrer-when-downgrade may result in websites moving towards passing the referrer information via URL parameters. I was curious whether y'all have any thoughts on that potential outcome?

johannhof commented 2 years ago

Hi @krgovind, thank you for pointing me to that breakage, I wasn't aware of it. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1734328 for tracking that.

Also, we found that the full referrer URL was being used by some sites such as third-party payments providers to run security checks (we blogged about this here). Our recommendation was to rely on the origin portion of the referrer; but I believe some folks may instead have passed the referrer as a URL parameter to minimize churn to their existing systems.

That's a really great blog post about the referrer changes! I haven't seen the mentioned payment provider breakage but I can imagine it might still exist somewhere. Your advice of using the origin seems to be a good path forward for these sites, so they hopefully shouldn't find it hard to migrate to that, faced with a larger number of browsers restricting referrers.

I think capping referrers even where the originating site opted-in to sending the destination site the full referrer by specifying a referrer-policy of no-referrer-when-downgrade may result in websites moving towards passing the referrer information via URL parameters. I was curious whether y'all have any thoughts on that potential outcome?

I think you're generally right that referrers are navigational tracking, and should be considered in that work. However, given the low amount of potential breakage from reducing referrers as much as possible (compared to the vast universe of breakage from restricting URLs in any way), it's tempting to just close the referrer vector to a large extent and focus on the URL as the primary source of information for navigational tracking. "Asymptotically" speaking, I don't think we add any complexity to the URL problem when the above mentioned breakage is fixed through URL parameters.

In most cases, we think that encoding information in the URL is more user-friendly as it exposes which data is being shared (to advanced users) and allows for easier sharing of the URL and retaining functionality (of course you again get the problem that sensitive/identifying data could be included in the URL, but we already have that problem for URLs, not cutting referrers wouldn't fix that.).

Eliminating referrers from the discussion to reduce complexity (and easily mitigating a tracking vector) has been our motivating driver, but I'm happy to discuss this approach further. If we can agree that we're comfortable with sites migrating to either relying on origin or the URL for passing this information, would Chrome folks be open to align on this restriction?

johannhof commented 2 years ago

@englehardt do you mind updating your initial summary to reflect that WebKit is only trimming referrer headers in sub-resource requests (see https://github.com/privacycg/proposals/issues/13#issuecomment-707242581). I had not remembered these comments and spent a while trying to figure out why the breakage shown by Kaustubha wasn't happening in Safari (until @annevk thankfully caught it).

@johnwilander do you remember what motivated Safari to avoid trimming referrer headers on top-level navigations?

If there is a larger amount of site breakage to consider I would be up for temporarily adding this carve-out, but I still believe we should just give developers the consistent expectation that strict-origin-when-cross-origin can not be downgraded across sites.

kdzwinel commented 2 years ago

FWIW we have a test page that makes it easy to evaluate referrer trimming: https://privacy-test-pages.glitch.me/privacy-protections/referrer-trimming/ .

Two notes:

maudnals commented 2 years ago

One question for @erik-anderson, What's Edge behaviour as of today? Does Edge now default to strict-origin-when-cross-origin in Stable?

The Edge team has been experimenting with defaulting to strict-origin-when-cross-origin in our Dev and Canary channels. (comment April 2020)

krgovind commented 2 years ago

If we can agree that we're comfortable with sites migrating to either relying on origin or the URL for passing this information, would Chrome folks be open to align on this restriction?

@johannhof - I have a couple of concerns around recommending sites migrate to using URL parameters instead of using referrer-policy:

I'd be happy to reconsider if all of you feel strongly about this; but I'm not convinced about the privacy gains. :)

johnwilander commented 2 years ago

@johnwilander do you remember what motivated Safari to avoid trimming referrer headers on top-level navigations?

We’ve viewed navigational cross-site data and subresource cross-site data as different cases requiring different tracking prevention solutions. Not in the referrer case specifically but in general. We felt that there was a need to reduce the amount of cross-site data leaking to third-parties by mere page loads and also saw very few compatibility bugs because of it.

In many anti tracking cases, Safari is the first or second mover and we have to make sure we give developers a reasonable chance to catch up and don’t hurt compatibility too much. Sometimes we have to wait multiple years before other browsers catch up (see storage, SW, and cache partitioning) which means we risk being seen as buggy. Other browser vendors may even leverage that to try to sway users to switch to their browser or to make developers hate us. It’s always a measured approach with long term goals requiring several releases.

johannhof commented 2 years ago

Thanks both for your feedback on this, these are great points to consider.

Trying to summarize and simplify, it looks like we're all mainly concerned about breakage and developer experience here, and that so far the only concrete source of breakage we can show is from referrer headers in top-level navigations. This suggests to me that:

Regarding privacy gains, I agree that the primary risk currently seems to be around subresources as well as scripts accessing document.referrer. I still think it would be great for privacy-minded browser developers to have the simplicity of an origin-only referrer on all cross-site requests, but the Priority of Constituencies tells me I should let that argument rest. :)

krgovind commented 2 years ago
  • On Mozilla side, we should experiment with aligning with Safari by default (referrers stripped except header for top-lvl nav) to smoke out other unseen breakage. It would obviously be great if Chrome was up for such an experiment as well.

For Chrome, we had only considered referrer trimming on top-level navigations, but not on cross-site subresources; because in the end-state we're targeting, all third-party state should be partitioned. In that end-state, I don't see a cross-site tracking risk presented by information passed on via the referrer to iframes/subresources. (Perhaps this then comes down to the question of the threat model, which I realize may be slightly different across browsers)

Note that sites can easily use alternative mechanisms like postMessage to third-party iframes to achieve the same functionality, instead of via the referrer or URL parameters.

englehardt commented 2 years ago

Thanks both for your feedback on this, these are great points to consider.

Trying to summarize and simplify, it looks like we're all mainly concerned about breakage and developer experience here, and that so far the only concrete source of breakage we can show is from referrer headers in top-level navigations. This suggests to me that:

* On Mozilla side, we should experiment with aligning with Safari by default (referrers stripped except header for top-lvl nav) to smoke out other unseen breakage. It would obviously be great if Chrome was up for such an experiment as well.

* When we're more confident about the (lack of) breakage there are no major blockers to standardizing on the Safari behavior.

Regarding privacy gains, I agree that the primary risk currently seems to be around subresources as well as scripts accessing document.referrer. I still think it would be great for privacy-minded browser developers to have the simplicity of an origin-only referrer on all cross-site requests, but the Priority of Constituencies tells me I should let that argument rest. :)

Getting browsers standardized on the two conditions in which Safari trims to origin seems like a reasonable next step. We can bring HTTP referrers on navigation (and the link decoration modifier for document.referrer) into the navigational tracking protection discussion. (Also, I've update the description as per your suggestion, thanks for catching that).

annevk commented 2 years ago

In reply to @krgovind: not leaking the referrer to cross-site subresources is also a privacy feature. Just because Popular Video Site is the de facto source of hosting a video, shouldn't mean that Popular Video Site gets to see all the sites where it is embedded. Of course, there is nothing preventing Popular Video Site from requiring this and having embedders pass that information along with the URL for the video, but at that point we've turned a passive privacy leak into an active one, which I think is ultimately a win.

krgovind commented 2 years ago

@annevk - I agree with that as a privacy goal. We've already achieved it by changing the default referrer policy for all (subresource and navigational) cross-site requests. In the example you described, the embedder has to now explicitly take action to specify a more permissive referrer policy than strict-origin-when-cross-origin.

annevk commented 2 years ago

It would be interesting to see more research into how overrides of the default policy are in use, but in the examples I've seen people moved directly to unsafe-url just to be able to share a referrer with a same-site resource. And I somewhat doubt they thought through the privacy consequences as they probably just wanted to get their image back up.

krgovind commented 2 years ago

It would be interesting to see more research into how overrides of the default policy are in use, but in the examples I've seen people moved directly to unsafe-url just to be able to share a referrer with a same-site resource. And I somewhat doubt they thought through the privacy consequences as they probably just wanted to get their image back up.

I agree such research may be valuable; but unfortunately it needs more work than my simple HTTPArchive query because of the multitude of ways that referrer policies can be specified (e.g. document-level policies applied via response headers, or <meta> tags are harder to analyze than element-level policies). :)

We do have to consider the fact that developers face the pressing reality of keeping their sites running, often having to deal with different behavior across browsers. We tried to address this with extensive developer guidance in our blogpost, by highlighting the privacy and security risks, cautioning against relying on anything more than the origin, and describing multiple use-cases and preferred solutions. We tested referrer behavior across multiple browsers (and continue to update it) to ensure that our prescribed solutions were interoperable.

What I'm questioning here is whether having them re-do the work of moving from an explicit policy specification (which many had to do fairly recently in response to the default referrer policy change), to writing JavaScript that adds on a new URL parameter - essentially just a syntactic change - is wise; considering that there is no privacy gain to users.

annevk commented 2 years ago

Well, as I tried to illustrate above there definitely will be a privacy gain in various cases. Coupled with Safari having proved it out makes me think it's worth doing.

Also, as @johannhof pointed out elsewhere, we see value in reducing the number of communication channels. From a model perspective it might not be a privacy gain, but a) it makes the problem more tractable, and b) unless the information was actually necessary, it will simply no longer end up being conveyed. And b) is definitely applicable here.

johnwilander commented 2 years ago

What I'm questioning here is whether having them re-do the work of moving from an explicit policy specification (which many had to do fairly recently in response to the default referrer policy change), to writing JavaScript that adds on a new URL parameter - essentially just a syntactic change - is wise; considering that there is no privacy gain to users.

I do not agree that "there is no privacy gain to users." Third-parties automatically learning full first party referrers is bad for privacy, especially in browsers without IP address protection. Third-parties being in control of whether they get full referrers is almost as bad. Requiring small changes from first parties is better but not good. It's very similar to the SameSite=lax by default change were all third-parties that want to learn about users across sites just opt in to the old, bad behavior.

There is a huge privacy benefit in making it hard(er) for third-parties to learn things about users cross-site. Requiring significant collusion with the first party is making it harder, especially for all the JavaScript-less tracking pixels out there. The end goal is to make cross-site data leakage impossible without explicit user opt-in. On our way there we should continuously make it harder.

FWIW, I believe I said the same thing when the referrer downgrade by default change was discussed. I think it was the wrong decision and only lead to busy work for developers with no real privacy benefit. Unconditional referrer downgrade provides real privacy benefit.

annevk commented 2 years ago

@johnwilander FYI, the third party is not in control with regards to the referrer they get. The first party would have to change its policy. So it's different from SameSite=Lax. Agreed with the larger point though.

Also, I do think changing the default is good, as it reduces entropy in cross-origin-but-same-site cases, as well as various navigation cases if the policy isn't change by the first party.

krgovind commented 2 years ago

@johnwilander - I think we may be talking past each other. I agree that third-parties automatically learning the full referrer URL is bad; and that is exactly what the default policy change was meant to address. So we've already made it harder by having the requirement for first-party opt-in/collusion in place today, no? Are you suggesting that requiring top-level sites to write JavaScript is harder than specifying a referrer policy? I don't understand why making things harder for the first-party (not the third-party) is better?

johnwilander commented 2 years ago

@johnwilander - I think we may be talking past each other. I agree that third-parties automatically learning the full referrer URL is bad; and that is exactly what the default policy change was meant to address. So we've already made it harder by having the requirement for first-party opt-in/collusion in place today, no? Are you suggesting that requiring top-level sites to write JavaScript is harder than specifying a referrer policy? I don't understand why making things harder for the first-party (not the third-party) is better?

Look at all the tracking pixels on the web. They have no scripting capabilities. Having the first-party change them all to be dynamically created with referrer query parameters is a heavy lift, and in today's privacy climate, site owners might be reluctant to do that for well-known trackers.

johnwilander commented 2 years ago

@johnwilander FYI, the third party is not in control with regards to the referrer they get. The first party would have to change its policy. So it's different from SameSite=Lax. Agreed with the larger point though.

True. I was thinking of how simple it is to add a new site-wide response header versus dynamically changing URLs for subresources.

Also, I do think changing the default is good, as it reduces entropy in cross-origin-but-same-site cases, as well as various navigation cases if the policy isn't change by the first party.

I just don't believe in just changing defaults if sites can change them. The user agent needs to protect the user and have sites ask the user for permission to leak sensitive cross-site data through their browser. Getting there in general is a long journey we're on.

erik-anderson commented 2 years ago

One question for @erik-anderson, What's Edge behaviour as of today? Does Edge now default to strict-origin-when-cross-origin in Stable?

The Edge team has been experimenting with defaulting to strict-origin-when-cross-origin in our Dev and Canary channels. (comment April 2020)

Yes, we switched over to default to this behavior at the same time that Chrome did which I believe was in M89.

krgovind commented 2 years ago

Look at all the tracking pixels on the web. They have no scripting capabilities. Having the first-party change them all to be dynamically created with referrer query parameters is a heavy lift, and in today's privacy climate, site owners might be reluctant to do that for well-known trackers.

@johnwilander - With the default referrer policy change, for such tracking pixels, the first-party site was already required to change:

<img style="display: none" src="https://tracker.example/foo.png">

to:

<img style="display: none" src="https://tracker.example/foo.png" referrerpolicy="no-referrer-when-downgrade">

Which I think is a reasonably heavy lift for most first-party sites that tend to be resource-constrained.

Also, we are aware that use-cases like payments, and the GitHub/Heroku button rely on this functionality. While our intent here is to make it harder for trackers, it behooves us to also think about all the non-tracking use-cases that rely on this mechanism, and not just treat them like collateral damage. It pains me to think that we should force these sites to write JavaScript, or potentially compel them to provide their third-party service providers with scripting privileges; instead of (IMO) a much more elegant and ergonomic mechanism. :)

The end goal is to make cross-site data leakage impossible without explicit user opt-in.

This end goal that you mentioned earlier makes sense; and I think that's where the navigation-based tracking mitigations work may be headed. Which is why I'm suggesting that we include the referrer within scope of that work.

krgovind commented 2 years ago

One question for @erik-anderson, What's Edge behaviour as of today? Does Edge now default to strict-origin-when-cross-origin in Stable?

The Edge team has been experimenting with defaulting to strict-origin-when-cross-origin in our Dev and Canary channels. (comment April 2020)

Yes, we switched over to default to this behavior at the same time that Chrome did which I believe was in M89.

Yes, M89 is correct. We enabled the feature remotely for Chrome users starting in M85, but the feature in the binary (which impacts downstream Chromium) was flipped in M89.

annevk commented 2 years ago

I just don't believe in just changing defaults if sites can change them. The user agent needs to protect the user and have sites ask the user for permission to leak sensitive cross-site data through their browser. Getting there in general is a long journey we're on.

Cross-site, yes, but same-site seems okay. And same-origin seems like a better default.

annevk commented 2 years ago

Removing agenda+ as we'd prefer to discuss this at a later meeting.

martinthomson commented 2 years ago

@erik-anderson wrote:

A site that uses links from a github repo markdown file to a different domain that they own which then turns around and load resources from a https://raw.githubusercontent.com/ URL which has a path component based on the referrer info from the github page.

In case anyone cares, this is something that one my own projects does. It's a convenience function only: outbound links to content on GitHub Pages from the readme of a project are automatically redirected by script to the matching content. The result is a fallback to the content on the main branch.