[tor-bugs] #5708 [Tor Client]: Don't make too many circuits once we're separating streams by domain

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Mon May 7 18:12:49 UTC 2012


#5708: Don't make too many circuits once we're separating streams by domain
------------------------+---------------------------------------------------
 Reporter:  arma        |          Owner:       
     Type:  task        |         Status:  new  
 Priority:  normal      |      Milestone:       
Component:  Tor Client  |        Version:       
 Keywords:              |         Parent:  #5752
   Points:              |   Actualpoints:       
------------------------+---------------------------------------------------
Changes (by gk):

 * cc: g.koppen@… (added)


Comment:

 Replying to [comment:9 mikeperry]:
 > Replying to [comment:4 Sebastian]:
 > > Replying to [comment:2 mikeperry]:
 > > > I'm also not really too worried about the CPU load of this over
 auto-expiry, especially if we just remove auto-expiry when we deploy it.
 Users tend to only open a few websites at a time.
 > >
 > > I'm not sure I buy that with the amount of third-party stuff that a
 lot of websites contain
 >
 > That's because you didn't read #3455. It describes how Tor Browser is
 going to use the feature. Third party elements (user link-click
 navigation) would all share the same circuit, because they all share
 referers.

 What about DOS attacks like a folder with _lots_ of bookmarks + right-
 click on it and "Open all in Tabs"?

 > However, I'll add a note in #3455 that we'll need to still force this
 binding if users somehow disable referers.. That's going to be a pain,
 though, because there are lots of ways referers can get spoofed/disabled
 by wacky third party addons...

 I am wondering whether you would still get the internal referer and could
 use that somehow: http://stackoverflow.com/questions/7471192/how-do-i
 -reliably-find-a-requests-referrer-in-a-firefox-addon
 Btw: Do not forget requests that have no referer per definition like
 safebrowsing requests. The latter might not be a problem as they do not
 happen very often. But what about requests done by the favicon service?
 Don't they matter either?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5708#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list