Prevent redirects from transmitting+storing cookies+identifiers
I've been using RequestPolicy for so long I'd not realized that redirects have been getting more and more transparent. In Firefox 4/5, the loading indications are impossible to differentiate between redirects and 3rd party loads.
There does not appear to be any obvious about:config options to enable more prompting either. We may have to dig into the RequestPolicy source to see how they do this.
Redirect notification is important if we're going to try to keep 3rd party cookies disabled (or dual-keyed). If redirects are 100% transparent, there's little point in disabling 3rd party cookies.
NoScript has some options for notifying in the case of JS redirects. We'll probably want to enable those options in TBB, too.
Activity
Trac:
Description: I've been using RequestPolicy for so long I'd not realized that redirects have been getting more and more transparent. In Firefox 4/5, the loading indications are impossible to differentiate between redirects andThere does not appear to be any obvious about:config options to cause this prompting either. We may have to dig into the RequestPolicy source to see how they do this.
Redirect notification is important if we're going to try to keep 3rd party cookies disabled (or dual-keyed). If redirects are 100% transparent, there's little point in disabling 3rd party cookies.
to
I've been using RequestPolicy for so long I'd not realized that redirects have been getting more and more transparent. In Firefox 4/5, the loading indications are impossible to differentiate between redirects and 3rd party loads.
There does not appear to be any obvious about:config options to enable more prompting either. We may have to dig into the RequestPolicy source to see how they do this.
Redirect notification is important if we're going to try to keep 3rd party cookies disabled (or dual-keyed). If redirects are 100% transparent, there's little point in disabling 3rd party cookies.
NoScript has some options for notifying in the case of JS redirects. We'll probably want to enable those options in TBB, too.
Summary: TBB should display redirects for user confirmation to We should get user confirmation for redirects-
Bleh. Turns out that RequestPolicy only even knows about redirects that set Location or Refresh headers. It doesn't seem to know anything about meta-refresh or window.location redirects.
NoScript knows about both of the latter, but it finds out by groveling through the DOM looking for regular expressions...
This doesn't really appear to be easily doable..
Mike,
I too use RequestPolicy (RP), may I ask why it's not included in TBB by default? Is it that you're worried it will confuse too many users who are not familiar with RP?
I dislike that TBB seems to lack important add-ons such as AdBlock Plus, RequestPolicy and (now) BetterPrivacy (although I'm aware of why it was temporally removed). I am unhappy about the lack of those add-ons (and others such as anti-tracking cookie add-on(s)) because it then makes me use a smaller (an wholly unique?) anonymity set being that I install those add-ons to my TBBs.
Why do you choose to not include sound add-ons that will increase user security and/or privacy?
Thank you
Trac:
Username: joyton
Cc: N/A to joyton-
Replying to joyton:
I too use RequestPolicy (RP), may I ask why it's not included in TBB by default? Is it that you're worried it will confuse too many users who are not familiar with RP?
I dislike that TBB seems to lack important add-ons such as AdBlock Plus, RequestPolicy and (now) BetterPrivacy (although I'm aware of why it was temporally removed). I am unhappy about the lack of those add-ons (and others such as anti-tracking cookie add-on(s)) because it then makes me use a smaller (an wholly unique?) anonymity set being that I install those add-ons to my TBBs.
The basic reasoning here is the same as https://trac.torproject.org/projects/tor/ticket/3975#comment:1 (and https://blog.torproject.org/blog/improving-private-browsing-modes-do-not-track-vs-real-privacy-design).
On top of that philosophy is our belief that RequestPolicy is very hard to use. However, we also believe that AdBlock plus will be of marginal use against a determined adversary intent upon subverting its rules.
Note that we very much want to be able to support an auto-update mechanism that allows you to keep your addons, though. The primary barrier to that is an auto-updater, but there are also some educational concerns in that if you are the only one using an addon, you have little anonymity. Of course, this depends on addon behavior and install set, but request policy in particular is very fingerprintable because each user has their own policy.
-
pde pointed out that without exceptions, prompting for all redirects is going to cause warning fatigue, especially now that both google and twitter use them by default for click tracking.
So instead, let's try to address the linkability issue. We should prompt for automated redirect cycles that bounce off an intermediate site without prompting the user before returning to a previous site in the redirect chain. Such automated cycles would be evidence of parternerships attempting to elevate ad servers to first-party status.
We can track these cycles with a navigation observer, but it will be a fun challenge to differentiate automated redirects from those that stop for user input from XPCOM. We may need to alter some APIs. :/
Trac:
Summary: We should get user confirmation for redirects to We should get user confirmation for automated redirect cycles -
Hrmm, instead of warning at all, we should prevent redirects from transmitting or storing any identifiers. The best heuristic might still be to delete identifiers after the fact when a cycle is detected, but we should think a little more about alternatives, as after-the-fact deletion won't cover all cases.
See also #4286 (moved) for redirect API discussion.
Trac:
Summary: We should get user confirmation for automated redirect cycles to Prevent redirects from storing cookies+identifiers 
Trac:
Cc: joyton to joyton, g.koppen@jondos.de-
FYI: Youtube.com has begun redirecting to accounts.google.com in some cases but not all (search results and video deeplinks seem to trigger it?) and using the redirect to automatically log you in to your google account on youtube...
I'm not exactly a fan of that. We should find some way to prevent it.
-
To be clear, the property that bugs me is that it is fully automatic and non-consensual. I think we can get the behavior we want if we do not transmit the cookies to accounts.google.com on the redirect, but we'll need to test it.
Trac:
Summary: Prevent redirects from storing cookies+identifiers to Prevent redirects from transmitting+storing cookies+identifiers -
FTR: I might flip-flop on this one or two more times before we finally decide to try to solve it. Because identifiers can be encoded in GET parameters, the only way to really prevent transmission is to prompt the user before following the redirect....
Anyone have any other comments/suggestions?
-
If we decide to prompt, it would say something like "Website https://bit.ly/foobar wishes to redirect you to https://trac.torproject.org/projects/tor/ticket/3600. Usually this is harmless, but in some cases it can be abused through advertising partnerships to link your identity on one website to your identity on another website. If the ability of these two websites to cooperate to track you is a problem, you should click Cancel. Otherwise, click OK."
Cancel would redirect the user to about:blank, and OK would follow the redirect.
-
window.name is another vector for linking across automatic top-level redirects. If we try to find a non-prompt-based solution, it will need to be cleared for them, too. If we have a prompt, it might be OK to leave it, to allow things like ancient federated login systems that abuse window.name.