Consideration for disabling/trimming referrers within TBB

As per zyan's reply here (https://trac.torproject.org/projects/tor/ticket/9623#comment:23), I've created a new ticket.

It is definitely worth considering disabling referrer / trackers within TBB as it seems the security concerns (trackability/linkability) are [much] greater than the possiblity of occasional breakage on a few websites.

Possibly disable + include a way to toggle referrer on for particular site temporarily? Just an idea, needs to be examined for what would be the best solution.

added component::applications/tor browser owner::tbb-team priority::medium severity::normal status::new type::defect labels

Another possible solution: Add functionality to Security Slider, basic example =>

High-ish: Completely disable referrers Low-ish: Allow referrers

the referrer could also always point to the domain of the target url (except for whitelist exceptions)). i believe some addons do this

Trac:
Username: elypter

There are two preferences that can be combined in various ways to control and spoof the referer header. My favorite choices for different security levels:

Lowest: no referrer restrictions (network.http.referer.XOriginPolicy=0) and no spoofing (network.http.referer.spoofSource=false)

Medium-low: send referrer only if base domains match (network.http.referer.XOriginPolicy=1) but don't change it (network.http.referer.spoofSource=false)

Medium-high: send referrer only if base domains match (network.http.referer.XOriginPolicy=1) and point it to the target url (network.http.referer.spoofSource=true), or: send unchanged referrer but only if hosts match (network.http.referer.XOriginPolicy=2 and network.http.referer.spoofSource=false)

Highest: send referrer only if hosts match (network.http.referer.XOriginPolicy=2) and point it to the target url (network.http.referer.spoofSource=true)

To get the bikeshed properly going: I am not convinced that this should be mixed with the security slider/levels in any way: The privacy settings (where the referer spoofing would belong to) are clearly separated form the security related settings in our UI (on purpose). And the functionality is decoupled as well: One can tune the one without impacting the other. Keeping this has a bunch of advantages: it makes the system easier to understand and to analyze; it helps explaining these complex things to users; it minimizes the risk to shoot oneself in the foot...

I think we should enable it for all security levels because usually websites check only top domain to prevent hotlinking and it is unlikely it can breake any serious website.

So I propose to fix this as fast as possible because it is easy to implement and will allow better privacy for all tor users.

Trac:
Severity: N/A to Normal
Priority: Medium to High

Marking #20450 (moved) as duplicate. See http://feeding.cloud.geek.nz/posts/tweaking-referrer-for-privacy-in-firefox/ for a good overview of possible options for tweaking Referer preferences.

Trac:
Reviewer: N/A to N/A
Cc: N/A to lunar

Just to add a note here, as this is something I've had to consider today, we should probably never pass referrer information for onion->clearnet sites. This is the current behavior.

I was thinking about this as I wanted to set a homepage for Tor browser with my commonly visited onion services with handy search boxes and links for Trac reports etc. and I realised that if I'm the only person using that page and it shows up in referrer headers, then that's anonymity gone.

Replying to irl:

Just to add a note here, as this is something I've had to consider today, we should probably never pass referrer information for onion->clearnet sites. This is the current behavior.

Are you sure? We have #9623 (moved) that fixed this problem and moved that into a Firefox patch with #17334 (moved). If that does not work do you mind filing a new ticket outlining steps to reproduce your problem?

#25180 (moved) is a duplicate.

@ gk

cane recommends setting network.http.referer.XOriginPolicy=2. Why don't you agree on his recommendation? The current state means that Tor/Tails users are easily identified as such simply by the referer (e.g. by coming from the Tails startpage). I know Tor users can also be identified as such by looking up the IP addresses of the exit nodes. But storing and analyzing referers should be more common for website operators than cross-referencing website visitors' IP addresses with the publicy known Tor exit nodes addresses. There should be no obvious flag like 'Hey! I'm just arriving on your website, coming from Tails' startpage! I'm a Tor/Tails user! Now you know, without any sophisticated effort!'.

We just need a smarter fake referer generation algo taking in account such factors as type of content.

Anything new on this topic? There still seem to be open questions.

#25736 (moved) is a duplicate

Trac:
Cc: lunar to lunar, Wally

#27883 (moved), #27884 (moved), and #27885 (moved) are duplicates if this ticket.

Trac:
Cc: lunar, Wally to lunar, Wally, floweb
Summary: Consideration for disabling referrers within TBB to Consideration for disabling/trimming referrers within TBB

Some interesting breakage depending on XOriginPolicy and spoofSource settings: https://bugzilla.mozilla.org/show_bug.cgi?id=970136#c4.

Resolved #30276 (moved) as a duplicate.

Trac:
Priority: High to Medium
Cc: lunar, Wally, floweb to lunar, Wally, floweb, randomname213324

mentioned in issue #20450 (moved)

mentioned in issue #25180 (moved)

mentioned in issue #25736 (moved)