[or-cvs] r23685: {website} replay r23271, since it got lost in the move (website/trunk/getinvolved/en)

[Roger Dingledine]

Author: arma
Date: 2010-10-27 10:19:37 +0000 (Wed, 27 Oct 2010)
New Revision: 23685

Modified:
   website/trunk/getinvolved/en/volunteer.wml
Log:
replay r23271, since it got lost in the move


Modified: website/trunk/getinvolved/en/volunteer.wml
===================================================================
--- website/trunk/getinvolved/en/volunteer.wml	2010-10-27 10:15:25 UTC (rev 23684)
+++ website/trunk/getinvolved/en/volunteer.wml	2010-10-27 10:19:37 UTC (rev 23685)
@@ -1033,19 +1033,6 @@
     by their rotating UserAgents; malicious websites who only attack certain
     browsers; and whether the answers to question one impact this answer.
     </li>
-    <li>Right now Tor clients are willing to reuse a given circuit for ten
-    minutes after it's first used. The goal is to avoid loading down the
-    network with too many circuit extend operations, yet to also avoid having
-    clients use the same circuit for so long that the exit node can build a
-    useful pseudonymous profile of them. Alas, ten minutes is probably way
-    too long, especially if connections from multiple protocols (e.g. IM and
-    web browsing) are put on the same circuit. If we keep fixed the overall
-    number of circuit extends that the network needs to do, are there more
-    efficient and/or safer ways for clients to allocate streams to circuits,
-    or for clients to build preemptive circuits? Perhaps this research item
-    needs to start with gathering some traces of what connections typical
-    clients try to launch, so you have something realistic to try to optimize.
-    </li>
     <li>How many bridge relays do you need to know to maintain
     reachability? We should measure the churn in our bridges. If there is
     lots of churn, are there ways to keep bridge users more likely to stay