Opened 6 years ago

Last modified 11 months ago

#3600 new defect

Prevent redirects from transmitting+storing cookies+identifiers

Reported by: mikeperry Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: tbb-linkability, tbb-testcase, tbb-torbutton
Cc: joyton, gk, michael, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by mikeperry)

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.

Child Tickets

Change History (34)

comment:1 Changed 6 years ago by mikeperry

Description: modified (diff)
Summary: TBB should display redirects for user confirmationWe should get user confirmation for redirects

comment:2 Changed 6 years ago by mikeperry

Points: 3

comment:3 Changed 6 years ago by mikeperry

Priority: normalmajor

comment:4 Changed 6 years ago by mikeperry

Keywords: MikePerryIteration20110911 added

Might not be able to actually enable this due to lack of translations.. But we should start the plumbing and get the strings out there, at least.

comment:5 Changed 6 years ago by mikeperry

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..

comment:6 Changed 6 years ago by joyton

Cc: joyton added

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

comment:7 in reply to:  6 Changed 6 years ago by mikeperry

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.

comment:8 Changed 6 years ago by mikeperry

Keywords: MikePerryIteration20110911 removed
Points: 3

We need a better API for this to be feasible in a reasonable amount of time. Or at least a better plan...

comment:9 Changed 6 years ago by mikeperry

Milestone: TorBrowserBundle 2.2.x-stableTorBrowserBundle 2.3.x-stable

comment:10 Changed 6 years ago by mikeperry

Summary: We should get user confirmation for redirectsWe should get user confirmation for automated redirect cycles

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. :/

comment:11 Changed 6 years ago by mikeperry

Summary: We should get user confirmation for automated redirect cyclesPrevent redirects from storing cookies+identifiers

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 for redirect API discussion.

comment:12 Changed 6 years ago by gk

Cc: g.koppen@… added

comment:13 Changed 6 years ago by mikeperry

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.

comment:14 Changed 6 years ago by mikeperry

Summary: Prevent redirects from storing cookies+identifiersPrevent redirects from transmitting+storing cookies+identifiers

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.

comment:15 Changed 5 years ago by mikeperry

Keywords: tbb-linkability added

comment:16 Changed 5 years ago by mikeperry

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?

comment:17 Changed 5 years ago by mikeperry

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.

comment:18 Changed 5 years ago by mikeperry

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.

comment:19 Changed 5 years ago by mikeperry

We could also make the prompt behave such that "Cancel" returns to the redirecting site and blocks further redirects from it. Might be slightly better UX.

comment:20 Changed 5 years ago by mikeperry

Another datapoint: Google adwords will in some cases transparently redirect you through www.google.com as a first party with a huge bunch of mystery data encoded in the GET url path. It's not a regular behavior for all ads, but my guess would be that it is done through a window.location-style JS redirect during ad click, since my browser status bar did not display a www.google.com destination url prior to click.

I'm not sure if this example helps settle the "prompt or defang?" dilemma for these types of redirects.. That probably depends on common federated login mechanisms and viable alternatives, which in and of itself probably means "deploy the prompt first, and see what gets interrupted by it".

comment:21 Changed 5 years ago by mikeperry

Somewhere, somehow we should enumerate the various ways automated redirects can happen. Here's a few off the top of my head:

  1. HTTP 3xx headers
  2. meta-refresh
  3. window/document.location updates
  4. JS-driven form submits
  5. Synthetic click events (https://developer.mozilla.org/en-US/docs/DOM/element.dispatchEvent)
  6. window.history manipulation (can't really target specific domains though)
  7. Clickjacking (out of scope, as Mozilla hopefully considers these to be a security issue?)

comment:22 Changed 4 years ago by mikeperry

If we need to try to differentiate between user initiated clicks and synthetic clicks as part of this, the implementation in https://bugzilla.mozilla.org/show_bug.cgi?id=769569 may be a helpful starting point.

comment:23 Changed 4 years ago by gk

Cc: gk added; g.koppen@… removed
Keywords: tbb-testcase added

comment:24 Changed 3 years ago by erinn

Component: TorBrowserButtonTor Browser
Keywords: tbb-torbutton added
Owner: changed from mikeperry to tbb-team

comment:25 Changed 3 years ago by michael

Cc: michael added

comment:26 Changed 3 years ago by mikeperry

With double-keyed cookies, we could make redirect destinations behave like third parties of the redirecting site for purposes of cookie storage, cache storage, DOM storage, etc. This may require complicated state keeping for chained redirects, unless we simply ignore redirect chains..

comment:27 in reply to:  26 Changed 3 years ago by michael

Replying to mikeperry:

we could make redirect destinations behave like third parties of the redirecting site
[...]

Let's remember that Mozilla itself originated this idea.

comment:28 Changed 19 months ago by mikeperry

Cc: arma added
Severity: Major

I hopped into my tardis (it's not just a hot air balloon, I swear) and found a potential stopgap solution from the future. What if we prompted before every first party redirect and provided a message that said something like the following, containing two buttons with the bracketed text:

Warning: The website domain.com is redirecting you to destination.com. This may mean that domain.com and destination.com are attempting to communicate to determine your identity and track your activity.

[Proceed with tracking] [ Proceed without tracking]

If the user clicks "Proceed with tracking", then cookies, cache, etc would be preserved. If the user clicks "Proceed without tracking", then we clear all state and identifiers stored for destination.com before loading the redirect request. (We would strip any subdomains from both domain.com and destination.com in the message dialog, both because this would be less confusing and also because our isolation applies to top-level domains).

Anyway, just an idea that might come in handy.

Happy Caturday! Take it easy, everyone!

comment:29 Changed 19 months ago by arma

How often would this pop-up prompt occur?

People are already driven nuts by the canvas thing.

I would say if it's really rare, awesome, but if it's really common, we want something that is less mental load on the user.

comment:30 in reply to:  28 Changed 19 months ago by cypherpunks

Replying to mikeperry:

If the user clicks "Proceed with tracking", then cookies, cache, etc would be preserved. If the user clicks "Proceed without tracking", then we clear all state and identifiers stored for destination.com before loading the redirect request. (We would strip any subdomains from both domain.com and destination.com in the message dialog, both because this would be less confusing and also because our isolation applies to top-level domains).

Would the state also be cleared after the redirect happened? Or would it stay in place but keyed on the originator of the redirection?

Replying to arma:

People are already driven nuts by the canvas thing.

Oh come on arma! "People" are also not at all bothered by the canvas thing, and "people" would very much like to have more control about attempts to track and correlate them. Yes privacy/security and convenience are opposite ends of the scale, what's new? "People" can already use any number of other browsers if they want convenience.

comment:31 Changed 19 months ago by bugzilla

Please, no more popups (especially, modal)!
GUI should be straightlined for "private browsing" and can be a little bit annoying for "unsafe" actions. Solution as with warning message when maximized is optimal. It could be with those two buttons or auto redirected without tracking, but asking about "replay" with tracking (for compatibility).

comment:32 Changed 14 months ago by bugzilla

Milestone: TorBrowserBundle 2.3.x-stable

NoScript has some options for notifying in the case of JS redirects. We'll probably want to enable those options in TBB, too.

Are you going to separate JS from non-JS redirect handling to NoScript?

comment:34 Changed 11 months ago by gk

#20859 is a duplicate.

Note: See TracTickets for help on using tickets.