On 3/28/2015 4:34 AM, A. Johnson wrote:
Would you still set a max lifetime for a circuit to accept new streams of 2 hours, or would the circuit potentially persist forever?
Nick set a max lifetime in his updated version of the patch that also deals with non-Tor Browser activity, but I am not convinced that a max is a great idea yet. He also randomized the per-circuit max from [0,max], which seemed not great for usability.
Regardless of whether you use a maximum, I think it is an obvious improvement to randomize the “typical” circuit switch time (use a new randomly-selected time with each new circuit). A deterministic time makes it possible to predict when a client should switch circuits and thereby facilitates tracking. This is a recommendation from Hutha and Danezis’s “Linking Tor Circuits” (Sec. 5.3) [0].
Indeed, that is a paper I have marked as interesting and more interesting is Paul Syverson's mitigation solution:
https://lists.torproject.org/pipermail/tor-dev/2014-September/007518.html
This should be implemented everywhere, not just in Tor Browser. So far we didn't research how much additional load such a change will put on the network.
In fact, I think it would be great for TorBrowser to treat each tab/window as a separate identity and send *all* streams in a given tab/window over the same path (i.e. sequence of relays).
The 4.5 series of Tor Browser actually already does a form of this, but instead of per tab, we do per URL bar domain. If you have two tabs open to Facebook, all of those content elements will use the same circuit, but Facebook like buttons on cnn.com will use the cnn.com circuit.
In addition to being a more sane way of handling web browsing, it also enables a very simple circuit status UI. The Torbutton menu now tells you the current circuit for the site in the URL bar in a compact display that is no larger than the dropdown menu itself.
Interesting - I did not know this! An adversarial destinations could still observe new circuits by including resources from other domains that he controls, which would be prevented by per-tab circuits, but this does seem like very good feature.
Cheers, Aaron
per-tab circuits would help in other aspects too.
Take for example the providers who offer multiple different services (hosted on their subdomains) for the same user account. Simple example, google: fist you have to login on accounts.google.com, you are then redirected to mail.google.com and you can also access drive.google.com. maps, calendar, etc. At this moment TBB 4.5a4 will use different circuits for each, regardless all pages are opened in the same tab. At current moment it works, you are not logged out but some providers to kill the session if the IP address changes during the session. Of course such circuits can also be linked.
What if all pages opened in a tab would use the same circuit, and if other new links will be opened in a new tab but request came from a previously opened tab (Open link in new tab clicked by client or target="_blank" on link source or other way to open links from a page in a new browser tab) would use the same circuit as the initial tab, where the request came from? This could be useful.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev