Referrer trimming #13
Comments
This is correct. However, ITP also detects if link decoration tracking is potentially happening and in that case downgrades |
Thanks! I've updated the original post with a link to https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/. |
Correct, we have experimented with
We are also interested in the answers to these questions. |
|
The Edge team has been experimenting with defaulting to Examples:
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. |
|
FWIW here, Brave is now shipping a modified referrer policy, similar to the above. The flow-chart is in our wiki, but basically (simplified):
If the brave desc in the issue text could be updated, that'd be appreciated :) |
|
cc @domfarolino |
@pes10k - Did you mean to say "We respect site requests for more restrictive policies"? |
|
@krgovind ah yes, of course, fixed . Thank you for catching that :) |
@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:
|
|
Hi everybody. |
@renebaudisch Thanks for asking! For those of us not familiar with the document, could you explain what I'm guessing Could you help us understand the use-cases that need the full page URL? |
|
@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. Counting deliveries therefore is easy, but adservers also count clicks. Because of this there is a need to an option to pass the delivering adservers counting url to the creative. As we use Xandr I can provide you an example url of a hosted creative that uses that feature. When the user clicks that ad, the ad will take the clicktag from the decoration and invoke it. Sure this can be changed and adopted to be done by postMessage, |
|
@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. |
|
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? |
|
The term "referrer trimming" for the purpose of this thread is narrowly scoped to the use of the HTTP Having said that, the privacy principles we use here should generally apply to "navigational tracking", which does include link decoration. |
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 |
I don't think the bug you mentioned was my team, but we created one today to capture the issue with element-level
Re: 1) we see that |
|
For reference: we've updated the bug in question with a few more observations regarding Safari 14. |
|
Just to update, Brave's policy has changed to:
|
|
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 |
|
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. |
|
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. |
|
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. |
|
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:
|
|
One question for @erik-anderson,
|
@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. :) |
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. |
|
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. :) |
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 |
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 |
|
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. |
|
@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 |
|
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 |
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 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. |
|
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. |
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. |
|
@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. |
|
@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. |
True. I was thinking of how simple it is to add a new site-wide response header versus dynamically changing URLs for subresources.
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. |
Yes, we switched over to default to this behavior at the same time that Chrome did which I believe was in M89. |
@johnwilander - With the default referrer policy change, for such tracking pixels, the first-party site was already required to change:
to:
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. :)
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. |
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. |
Cross-site, yes, but same-site seems okay. And same-origin seems like a better default. |
|
Removing agenda+ as we'd prefer to discuss this at a later meeting. |
|
@erik-anderson wrote:
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 |
|
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. |
|
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. |
|
FWIW, Brave also implements the above (clamping w/o the ability of sites to override) |
"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 Although the particular pattern works on external websites, it fails on 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. |
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
strict-origin-when-cross-origin.document.referrerdown 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
strict-origin-when-cross-origin, but sites can not override this setting.document.referrerto the page's origin.document.referrerto 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-originand 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?The text was updated successfully, but these errors were encountered: