Referrer trimming

[englehardt]

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: 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?

• 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?

[erik-anderson]

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]

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]

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

[ChadBailey]

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.