reminder: tighten cross origin referers

[Thorin-Oakenpants]

current

/*** [SECTION 1600]: HEADERS / REFERERS
     Only *cross domain* referers need controlling: leave 1601, 1602, 1605 and 1606 alone
     ---
            harden it a bit: set XOriginPolicy (1603) to 1 (as per the settings below)
       harden it a bit more: set XOriginPolicy (1603) to 2 (and optionally 1604 to 1 or 2), expect breakage
     ---
     If you want any REAL control over referers and breakage, then use an extension
     ---
                    full URI: https://example.com:8888/foo/bar.html?id=1234
       scheme+host+port+path: https://example.com:8888/foo/bar.html
            scheme+host+port: https://example.com:8888
     ---
     #Required reading [#] https://feeding.cloud.geek.nz/posts/tweaking-referrer-for-privacy-in-firefox/
***/

/* 1603: CROSS ORIGIN: control when to send a referer
 * 0=always (default), 1=only if base domains match, 2=only if hosts match
 * [SETUP-WEB] Known to cause issues with older modems/routers and some sites e.g vimeo, icloud ***/
user_pref("network.http.referer.XOriginPolicy", 1);
/* 1604: CROSS ORIGIN: control the amount of information to send [FF52+]
 * 0=send full URI (default), 1=scheme+host+port+path, 2=scheme+host+port ***/
user_pref("network.http.referer.XOriginTrimmingPolicy", 0); // [DEFAULT: 0]

Hmmm ... the "harden it a bit" line seems weird, it's already at 1: probably a left-over from recommending extensions as an option

I think we can actually change these to 2 and 2 based on Safari

---

source

Downgraded Third-Party Referrers

All third-party referrers are downgraded to their origins by default. This applies to both HTTP referrer headers and document.referrer. For example, if the full referrer is https://www.social.example/feed?clickID=123456, it will show up as https://www.social.example/

see this blog which indicates the "Origin-Only Referrer For All Third-Party Requests" as being implemented since Dec 2019

--

and here

All cross-site referrers are downgraded to just the origin by default (https://www.domain.com)

If the classified domain sends traffic to other sites, and the classified domain has URL parameters (or fragments) in the URL, the document.referrer string on the target site will be truncated to just eTLD+1 (so https://www.simoahava.com/some-page becomes https://simoahava.com/).

--

and here

Safari downgrades document.referrer to origin in cross-site navigation.

Safari downgrades the referrer in cross-site request headers to origin. Thus if a page on https://www.domain.com/page/page.html tried to load an image from https://images.imagecdn.com, the referer header would show https://www.domain.com rather than the full referrer.

Furthermore, if the referring domain is a known tracker, and if the referring page has query parameters (?key=value) or fragments (#somevalue), the document.referrer property is downgraded to effective top-level domain plus one part (eTLD+1). Thus a request originating from https://sub.classified.domain.com/page?userId=abcd1234 would end up as https://domain.com in the document.referrer property of the landing page.

For navigational requests, no-referrer-when-downgrade applies.

---

If Safari can tighten it, then I'm pretty sure that SFA (sweet F all) would break. Currently we're at 1 + 0 which is OK'ish but not brilliant. Personally I've been at 2 + 2 for the last several years with no breakage, but I'm not atypical

Anyone want to chip in with their thoughts?

[g-2-s]

Hi. I'm kinda "forced" to use Smart Referer plus network.http.referer.XOriginPolicy at the default value of 0 because 1 (one, uno) damn site doesn't work if I set it to anything more than that.

I want to ask, is there any benefit to set network.http.referer.XOriginTrimmingPolicy to 2 if I use the addon? It seems that this option doesn't have any impact on said damn site but I don't know if it's redundant with Smart Referer.

Thank you and sorry if I just asked something incredibly dumb.

EDIT: actually, I don't even know if I'm allowed to ask this here, sorry again if I'm breaking some rules.

[Thorin-Oakenpants]

Depends on how you configured Smart Referer (I've never used it, so I'm not familiar with changing the default origin-destination rules). If you're effectively 2+2 (whatever that is in Smart Referer terms), but can whitelist or have different rules for a few problematic sites, then you're all good

[rusty-snake]

network.http.referer.XOriginPolicy=2 in Smart Referer:

• Rewrite Mode: Send nothing as referer, looks like a direct hit
• Domain name matching strictness: Strict

[rawlife56]

network.http.referer.XOriginPolicy=2 in Smart Referer:

* Rewrite Mode: Send nothing as referer, looks like a direct hit

* Domain name matching strictness: Strict

I guess Umatrix 'Spoof referrer' also does the same thing in a less granular level. right ?
Is enabling Spoof referrer option globally in umatrix equal to 2 + 2 in user.js ?

[Thorin-Oakenpants]

I used to just use uMatrix's checkbox: but have since pared back anything in uM to the bare minimum in anticipation of one day dropping it: pretty sure I can cover everything it does in other ways such as prefs (but I'll probably use it until it breaks or becomes a liability)

from the extension (emphasis + italics mine)

If this setting is checked, uMatrix will spoof the HTTP referrer information if the domain name of the HTTP referrer is third-party to the domain name of net request

from the wiki

the referer information will now be foiled using the root URL derived from the URL of the request. For example, if the URL of a request is http://www.example.com/blahblahblah/boring.html and the referer is http://google.com, the referer will be spoofed using the http://www.example.com/ string.

If I read that correctly - when you request a resource, the referer will always be the same as the resource - which is not what the Firefox prefs do. FF only trims it etc, it doesn't change it. But of course, with Firefox at 2 + whatever, host domains must match so 3rd party is already nixed (I think: referers always confuse me)

[earthlng]

I think 0+2 would be more like what Safari does but tightening our settings to 2+2 probably shouldn't cause much more breakage than what we currently have

[KOLANICH]

think 0+2 would be more like what Safari does but tightening our settings to 2+2 probably shouldn't cause much more breakage than what we currently have

I use 2 + 2 for many years. The only case I have experienced breakage was OpenStreetMap forum that tracked referers within same website in an attempt to detect bots.

[crssi]

Login to https://www.icloud.com/ doesn't work with network.http.referer.XOriginPolicy other than default.
But it also doesn't work when using resistFingerprinting, so it doesn't matter then.

[Thorin-Oakenpants]

resistFingerprinting only breaks the login part though, right? it was like that pornhub one or something?

edit: if I remember rightly the pornhub was solved (a timing thing) and that let icloud's error also get fixed, but icloud then still had something else blocking it? Is there a ticket for the icloud login failing with RFP?

[crssi]

^^ https://bugzilla.mozilla.org/show_bug.cgi?id=1621729

[Thorin-Oakenpants]

ahh that's right .. see comment 14

[crssi]

Oh... and RFP was not the point here, it was network.http.referer.XOriginPolicy.

[crssi]

I don't see a point having network.http.referer.XOriginTrimmingPolicy different that default when network.http.referer.XOriginPolicy is different than 0.
At that point we are already at the same domain or even host and we are just teasing for breakage for nothing... or I do not see the whole picture as usually.

Cheers

[earthlng]

@crssi with XOriginPolicy at 2, the trimming of 1604=2 only happens in very rare cases, namely if the scheme or the port changes but on the same host. Any request on the same scheme+host+port will still get the untrimmed referrer because those requests are not cross-origin.
fe.
https://www.foo.bar/article/blah.html loads https://www.foo.bar/js/main.js -> full referrer
https://www.foo.bar/article/blah.html loads https://www.foo.bar:8080/js/main.js -> trimmed referrer

So I don't think 1604=2 should cause that much more breakage but it's a good value to have because it will leak a bit less information if someone relaxes 1603.

[crssi]

Doh... I had a very important typo in my prevous post... did a correction now.
Thank you @earthlng. I will keep your latest value for network.http.referer.XOriginTrimmingPolicy at 2 and will see what happens.
I am having network.http.referer.XOriginPolicy at 0 since I am using SmartReferer Extension, otherwise I have a breakages on a few sites here, that are visited often.

Cheers

[Kein]

Just so you know this breaks popular stuff like Pixiv, might add note to comment

[Svallinn]

@Kein
Actually, Pixiv would break even with the previous settings (because it uses the pximg.net domain for images), so that's nothing new
There's already a warning anyway

/* 1603: CROSS ORIGIN: control when to send a referer
 * 0=always (default), 1=only if base domains match, 2=only if hosts match
 * [SETUP-WEB] Known to cause issues with older modems/routers and some sites e.g vimeo, icloud ***/

[yokoffing]

Login to https://www.icloud.com/ doesn't work with network.http.referer.XOriginPolicy other than default.
But it also doesn't work when using resistFingerprinting, so it doesn't matter then.

I can login to iCloud with 0 + 2 and dFPI enabled.

In my experience, you will won't be able to login to https://www.bing.com and other Microsoft websites if you set XOriginPolicy to anything other than 0.

(I don't use Firefox's privacy.resistFingerprinting due to breakage of everyday use cases.)

[crssi]

ATM the only site that I know (and it is not important, at least for me) is https://www.icloud.com which breaks due to resistFingerprinting.

In the past, but way ago, there were problems, but now... not anymore.

Do you have any samples?