Browse code

Remove getinvolved/research which has moved to research.torproject.org

Karsten Loesing authored on20/08/2012 09:23:26
Showing2 changed files
1 1
deleted file mode 100644
... ...
@@ -1,226 +0,0 @@
1
-## translation metadata
2
-# Revision: $Revision$
3
-# Translation-Priority: 4-optional
4
-
5
-#include "head.wmi" TITLE="Tor: Research" CHARSET="UTF-8"
6
-<div id="content" class="clearfix">
7
-  <div id="breadcrumbs">
8
-    <a href="<page index>">Home &raquo; </a>
9
-    <a href="<page getinvolved/research>">Research</a>
10
-  </div>
11
-  <div id="maincol">
12
-    <!-- PUT CONTENT AFTER THIS TAG -->
13
-<h2>Tor: Research</h2>
14
-<hr />
15
-
16
-<p>
17
-Many people around the world are doing research on how to improve the Tor
18
-design, what's going on in the Tor network, and more generally on attacks
19
-and defenses for anonymous communication systems. This page summarizes
20
-the resources we provide to help make your Tor research more effective.
21
-The best way to reach us about research is through the <a href="<page
22
-about/contact>">tor-assistants</a> list.
23
-</p>
24
-
25
-<ul>
26
-
27
-<li>
28
-<b>Data.</b>
29
-We've been <a href="https://metrics.torproject.org/data.html">collecting
30
-data to learn more about the Tor network</a>: how many relays and
31
-clients there are in the network, what capabilities they have, how
32
-fast the network is, how many clients are connecting via bridges,
33
-what traffic exits the network, etc. We are also developing
34
-tools to process these huge data archives and come up with
35
-<a href="https://metrics.torproject.org/graphs.html">useful
36
-statistics</a>. Let us know what other information you'd like to
37
-see, and we can work with you to help make sure it gets collected
38
-<a href="https://metrics.torproject.org/papers/wecsr10.pdf">safely</a>
39
-and robustly.
40
-</li>
41
-
42
-<li>
43
-<b>Analysis.</b>
44
-If you're investigating Tor, or solving a Tor-related problem,
45
-<i>_please_</i> talk to us somewhere along the way &mdash; the earlier
46
-the better. These days we review too many conference paper submissions
47
-that make bad assumptions and end up solving the wrong problem. Since
48
-the Tor protocol and the Tor network are both moving targets, measuring
49
-things without understanding what's going on behind the scenes is going
50
-to result in bad conclusions. In particular, different groups often
51
-unwittingly run a variety of experiments in parallel, and at the same
52
-time we're constantly modifying the design to try new approaches. If
53
-you let us know what you're doing and what you're trying to learn,
54
-we can help you understand what other variables to expect and how to
55
-interpret your results.
56
-</li>
57
-
58
-<li>
59
-<b>Measurement and attack tools.</b>
60
-We're building a <a
61
-href="https://metrics.torproject.org/tools.html">repository</a> of tools
62
-that can be used to measure, analyze, or perform attacks on Tor. Many
63
-research groups end up needing to do similar measurements (for example,
64
-change the Tor design in some way and then see if latency improves),
65
-and we hope to help everybody standardize on a few tools and then make
66
-them really good. Also, while there are some really neat Tor attacks
67
-that people have published about, it's hard to track down a copy of
68
-the code they used. Let us know if you have new tools we should list,
69
-or improvements to the existing ones. The more the better, at this stage.
70
-</li>
71
-
72
-<li>
73
-<b>We need defenses too &mdash; not just attacks.</b>
74
-Most researchers find it easy and fun to come up with novel attacks on
75
-anonymity systems. We've seen this result lately in terms of improved
76
-congestion attacks, attacks based on remotely measuring latency or
77
-throughput, and so on. Knowing how things can go wrong is important,
78
-and we recognize that the incentives in academia aren't aligned with
79
-spending energy on designing defenses, but it sure would be great to
80
-get more attention to how to address the attacks. We'd love to help
81
-brainstorm about how to make Tor better. As a bonus, your paper might
82
-even end up with a stronger "countermeasures" section.
83
-</li>
84
-
85
-<li>
86
-<b>In-person help.</b>
87
-If you're doing interesting and important Tor research and need help
88
-understanding how the Tor network or design works, interpreting your
89
-data, crafting your experiments, etc, we can send a Tor researcher to
90
-your doorstep. As you might expect, we don't have a lot of free time;
91
-but making sure that research is done in a way that's useful to us is
92
-really important. So let us know, and we'll work something out.
93
-</li>
94
-
95
-</ul>
96
-
97
-<a id="Groups"></a>
98
-<h2><a class="anchor" href="#Groups">Research Groups</a></h2>
99
-
100
-<p>Interested to find other anonymity researchers? Here are some
101
-research groups you should take a look at.</p>
102
-
103
-<ul>
104
-<li>Ian Goldberg's <a href="http://crysp.uwaterloo.ca/">CrySP</a> group
105
-at Waterloo.
106
-</li>
107
-<li><a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>'s
108
-group at UMN.
109
-</li>
110
-<li><a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>'s
111
-group at Illinois.
112
-</li>
113
-<li>Micah Sherr's <a href="https://security.cs.georgetown.edu/">SecLab</a>
114
-group at Georgetown.
115
-</li>
116
-<li>Matt Wright's <a href="http://isec.uta.edu/">iSec</a> group at
117
-UTA.
118
-</li>
119
-</ul>
120
-
121
-<a id="Ideas"></a>
122
-<h2><a class="anchor" href="#Ideas">Research Ideas</a></h2>
123
-
124
-<p>
125
-If you're interested in anonymity research, you must make it to the
126
-<a href="http://petsymposium.org/">Privacy Enhancing Technologies
127
-Symposium</a>. Everybody who's anybody in the anonymity research world
128
-will be there. Stipends are generally available for people whose presence
129
-will benefit the community.
130
-</p>
131
-
132
-<p>To get up to speed on anonymity research, read <a
133
-href="http://freehaven.net/anonbib/">these papers</a> (especially the
134
-ones in boxes).</p>
135
-
136
-<p>We need people to attack the system, quantify defenses,
137
-etc. Here are some example projects:</p>
138
-
139
-<ul>
140
-
141
-<li>What algorithm should we use to assign Guard flags such that a)
142
-we assign the flag to as many relays as possible, yet b) we minimize
143
-the chance that Alice will use an attacker's node as a guard? See the
144
-<a href="<blog>/research-problem-better-guard-rotation-parameters">blog
145
-post</a> for details.
146
-</li>
147
-
148
-<li>For various diversity metrics, how has the diversity of
149
-the Tor network changed over time? How robust is it to change or
150
-attack? These results can help us make better design decisions. See the <a
151
-href="<blog>/research-problem-measuring-safety-tor-network">blog post</a>
152
-for details.
153
-</li>
154
-
155
-<li>If we prevent the really loud users from using too much of the Tor
156
-network, how much can it help? We've instrumented Tor's entry relays
157
-so they can rate-limit connections from users, and we've instrumented
158
-the directory authorities so they can change the rate-limiting
159
-parameters globally across the network. Which parameter values improve
160
-performance for the Tor network as a whole? How should relays adapt
161
-their rate-limiting parameters based on their capacity and based on
162
-the network load they see, and what rate-limiting algorithms will work
163
-best? See the <a
164
-href="<blog>/research-problem-adaptive-throttling-tor-clients-entry-guards">blog
165
-post</a> for details.
166
-</li>
167
-
168
-<li>Right now Tor clients are willing to reuse a given circuit for ten
169
-minutes after it's first used. The goal is to avoid loading down the
170
-network with too many circuit creations, yet to also avoid having
171
-clients use the same circuit for so long that the exit node can build a
172
-useful pseudonymous profile of them. Alas, ten minutes is probably way
173
-too long, especially if connections from multiple protocols (e.g. IM and
174
-web browsing) are put on the same circuit. If we keep fixed the overall
175
-number of circuit extends that the network needs to do, are there more
176
-efficient and/or safer ways for clients to allocate streams to circuits,
177
-or for clients to build preemptive circuits? Perhaps this research item
178
-needs to start with gathering some traces of what requests typical
179
-clients try to launch, so you have something realistic to try to optimize.
180
-</li>
181
-
182
-<li>The "website fingerprinting attack": make a list of a few
183
-hundred popular websites, download their pages, and make a set of
184
-"signatures" for each site. Then observe a Tor client's traffic. As
185
-you watch him receive data, you quickly approach a guess about which
186
-(if any) of those sites he is visiting. First, how effective is
187
-this attack on the deployed Tor design? The problem with all the
188
-previous attack papers is that they look at timing and counting of
189
-IP packets on the wire. But OpenSSL's TLS records, plus Tor's use of
190
-TCP pushback to do rate limiting, means that tracing by IP packets
191
-produces very poor results. The right approach is to realize that
192
-Tor uses OpenSSL, look inside the TLS record at the TLS headers, and
193
-figure out how many 512-byte cells are being sent or received. Then
194
-start exploring defenses: for example, we could change Tor's cell
195
-size from 512 bytes to 1024 bytes, we could employ padding techniques
196
-like <a href="http://freehaven.net/anonbib/#timing-fc2004">defensive
197
-dropping</a>, or we could add traffic delays. How much of an impact do
198
-these have, and how much usability impact (using some suitable metric)
199
-is there from a successful defense in each case?</li>
200
-
201
-<!--
202
-<li>
203
-Path selection algorithms, directory fetching schedules for Tor-on-mobile
204
-that are compatible anonymity-wise with our current approaches.
205
-</li>
206
-
207
-
208
-<li>More coming soon. See also the "Research" section of the <a
209
-href="<page getinvolved/volunteer>#Research">volunteer</a> page for
210
-other topics.
211
-</li>
212
-
213
-</ul>
214
-
215
-  </div>
216
-  <!-- END MAINCOL -->
217
-  <div id = "sidecol">
218
-#include "side.wmi"
219
-#include "info.wmi"
220
-  </div>
221
-  <!-- END SIDECOL -->
222
-</div>
223
-<!-- END CONTENT -->
224
-#include <foot.wmi>
225
-
... ...
@@ -25,7 +25,7 @@
25 25
         {'url'  => 'getinvolved/relays',
26 26
          'txt'  => 'Set up relays',
27 27
         },
28
-        {'url'  => 'getinvolved/research',
28
+        {'url'  => 'https://research.torproject.org/',
29 29
          'txt'  => 'Research',
30 30
         },
31 31
         {'url'  => 'donate/donate',