User.js: network.http.referer.spoofSource and browser.privatebrowsing.autostart breaks sites.

[alabrand]

network.http.referer.spoofSource, for example, breaks Bato.to and some other sites.
browser.privatebrowsing.autostart, for example, breaks 4chan and a few other sites.

I suggest leaving these to their default value but encouraging the use of them on the main github page if at all possible.

[Hunter-Github]

How many people willingly use the sites you cited while knowing about the privacy implications?

[pyllyukko]

network.http.referer.spoofSource, for example, breaks Bato.to and some other sites.
browser.privatebrowsing.autostart, for example, breaks 4chan and a few other sites.

Make sure your network.http.sendRefererHeader setting value is 2. I haven't seen any sites that break with this setting combination. HTTP referer header is one of the worst information leakages IMO, so we should really keep the spoofing turned on.

How exactly does browser.privatebrowsing.autostart break 4chan and these other sites?

I suggest leaving these to their default value but encouraging the use of them on the main github page if at all possible.

I'm afraid it's not possible as these settings are really important regarding privacy.

[alabrand]

Hm, am I doing something wrong then? It's a clean Firefox installation, and the default value for network.http.sendRefererHeader is 2 so that shouldn't be a problem.

Private Browsing breaks 4chan in that you can't use certain functions. Or actually, when I think about it, that could have been referer spoofer breaking it instead of Private Browsing.

Still, I don't know why referer spoofer didn't work. As I said, the default value on a clean Firefox installation for network.http.sendRefererHeader is 2.

[pyllyukko]

Private Browsing breaks 4chan in that you can't use certain functions. Or actually, when I think about it, that could have been referer spoofer breaking it instead of Private Browsing.

It is more likely, yes. I can't think of any reason, why private browsing would break anything like that. Can you say what exact functions does it break?

Still, I don't know why referer spoofer didn't work. As I said, the default value on a clean Firefox installation for network.http.sendRefererHeader is 2.

I guess the web application just has strict checking against the referer header and spoofing doesn't cut it.

[pyllyukko]

Relates to #2

[Atavic]

@alabrand This issue is upon the user.

I suggest that the user should change the values to use such sites, because if those values are left as default, the scope of _pyllyukko/user.js_ is lost.

[Gitoffthelawn]

Referrer Control (https://github.com/muzuiget/referrer_control) and RefControl (http://www.stardrifter.org/refcontrol/) are two Firefox extensions that can help people better manage HTTP referer information being sent.

They both allow adjusting settings per site.

Referrer Control is the better of the two, IMO, but is in need of an update.

[fmarier]

I've spent a lot of time looking into the referrer header in the past few weeks and wrote a blog post about it: https://feeding.cloud.geek.nz/posts/tweaking-referrer-for-privacy-in-firefox/

The summary of that is that I no longer recommend using network.http.referer.spoofSource = true and have instead started using network.http.referer.XOriginPolicy = 2 with very little breakage. Maybe we should update user.js with this too?

[pyllyukko]

Maybe we should update user.js with this too?

I haven't experienced much breakage with network.http.referer.spoofSource, so I'm not that eager to change it.

Maybe we should still add network.http.referer.XOriginPolicy = 2 to the user.js anyways. I think setting the trimming policy also to 1 might be a good idea. Even though we don't currently leak any info through the referrer because of spoofing, this would be a step to start experimenting how these two settings affect sites.

[fmarier]

I haven't experienced much breakage with network.http.referer.spoofSource, so I'm not that eager to change it.

There's not much breakage with that setting. The main concern is that you're essentially disabling CSRF protection on a bunch of sites so you're a little more exposed than you would if you hadn't spoofed anything.

I think setting the trimming policy also to 1 might be a good idea.

I was thinking that XOriginPolicy = 2 and XOriginTrimmingPolicy = 2 might be an appropriate default that will not break very much. People can comment out XOriginPolicy if they see breakage they can't live without.

I'm not entirely convinced that TrimmingPolicy does anything useful over XOriginTrimmingPolicy because you can't hide your query string from the server you're connecting to. They have all of your traffic in their access log and it's easy to link all of your page views together. They don't need the referrer to do any of that.

[nodiscc]

This was mostly fixed in recent commits (there is a NOTICE: about this referer prefs causing breakage, and a commented out fallback preference XOriginPolicy).

I think this can be closed.

[CircuitSerialKiller]

Setting network.http.referer.spoofSource to true definitely breaks ride.lyft.com! The site will return an invalid origin header error.

[solarchemist]

Thanks for documenting the effect these settings might have on certain websites.
I've found that setting network.http.referer.spoofSource to TRUE causes certain actions in Wallabag (such as marking read/unread, or setting/unsetting tags) to return the Firefox error page "The page isn't redirecting properly" instead of redirecting back to Wallabag.

Toggling network.http.referer.spoofSource back to FALSE immediately fixes this issue and Wallabag behaves as per usual again.

Sorry for commenting on a closed issue, thought I might benefit someone else who is also using network.http.referer.spoofSource and Wallabag and is wondering what's going on.