Roger Dingledine commited on 2010-03-30 07:32:14
Zeige 1 geänderte Dateien mit 19 Einfügungen und 11 Löschungen.
| ... | ... |
@@ -199,7 +199,7 @@ tordnsel</a> via git. |
| 199 | 199 |
<br /> |
| 200 | 200 |
Priority: <i>Medium to High</i> |
| 201 | 201 |
<br /> |
| 202 |
-Effort Level: <i>Medium</i> |
|
| 202 |
+Effort Level: <i>Medium to High</i> |
|
| 203 | 203 |
<br /> |
| 204 | 204 |
Skill Level: <i>High</i> |
| 205 | 205 |
<br /> |
| ... | ... |
@@ -209,21 +209,29 @@ The Tor 0.2.1.x series makes <a |
| 209 | 209 |
href="<svnprojects>design-paper/blocking.html">significant |
| 210 | 210 |
improvements</a> in resisting national and organizational censorship. |
| 211 | 211 |
But Tor still needs better mechanisms for some parts of its |
| 212 |
-anti-censorship design. For example, current Tors can only listen on a |
|
| 213 |
-single address/port combination at a time. There's |
|
| 212 |
+anti-censorship design. |
|
| 213 |
+<br /> |
|
| 214 |
+One huge category of work is adding features to our <a |
|
| 215 |
+href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a> |
|
| 216 |
+service (Python). Tor aims to give out <a href="<page bridges>">bridge |
|
| 217 |
+relay addresses</a> to users that can't reach the Tor network |
|
| 218 |
+directly, but there's an arms race between algorithms for distributing |
|
| 219 |
+addresses and algorithms for gathering and blocking them. See <a |
|
| 220 |
+href="https://blog.torproject.org/blog/bridge-distribution-strategies">our |
|
| 221 |
+blog post on the topic</a> as an overview, and then look at <a |
|
| 222 |
+href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">Roger's |
|
| 223 |
+or-dev post</a> from December for more recent thoughts — lots of |
|
| 224 |
+design work remains. |
|
| 225 |
+<br /> |
|
| 226 |
+If you want to get more into the guts of Tor itself (C), another problem |
|
| 227 |
+we should address is that current Tors can only listen on a single |
|
| 228 |
+address/port combination at a time. There's |
|
| 214 | 229 |
<a href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">a |
| 215 | 230 |
proposal to address this limitation</a> and allow clients to connect |
| 216 | 231 |
to any given Tor on multiple addresses and ports, but it needs more |
| 217 | 232 |
work. |
| 218 | 233 |
<br /> |
| 219 |
-Another area that needs work is our <a |
|
| 220 |
-href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a> |
|
| 221 |
-service. See e.g. <a |
|
| 222 |
-href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">Roger's |
|
| 223 |
-or-dev post</a> from December for details — lots of design work |
|
| 224 |
-remains. |
|
| 225 |
-<br /> |
|
| 226 |
-This project involves a lot of research and design. One of the big |
|
| 234 |
+This project could involve a lot of research and design. One of the big |
|
| 227 | 235 |
challenges will be identifying and crafting approaches that can still |
| 228 | 236 |
resist an adversary even after the adversary knows the design, and |
| 229 | 237 |
then trading off censorship resistance with usability and robustness. |
| 230 | 238 |