Tor Browser should set SOCKS username for a request based on first party domain
Once Proposal 171 is implemented (legacy/trac#1865 (moved)), Tor Browser should set the Proposal 171 SOCKS username to a function of the hostname in the referer header (possibly caching the first referer for subsequent link navigation).
If the referer is blank, we should use a function of the request URL hostname. This policy should effectively give us the same top-level origin isolation for circuit use that we want for other identifiers.
Lunar also points out that if this function introduces a hashed nonce that is changed on "New Identity" invocations, we can then do without the control port and control auth/password inside torbutton but still provide New Identity. This would simplify a lot of setups, and potentially allow us to remove more code from Torbutton.
Activity
changed milestone to %TorBrowserBundle 2.3.x-stable in legacy/trac
added MikePerry201410R in Legacy / Trac TorBrowserTeam201410 in Legacy / Trac component::applications/tor browser in Legacy / Trac milestone::TorBrowserBundle 2.3.x-stable in Legacy / Trac owner::arthuredelstein in Legacy / Trac parent::5752 in Legacy / Trac priority::high in Legacy / Trac resolution::fixed in Legacy / Trac status::closed in Legacy / Trac tbb-4.5-alpha in Legacy / Trac tbb-firefox-patch in Legacy / Trac tbb-linkability in Legacy / Trac tbb-usability in Legacy / Trac type::enhancement in Legacy / Trac labels
Replying to mikeperry:
Once Proposal 171 is implemented (legacy/trac#1865 (moved)), Tor Browser should set the Proposal 171 SOCKS username to a function of the hostname in the referer header (possibly caching the first referer for subsequent link navigation).
The SOCKS password would be a better field for intra-application identity compartments, so that when Tor decides to shove two compartments into the same circuit, it can merge two compartments run by the same application together before it merges different applications' compartments (which could have different SOCKS usernames) together.
Trac:
Cc: N/A to g.koppen@jondos.deTrac:
Cc: g.koppen@jondos.de to g.koppen@jondos.de, proper@secure-mail.biz
Trac:
Parent: N/A to legacy/trac#5752 (moved)
Can we write this up a little more verbosely, and explain what isolation policy it's meant to provide?
If I understand you right, it would mean for every page I visit, everything embedded in that page, and all pages on the same site, and everything embedded in them, would be linkable, but if I visit a page on a different site, it would get a different circuit?
-
Replying to nickm:
Can we write this up a little more verbosely, and explain what isolation policy it's meant to provide?
You may like https://www.torproject.org/projects/torbrowser/design/#identifier-linkability
If I understand you right, it would mean for every page I visit, everything embedded in that page, and all pages on the same site, and everything embedded in them, would be linkable, but if I visit a page on a different site, it would get a different circuit?
I believe that's right. It's quite a jump from the old "isolate by time interval" design. Clearly an improvement -- if we can afford to do it.
-
Note that we'll also need to find some way to extract the referer even for users who disable referers/have arbitrary 3rd party addons that spoof them, especially if we want to stop those users from creating tons of circuits (legacy/trac#5708 (moved)).
-
Replying to arma:
Is "referer" really the best stand-in we have for "was launched from that tab"?
"Launched from that tab" is not the model we're going for. It's the model used by JonDos, but what we want is "Launched from the same url bar origin/navigation session" (aka privacy requirement 1 in the design doc). Referer actually does map to what we want for that.
Now, this model does get a little sticky with redirects. See https://trac.torproject.org/projects/tor/ticket/3600#comment:16 for my thoughts on that case.
Replying to mikeperry:
Replying to arma:
Is "referer" really the best stand-in we have for "was launched from that tab"?
"Launched from that tab" is not the model we're going for. It's the model used by JonDos, but what we want is "Launched from the same url bar origin/navigation session" (aka privacy requirement 1 in the design doc). Referer actually does map to what we want for that.
I think “launched from that tab/window” is a better model. It's easier to control, it doesn't require me to launch a second TBB if I want two separate sessions with the same website, ...
Now, this model does get a little sticky with redirects. See https://trac.torproject.org/projects/tor/ticket/3600#comment:16 for my thoughts on that case.
and it doesn't require me to know where those **** shortened links will take me, or remember which sites I have ‘visited’ or been redirected through since clicking ‘New Identity’ and flushing all of my currently-open tabs.
(Also, note that [ticket:3600#comment:16] is a more concise way to link to a comment on another ticket.
-
Replying to rransom:
Replying to mikeperry:
Replying to arma:
Is "referer" really the best stand-in we have for "was launched from that tab"?
"Launched from that tab" is not the model we're going for. It's the model used by JonDos, but what we want is "Launched from the same url bar origin/navigation session" (aka privacy requirement 1 in the design doc). Referer actually does map to what we want for that.
I think “launched from that tab/window” is a better model. It's easier to control, it doesn't require me to launch a second TBB if I want two separate sessions with the same website, ...
Try to virtualize the rest of humanity (or just your densest cousin) using a per-tab/window model after having been trained to use their browsers as single identity bags. Here, let me help you understand what it would be like:
"What do you mean, log in to google again? I just did that in this other tab." "OOps, I thought this tab was the OTHER gmail account..." "Oh, I though the fourth tab was twitter, not gmail. I guess I reordered them."
Express route to Fail City, imo. See also point 1 in https://www.torproject.org/projects/torbrowser/design/#philosophy
Now, this model does get a little sticky with redirects. See https://trac.torproject.org/projects/tor/ticket/3600#comment:16 for my thoughts on that case.
and it doesn't require me to know where those **** shortened links will take me, or remember which sites I have ‘visited’ or been redirected through since clicking ‘New Identity’ and flushing all of my currently-open tabs.
Except for other activity on that tab... There's no way humans can remember what each tab/window was used for what and be expected not to mess up, forget, and link themselves.
We need to design this stuff for normal humans, not mentats.
-
Replying to rransom:
And you think they would be better able to understand a barrage of ‘click OK to link your identity on one website to your identity on another website’ popups?
No. As is quite clear in [ticket:3600#comment:16], I am still conflicted on this being a good idea. But you're commenting in the wrong bug now, because redirects are an orthogonal problem to choosing tab isolation vs url origin isolation. They happen in both. If you have an opinion/better idea for handling redirects, please comment in legacy/trac#3600 (moved), not here.
Instead of going to the ControlPort to send a NEWNYM command, Torbutton could simply create a new SOCKS username each time the 'new identity button is pressed'. Stream isolation will make both have the same outcome.
This would also reduce some complexity in the TBB launching script, because they would be no need to pass environment variable around to get access to the ControlPort.
Trac:
Cc: g.koppen@jondos.de, proper@secure-mail.biz to g.koppen@jondos.de, proper@secure-mail.biz, lunar@debian.org