[tor-commits] [research-web/master] move the pets and anonbib references to the frontpage

[arma at torproject.org]

commit d8eaa70279e380d73d0150c06dbc2b33e96f3810
Author: Roger Dingledine <arma at torproject.org>
Date:   Mon Aug 13 03:28:48 2012 -0400

    move the pets and anonbib references to the frontpage
    
    and remove the redundant text too
---
 ideas.html |   14 --------
 index.html |  109 ------------------------------------------------------------
 2 files changed, 0 insertions(+), 123 deletions(-)

diff --git a/ideas.html b/ideas.html
index 7947755..fd5fbe6 100644
--- a/ideas.html
+++ b/ideas.html
@@ -28,20 +28,6 @@
 <h2>Research Ideas</h2>
 <br>
 
-<p>
-If you're interested in anonymity research, you must make it to the
-<a href="http://petsymposium.org/">Privacy Enhancing Technologies
-Symposium</a>. Everybody who's anybody in the anonymity research world
-will be there. Stipends are generally available for people whose presence
-will benefit the community.
-</p>
-
-<p>To get up to speed on anonymity research, read <a
-href="http://freehaven.net/anonbib/">these papers</a> (especially the
-ones in boxes).
-We also keep a list of <a href="techreports.html">Tor Tech Reports</a>
-that are (co-)authored by Tor developers.</p>
-
 <p>We need people to attack the system, quantify defenses,
 etc. Here are some example projects:</p>
 
diff --git a/index.html b/index.html
index 450824c..cc48583 100644
--- a/index.html
+++ b/index.html
@@ -110,35 +110,6 @@ really important. So let us know, and we'll work something out.
 
 </ul>
 
-<a id="Groups"></a>
-<h2><a class="anchor" href="#Groups">Research Groups</a></h2>
-<br>
-
-<p>Interested to find other anonymity researchers? Here are some
-research groups you should take a look at.</p>
-
-<ul>
-<li>Ian Goldberg's <a href="http://crysp.uwaterloo.ca/">CrySP</a> group
-at Waterloo.
-</li>
-<li><a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>'s
-group at UMN.
-</li>
-<li><a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>'s
-group at Illinois.
-</li>
-<li>Micah Sherr's <a href="https://security.cs.georgetown.edu/">SecLab</a>
-group at Georgetown.
-</li>
-<li>Matt Wright's <a href="http://isec.uta.edu/">iSec</a> group at
-UTA.
-</li>
-</ul>
-
-<a id="Ideas"></a>
-<h2><a class="anchor" href="#Ideas">Research Ideas</a></h2>
-<br>
-
 <p>
 If you're interested in anonymity research, you must make it to the
 <a href="http://petsymposium.org/">Privacy Enhancing Technologies
@@ -153,86 +124,6 @@ ones in boxes).
 We also keep a list of <a href="techreports.html">Tor Tech Reports</a>
 that are (co-)authored by Tor developers.</p>
 
-<p>We need people to attack the system, quantify defenses,
-etc. Here are some example projects:</p>
-
-<ul>
-
-<li>What algorithm should we use to assign Guard flags such that a)
-we assign the flag to as many relays as possible, yet b) we minimize
-the chance that Alice will use an attacker's node as a guard? See the
-<a href="https://blog.torproject.org/research-problem-better-guard-rotation-parameters">blog
-post</a> for details.
-</li>
-
-<li>For various diversity metrics, how has the diversity of
-the Tor network changed over time? How robust is it to change or
-attack? These results can help us make better design decisions. See the <a
-href="https://blog.torproject.org/research-problem-measuring-safety-tor-network">blog post</a>
-for details.
-</li>
-
-<li>If we prevent the really loud users from using too much of the Tor
-network, how much can it help? We've instrumented Tor's entry relays
-so they can rate-limit connections from users, and we've instrumented
-the directory authorities so they can change the rate-limiting
-parameters globally across the network. Which parameter values improve
-performance for the Tor network as a whole? How should relays adapt
-their rate-limiting parameters based on their capacity and based on
-the network load they see, and what rate-limiting algorithms will work
-best? See the <a
-href="https://blog.torproject.org/research-problem-adaptive-throttling-tor-clients-entry-guards">blog
-post</a> for details.
-</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 creations, 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 requests typical
-clients try to launch, so you have something realistic to try to optimize.
-</li>
-
-<li>The "website fingerprinting attack": make a list of a few
-hundred popular websites, download their pages, and make a set of
-"signatures" for each site. Then observe a Tor client's traffic. As
-you watch him receive data, you quickly approach a guess about which
-(if any) of those sites he is visiting. First, how effective is
-this attack on the deployed Tor design? The problem with all the
-previous attack papers is that they look at timing and counting of
-IP packets on the wire. But OpenSSL's TLS records, plus Tor's use of
-TCP pushback to do rate limiting, means that tracing by IP packets
-produces very poor results. The right approach is to realize that
-Tor uses OpenSSL, look inside the TLS record at the TLS headers, and
-figure out how many 512-byte cells are being sent or received. Then
-start exploring defenses: for example, we could change Tor's cell
-size from 512 bytes to 1024 bytes, we could employ padding techniques
-like <a href="http://freehaven.net/anonbib/#timing-fc2004">defensive
-dropping</a>, or we could add traffic delays. How much of an impact do
-these have, and how much usability impact (using some suitable metric)
-is there from a successful defense in each case?</li>
-
-<!--
-<li>
-Path selection algorithms, directory fetching schedules for Tor-on-mobile
-that are compatible anonymity-wise with our current approaches.
-</li>
-
--->
-
-<li>More coming soon. See also the "Research" section of the <a
-href="https://www.torproject.org/getinvolved/volunteer.html.en#Research">volunteer</a> page for
-other topics.
-</li>
-
-</ul>
-
 </div>
 </div>