Re: [tor-dev] Tor Browser 4.5a5 will change circuit expiry to 2hrs

[s7r <s7r@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev