[tor-commits] [research-web/master] Move everything to htdocs/ subdirectory.
karsten at torproject.org
karsten at torproject.org
Tue Sep 4 19:52:17 UTC 2012
commit ee648b57069610a437c2d149dff802dd50fde4c4
Author: Karsten Loesing <karsten.loesing at gmx.net>
Date: Tue Sep 4 15:18:27 2012 -0400
Move everything to htdocs/ subdirectory.
We'll soon have scripts to automatically generate techreports.html from a
BibTeX file, and we don't the webserver to serve those scripts.
---
.gitignore | 2 +-
css/stylesheet-ltr.css | 161 ---------------------------
groups.html | 57 ----------
htdocs/css/stylesheet-ltr.css | 161 +++++++++++++++++++++++++++
htdocs/groups.html | 57 ++++++++++
htdocs/ideas.html | 116 +++++++++++++++++++
htdocs/images/favicon.ico | Bin 0 -> 1150 bytes
htdocs/images/top-left.png | Bin 0 -> 11039 bytes
htdocs/images/top-middle.png | Bin 0 -> 257 bytes
htdocs/images/top-right.png | Bin 0 -> 462 bytes
htdocs/index.html | 132 ++++++++++++++++++++++
htdocs/techreports.html | 246 +++++++++++++++++++++++++++++++++++++++++
ideas.html | 116 -------------------
images/favicon.ico | Bin 1150 -> 0 bytes
images/top-left.png | Bin 11039 -> 0 bytes
images/top-middle.png | Bin 257 -> 0 bytes
images/top-right.png | Bin 462 -> 0 bytes
index.html | 132 ----------------------
techreports.html | 246 -----------------------------------------
19 files changed, 713 insertions(+), 713 deletions(-)
diff --git a/.gitignore b/.gitignore
index b163bd2..9f9f5bf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,2 @@
-techreports/
+htdocs/techreports/*.pdf
diff --git a/css/stylesheet-ltr.css b/css/stylesheet-ltr.css
deleted file mode 100644
index ce0c54e..0000000
--- a/css/stylesheet-ltr.css
+++ /dev/null
@@ -1,161 +0,0 @@
-body {
- background-color: white;
- margin-top: 0px;
- font-family: Arial, Helvetica, sans-serif;
- font-size: 1em;
- font-style: normal;
- color: #000000;
- padding-top: 0px;
-}
-
-/* images */
-
-img {
- border: 0;
-}
-
-
-li {
- margin: .2em .2em .2em 1em;
-}
-
-/* this centers the page */
-
-.center {
- text-align: center;
- background-color: white;
- margin: 0px auto 0 auto;
- width: 85%;
-}
-
-.center table {
- margin-left: auto;
- margin-right: auto;
- text-align: left;
-}
-
-div.bottom {
- font-size: 0.8em;
- margin-top: 0.5cm;
- margin-left: 1em;
- margin-right: 1em;
- text-align: center;
-}
-
-/* The main column (left text) */
-
-div.main-column {
- padding: 15px 0 10px 10px;
- text-indent: 0pt;
- font-size: 1em;
- direction: ltr;
- text-align: left;
-}
-
-/* formatting styles */
-
-h2 {
- font-size: 1.4em;
- margin-bottom: 0em;
- font-weight: bold;
- margin-top: 0;
-}
-
-h3 {
- font-size: 1.2em;
- margin-bottom: 0em;
- font-weight: bold;
- margin-top: 0;
-}
-
-p {
- margin-top: 0;
- margin-bottom: 1em;
-}
-
-a:link {
- color: blue;
- font-size: 1em;
-}
-
-a:visited {
- color: purple;
- font-size: 1em;
-}
-
-a.anchor {
- font-size: 1em;
- color: black;
- font-weight: bold;
- text-decoration: none;
-}
-
-td {
- vertical-align: top;
-}
-
-/* the banner */
-
-table.banner {
- width: 100%;
- height: 79px;
- margin-left: auto;
- margin-right: auto;
-}
-
-td.banner-left {
- /* This is done with an <img> in the HTML so it can be clickable
- background-image: url("images/top-left.png");
- background-repeat: no-repeat; */
- width: 193px;
-}
-
-td.banner-middle {
- background-color: #00802B;
- background-image: url("/images/top-middle.png");
- background-repeat: repeat-x;
- vertical-align: bottom;
- padding-bottom: 10px;
- color: white;
- font-weight: bold;
- font-size: 1.2em;
-}
-
-td.banner-middle a, td.banner-middle a:visited {
- margin-right: 5px;
- color: white;
- font-weight: bold;
- font-size: 1em;
-}
-
-td.banner-middle a:hover {
- color: #FF7F00;
- font-weight: bold;
- font-size: 1em;
-}
-
-td.banner-right {
- background-image: url("/images/top-right.png");
- background-repeat: no-repeat;
- width: 15px;
- background-position: right;
- padding-top: 8px;
-}
-
-.banner-middle a.current {
- text-decoration: none;
- color: #FF7F00;
- font-weight: bold;
- font-size: 1em;
- width: auto;
- left: -50px;
-}
-
-hr {
- background-color:#002200;
- color:#666666;
- font-size:1px;
- height:1px;
- line-height:0;
- margin:15px 0 5px;
-}
diff --git a/groups.html b/groups.html
deleted file mode 100644
index a923d6d..0000000
--- a/groups.html
+++ /dev/null
@@ -1,57 +0,0 @@
-<html>
-<head>
-<title>Tor Research: Research Groups</title>
-<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
-<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet">
-<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon">
-</head>
-<body>
-
-<table class="banner" border="0" cellpadding="0" cellspacing="0" summary="">
-<tr>
- <td class="banner-left">
- <a href="index.html">
- <img src="/images/top-left.png" alt="Click to go to home page"
- width="193" height="79"></a></td>
- <td class="banner-middle">
- <a href="index.html">Home</a>
- Groups
- <a href="ideas.html">Ideas</a>
- <a href="techreports.html">Tech Reports</a>
- </td>
- <td class="banner-right"></td>
-</tr>
-</table>
-
-<div class="center">
-<div class="main-column">
-<h2>Research Groups</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>
-
-</div>
-</div>
-
-</body>
-</html>
-
diff --git a/htdocs/css/stylesheet-ltr.css b/htdocs/css/stylesheet-ltr.css
new file mode 100644
index 0000000..ce0c54e
--- /dev/null
+++ b/htdocs/css/stylesheet-ltr.css
@@ -0,0 +1,161 @@
+body {
+ background-color: white;
+ margin-top: 0px;
+ font-family: Arial, Helvetica, sans-serif;
+ font-size: 1em;
+ font-style: normal;
+ color: #000000;
+ padding-top: 0px;
+}
+
+/* images */
+
+img {
+ border: 0;
+}
+
+
+li {
+ margin: .2em .2em .2em 1em;
+}
+
+/* this centers the page */
+
+.center {
+ text-align: center;
+ background-color: white;
+ margin: 0px auto 0 auto;
+ width: 85%;
+}
+
+.center table {
+ margin-left: auto;
+ margin-right: auto;
+ text-align: left;
+}
+
+div.bottom {
+ font-size: 0.8em;
+ margin-top: 0.5cm;
+ margin-left: 1em;
+ margin-right: 1em;
+ text-align: center;
+}
+
+/* The main column (left text) */
+
+div.main-column {
+ padding: 15px 0 10px 10px;
+ text-indent: 0pt;
+ font-size: 1em;
+ direction: ltr;
+ text-align: left;
+}
+
+/* formatting styles */
+
+h2 {
+ font-size: 1.4em;
+ margin-bottom: 0em;
+ font-weight: bold;
+ margin-top: 0;
+}
+
+h3 {
+ font-size: 1.2em;
+ margin-bottom: 0em;
+ font-weight: bold;
+ margin-top: 0;
+}
+
+p {
+ margin-top: 0;
+ margin-bottom: 1em;
+}
+
+a:link {
+ color: blue;
+ font-size: 1em;
+}
+
+a:visited {
+ color: purple;
+ font-size: 1em;
+}
+
+a.anchor {
+ font-size: 1em;
+ color: black;
+ font-weight: bold;
+ text-decoration: none;
+}
+
+td {
+ vertical-align: top;
+}
+
+/* the banner */
+
+table.banner {
+ width: 100%;
+ height: 79px;
+ margin-left: auto;
+ margin-right: auto;
+}
+
+td.banner-left {
+ /* This is done with an <img> in the HTML so it can be clickable
+ background-image: url("images/top-left.png");
+ background-repeat: no-repeat; */
+ width: 193px;
+}
+
+td.banner-middle {
+ background-color: #00802B;
+ background-image: url("/images/top-middle.png");
+ background-repeat: repeat-x;
+ vertical-align: bottom;
+ padding-bottom: 10px;
+ color: white;
+ font-weight: bold;
+ font-size: 1.2em;
+}
+
+td.banner-middle a, td.banner-middle a:visited {
+ margin-right: 5px;
+ color: white;
+ font-weight: bold;
+ font-size: 1em;
+}
+
+td.banner-middle a:hover {
+ color: #FF7F00;
+ font-weight: bold;
+ font-size: 1em;
+}
+
+td.banner-right {
+ background-image: url("/images/top-right.png");
+ background-repeat: no-repeat;
+ width: 15px;
+ background-position: right;
+ padding-top: 8px;
+}
+
+.banner-middle a.current {
+ text-decoration: none;
+ color: #FF7F00;
+ font-weight: bold;
+ font-size: 1em;
+ width: auto;
+ left: -50px;
+}
+
+hr {
+ background-color:#002200;
+ color:#666666;
+ font-size:1px;
+ height:1px;
+ line-height:0;
+ margin:15px 0 5px;
+}
diff --git a/htdocs/groups.html b/htdocs/groups.html
new file mode 100644
index 0000000..a923d6d
--- /dev/null
+++ b/htdocs/groups.html
@@ -0,0 +1,57 @@
+<html>
+<head>
+<title>Tor Research: Research Groups</title>
+<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
+<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet">
+<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon">
+</head>
+<body>
+
+<table class="banner" border="0" cellpadding="0" cellspacing="0" summary="">
+<tr>
+ <td class="banner-left">
+ <a href="index.html">
+ <img src="/images/top-left.png" alt="Click to go to home page"
+ width="193" height="79"></a></td>
+ <td class="banner-middle">
+ <a href="index.html">Home</a>
+ Groups
+ <a href="ideas.html">Ideas</a>
+ <a href="techreports.html">Tech Reports</a>
+ </td>
+ <td class="banner-right"></td>
+</tr>
+</table>
+
+<div class="center">
+<div class="main-column">
+<h2>Research Groups</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>
+
+</div>
+</div>
+
+</body>
+</html>
+
diff --git a/htdocs/ideas.html b/htdocs/ideas.html
new file mode 100644
index 0000000..904ddaa
--- /dev/null
+++ b/htdocs/ideas.html
@@ -0,0 +1,116 @@
+<html>
+<head>
+<title>Tor Research: Research Ideas</title>
+<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
+<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet">
+<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon">
+</head>
+<body>
+
+<table class="banner" border="0" cellpadding="0" cellspacing="0" summary="">
+<tr>
+ <td class="banner-left">
+ <a href="index.html">
+ <img src="/images/top-left.png" alt="Click to go to home page"
+ width="193" height="79"></a></td>
+ <td class="banner-middle">
+ <a href="index.html">Home</a>
+ <a href="groups.html">Groups</a>
+ Ideas
+ <a href="techreports.html">Tech Reports</a>
+ </td>
+ <td class="banner-right"></td>
+</tr>
+</table>
+
+<div class="center">
+<div class="main-column">
+<h2>Research Ideas</h2>
+<br>
+
+<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>
+
+</body>
+</html>
+
diff --git a/htdocs/images/favicon.ico b/htdocs/images/favicon.ico
new file mode 100644
index 0000000..48060b1
Binary files /dev/null and b/htdocs/images/favicon.ico differ
diff --git a/htdocs/images/top-left.png b/htdocs/images/top-left.png
new file mode 100644
index 0000000..050adb4
Binary files /dev/null and b/htdocs/images/top-left.png differ
diff --git a/htdocs/images/top-middle.png b/htdocs/images/top-middle.png
new file mode 100644
index 0000000..fa612d8
Binary files /dev/null and b/htdocs/images/top-middle.png differ
diff --git a/htdocs/images/top-right.png b/htdocs/images/top-right.png
new file mode 100644
index 0000000..8eaa644
Binary files /dev/null and b/htdocs/images/top-right.png differ
diff --git a/htdocs/index.html b/htdocs/index.html
new file mode 100644
index 0000000..4f77d2a
--- /dev/null
+++ b/htdocs/index.html
@@ -0,0 +1,132 @@
+<html>
+<head>
+<title>Tor Research Home</title>
+<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
+<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet">
+<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon">
+</head>
+<body>
+
+<table class="banner" border="0" cellpadding="0" cellspacing="0" summary="">
+<tr>
+ <td class="banner-left">
+ <a href="index.html">
+ <img src="/images/top-left.png" alt="Click to go to home page"
+ width="193" height="79"></a></td>
+ <td class="banner-middle">
+ Home
+ <a href="groups.html">Groups</a>
+ <a href="ideas.html">Ideas</a>
+ <a href="techreports.html">Tech Reports</a>
+ </td>
+ <td class="banner-right"></td>
+</tr>
+</table>
+
+<div class="center">
+<div class="main-column">
+<h2>Tor Research Home</h2>
+<br>
+
+<p>Many people around the world are doing research on how to improve the
+Tor design, what's going on in the Tor network, and more generally on
+attacks and defenses for anonymous communication systems.
+This page summarizes the resources we provide to help make your Tor
+research more effective.
+The best way to reach us about research is through the
+<a href="mailto:tor-assistants at lists.torproject.org">tor-assistants</a>
+list.</p>
+
+<ul>
+
+<li>
+<b>Data.</b>
+We've been <a href="https://metrics.torproject.org/data.html">collecting
+data to learn more about the Tor network</a>: how many relays and
+clients there are in the network, what capabilities they have, how
+fast the network is, how many clients are connecting via bridges,
+what traffic exits the network, etc. We are also developing
+tools to process these huge data archives and come up with
+<a href="https://metrics.torproject.org/graphs.html">useful
+statistics</a>.
+Let us know what other information you'd like to
+see, and we can work with you to help make sure it gets collected
+<a href="papers/wecsr10.pdf">safely</a>
+and robustly.
+</li>
+
+<li>
+<b>Analysis.</b>
+If you're investigating Tor, or solving a Tor-related problem,
+<i>_please_</i> talk to us somewhere along the way — the earlier
+the better. These days we review too many conference paper submissions
+that make bad assumptions and end up solving the wrong problem. Since
+the Tor protocol and the Tor network are both moving targets, measuring
+things without understanding what's going on behind the scenes is going
+to result in bad conclusions. In particular, different groups often
+unwittingly run a variety of experiments in parallel, and at the same
+time we're constantly modifying the design to try new approaches. If
+you let us know what you're doing and what you're trying to learn,
+we can help you understand what other variables to expect and how to
+interpret your results.
+</li>
+
+<li>
+<b>Measurement and attack tools.</b>
+We're building a
+<a href="https://metrics.torproject.org/tools.html">repository</a> of tools
+that can be used to measure, analyze, or perform attacks on Tor. Many
+research groups end up needing to do similar measurements (for example,
+change the Tor design in some way and then see if latency improves),
+and we hope to help everybody standardize on a few tools and then make
+them really good. Also, while there are some really neat Tor attacks
+that people have published about, it's hard to track down a copy of
+the code they used. Let us know if you have new tools we should list,
+or improvements to the existing ones. The more the better, at this stage.
+</li>
+
+<li>
+<b>We need defenses too — not just attacks.</b>
+Most researchers find it easy and fun to come up with novel attacks on
+anonymity systems. We've seen this result lately in terms of improved
+congestion attacks, attacks based on remotely measuring latency or
+throughput, and so on. Knowing how things can go wrong is important,
+and we recognize that the incentives in academia aren't aligned with
+spending energy on designing defenses, but it sure would be great to
+get more attention to how to address the attacks. We'd love to help
+brainstorm about how to make Tor better. As a bonus, your paper might
+even end up with a stronger "countermeasures" section.
+</li>
+
+<li>
+<b>In-person help.</b>
+If you're doing interesting and important Tor research and need help
+understanding how the Tor network or design works, interpreting your
+data, crafting your experiments, etc, we can send a Tor researcher to
+your doorstep. As you might expect, we don't have a lot of free time;
+but making sure that research is done in a way that's useful to us is
+really important. So let us know, and we'll work something out.
+</li>
+
+</ul>
+
+<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>
+
+</div>
+</div>
+
+</body>
+</html>
+
diff --git a/htdocs/techreports.html b/htdocs/techreports.html
new file mode 100644
index 0000000..b249c33
--- /dev/null
+++ b/htdocs/techreports.html
@@ -0,0 +1,246 @@
+<html>
+<head>
+<title>Tor Tech Reports</title>
+<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
+<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet">
+<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon">
+</head>
+<body>
+
+<table class="banner" border="0" cellpadding="0" cellspacing="0" summary="">
+<tr>
+ <td class="banner-left">
+ <a href="index.html">
+ <img src="/images/top-left.png" alt="Click to go to home page"
+ width="193" height="79"></a></td>
+ <td class="banner-middle">
+ <a href="index.html">Home</a>
+ <a href="groups.html">Groups</a>
+ <a href="ideas.html">Ideas</a>
+ Tech Reports
+ </td>
+ <td class="banner-right"></td>
+</tr>
+</table>
+
+<div class="center">
+<div class="main-column">
+<h2>Tor Tech Reports</h2>
+<br>
+
+<h3>2012</h3>
+<br>
+
+<p>Jacob Appelbaum.
+<i>Tor and NAT devices: increasing bridge & relay reachability or,
+enabling the use of NAT-PMP and UPnP by default.</i>
+Tor Tech Report 2012-08-001.
+August 22, 2012.
+<a href="techreports/tor-nat-plan-2012-08-22.pdf">PDF</a>.</p>
+
+<p>Steven J. Murdoch and George Kadianakis.
+<i>Pluggable Transports Roadmap.</i>
+Tor Tech Report 2012-03-003.
+March 17, 2012.
+<a href="techreports/pluggable-roadmap-2012-03-17.pdf">PDF</a>.</p>
+
+<p>Steven J. Murdoch.
+<i>Datagram Testing Plan.</i>
+Tor Tech Report 2012-03-002.
+March 16, 2012.
+<a href="techreports/datagram-testing-plan-2012-03-16.pdf">PDF</a>.</p>
+
+<p>George Kadianakis.
+<i>Packet Size Pluggable Transport and Traffic Morphing.</i>
+Tor Tech Report 2012-03-004.
+March 13, 2012.
+<a href="techreports/morpher-2012-03-13.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>What if the Tor network had 50,000 bridges?</i>
+Tor Tech Report 2012-03-001.
+March 9, 2012.
+<a href="techreports/bridge-scaling-2012-03-09.pdf">PDF</a>.</p>
+
+<h3>2011</h3>
+<br>
+
+<p>Roger Dingledine.
+<i>Five ways to test bridge reachability.</i>
+Tor Tech Report 2011-12-001.
+December 1, 2011.
+<a href="techreports/five-ways-test-bridge-reachability-2011-12-01.pdf">PDF</a>.</p>
+
+<p>Sebastian Hahn.
+<i>Different Ways to Use a Bridge.</i>
+Tor Tech Report 2011-11-002.
+November 29, 2011.
+<a href="techreports/different-ways-use-bridge-2011-11-29.pdf">PDF</a>.</p>
+
+<p>Steven J. Murdoch.
+<i>Comparison of Tor Datagram Designs.</i>
+Tor Tech Report 2011-11-001.
+November 7, 2011.
+<a href="techreports/datagram-comparison-2011-11-07.pdf">PDF</a>.</p>
+
+<p>Roger Dingledine.
+<i>Ten ways to discover Tor bridges.</i>
+Tor Tech Report 2010-10-002.
+October 31, 2011.
+<a href="techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>An Analysis of Tor Bridge Stability—Making BridgeDB give out at
+least one stable bridge per user.</i>
+Tor Tech Report 2011-10-001.
+October 31, 2011.
+<a href="techreports/bridge-stability-2011-10-31.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>Case study: Learning whether a Tor bridge is blocked by looking at its
+aggregate usage statistics, Part one.</i>
+Tor Tech Report 2011-09-002.
+September 15, 2011.
+<a href="techreports/blocking-2011-09-15.pdf">PDF</a>.</p>
+
+<p>George Danezis.
+<i>An anomaly-based censorship-detection system for Tor.</i>
+Tor Tech Report 2011-09-001.
+September 9, 2011.
+<a href="techreports/detector-2011-09-09.pdf">PDF</a>.</p>
+
+<p>Roger Dingledine.
+<i>Better guard rotation parameters.</i>
+Tor Tech Report 2011-08-001.
+August 20, 2011.
+<a href="techreports/better-guard-rotation-parameters-2011-08-20.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>An Analysis of Tor Relay Stability.</i>
+Tor Tech Report 2011-06-001.
+June 30, 2011.
+<a href="techreports/relay-stability-2011-06-30.pdf">PDF</a>.</p>
+
+<p>Roger Dingledine.
+<i>Strategies for getting more bridges.</i>
+Tor Tech Report 2011-05-001.
+May 13, 2011.
+<a href="techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>Overview of Statistical Data in the Tor Network.</i>
+Tor Tech Report 2011-03-001.
+March 14, 2011.
+<a href="techreports/data-2011-03-14.pdf">PDF</a>.</p>
+
+<p>Roger Dingledine.
+<i>Measuring the safety of the Tor network.</i>
+Tor Tech Report 2011-02-001.
+February 5, 2011.
+<a href="techreports/measuring-safety-tor-network-2011-02-001.pdf">PDF</a>.</p>
+
+<h3>2010</h3>
+<br>
+
+<p>Karsten Loesing.
+<i>Privacy-preserving Ways to Estimate the Number of Tor Users.</i>
+Tor Tech Report 2010-11-001.
+November 30, 2010.
+<a href="techreports/countingusers-2010-11-30.pdf">PDF</a>.</p>
+
+<p>Roger Dingledine.
+<i>Adaptive throttling of Tor clients by entry guards.</i>
+Tor Tech Report 2010-09-001.
+September 19, 2010.
+<a href="techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf">PDF</a>.</p>
+
+<h3>2009</h3>
+<br>
+
+<p>Roger Dingledine and Steven J. Murdoch.
+<i>Performance Improvements on Tor or, Why Tor is slow and what we're
+going to do about it.</i>
+Tor Tech Report 2009-11-001.
+November 9, 2009.
+<a href="techreports/performance-2009-11-09.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>Comparison of GeoIP Databases for Tor.</i>
+Tor Tech Report 2009-10-001.
+October 23, 2009.
+<a href="techreports/geoipdbcomp-2009-10-23.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>Performance of Requests over the Tor Network.</i>
+Tor Tech Report 2009-09-001.
+September 22, 2009.
+<a href="techreports/torperf-2009-09-22.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>Reducing the Circuit Window Size in Tor.</i>
+Tor Tech Report 2009-09-002.
+September 20, 2009.
+<a href="techreports/circwindow-2009-09-20.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>Analysis of Circuit Queues in Tor.</i>
+Tor Tech Report 2009-08-001.
+August 25, 2009.
+<a href="techreports/bufferstats-2009-08-25.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>Measuring the Tor Network, Evaluation of Client Requests to the
+Directories to determine total numbers and countries of users.</i>
+Tor Tech Report 2009-06-002.
+June 25, 2009.
+<a href="techreports/directory-requests-2009-06-25.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>Analysis of Bridge Usage in Tor.</i>
+Tor Tech Report 2009-06-003.
+June 22, 2009.
+<a href="techreports/bridges-2009-06-22.pdf">PDF</a>.</p>
+
+<p>Karsten Loesing.
+<i>Measuring the Tor Network, Evaluation of Relays from Public Directory
+Data.</i>
+Tor Tech Report 2009-06-001.
+June 22, 2009.
+<a href="techreports/dirarch-2009-06-22.pdf">PDF</a>.</p>
+
+<p>Sebastian Hahn, Karsten Loesing, and Steven J. Murdoch.
+<i>Measuring the Tor Network, Simulation of the number of Fast, Stable,
+and Guard flags for changed requirements.</i>
+Tor Tech Report 2009-04-001.
+April 11, 2009.
+<a href="techreports/flagrequirements-2009-04-11.pdf">PDF</a>.</p>
+
+<p>Roger Dingledine.
+<i>Overhead from directory info: past, present, future.</i>
+Tor Tech Report 2009-02-001.
+February 16, 2009.
+<a href="techreports/overhead-directory-info-2009-02-16.pdf">PDF</a>.</p>
+
+<h3>2006</h3>
+<br>
+
+<p>Roger Dingledine and Nick Mathewson.
+<i>Design of a blocking-resistant anonymity system.</i>
+Tor Tech Report 2006-11-001.
+November 2006.
+<a href="techreports/blocking-2006-11.pdf">PDF</a>.</p>
+
+<h3>2005</h3>
+<br>
+
+<p>Roger Dingledine, Nick Mathewson, and Paul Syverson.
+<i>Challenges in deploying low-latency anonymity.</i>
+Tor Tech Report 2005-02-001.
+February 2005.
+<a href="techreports/challenges-2005-02.pdf">PDF</a>.</p>
+
+</div>
+</div>
+</body>
+</html>
+
diff --git a/ideas.html b/ideas.html
deleted file mode 100644
index 904ddaa..0000000
--- a/ideas.html
+++ /dev/null
@@ -1,116 +0,0 @@
-<html>
-<head>
-<title>Tor Research: Research Ideas</title>
-<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
-<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet">
-<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon">
-</head>
-<body>
-
-<table class="banner" border="0" cellpadding="0" cellspacing="0" summary="">
-<tr>
- <td class="banner-left">
- <a href="index.html">
- <img src="/images/top-left.png" alt="Click to go to home page"
- width="193" height="79"></a></td>
- <td class="banner-middle">
- <a href="index.html">Home</a>
- <a href="groups.html">Groups</a>
- Ideas
- <a href="techreports.html">Tech Reports</a>
- </td>
- <td class="banner-right"></td>
-</tr>
-</table>
-
-<div class="center">
-<div class="main-column">
-<h2>Research Ideas</h2>
-<br>
-
-<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>
-
-</body>
-</html>
-
diff --git a/images/favicon.ico b/images/favicon.ico
deleted file mode 100644
index 48060b1..0000000
Binary files a/images/favicon.ico and /dev/null differ
diff --git a/images/top-left.png b/images/top-left.png
deleted file mode 100644
index 050adb4..0000000
Binary files a/images/top-left.png and /dev/null differ
diff --git a/images/top-middle.png b/images/top-middle.png
deleted file mode 100644
index fa612d8..0000000
Binary files a/images/top-middle.png and /dev/null differ
diff --git a/images/top-right.png b/images/top-right.png
deleted file mode 100644
index 8eaa644..0000000
Binary files a/images/top-right.png and /dev/null differ
diff --git a/index.html b/index.html
deleted file mode 100644
index 4f77d2a..0000000
--- a/index.html
+++ /dev/null
@@ -1,132 +0,0 @@
-<html>
-<head>
-<title>Tor Research Home</title>
-<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
-<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet">
-<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon">
-</head>
-<body>
-
-<table class="banner" border="0" cellpadding="0" cellspacing="0" summary="">
-<tr>
- <td class="banner-left">
- <a href="index.html">
- <img src="/images/top-left.png" alt="Click to go to home page"
- width="193" height="79"></a></td>
- <td class="banner-middle">
- Home
- <a href="groups.html">Groups</a>
- <a href="ideas.html">Ideas</a>
- <a href="techreports.html">Tech Reports</a>
- </td>
- <td class="banner-right"></td>
-</tr>
-</table>
-
-<div class="center">
-<div class="main-column">
-<h2>Tor Research Home</h2>
-<br>
-
-<p>Many people around the world are doing research on how to improve the
-Tor design, what's going on in the Tor network, and more generally on
-attacks and defenses for anonymous communication systems.
-This page summarizes the resources we provide to help make your Tor
-research more effective.
-The best way to reach us about research is through the
-<a href="mailto:tor-assistants at lists.torproject.org">tor-assistants</a>
-list.</p>
-
-<ul>
-
-<li>
-<b>Data.</b>
-We've been <a href="https://metrics.torproject.org/data.html">collecting
-data to learn more about the Tor network</a>: how many relays and
-clients there are in the network, what capabilities they have, how
-fast the network is, how many clients are connecting via bridges,
-what traffic exits the network, etc. We are also developing
-tools to process these huge data archives and come up with
-<a href="https://metrics.torproject.org/graphs.html">useful
-statistics</a>.
-Let us know what other information you'd like to
-see, and we can work with you to help make sure it gets collected
-<a href="papers/wecsr10.pdf">safely</a>
-and robustly.
-</li>
-
-<li>
-<b>Analysis.</b>
-If you're investigating Tor, or solving a Tor-related problem,
-<i>_please_</i> talk to us somewhere along the way — the earlier
-the better. These days we review too many conference paper submissions
-that make bad assumptions and end up solving the wrong problem. Since
-the Tor protocol and the Tor network are both moving targets, measuring
-things without understanding what's going on behind the scenes is going
-to result in bad conclusions. In particular, different groups often
-unwittingly run a variety of experiments in parallel, and at the same
-time we're constantly modifying the design to try new approaches. If
-you let us know what you're doing and what you're trying to learn,
-we can help you understand what other variables to expect and how to
-interpret your results.
-</li>
-
-<li>
-<b>Measurement and attack tools.</b>
-We're building a
-<a href="https://metrics.torproject.org/tools.html">repository</a> of tools
-that can be used to measure, analyze, or perform attacks on Tor. Many
-research groups end up needing to do similar measurements (for example,
-change the Tor design in some way and then see if latency improves),
-and we hope to help everybody standardize on a few tools and then make
-them really good. Also, while there are some really neat Tor attacks
-that people have published about, it's hard to track down a copy of
-the code they used. Let us know if you have new tools we should list,
-or improvements to the existing ones. The more the better, at this stage.
-</li>
-
-<li>
-<b>We need defenses too — not just attacks.</b>
-Most researchers find it easy and fun to come up with novel attacks on
-anonymity systems. We've seen this result lately in terms of improved
-congestion attacks, attacks based on remotely measuring latency or
-throughput, and so on. Knowing how things can go wrong is important,
-and we recognize that the incentives in academia aren't aligned with
-spending energy on designing defenses, but it sure would be great to
-get more attention to how to address the attacks. We'd love to help
-brainstorm about how to make Tor better. As a bonus, your paper might
-even end up with a stronger "countermeasures" section.
-</li>
-
-<li>
-<b>In-person help.</b>
-If you're doing interesting and important Tor research and need help
-understanding how the Tor network or design works, interpreting your
-data, crafting your experiments, etc, we can send a Tor researcher to
-your doorstep. As you might expect, we don't have a lot of free time;
-but making sure that research is done in a way that's useful to us is
-really important. So let us know, and we'll work something out.
-</li>
-
-</ul>
-
-<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>
-
-</div>
-</div>
-
-</body>
-</html>
-
diff --git a/techreports.html b/techreports.html
deleted file mode 100644
index b249c33..0000000
--- a/techreports.html
+++ /dev/null
@@ -1,246 +0,0 @@
-<html>
-<head>
-<title>Tor Tech Reports</title>
-<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
-<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet">
-<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon">
-</head>
-<body>
-
-<table class="banner" border="0" cellpadding="0" cellspacing="0" summary="">
-<tr>
- <td class="banner-left">
- <a href="index.html">
- <img src="/images/top-left.png" alt="Click to go to home page"
- width="193" height="79"></a></td>
- <td class="banner-middle">
- <a href="index.html">Home</a>
- <a href="groups.html">Groups</a>
- <a href="ideas.html">Ideas</a>
- Tech Reports
- </td>
- <td class="banner-right"></td>
-</tr>
-</table>
-
-<div class="center">
-<div class="main-column">
-<h2>Tor Tech Reports</h2>
-<br>
-
-<h3>2012</h3>
-<br>
-
-<p>Jacob Appelbaum.
-<i>Tor and NAT devices: increasing bridge & relay reachability or,
-enabling the use of NAT-PMP and UPnP by default.</i>
-Tor Tech Report 2012-08-001.
-August 22, 2012.
-<a href="techreports/tor-nat-plan-2012-08-22.pdf">PDF</a>.</p>
-
-<p>Steven J. Murdoch and George Kadianakis.
-<i>Pluggable Transports Roadmap.</i>
-Tor Tech Report 2012-03-003.
-March 17, 2012.
-<a href="techreports/pluggable-roadmap-2012-03-17.pdf">PDF</a>.</p>
-
-<p>Steven J. Murdoch.
-<i>Datagram Testing Plan.</i>
-Tor Tech Report 2012-03-002.
-March 16, 2012.
-<a href="techreports/datagram-testing-plan-2012-03-16.pdf">PDF</a>.</p>
-
-<p>George Kadianakis.
-<i>Packet Size Pluggable Transport and Traffic Morphing.</i>
-Tor Tech Report 2012-03-004.
-March 13, 2012.
-<a href="techreports/morpher-2012-03-13.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>What if the Tor network had 50,000 bridges?</i>
-Tor Tech Report 2012-03-001.
-March 9, 2012.
-<a href="techreports/bridge-scaling-2012-03-09.pdf">PDF</a>.</p>
-
-<h3>2011</h3>
-<br>
-
-<p>Roger Dingledine.
-<i>Five ways to test bridge reachability.</i>
-Tor Tech Report 2011-12-001.
-December 1, 2011.
-<a href="techreports/five-ways-test-bridge-reachability-2011-12-01.pdf">PDF</a>.</p>
-
-<p>Sebastian Hahn.
-<i>Different Ways to Use a Bridge.</i>
-Tor Tech Report 2011-11-002.
-November 29, 2011.
-<a href="techreports/different-ways-use-bridge-2011-11-29.pdf">PDF</a>.</p>
-
-<p>Steven J. Murdoch.
-<i>Comparison of Tor Datagram Designs.</i>
-Tor Tech Report 2011-11-001.
-November 7, 2011.
-<a href="techreports/datagram-comparison-2011-11-07.pdf">PDF</a>.</p>
-
-<p>Roger Dingledine.
-<i>Ten ways to discover Tor bridges.</i>
-Tor Tech Report 2010-10-002.
-October 31, 2011.
-<a href="techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>An Analysis of Tor Bridge Stability—Making BridgeDB give out at
-least one stable bridge per user.</i>
-Tor Tech Report 2011-10-001.
-October 31, 2011.
-<a href="techreports/bridge-stability-2011-10-31.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>Case study: Learning whether a Tor bridge is blocked by looking at its
-aggregate usage statistics, Part one.</i>
-Tor Tech Report 2011-09-002.
-September 15, 2011.
-<a href="techreports/blocking-2011-09-15.pdf">PDF</a>.</p>
-
-<p>George Danezis.
-<i>An anomaly-based censorship-detection system for Tor.</i>
-Tor Tech Report 2011-09-001.
-September 9, 2011.
-<a href="techreports/detector-2011-09-09.pdf">PDF</a>.</p>
-
-<p>Roger Dingledine.
-<i>Better guard rotation parameters.</i>
-Tor Tech Report 2011-08-001.
-August 20, 2011.
-<a href="techreports/better-guard-rotation-parameters-2011-08-20.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>An Analysis of Tor Relay Stability.</i>
-Tor Tech Report 2011-06-001.
-June 30, 2011.
-<a href="techreports/relay-stability-2011-06-30.pdf">PDF</a>.</p>
-
-<p>Roger Dingledine.
-<i>Strategies for getting more bridges.</i>
-Tor Tech Report 2011-05-001.
-May 13, 2011.
-<a href="techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>Overview of Statistical Data in the Tor Network.</i>
-Tor Tech Report 2011-03-001.
-March 14, 2011.
-<a href="techreports/data-2011-03-14.pdf">PDF</a>.</p>
-
-<p>Roger Dingledine.
-<i>Measuring the safety of the Tor network.</i>
-Tor Tech Report 2011-02-001.
-February 5, 2011.
-<a href="techreports/measuring-safety-tor-network-2011-02-001.pdf">PDF</a>.</p>
-
-<h3>2010</h3>
-<br>
-
-<p>Karsten Loesing.
-<i>Privacy-preserving Ways to Estimate the Number of Tor Users.</i>
-Tor Tech Report 2010-11-001.
-November 30, 2010.
-<a href="techreports/countingusers-2010-11-30.pdf">PDF</a>.</p>
-
-<p>Roger Dingledine.
-<i>Adaptive throttling of Tor clients by entry guards.</i>
-Tor Tech Report 2010-09-001.
-September 19, 2010.
-<a href="techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf">PDF</a>.</p>
-
-<h3>2009</h3>
-<br>
-
-<p>Roger Dingledine and Steven J. Murdoch.
-<i>Performance Improvements on Tor or, Why Tor is slow and what we're
-going to do about it.</i>
-Tor Tech Report 2009-11-001.
-November 9, 2009.
-<a href="techreports/performance-2009-11-09.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>Comparison of GeoIP Databases for Tor.</i>
-Tor Tech Report 2009-10-001.
-October 23, 2009.
-<a href="techreports/geoipdbcomp-2009-10-23.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>Performance of Requests over the Tor Network.</i>
-Tor Tech Report 2009-09-001.
-September 22, 2009.
-<a href="techreports/torperf-2009-09-22.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>Reducing the Circuit Window Size in Tor.</i>
-Tor Tech Report 2009-09-002.
-September 20, 2009.
-<a href="techreports/circwindow-2009-09-20.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>Analysis of Circuit Queues in Tor.</i>
-Tor Tech Report 2009-08-001.
-August 25, 2009.
-<a href="techreports/bufferstats-2009-08-25.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>Measuring the Tor Network, Evaluation of Client Requests to the
-Directories to determine total numbers and countries of users.</i>
-Tor Tech Report 2009-06-002.
-June 25, 2009.
-<a href="techreports/directory-requests-2009-06-25.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>Analysis of Bridge Usage in Tor.</i>
-Tor Tech Report 2009-06-003.
-June 22, 2009.
-<a href="techreports/bridges-2009-06-22.pdf">PDF</a>.</p>
-
-<p>Karsten Loesing.
-<i>Measuring the Tor Network, Evaluation of Relays from Public Directory
-Data.</i>
-Tor Tech Report 2009-06-001.
-June 22, 2009.
-<a href="techreports/dirarch-2009-06-22.pdf">PDF</a>.</p>
-
-<p>Sebastian Hahn, Karsten Loesing, and Steven J. Murdoch.
-<i>Measuring the Tor Network, Simulation of the number of Fast, Stable,
-and Guard flags for changed requirements.</i>
-Tor Tech Report 2009-04-001.
-April 11, 2009.
-<a href="techreports/flagrequirements-2009-04-11.pdf">PDF</a>.</p>
-
-<p>Roger Dingledine.
-<i>Overhead from directory info: past, present, future.</i>
-Tor Tech Report 2009-02-001.
-February 16, 2009.
-<a href="techreports/overhead-directory-info-2009-02-16.pdf">PDF</a>.</p>
-
-<h3>2006</h3>
-<br>
-
-<p>Roger Dingledine and Nick Mathewson.
-<i>Design of a blocking-resistant anonymity system.</i>
-Tor Tech Report 2006-11-001.
-November 2006.
-<a href="techreports/blocking-2006-11.pdf">PDF</a>.</p>
-
-<h3>2005</h3>
-<br>
-
-<p>Roger Dingledine, Nick Mathewson, and Paul Syverson.
-<i>Challenges in deploying low-latency anonymity.</i>
-Tor Tech Report 2005-02-001.
-February 2005.
-<a href="techreports/challenges-2005-02.pdf">PDF</a>.</p>
-
-</div>
-</div>
-</body>
-</html>
-
More information about the tor-commits
mailing list