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

Referrer trimming #13

Open
englehardt opened this issue Apr 29, 2020 · 54 comments
Open

Referrer trimming #13

englehardt opened this issue Apr 29, 2020 · 54 comments

Comments

@englehardt
Copy link

englehardt commented Apr 29, 2020

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

  • Referrers default to strict-origin-when-cross-origin.
  • Trim document.referrer down to eTLD+1 when we observe tokens that can be used to circumvent our cross-site tracking protections.

Chrome

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

Safari

  • All cross-site subresource HTTP referrers are trimmed to the page's origin. This matches strict-origin-when-cross-origin, but sites can not override this setting.
  • Trim all cross-site document.referrer to the page's origin.
  • Trim document.referrer to eTLD+1 if the referrer has link decoration and the user was navigated from a domain classified by ITP. See ITP 2.3.

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: w3c/webappsec-referrer-policy#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?

  • 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?
@johnwilander
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Member

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
Copy link

pes10k commented Jul 6, 2020

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
Copy link

annevk commented Jul 7, 2020

cc @domfarolino

@krgovind
Copy link

  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
Copy link

pes10k commented Jul 16, 2020

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

@atjn
Copy link

atjn commented Sep 13, 2020

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
Copy link

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:

  • Referrers are capped on cross-origin iframes, but not on other cross-origin subresources such as <img> elements.
  • The element-level referrerpolicy specification is not honored consistently (even when the policy is more restrictive than the page-level specification). See her post on webkit-dev.

@renebaudisch
Copy link

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
Copy link

krgovind commented Oct 2, 2020

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
Copy link

@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
Copy link

krgovind commented Oct 2, 2020

@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
Copy link

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
Copy link

krgovind commented Oct 2, 2020

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
Copy link

@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
Copy link

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
Copy link

maudnals commented Oct 21, 2020

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

@pes10k
Copy link

pes10k commented Jan 28, 2021

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

  • Referrer values are capped to strict-origin-when-cross-origin and can only be tightened via referrer policy, not weakened.

@englehardt
Copy link
Author

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
Copy link

fmarier commented Apr 12, 2021

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
Copy link
Member

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
Copy link
Member

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.

@kdzwinel
Copy link

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:

  • this page has unsafe-url set as a referrer policy and
  • couple of tests refer to "trackers", you can ignore those, those are DDG specific (we use broken.third-party.site and bad.thrid-party.site as "known trackers" for which our browsers and extensions have special treatment - referrer trimmed to eTLD+1).

@maudnals
Copy link

maudnals commented Oct 14, 2021

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
Copy link

krgovind commented Oct 14, 2021

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:

  • This might create unnecessary "busy work" for developers without any privacy improvements. I appreciate what you're saying about URL parameters being more transparent to advanced users, but I'm not convinced that this would necessarily compel trackers into changing behaviors (I'm assuming that's what we expect the increased transparency will eventually result in). In fact, it's fairly trivial to quickly replace the URL using clever tricks like window.history.replaceState, so the user can't even notice this.
    • This is not super scientific, but I ran a simple query on the HTTPArchive corpus on June 2020 data (before we announced the Chrome change to the default policy), and again on September 2021 data. I saw that the % of sites specifying the no-referrer-when-downgrade policy increased from 0.11% to 0.78% of the ~6 million sites in the corpus. While 0.78% is an upper bound for potential breakage, I think it's a relatively high number from the compatibility hit perspective.
  • Ergonomics - There is no declarative way to insert URL parameters; so this would require the originating site to write JavaScript that potentially annotates every outgoing URL (e.g. in the GitHub/Heroku buttons example).

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

@johnwilander
Copy link

johnwilander commented Oct 14, 2021

@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
Copy link
Member

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

@krgovind
Copy link

krgovind commented Oct 14, 2021

  • 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
Copy link
Author

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
Copy link

annevk commented Oct 15, 2021

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
Copy link

@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
Copy link

annevk commented Oct 15, 2021

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
Copy link

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
Copy link

annevk commented Oct 15, 2021

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
Copy link

johnwilander commented Oct 15, 2021

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
Copy link

annevk commented Oct 15, 2021

@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
Copy link

krgovind commented Oct 15, 2021

@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
Copy link

@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
Copy link

@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
Copy link
Member

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
Copy link

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
Copy link

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
Copy link

annevk commented Oct 18, 2021

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.

@johannhof johannhof added the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Oct 20, 2021
@annevk annevk removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Dec 7, 2021
@annevk
Copy link

annevk commented Dec 7, 2021

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

@martinthomson
Copy link

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

@erik-anderson
Copy link
Member

The default value was formally changed in this WebAppSec PR.

Are there still additional areas that we want to continue to discuss via this proposal, e.g. not just the default referrer policy but also potential alignment on what behavior sites are allowed to choose? If so, it might be better to create a new proposal focused on what sites are allowed to do with referrer policies.

@annevk
Copy link

annevk commented Apr 4, 2022

The recent discussion in this issue focuses on not allowing overrides for cross-site subresources, which is what Safari implements and Firefox also sees value in.

@pes10k
Copy link

pes10k commented Apr 4, 2022

FWIW, Brave also implements the above (clamping w/o the ability of sites to override)

@ChadBailey
Copy link

ChadBailey commented Sep 10, 2022

UPDATE

Well, this is embarrassing - what I wrote below was incorrect. Rather than delete my post I'll supply my answer in the event any other poor soul makes it as far as this thread. It would appear the problem can be resolved via the following in the content_scripts section:

    "all_frames": true,
    "matches": ["<all_urls>"],
    "match_about_blank": true,

An edge case to be sure, but this appears to misbehave when using browser extensions (webextensions) to access local files via file://.

Although the particular pattern works on external websites, it fails on file:// urls due to the default/minimal html there. This wouldn't normally be a problem (I'm all about more protection), however, the issue appears to be insurmountable using the designated web_accessible_resources configuration. This tempts the developer to do weird things that are probably much worse crimes than allowing access to the explicitly stated files in manifest.json.

I think for my use-case this isn't going to be a problem since I can simply import what I need into my bundle, but thought it would be helpful to document here.

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

No branches or pull requests