Opened 8 years ago

Closed 7 years ago

#3429 closed defect (wontfix)

Referer blocking option breaks browser navigation

Reported by: Anna Owned by: mikeperry
Priority: Medium Milestone:
Component: TorBrowserButton Version:
Severity: Keywords:
Cc: arma, joyton Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor:

Description

I was having problems with the Tor Browser pack that uses Firefox 4. The back, forward, and refresh buttons as well as the auto-refresh feature of NoScript would stop working within a few pages of opening each new browsing session. The buttons would still be there, looking normal and I could click them and they'd register the click but wouldn't load the requested page.

I tested a variety of different combinations of settings and I think I have isolated the problem as being caused by the Block All Referer setting. This problem occurs both when using the Block All Referer feature in Torbutton's header settings and also when doing the same with the RefControl addon. But this applies only in the version of the Tor Browser that uses Firefox 4. I've tried the same settings out on the regular Firefox 4 and on the Firefox 3 version of the Tor Browser and haven't had any problems with back, forward, or refresh.

Child Tickets

Change History (19)

comment:1 Changed 8 years ago by Anna

Component: TorBrowserButtonTor Browser

comment:2 Changed 8 years ago by rransom

Component: Tor BrowserTorBrowserButton

The appropriate Trac component for this bug is TorBrowserButton (because it seems to be caused by the Torbutton browser addon, and is not related to Torbutton's old ‘toggle model’).

Which operating system are you using? Some of the Tor Browser Bundles contain Polipo, and some do not, depending on which operating system the bundle is for, and Polipo has caused issues with the Referer header before.

comment:3 Changed 8 years ago by Anna

I'm using Windows.

comment:4 Changed 8 years ago by Anna

I've just switched to the latest Firefox 5 Windows bundle and it's still having this problem even though it looks like Polipo is gone.

comment:5 Changed 8 years ago by mikeperry

Milestone: TorBrowserBundle 2.2.x-stable
Priority: normalmajor

comment:6 Changed 8 years ago by mikeperry

Keywords: MikePerryIteration20110828 added
Points: 3

comment:7 Changed 8 years ago by mikeperry

The good news is we can fix this. The bad news is that it makes the toggle model even less safe if we do so, because of Firefox API limitations. Basically the fix would increase the probability that some requests might leak through from one torbutton state to another.

I am kind of torn. On the one hand, since we're don't really support the toggle model, it might be fine to make it (more) insecure. However, I don't really think the referrer blocking feature is very useful, and I am planning on removing it in the next major release.. So to break it for this reason seems kind of silly.

comment:8 Changed 8 years ago by arma

Mike: If you are planning to take other actions soon that make this one moot, then I suggest you just move on. We already don't have enough Mikes to maintain Torbutton as well as develop Torbutton.

comment:9 Changed 8 years ago by mikeperry

Cc: arma added

So for 1.4.1, do I hide the option, or forcibly disable it?

comment:10 in reply to:  9 Changed 8 years ago by rransom

Replying to mikeperry:

So for 1.4.1, do I hide the option, or forcibly disable it?

If you plan to remove it completely later, hide it.

comment:11 Changed 8 years ago by mikeperry

Keywords: MikePerryIteration20110828 removed
Milestone: TorBrowserBundle 2.2.x-stable
Points: 32

Ok. Created #3809 for the ticker for hiding it.

Leaving this ticket open in case we decide to alter the content policy for TBB users who install something like RefControl...

comment:12 Changed 8 years ago by mikeperry

Anna: Does the "Smart Referrer spoofing" option also trigger this bug?

comment:13 Changed 8 years ago by joyton

I have never come across this bug, and I have used the most up-to-date versions of TorButton/TBB since both were made available. Also, I have used RefControl for _years_ with Tor, TorButton and native Firefox before TBB was 'born'.

In no version of Firefox (v2... to v6...) have I seen this bug, while using RefControl for non-Tor browsing or RefControl for Tor browsing (with TorButton). I use Windows XP SP3.

I already posted in the ticket thread for #3809, re using RefControl being that TorButton dev(s) no longer like(s) to spoof referrers. To me it seems the risk of not spoofing referrers is pretty large with respect to anonymity set as well as cross-site tracking/linking by evil exit nodes, but I'm just some dumb gal so I could be missing critical understanding of the issues.

comment:14 Changed 8 years ago by joyton

Cc: joyton added

comment:15 Changed 8 years ago by joyton

Edit:

I just noticed Anna wrote TorButton broke her Firefox when the setting "Block All Referer" was activated. I have never used that setting because it seems unwise to block all referrer instead of spoofing said referrer to the current site's root. And by blocking all referrer I assume one would stick out like a sore thumb with respect to anonymity set ...

If this bug ticket is _only_ due to blocking referrers then why not simply remove that option, but still allow for spoofing?

comment:16 in reply to:  12 Changed 8 years ago by joyton

Replying to mikeperry:

Anna: Does the "Smart Referrer spoofing" option also trigger this bug?

For me it does not, and never has. That is why I'm so in knots about the removal of referrer spoofing.

comment:17 Changed 8 years ago by mikeperry

joyton: This is not a high priority for us because we believe a determined adversary still has the information channels available to transmit referer information in other ways. For example, are you aware that the Google+ +1 buttons already subvert your referer spoofing by transmitting the url in the request parameters? They do this so that they can still display the count for people who block referers... Since this is impossible to prevent in a real sense (imagine encrypted url parameters), our plan is to simply prevent them from tracking you between sites.

I linked you the Tor Blog post that explains this reasoning as part of one of it's points in the NoScript bug (for others: https://blog.torproject.org/blog/improving-private-browsing-modes-do-not-track-vs-real-privacy-design), but we also discussed this particular issue on tor-dev in this thread: https://lists.torproject.org/pipermail/tor-dev/2011-June/002801.html.

comment:18 Changed 8 years ago by mikeperry

Priority: majornormal

comment:19 Changed 7 years ago by mikeperry

Resolution: wontfix
Status: newclosed

See https://www.torproject.org/projects/torbrowser/design/#Transparency for our stance on referers.

Short answer: addressing any breakage from Referer spoofing is out of scope for us at this time. Feel free to roll your own solution and keep both pieces when it breaks.

Note: See TracTickets for help on using tickets.