tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 19218

3) # Last-Translator: peihanru AT gmail.com
4) 

5) #include "head.wmi" TITLE="Tor: 志愿者" CHARSET="UTF-8"

6) 
7) <div class="main-column">
8) 
9) <!-- PUT CONTENT AFTER THIS TAG -->

10) <h2>几件每个人都可以做的事:</h2>

11) <ol>

12) 
13) <li>请考虑<a href="<page docs/tor-doc-relay>">运行一台中继</a>帮助 Tor 网络成长。
14) </li>
15) 
16) <li>告诉你的朋友！请他们运行中继。请他们运行隐匿服务。请他们告诉他们的朋友。
17) </li>
18) 
19) <li>如果你认同 Tor 的目标，请<a href="<page donate>">花一些时间捐助以支持 Tor 的后继开发</a>。
20) 我们正在寻求资助与赞助商，如果你还知道任何需要匿名、私有、通信安全的公司、非政府组织、
21) 代理商或其他组织，把我们告诉他们。
22) </li>
23) 
24) <li>我们在寻找一些<a href="<page torusers>">使用 Tor 的好的例子。</a>
25) 如果你使用 Tor 的目的和方式我们还不了解，我们会很高兴你能告诉我们你的故事。
26) </li>
27) 

28) </ol>
29) 
30) <a id="Usability"></a>
31) <h2><a class="anchor" href="#Usability">支撑应用</a></h2>
32) <ol>

33) <li>我们需要更多更好的办法拦截 DNS 请求，这样，当我们想要匿名时，DNS 请求就不会泄露给本地的窃听者。
34) （会发生这种情况是因为应用程序在使用 SOCKS 代理之前进行了 DNS 解析。）
35) </li>
36) 

37) <li>Tsocks/dsocks 相关：

38) 

39) <ul>

40) 

41) <li>我们需要<a href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">应用

42) 我们所有的 tsocks 补丁</a>并维护一个新的分支。如果你需要，我们将提供空间。
43) </li>
44) 

45) <li>我们应该修补 Dug Song 的“dsocks”程序，令其从控制接口使用 Tor 的 <i>mapaddress</i> 命令，

46) 这样我们就不用浪费连接前在 Tor 内部作解析的整个时间。
47) </li>
48) 

49) <li>我们需要使我们的 <i>torify</i> 脚本检测安装的是 tsocks 还是 dsocks，并恰当地调用它们。

50) 这或许意味着统一它们的接口，也许还包括在它们之间共用代码或弃用其中之一。
51) </li>
52) 

53) </ul>

54) 

55) </li>

56) 

57) <li>运行中继的志愿者告诉我们他们想在一天中的某个时间段限制一种速率，在其他的时间段限制另一种速率。

58) 我们应当写一个脚本通过 <a href="<page gui/index>">Tor 控制接口</a>修改带宽限制，而不是把代码加入 Tor。

59) Unix 和 Mac 已经有了这样的一个脚本（它使用了 bash 和 cron），但是 Windows 用户仍缺少解决方案。

60) </li>

61) 
62) <!--
63) 

64) <li>Tor 能够<a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">从

65) Tor 网络中选择特定的出口节点</a>，但我们应当能够指定一个国家并自动挑选（该国家的出口节点）。
66) 最有希望的办法是一并获取 Blossom 的目录，在本地运行一个 Blossom 客户端能够安全地获取这个目录

67) （通过 Tor 并检查签名），拦截 <tt>.country.blossom</tt> 主机名，并做该做的事。
68) </li>
69) 
70) 

71) <li>说到地理位置数据，希望有人能画出一张标记每一台 Tor 中继地理位置的地图。

72) 如果它能随着网络的变化而更新就更好了。
73) 不幸的是，实现这个功能的简单的办法会将所有的数据发送至 Google 并由他们画出地图。

74) 这么做会影响隐私吗，我们有其他好办法吗？
75) </li>
76) 
77) </ol>
78) 
79) <a id="Advocacy"></a>
80) <h2><a class="anchor" href="#Advocacy">宣传</a></h2>
81) <ol>
82) <li>基于 Creative Commons 协议创建一个社区 log 以便大众自由使用</li>
83) <li>Create a presentation that can be used for various user group meetings around the world</li>
84) <li>编写一段可以适用于全世界大多数用户组织的会议上的介绍</li>
85) <li>拍摄一段视频来介绍你如果使用 Tor，已经有人在 Seesmic 上这么做了</li>
86) <li>围绕 "Tor for Freedom!" 这个主题创作海报</li>

87) </ol>
88) 

89) 

90) <a id="Documentation"></a>
91) <h2><a class="anchor" href="#Documentation">文档</a></h2>
92) <ol>

93) 

94) <li>请帮助 Matt Edman 完善他的 Tor 控制器——<a href="<page vidalia/index>">Vidalia</a>

95) 的文档和使用指导。
96) </li>
97) 

98) <li>评估并完善能被配置使用 Tor 的<a

99) href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">程序列表</a>。
100) </li>
101) 

102) <li>我们需要更好的文档描述动态拦截连接并通过 Tor 发送。tsocks（Linux）、dsocks（BSD）和

103) freecap（Windows）看上去是不错的候选，但最好使用我们的新的 TransPort 特性。
104) </li>
105) 

106) <li>我们有一张<a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">与

107) Tor 接口的可能有用的程序</a>的冗长列表。在哪些情形下哪些是有用的？请帮助我们测试并写下你的结果。
108) </li>
109) 

110) <li>帮忙将网页与文档翻译成其他语言。如果你感兴趣，请阅读<a href="<page translation>">翻译指导</a>。

111) 为了帮助受限地区的 Tor 用户，我们特别需要阿拉伯语和波斯语翻译。
112) </li>
113) 

114) </ol>
115) 
116) <a id="Coding"></a>

117) <a id="Summer"></a>
118) <a id="Projects"></a>
119) 
120) <h2><a class="anchor" href="Projects">更好的编码</a></h2>
121) <p>
122) You may find some of these projects to be good <a href="<page
123) gsoc>">Google Summer of Code 2009</a> ideas. We have labelled each idea
124) with how useful it would be to the overall Tor project (priority), how
125) much work we expect it would be (effort level), how much clue you should
126) start with (skill level), and which of our <a href="<page
127) people>#Core">core developers</a> would be good mentors.
128) If one or more of these ideas looks promising to you, please <a
129) href="<page contact>">contact us</a> to discuss your plans rather than
130) sending blind applications. You may also want to propose your own project
131) idea which often results in the best applications.
132) </p>
133) 
134) <ol>
135) 
136) <li>
137) <b>Tor Browser Bundle for Linux/Mac OS X</b>
138) <br />
139) Priority: <i>High</i>
140) <br />
141) Effort Level: <i>High</i>
142) <br />
143) Skill Level: <i>Medium</i>
144) <br />
145) Likely Mentors: <i>Steven, Andrew</i>
146) <br />
147) The Tor Browser bundle incorporates Tor, Firefox, and the Vidalia user
148) interface (and optionally Pidgin IM). Components are pre-configured to
149) operate in a secure way, and it has very few dependencies on the
150) installed operating system. It has therefore become one of the most
151) easy to use, and popular, ways to use Tor on Windows.
152) <br />
153) However, there is currently no comparable package for Linux and Mac OS
154) X, so this project would be to implement Tor Browser Bundle for these
155) platforms. This will involve modifications to Vidalia (C++), possibly
156) Firefox (C) then creating and testing the launcher on a range of
157) operating system versions and configurations to verify portability.
158) <br />
159) Students should be familiar with application development on one or
160) preferably both of Linux and Mac OS X, and be comfortable with C/C++
161) and shell scripting.
162) <br />
163) Part of this project could be usability testing of Tor Browser Bundle,
164) ideally amongst our target demographic.
165) That would help a lot in knowing what needs to be done in terms of bug
166) fixes or new features. We get this informally at the moment, but a more
167) structured process would be better.
168) </li>
169) 
170) <li>
171) <b>Translation wiki for our website</b>
172) <br />
173) Priority: <i>High</i>
174) <br />
175) Effort Level: <i>Medium</i>
176) <br />
177) Skill Level: <i>Medium</i>
178) <br />
179) Likely Mentors: <i>Jacob</i>
180) <br />
181) The Tor Project has been working over the past year to set up web-based
182) tools to help volunteers translate our applications into other languages.
183) We finally hit upon Pootle, and we have a fine web-based translation engine
184) in place for Vidalia, Torbutton, and Torcheck. However, Pootle only
185) translates strings that are in the "po" format, and our website uses wml
186) files. This project is about finding a way to convert our wml files into po
187) strings and back, so they can be handled by Pootle.
188) </li>
189) 
190) <li>
191) <b>跟踪 Tor 网络状态</b>
192) <br />
193) Priority: <i>Medium to High</i>
194) <br />
195) Effort Level: <i>Medium</i>
196) <br />
197) Skill Level: <i>Medium</i>
198) <br />
199) Likely Mentors: <i>Karsten, Roger</i>
200) <br />
201) 如果有一个自动化的机制来全时的跟踪网络的健康情况并给出图表等等，那将是一件非常
202) 美妙的事情。这要求有一个更好的机制来获取网路的健康信息以及它的成长情况。网络的
203) 平均活动时间增加了吗？跟上月比较这个月有多少个中继在持续运行中？新增中继和停止
204) 的中继有什么样的变动？我们周期性的收集一些快照摘要，但是如果我们能够全时的跟踪
205) 数据那将会变得非常有趣。
206) <br />
207) 数据可以通过 <a href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>
208) 的“Tor 节点扫描”来得到，可以从服务器和其他来源得到所有公开的
209) 中继信息。全时监控的结果可以被整合到<a href="https://torstatus.blutmagie.de/">Tor 状态</a>
210) 页面，或者保持单独的数据格式。关于 Tor 状态页面的讨论，可以看看Roger的
211) <a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor
212) Status wish list</a>。
213) </li>
214) 
215) <li>
216) <b>提高 Tor 抵抗审查的能力</b>
217) <br />
218) Priority: <i>Medium to High</i>
219) <br />
220) Effort Level: <i>Medium</i>
221) <br />
222) Skill Level: <i>High</i>
223) <br />
224) Likely Mentors: <i>Nick, Roger, Steven</i>
225) Tor 0.2.0.x系列的<a href="<svnsandbox>doc/design-paper/blocking.html">一个重要改进</a
226) >是提高了抵抗政府机关或者组织探测的能力。但是 Tor 的反审查设计在某些方面仍然需要
227) 更好的机制来改进。比如，现在 Tor 只能在一个 地址/端口  对上进行监听，
228) 有<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">建议放开这个限制</a>，
229) 并允许客户端可以连接到任意给定的 Tor 地址和端口上，但是，这需要大量的工作。另外一个
230) 提高反审查能力的方案（更加复杂和困难）希望能够提高 Tor 对端口扫描的抵抗能力。现在，恶意
231) 的扫描者可以通过尝试连接一个假定的 Tor 主机，向其发送 Tor 协议包，并检查它的响应来确定
232) 它是否在运行<a href="<svnsandbox>doc/spec/proposals/125-bridges.txt"> Tor 网桥</a>。
233) 要解决这个问题，当受到端口扫描工具扫描的时候，网桥应该
234) <a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">伪装成一个 web 服务器</a>
235) （HTTP或者HTTPS），如果对方没有提供正确的网桥 key，那么它不会作出正确的网桥连接响应。
236) <br />
237) 这部分的工作需要大量的研究和设计。一个巨大的挑战是，即使一个攻击者知道我们的算法和机制，
238) 但他仍然没有办法削弱我们的反审查能力，这要求我们的设计具备足够的可用性和健壮性。
239) 
240) 
241) <li>
242) <b>动态调整 Tor!</b>
243) <br />
244) Priority: <i>Medium to High</i>
245) <br />
246) Effort Level: <i>Medium to High</i>
247) <br />
248) Skill Level: <i>High</i>
249) <br />
250) Likely Mentors: <i>Nick, Roger, Mike, Karsten</i>
251) <br />
252) 现在，Tor 中继自己估算并报告自己的带宽能力，Tor 客户端则根据中继的带宽报告
253) 来选择自己的路由。这种策略使得<a href="http://freehaven.net/anonbib/#bauer:wpes2007">
254) 中继谎报带宽的攻击</a>变得非常容易。为了改善这个问题，Tor 计算最大带宽的交，
255) 但它仍然乐于相信来自中继提供者的报告。这是一个有限的修正，而且会浪费有余的带
256) 宽。因此我们希望，Tor 可以通过更为分布式的模型来测算中继的带宽，比如 Snader 
257) 和 Borisov 的论文<a href="http://freehaven.net/anonbib/author.html#snader08">
258) "A Tune-up for Tor"</a>。我们希望有人能够使用现有的测试代码来对这篇论文进行
259) 双重检查，确认该论文中的发现，并验证它是否吻合 Tor 在广域网部署的情况，并设法
260) 找到一个好办法来将这些想法合并到 Tor 中而又不会大幅增加中继和目录服务器之间的
261) 通讯流量。
262) </li>
263) 
264) <li>
265) <b>Improving Polipo on Windows</b>
266) <br />
267) Priority: <i>Medium to High</i>
268) <br />
269) Effort Level: <i>Medium</i>
270) <br />
271) Skill Level: <i>Medium</i>
272) <br />
273) Likely Mentors: <i>Martin</i>
274) <br />
275) Help port <a
276) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
277) Windows. Example topics to tackle include:
278) 1) the ability to asynchronously
279) query name servers, find the system nameservers, and manage netbios
280) and dns queries.
281) 2) manage events and buffers
282) natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
283) Windows it's whatever the config specifies). 3) some sort of GUI config
284) and reporting tool, bonus if it has a systray icon with right clickable
285) menu options. Double bonus if it's cross-platform compatible.
286) 4) allow the software to use the Windows Registry and handle proper 
287) Windows directory locations, such as "C:\Program Files\Polipo"
288) </li>
289) 
290) <li>
291) <b>Implement a torrent-based scheme for downloading Thandy packages</b>
292) <br />
293) Priority: <i>Medium to High</i>
294) <br />
295) Effort Level: <i>High</i>
296) <br />
297) Skill Level: <i>Medium to High</i>
298) <br />
299) Likely Mentors: <i>Martin, Nick</i>
300) <br />
301) <a
302) href="http://git.torproject.org/checkout/thandy/master/specs/thandy-spec.txt">Thandy</a>
303) is a relatively new software to allow assisted updates of Tor and related
304) software. Currently, there are very few users, but we expect Thandy to be
305) used by almost every Tor user in the future. To avoid crashing servers on
306) the day of a Tor update, we need new ways to distribute new packages
307) efficiently, and using libtorrent seems to be a possible solution. If you
308) think of other good ideas, great - please do let us know!<br />
309) We also need to investigate how to include our mirrors better. If possible,
310) there should be an easy way for them to help distributing the packages.
311) </li>
312) 
313) <li>
314) <b>Tor Controller Status Event Interface</b>
315) <br />
316) Priority: <i>Medium</i>
317) <br />
318) Effort Level: <i>Medium</i>
319) <br />
320) Skill Level: <i>Low to Medium</i>
321) <br />
322) Likely Mentors: <i>Matt</i>
323) <br />
324) There are a number of status changes inside Tor of which the user may need
325) to be informed. For example, if the user is trying to set up his Tor as a
326) relay and Tor decides that its ports are not reachable from outside
327) the user's network, we should alert the user. Currently, all the user
328) gets is a couple log messages in Vidalia's 'message log' window, which they
329) likely never see since they don't receive a notification that something
330) has gone wrong. Even if the user does actually look at the message log,
331) most of the messages make little sense to the novice user.
332) <br />
333) Tor has the ability to inform Vidalia of many such status changes, and
334) we recently implemented support for a couple of these events. Still,
335) there are many more status events the user should be informed of and we
336) need a better UI for actually displaying them to the user.
337) <br />
338) The goal of this project then is to design and implement a UI for
339) displaying Tor status events to the user. For example, we might put a
340) little badge on Vidalia's tray icon that alerts the user to new status
341) events they should look at. Double-clicking the icon could bring up a
342) dialog that summarizes recent status events in simple terms and maybe
343) suggests a remedy for any negative events if they can be corrected by
344) the user. Of course, this is just an example and one is free to
345) suggest another approach.
346) <br />
347) A person undertaking this project should have good UI design and layout
348) and some C++ development experience. Previous experience with Qt and
349) Qt's Designer will be very helpful, but are not required. Some
350) English writing ability will also be useful, since this project will
351) likely involve writing small amounts of help documentation that should
352) be understandable by non-technical users. Bonus points for some graphic
353) design/Photoshop fu, since we might want/need some shiny new icons too.
354) </li>
355) 
356) <li>
357) <b>Improve our unit testing process</b>
358) <br />
359) Priority: <i>Medium</i>
360) <br />
361) Effort Level: <i>Medium</i>
362) <br />
363) Skill Level: <i>Medium</i>
364) <br />
365) Likely Mentors: <i>Nick, Roger</i>
366) <br />
367) Tor needs to be far more tested. This is a multi-part effort. To start
368) with, our unit test coverage should rise substantially, especially in
369) the areas outside the utility functions. This will require significant
370) refactoring of some parts of Tor, in order to dissociate as much logic
371) as possible from globals.
372) <br />
373) Additionally, we need to automate our performance testing. We've got
374) buildbot to automate our regular integration and compile testing already
375) (though we need somebody to set it up on Windows),
376) but we need to get our network simulation tests (as built in <a
377) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)
378) updated for more recent versions of Tor, and designed to launch a test
379) network either on a single machine, or across several, so we can test
380) changes in performance on machines in different roles automatically.
381) </li>
382) 
383) <li>
384) <b>Help revive an independent Tor client implementation</b>
385) <br />
386) Priority: <i>Medium</i>
387) <br />
388) Effort Level: <i>High</i>
389) <br />
390) Skill Level: <i>Medium to High</i>
391) <br />
392) Likely Mentors: <i>Karsten, Nick</i>
393) <br />
394) Reanimate one of the approaches to implement a Tor client in Java,
395) e.g. the <a href="http://onioncoffee.sourceforge.net/">OnionCoffee
396) project</a>, and make it run on <a
397) href="http://code.google.com/android/">Android</a>. The first step
398) would be to port the existing code and execute it in an Android
399) environment. Next, the code should be updated to support the newer Tor
400) protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
401) directory protocol</a>. Further, support for requesting or even
402) providing Tor hidden services would be neat, but not required.
403) <br />
404) A prospective developer should be able to understand and write new Java
405) code, including
406) a Java cryptography API. Being able to read C code would be helpful,
407) too. One should be willing to read the existing documentation,
408) implement code based on it, and refine the documentation
409) when things are underdocumented. This project is mostly about coding and
410) to a small degree about design.
411) </li>
412) 
413) <li>
414) <b>New Torbutton Features</b>
415) <br />
416) Priority: <i>Medium</i>
417) <br />
418) Effort Level: <i>High</i>
419) <br />
420) Skill Level: <i>High</i>
421) <br />
422) Likely Mentors: <i>Mike</i>
423) <br/>
424) There are several <a
425) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5&amp;type=2">good
426) feature requests</a> on the Torbutton Flyspray section. In particular, <a
427) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=523">Integrating
428) 'New Identity' with Vidalia</a>,
429) <a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">ways of
430) managing multiple cookie jars/identities</a>, <a
431) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=637">preserving
432) specific cookies</a> when cookies are cleared,
433) <a
434) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">better
435) referrer spoofing</a>, <a
436) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=564">correct
437) Tor status reporting</a>, and <a
438) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=462">"tor://"
439) and "tors://" urls</a> are all interesting
440) features that could be added.
441) <br />
442) This work would be independent coding in Javascript and the fun world of <a
443) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
444) with not too much involvement in the Tor internals.
445) </li>
446) 
447) <li>
448) <b>New Thandy Features</b>
449) <br />
450) Priority: <i>Medium</i>
451) <br />
452) Effort Level: <i>Medium</i>
453) <br />
454) Skill Level: <i>Medium to High</i>
455) <br />
456) Likely Mentors: <i>Martin</i>
457) <br />
458) Additional capabilities are needed for assisted updates of all the Tor
459) related software for Windows and other operating systems. Some of the
460) features to consider include:
461) 1) Integration of the <a
462) href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
463) Python library</a>
464) for authenticated HTTPS downloads. 2) Adding a level of indirection
465) between the timestamp signatures and the package files included in an
466) update. See the "Thandy attacks / suggestions" thread on or-dev.
467) 3) Support locale specific installation and configuration of assisted
468) updates based on preference, host, or user account language settings.
469) Familiarity with Windows codepages, unicode, and other character sets
470) is helpful in addition to general win32 and posix API experience and
471) Python proficiency.
472) </li>
473) 
474) <li>
475) <b>Simulator for slow Internet connections</b>
476) <br />
477) Priority: <i>Medium</i>
478) <br />
479) Effort Level: <i>Medium</i>
480) <br />
481) Skill Level: <i>Medium</i>
482) <br />
483) Likely Mentors: <i>Steven</i>
484) <br />
485) Many users of Tor have poor-quality Internet connections, giving low
486) bandwidth, high latency, and high packet loss/re-ordering. User
487) experience is that Tor reacts badly to these conditions, but it is
488) difficult to improve the situation without being able to repeat the
489) problems in the lab.
490) <br />
491) This project would be to build a simulation environment which
492) replicates the poor connectivity so that the effect on Tor performance
493) can be measured. Other components would be a testing utility to
494) establish what are the properties of connections available, and to
495) measure the effect of performance-improving modifications to Tor.
496) <br />
497) The tools used would be up to the student, but dummynet (for FreeBSD)
498) and nistnet (for Linux) are two potential components on which this
499) project could be built. Students should be experienced with network
500) programming/debugging and TCP/IP, and preferably familiar with C and a
501) scripting language.
502) </li>
503) 
504) <li>
505) <b>改善并使 Vidalia 的网络地图更有用</b>
506) <br />
507) Priority: <i>Low to Medium</i>
508) <br />
509) Effort Level: <i>Medium</i>
510) <br />
511) Skill Level: <i>Medium</i>
512) <br />
513) Likely Mentors: <i>Matt</i>
514) <br />
515) Vidalia 有一个已有的功能是提供一张网络地图来显示 Tor 网络中的用户的物理位置并勾画出用户的网络
516) 传输路径。现在的地图缺少交互功能而且图像质量也很差。事实上，我们已经实现了一个基于 KDE 的
517) Marble widget，这让我们可以提供更好的图像质量并且可以改善交互功能，比如允许用户点击单个中继或者
518) 回路，同时显示更多的附加信息。我们希望允许用户选择某个特定的中继或者某个特定国家的一组中继并
519) 告诉 Tor：我想从这里退出。
520) <br />
521) 这个项目首先要求熟悉 Vidalia 和 Marble widget 的 API。然后，将 Marble widget 整合进 Vidalia 并且
522) 定制化 Marble 使它更适合我们的应用，比如使回路可点击，将缓存的地图数据保存到 Vidalia 自己的数据目录，
523) 并定制某些窗口对话框。
524) <br />
525) 进行该项目的人要求具有良好的 C++ 开发经验，如果以前有过 Qt 和 CMake的经验会有所帮助，但不是必须的。
526) </li>
527) 
528) <li>
529) <b>Bring moniTor to life</b>
530) <br />
531) Priority: <i>Low</i>
532) <br />
533) Effort Level: <i>Medium</i>
534) <br />
535) Skill Level: <i>Low to Medium</i>
536) <br />
537) Likely Mentors: <i>Karsten, Jacob</i>
538) <br />
539) Implement a <a href="http://www.ss64.com/bash/top.html">top-like</a>
540) management tool for Tor relays. The purpose of such a tool would be
541) to monitor a local Tor relay via its control port and include useful
542) system information of the underlying machine. When running this tool, it
543) would dynamically update its content like top does for Linux processes.
544) <a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This
545) or-dev post</a> might be a good first read.
546) <br />
547) A person interested in this should be familiar
548) with or willing to learn about administering a Tor relay and configuring
549) it via its control port. As an initial prototype is written in Python,
550) some knowledge about writing Python code would be helpful, too. This
551) project is one part about identifying requirements to such a
552) tool and designing its interface, and one part lots of coding.
553) </li>
554) 
555) <li>
556) <b>Torbutton equivalent for Thunderbird</b>
557) <br />
558) Priority: <i>Low</i>
559) <br />
560) Effort Level: <i>High</i>
561) <br />
562) Skill Level: <i>High</i>
563) <br />
564) Likely Mentors: <i>Mike</i>
565) <br />
566) We're hearing from an increasing number of users that they want to use
567) Thunderbird with Tor. However, there are plenty of application-level
568) concerns, for example, by default Thunderbird will put your hostname in
569) the outgoing mail that it sends. At some point we should start a new
570) push to build a Thunderbird extension similar to Torbutton.
571) </li>
572) 
573) <li>
574) <b>Intermediate Level Network Device Driver</b>
575) <br />
576) Priority: <i>Low</i>
577) <br />
578) Effort Level: <i>High</i>
579) <br />
580) Skill Level: <i>High</i>
581) <br />
582) Likely Mentors: <i>Martin</i>
583) <br />
584) The WinPCAP device driver used by Tor VM for bridged networking does
585) not support a number of wireless and non-Ethernet network adapters.
586) Implementation of a intermediate level network device driver for win32
587) and 64bit would provide a way to intercept and route traffic over such
588) networks. This project will require knowledge of and experience with
589) Windows kernel device driver development and testing. Familiarity with
590) Winsock and Qemu would also be helpful.
591) </li>
592) 
593) <li>
594) <b>Improve Tor Weather</b>
595) <br />
596) Priority: <i>Medium</i>
597) <br />
598) Effort Level: <i>Medium</i>
599) <br />
600) Skill Level: <i>Medium</i>
601) <br />
602) Likely Mentors: <i>Jake, Roger</i>
603) <br />
604) <a href="https://weather.torproject.org/">Tor weather</a> is a tool
605) that allows signing up to receive notifications via email when the
606) tracked Tor relay is down. Currently, it isn't really useful for
607) people who use the hibernation feature of Tor, or for those who
608) have to shut down their relay regularly. During the project, Tor
609) weather could be extended to allow more flexible configurations.
610) Other enhancements are also possible: Weather could send out warnings
611) when your relay runs an out-of-date version of Tor, or when its
612) observed bandwith drops below a certain value. It might also be a
613) nice tool that allows for checking whether your relay has earned
614) you a <a href="<page tshirt>">T-Shirt</a>, or sending reminders to
615) directory authorities that
616) their keys are about to expire. Be creative, and consider how the
617) above project to track overall network status can help you get your job
618) done more quickly! See also its
619) <a href="https://svn.torproject.org/svn/weather/trunk/README">README</a>
620) and <a href="https://svn.torproject.org/svn/weather/trunk/TODO">TODO</a>.
621) </li>
622) 
623) 
624) <li>
625) <b>告诉我们新的想法!</b>
626) <br />
627) 这些项目你都不敢兴趣？看看<a href="<svnsandbox>doc/roadmaps/2008-12-19-roadmap-full.pdf">
628) Tor 开发路线图</a>，这里有更多资料。
629) <a href="<svnsandbox>doc/spec/proposals/">现有的建议</a>中的一些，也许很快就会进入开发流程。
630) </li>
631) 
632) <!-- Mike is already working on this.
633) 
634) <li>
635) <b>改善 Tor 节点扫描</b>
636) <br />
637) <br />类似于 SoaT 退出扫描（或者就在退出的时候），可以收集到节点的可靠性信息。
638) 一个节点如果回路断裂的情况出现得太多，那么它不应该被标记为可用的状态。也许，
639) 应该忽略它自己宣称的带宽而代之以某个处罚比例的计算结果来标记，或者，就直接标记
640) 为不可用。另外，如果一个节点表现出很低的吞吐能力却宣称了一个很高的带宽，也应该
641) 被标记为不可用。这些信息的收集相关的工作目前已经完成，但是它们需要一个机制来
642) 向目录服务器报告这些信息并建立一个黑名单或者处罚名单，这样，客户端就可以监听
643) 这些信息。
644) <br />
645) 另外，当一个传输通过某个节点时也可以收集到这些同样的统计信息，然后可以在
646) <a href="https://svn.torproject.org/svn/torctl/trunk/doc/howto.txt">Tor 控制协议</a>
647) 中增加一个事件来报告一个电路在试图通过一个节点时成功或者失败的情况，这样，一个
648) 基于节点的监视器就可以通过这些事件报告来被动的收集其他节点的带宽和可靠性信息。
649) 这样一个扫描机制还可以讲某些节点的不正常情况也报告给认证服务器，但是，现在还没有
650) 这样的一个通信机制的实现，然而，我们的确需要它。
651) </li>
652) -->
653) 
654) <!-- Is this still a useful project? If so, move it to another section.
655) 
656) <li>
657) <b>为Debian/Ubuntu提供更好的Tor+Vidalia的打包</b>
658) <b></b>
659) <br />
660) 目前在Debian/Ubuntu上，Vidalia 的缺省安装包运行的不算太好。当前的安装包用 debian-tor
661) 用户缺省的以守护进程运行 Tor，但是没有在缺省的 torrc 文件中定义
662) <a href="<svnsandbox>doc/spec/control-spec.txt">控制端口</a>。
663) 因此，Vidalia 会发现无法找到已经运行的 Tor 程序于是试图自行启动一个新的 Tor 进程，
664) 然后，这个进程会失败并退出，Vidalia 会得到一个错误消息并报告给用户，用户会因此而
665) 感到困惑，他们实际上已经有一个可用的 Tor 进程了，但仍然被报告错误。
666) <br />
667) 现在的解决方案是，告诉用户停止掉缺省的 Tor 守护进程，让 Vidalia 来启动 Tor，或者向
668) 用户解释如何在他们的 torrc 文件中设定控制端口和密码。Debian 上的一个更好的解决办法
669) 应该是使用 Tor 的ControlSocket，这样Vidalia可以通过Unix domain socket与 Tor 通讯，最好
670) 能够在 Tor 的 Debian 发布包中将其设定为缺省的方式，这样，如果用户同样用 debian-tor
671) 组来运行 Vidalia的话，Vidalia就可以用基于文件的认证方式（cookie）来连接 Tor。
672) <br />
673) 首先要做的是为 Vidalia 增加对 Tor 的 ControlSocket 的支持，开发并测试符合Debian和Ubuntu
674) 标准的发布包，并确认它能够和已有的 Tor 发布包一起正常工作。我们可以为此提供一个资料库
675) 以及相应的host服务。
676) <br />
677) 接下来的挑战是，既然在固定的位置（<code>/etc/tor/torrc</code>）可以找到 Tor 的控制文件，
678) 那么我们应该可以找到一个办法允许 Vadilia 修改 Tor 的控制文件（torrc）。我们能想到的最好的
679) 办法是当 Vadilia 启动后它可以通过控制端口（ControlSocket）向 Tor 提供一个新的配置，但是，
680) 有个问题是这可能会覆盖用户自己希望的配置。另外一个不错的想法是，由 Vadilia 创建一个临时
681) 配置文件并提示用户手工将其覆盖<code>/etc/tor/torrc</code>，这同样有个问题，用户会被
682) 要求直接操作文件，但通常我们不应该这样。
683) <br />
684) 打算在这方面做点工作的志愿者，应该具备Debian的包管理相关的知识以及有一定的 C++ 开发经验，
685) Qt的经验不是必须的，但是多少会有些帮助。
686) </li>
687) 
688) -->
689) 
690) 
691) <!-- This should be mostly done.
692) 
693) <li>
694) <b>Tor/Polipo/Vidalia 的自动更新框架</b>
695) <br />
696) 我们需要一个良好的可认证的更新框架。现在 Vidalia 通过检查 Tor 的目录信息，可以发现用户在
697) 运行一个较旧的或者不再被推荐的 Tor 版本，并通知用户。但它只是简单的弹出一个小小的消息框
698) 告诉用户他需要手动升级自己的 Tor 版本。我们的目标是能够扩展 Vidalia 的功能使之能够自动下载
699) 最新的 Tor 并自动安装。我们希望在可能的时候通过 Tor 来完成这个事情，但是也可以考虑其他
700) 更好的办法。如果时间许可，我们也希望可以一起更新 Tor 套件中的其他软件，比如 Polipo 和 Vidalia
701) 自己。
702) <br />
703) 要完成这项工作，研究者必须首先评估已有的自动更新框架，比如 OS X上的 Sparkle，并评估它们的
704) 功能，弱点，安全问题，以及与 Vidalia 的整合性。如果找不到合适的现成的解决方案，那么研究者就
705) 需要自行设计一个自动更新框架，并写出设计文档供其他开发者讨论和评估它的安全风险。研究者
706) 需要实现他自己的框架（或者整合一个既有的）并进行测试。
707) <br />
708) 从事这项工作需要良好的 C++ 开发经验，Qt 的开发经验会有所帮助但不是必需的，同时，还需要充分
709) 了解常见的安全相关问题，比如包签名验证等。 良好的写作能力也是非常重要的，因为这项工作的一个
710) 重要步骤是首先要写出设计文档供讨论和评估，并以此决定它的实现优先度。
711) </li>
712) 
713) -->
714) 
715) <!-- Jake already did most of this.
716) 
717) <li>
718) <b>Improvements on our active browser configuration tester</b> -
719) <a href="https://check.torproject.org/">https://check.torproject.org/</a>
720) <br />
721) We currently have a functional web page to detect if Tor is working. It
722) has a few places where it falls short. It requires improvements with
723) regard to default languages and functionality. It currently only responds
724) in English. In addition, it is a hack of a perl script that should have
725) never seen the light of day. It should probably be rewritten in python
726) with multi-lingual support in mind. It currently uses the <a
727) href="http://exitlist.torproject.org/">Tor DNS exit list</a>
728) and should continue to do so in the future. It currently result in certain
729) false positives and these should be discovered, documented, and fixed
730) where possible. Anyone working on this project should be interested in
731) DNS, basic perl or preferably python programming skills, and will have
732) to interact minimally with Tor to test their code.
733) <br />
734) If you want to make the project more exciting
735) and involve more design and coding, take a look at <a
736) href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
737) 131-verify-tor-usage.txt</a>.
738) </li>
739) 
740) -->
741) 
742) <!-- If we decide to switch to the exit list in TorStatus, this is obsolete.
743) 
744) <li>
745) <b>Improvements on our DNS Exit List service</b> -
746) <a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
747) <br />
748) The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a>
749) is written by our fabulous anonymous
750) contributer Tup. It's a DNS server written in Haskell that supports part of our <a
751) href="<svnsandbox>doc/contrib/torel-design.txt">exitlist
752) design document</a>. Currently, it is functional and it is used by
753) check.torproject.org and other users. The issues that are outstanding
754) are mostly aesthetic. This wonderful service could use a much better
755) website using the common Tor theme. It would be best served with better
756) documentation for common services that use an RBL. It could use more
757) publicity. A person working on this project should be interested in DNS,
758) basic RBL configuration for popular services, and writing documentation.
759) The person would require minimal Tor interaction &mdash; testing their
760) own documentation at the very least. Furthermore, it would be useful
761) if they were interested in Haskell and wanted to implement more of the
762) torel-design.txt suggestions.
763) </li>
764) 
765) -->
766) 
767) <!-- Nobody wanted to keep this.
768) <li>
769) <b>Testing integration of Tor with web browsers for our end users</b>
770) <br />
771) The Tor project currently lacks a solid test suite to ensure that a
772) user has a properly and safely configured web browser. It should test for as
773) many known issues as possible. It should attempt to decloak the
774) user in any way possible. Two current webpages that track these
775) kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
776) href="http://pseudo-flaw.net/tor/torbutton/">list of issues along
777) with their proof of concept code, bug issues, etc</a>. HD Moore runs
778) the <a href="http://metasploit.com/research/projects/decloak/">metasploit
779) decloak website</a>. A person interested in defending Tor could start
780) by collecting as many workable and known methods for decloaking a
781) Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may
782) be helpful as a start.) One should be familiar with the common pitfalls but
783) possibly have new methods in mind for implementing decloaking issues. The
784) website should ensure that it tells a user what their problem is. It
785) should help them to fix the problem or direct them to the proper support
786) channels. The person should also be closely familiar with using Tor and how
787) to prevent Tor information leakage.
788) </li>
789) 
790) -->
791) 
792) <!-- Nick did quite some work here. Is this project still required then?
793) 
794) <li>
795) <b>Libevent and Tor integration improvements</b>
796) <br />
797) Tor should make better use of the more recent features of Niels
798) Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a>
799) library.  Tor already uses Libevent for its low-level asynchronous IO
800) calls, and could also use Libevent's increasingly good implementations
801) of network buffers and of HTTP.  This wouldn't be simply a matter of
802) replacing Tor's internal calls with calls to Libevent: instead, we'll
803) need to refactor Tor to use Libevent calls that do not follow the
804) same models as Tor's existing backends. Also, we'll need to add
805) missing functionality to Libevent as needed &mdash; most difficult likely
806) will be adding OpenSSL support on top of Libevent's buffer abstraction.
807) Also tricky will be adding rate-limiting to Libevent.
808) </li>
809) 
810) -->
811) 
812) <!--
813) <li>
814) <b>Improving the Tor QA process: Continuous Integration for Windows builds</b>
815) <br />
816) It would be useful to have automated build processes for Windows and
817) probably other platforms. The purpose of having a continuous integration
818) build environment is to ensure that Windows isn't left behind for any of
819) the software projects used in the Tor project or its accompanying.<br />
820) Buildbot may be a good choice for this as it appears to support all of
821) the platforms Tor does. See the
822) <a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for
823) buildbot</a>.<br />
824) There may be better options and the person undertaking this task should
825) evaluate other options. Any person working on this automatic build
826) process should have experience or be willing to learn how to build all
827) of the respective Tor related code bases from scratch. Furthermore, the
828) person should have some experience building software in Windows
829) environments as this is the target audience we want to ensure we do not
830) leave behind. It would require close work with the Tor source code but
831) probably only in the form of building, not authoring.<br />
832) Additionally, we need to automate our performance testing for all platforms.
833) We've got buildbot (except on Windows &mdash; as noted above) to automate
834) our regular integration and compile testing already,
835) but we need to get our network simulation tests (as built in torflow)
836) updated for more recent versions of Tor, and designed to launch a test
837) network either on a single machine, or across several, so we can test
838) changes in performance on machines in different roles automatically.
839) </li>
840) -->
841) 
842) <!-- Removed, unless Mike still wants this to be in.
843) 
844) <li>
845) <b>Torbutton improvements</b>
846) <br />
847) Torbutton has a number of improvements that can be made in the post-1.2
848) timeframe. Most of these are documented as feature requests in the <a
849) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5">Torbutton
850) flyspray section</a>. Good examples include: stripping off node.exit on http
851) headers, more fine-grained control over formfill blocking, improved referrer
852) spoofing based on the domain of the site (a-la <a
853) href="https://addons.mozilla.org/en-US/firefox/addon/953">refcontrol extension</a>),
854) tighter integration with Vidalia for reporting Tor status, a New Identity
855) button with Tor integration and multiple identity management, and anything
856) else you might think of.
857) <br />
858) This work would be independent coding in Javascript and the fun world of <a
859) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
860) with not too much involvement in the Tor internals.
861) </li>
862) 
863) -->
864) 
865) <!-- Is Blossom development still happening?
866) 
867) <li>
868) <b>Rework and extend Blossom</b>
869) <br />
870) Rework and extend Blossom (a tool for monitoring and
871) selecting appropriate Tor circuits based upon exit node requirements
872) specified by the user) to gather data in a self-contained way, with
873) parameters easily configurable by the user.  Blossom is presently
874) implemented as a single Python script that interfaces with Tor using the
875) Controller interface and depends upon metadata about Tor nodes obtained
876) via external processes, such as a webpage indicating status of the nodes
877) plus publically available data from DNS, whois, etc.  This project has
878) two parts: (1) Determine which additional metadata may be useful and
879) rework Blossom so that it cleanly obtains the metadata on its own rather
880) than depend upon external scripts (this may, for example, involve
881) additional threads or inter-process communication), and (2) develop a
882) means by which the user can easily configure Blossom, starting with a
883) configuration file and possibly working up to a web configuration engine.
884) Knowledge of Tor and Python are important; knowledge of
885) TCP, interprocess communication, and Perl will also be helpful.  An
886) interest in network neutrality is important as well, since the
887) principles of evaluating and understanding internet inconsistency are at
888) the core of the Blossom effort.
889) </li>
890) 
891) <li>
892) <b>Improve Blossom: Allow users to qualitatively describe exit nodes they desire</b>
893) <br />
894) Develop and implement a means of affording Blossom
895) users the ability to qualitatively describe the exit node that they
896) want.  The Internet is an inconsistent place: some Tor exit nodes see
897) the world differently than others.  As presently implemented, Blossom (a
898) tool for monitoring and selecting appropriate Tor circuits based upon
899) exit node requirements specified by the user) lacks a sufficiently rich
900) language to describe how the different vantage points are different.
901) For example, some exit nodes may have an upstream network that filters
902) certain kinds of traffic or certain websites.  Other exit nodes may
903) provide access to special content as a result of their location, perhaps
904) as a result of discrimination on the part of the content providers
905) themselves.  This project has two parts: (1) develop a language for
906) describing characteristics of networks in which exit nodes reside, and
907) (2) incorporate this language into Blossom so that users can select Tor
908) paths based upon the description.
909) Knowledge of Tor and Python are important; knowledge of
910) TCP, interprocess communication, and Perl will also be helpful.  An
911) interest in network neutrality is important as well, since the
912) principles of evaluating and understanding internet inconsistency are at
913) the core of the Blossom effort.
914) </li>
915) 
916) -->
917) 
918) <!-- not really suited for GSoC; integrated into TBB for Linux/Mac OS X
919) 
920) <li>
921) <b>Usability testing of Tor</b>
922) <br />
923) Priority: <i>Medium</i>
924) <br />
925) Effort Level: <i>Medium</i>
926) <br />
927) Skill Level: <i>Low to Medium</i>
928) <br />
929) Likely Mentors: <i>Andrew</i>
930) <br />
931) Especially the browser bundle, ideally amongst our target demographic.
932) That would help a lot in knowing what needs to be done in terms of bug
933) fixes or new features. We get this informally at the moment, but a more
934) structured process would be better.
935) </li>
936) 
937) </ol>
938) 
939) <a id="OtherCoding"></a>
940) <h2><a class="anchor" href="#OtherCoding">Other Coding and Design related ideas</a></h2>

941) <ol>

942) 

943) <li>Tor 中继在 Windows XP 上工作得不好。在 Windows 平台，Tor 使用标准的 <tt>select()</tt> 系统调用，
944) 该函数不使用页面文件的空间。这意味着一个中等大小的 Tor 中继就会耗尽全部的物理内存，<a

945) href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">导致

946) 系统极不稳定以致崩溃</a>。我们或许应该使用重叠 IO（overlapped IO）。
947) 一种解决办法是教会 <a href="http://www.monkey.org/~provos/libevent/">libevent</a>

948) 如何在 Windows 上使用重叠 IO 而不是 select()，然后调整 Tor 以使用新的 libevent 接口。
949) 关于这方面的工作，2007年夏天，Christian King已经有了一个
950) <a href="https://svn.torproject.org/svn/libevent-urz/trunk/">不错的开始</a>。
951) </li>
952) 

953) <li>我们需要正式开始构建我们的<a href="<page documentation>#DesignDoc">抗封锁设计</a>。

954) 包括完善设计、修改 Tor 的许多部分、调整 <a href="<page vidalia/index>">Vidalia</a>

955) 以使它支持新特性以及计划部署工作。
956) </li>
957) 

958) <li>我们需要一个灵活的仿真框架来研究端到端的流量验证攻击（traffic confirmation attack）。
959) 许多研究人员仓促制作了特别的仿真器来支持他们的直觉——或者这种攻击很成功，
960) 或者一些抵御手段非常有效。我们能够构建一个文档撰写清晰的、足够开放的仿真器，
961) 令每一个都相信它在给出合理的答案吗？这会激励许多新的研究。查看<a href="#Research">下面</a>关于

962) 验证攻击的研究方面的细节——谁知道呢，如果这个任务完成了或许你也能帮忙写一篇或几篇论文了。
963) </li>
964) 
965) <li>Tor 0.1.1.x 及其后继版本包含对 OpenSSL 硬件密码加速器的支持。但是它只进行过轻量级的测试，可能存在很多
966) 问题，我们需要更认真严格的测试、性能分析和调优、以及代码修正。
967) </li>
968) 

969) <li>对 Tor 执行<a href="http://en.wikipedia.org/wiki/Fuzz_testing">“fuzz”</a>安全测试。

970) 确认有我们需要的好的 fuzzing 库。为你赢得声誉，我们可能因为你而发布新的版本！
971) </li>
972) 

973) <li>Tor 使用 TCP 传输数据，使用 TLS 加密连接。这种设计优雅而简单，
974) 但它意味着一个数据包的丢失就会导致一条连接上的所有单元的延时，它还意味着我们只能支持 TCP 流。

975) 我们列出了<a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">我们

976) 为什么还不转而使用 UDP 传输的理由</a>，这些理由越少越好。我们还提出了一个 <a
977) href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">Tor 和 UDP 的规格说明</a>——如果

978) 什么地方错了，请告诉我们。
979) </li>
980) 
981) <li>我们离在出口节点对 IPv6 的支持并不远。如果你非常在意 IPv6，或许该从这里着手。
982) </li>
983) 
984) <li>
985) 我们需要一个可以从源代码生成网站图片的方案（比如，<a href="<page overview>">概述</a>页面上的
986) “Tor 是如何工作的”这张图片），这样我们就可以用 UTF-8 的文本来进行翻译，而不是像现在这样，使用Gimp
987) 来手工制作图片。我们希望它可以被整合为一个 wml 文件，这样翻译会变得更加方便，而且只要我们进行一次
988) 构建，就可以轻松的生成所有语言的图片。
989) </li>
990) 
991) <li>我们如何让 <a
992) href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
993) 更易于维护，改善以及编写文档？</li>
994) 

995) </ol>
996) 
997) <a id="Research"></a>
998) <h2><a class="anchor" href="#Research">研究</a></h2>
999) <ol>

1000) 

1001) <li>网站指纹攻击（website fingerprinting attack）：列出数百个热门网站，下载它们的页面，
1002) 并为每个站点记录一系列的“指纹”。然后观察 Tor 客户端的流量。当你看到到他接收数据时，
1003) 你就能很快地猜测在那些站点中他正在访问哪一个（如果他访问的网站恰好在其中）。首先，
1004) 这种攻击对现有的 Tor 网络会多有效？然后开始探索抵御手段：例如，我们可以把 Tor 的单元尺寸从
1005) 512 字节变成 1024 字节，我们可以采用像 <a
1006) href="http://freehaven.net/anonbib/#timing-fc2004">defensive dropping</a>
1007) 这样的填充（padding）技术，或者我们可以增加延迟。这些手段会有怎样的影响？在每一种情形下，

1008) 一次成功的抵御对可用性（采用某种合适的衡量标准）会有怎样的影响？
1009) </li>
1010) 

1011) <li>端到端的流量验证攻击（end-to-end traffic confirmation attack）：通过观察 Alice 的和 Bob
1012) 的流量，我们能够<a href="http://freehaven.net/anonbib/#danezis:pet2004">比较流量签名
1013) 并证实我们在观察同样的串流</a>。目前为止 Tor 承认确实如此同时假定在任何情形下这种攻击都无足轻重。
1014) 首先，事实真的是这样吗？敌方需要多少哪种分布的流量才能确认他获胜了？这些方案（如不要传输很多）能

1015) 延缓攻击吗？有些流量填充（traffic padding）或流量整形（traffic shaping）方案比其他方案更好吗？
1016) </li>
1017) 

1018) <li>
1019) 一个相关的问题是，运行一个中继或者网桥，是否能提供对计时攻击的额外保护？如果某个无法看到 TLS 连接
1020) 内部情况的敌意观察者存在的情况下，我们仍然可以认为数据流是安全可靠的吗？大量的数据传输是否降低了
1021) 可靠性？如果一个客户端-中继故意延迟上行数据并为中继数据创建一个队列来模拟客户端下行传输，这样使自己
1022) 看上去似乎是一个中继，这种做法会有所帮助吗？使用<a href="http://www.freehaven.net/anonbib/#ShWa-Timing06">
1023) 自适应填充</a>中提到的技术方案，这个队列同样可用来混淆上行数据的时间，而不需要额外的数据传输。这种
1024) 客户端的交叉上行方案能否真的混淆外部攻击者的计时观察？这样的策略是否需要针对不对称连接作出调整？比如，
1025) 在不对称连接上，它是否能够真正区分出由于连接不对称造成的客户端的正常的流量爆发？或者，是否有其他理由
1026) 导致这比对称连接更加容易？
1027) </li>
1028) 
1029) <li>重复一下来自 Murdoch 和 Danezis 在现在的 Tor 网络上的攻击行为：<a
1030) href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">attack from Oakland 05</a>。看看你
1031) 能否搞清楚为什么它在某些节点上可以成功而在某些节点上却招到了失败。（在我看来，较快的节点为攻击提供了更好
1032) 的兼容性。）如果这是真的，那么运行一个中继，并在中继攻击者的传输时将它作为客户端使用，实验 RelayBandwidthRate
1033) 和 RelayBandwidthBurst 这两个参数的调整：如果我们降低 RelayBandwidthRate，会增加攻击的难度吗？RelayBandwidthRate
1034) 的合适的值是多少？或者它就只是一个传输率参数，跟攻击难度其实没有关系？更大的中继候选是否会增加针对攻击的假阳性错误率
1035) （false positive rate）或者其他复杂性？（Tor 网络的规模现在差不多是他们写那篇论文时的两倍。）请务必读读这篇文章,
1036) <a href="http://freehaven.net/anonbib/#clog-the-queue">Don't Clog the Queue</a> 。

1037) </li>
1038) 

1039) <li>路由区域攻击（routing zones attack）：绝大多数的文献将 Alice 与入口节点（及出口节点与 Bob）
1040) 之间的网络路径看作是图上的单条链路。但实际上，路径会通过许多自治系统（autonomous systems，ASes），
1041) <a href="http://freehaven.net/anonbib/#feamster:wpes2004">同一个 AS 同时出现在入口路径和
1042) 出口路径的情况并不罕见</a>。不幸的是，精确预测 Alice、入口、出口、Bob 四者是危险的，
1043) 我们需要下载整个 Internet 路由区域并对它施行耗费资源的操作。有切实可行的近似方法吗，

1044) 例如避免同一 /8 网络中的 IP 地址？
1045) </li>
1046) 

1047) <li>其他有关地理位置多样性的研究问题考虑了有效电路的选择与随机电路的选择的权衡。Stephen Rollyson
1048) 的<a href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">论文</a>讨论了
1049) 如何在不“过分”影响匿名的情况下放弃特别慢的选择。这些推理需要更多的工作和思考，

1050) 但看上去非常有希望。
1051) </li>
1052) 

1053) <li>当中继的带宽非对称时（如 cable 或 DSL）Tor 不能很好地工作。这是因为 Tor

1054) 在每一跳之间有不同的 TCP 连接，如果输入的数据正常到达而输出的数据丢失了，TCP
1055) 的回推机制并不会将这一信息返回输入流。也许 Tor 自身应该检测到它正在丢失许多输出数据包，
1056) 并对输入的数据流限制速率？我能设想一种递增——递减方案：我们先选择一种保守的速率，
1057) 慢慢提高它直至开始丢包，降低速率，重复。我们需要对网络精通的人士模拟这一方案，

1058) 并帮忙设计解决办法；并且/或者我们需要了解性能下降的程度，这会推动我们重新考虑 UDP 传输。
1059) </li>
1060) 

1061) <li>一个相关的议题是阻塞控制。我们现在的设计足以应付大量用户吗？也许我们应该尝试
1062) 可变大小而不是固定大小的滑动窗口？这一方案在一次 <a
1063) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">ssh 吞吐量试验</a>中表现不错。

1064) 我们需要评估、需要调整，如果结果不错的话，也许会来一次彻底的变化。
1065) </li>
1066) 

1067) <!-- NEED HELP -->
1068) <li>我们反审查机制的目标包括防止攻击者<a href="<svnsandbox>doc/design-paper/blocking.html#sec:network-fingerprint">
1069) 从普通 SSL 传输中区分 Tor 数据包</a>。很明显，我们不可能既做到完美的隐藏又保持可用性，但是，
1070) 首先，我们希望能够阻止攻击者仅仅观察几个数据包就可以取得成功。在这些攻击中，有一个我们没有进行太多测试的
1071) 问题是，Tor 的数据包是以512字节为单位的，因此，传输的数据包可以是512字节的倍数。在物理线路上，
1072) TLS 记录中的这种定量传输能够在多大程度上受到影响？如果 Tor 使用不同的缓冲策略会有所影响吗？作一些填充是否
1073) 会有所帮助，或者这是我们必须接受的攻击？

1074) </li>
1075) 
1076) 

1077) <li>Tor 电路一次建立一跳，因此理论上我们能够使一些数据流在第二跳退出，一些数据流在第三跳退出，等等。

1078) 这看上去不错因为这样一台中继就不能知道退出数据流是哪些了。但是如果要保证每个数据流都是安全的，

1079) 以我们现在的逻辑最短的路径至少需要三跳，其余的将更长。我们需要权衡这种方法的性能与安全。
1080) </li>
1081) 

1082) <li>拒绝服务（DoS）Tor 中继或权威目录并不难。客户端难题（puzzles）是正确的答案吗？

1083) 还有什么其他的实用方法？如果它们能兼容现有的 Tor 协议就更好了。
1084) </li>
1085) 
1086) <!-- NEED TRANSLATION -->
1087) <li>Programs like <a
1088) href="<page torbutton/index>">Torbutton</a> aim to hide
1089) your browser's UserAgent string by replacing it with a uniform answer for
1090) every Tor user. That way the attacker can't splinter Tor's anonymity set
1091) by looking at that header. It tries to pick a string that is commonly used
1092) by non-Tor users too, so it doesn't stand out. Question one: how badly
1093) do we hurt ourselves by periodically updating the version of Firefox
1094) that Torbutton claims to be? If we update it too often, we splinter the
1095) anonymity sets ourselves. If we don't update it often enough, then all the
1096) Tor users stand out because they claim to be running a quite old version
1097) of Firefox. The answer here probably depends on the Firefox versions seen
1098) in the wild. Question two: periodically people ask us to cycle through N
1099) UserAgent strings rather than stick with one. Does this approach help,
1100) hurt, or not matter? Consider: cookies and recognizing Torbutton users
1101) by their rotating UserAgents; malicious websites who only attack certain
1102) browsers; and whether the answers to question one impact this answer.
1103) </li>
1104) 
1105) <!-- NEED TRANSLATION -->
1106) <li>Right now Tor clients are willing to reuse a given circuit for ten
1107) minutes after it's first used. The goal is to avoid loading down the
1108) network with too many circuit extend operations, yet to also avoid having
1109) clients use the same circuit for so long that the exit node can build a
1110) useful pseudonymous profile of them. Alas, ten minutes is probably way
1111) too long, especially if connections from multiple protocols (e.g. IM and
1112) web browsing) are put on the same circuit. If we keep fixed the overall
1113) number of circuit extends that the network needs to do, are there more
1114) efficient and/or safer ways for clients to allocate streams to circuits,
1115) or for clients to build preemptive circuits? Perhaps this research item
1116) needs to start with gathering some traces of what connections typical
1117) clients try to launch, so you have something realistic to try to optimize.
1118) </li>
1119) 
1120) <!-- NEED TRANSLATION -->
1121) <li>How many bridge relays do you need to know to maintain
1122) reachability? We should measure the churn in our bridges. If there is
1123) lots of churn, are there ways to keep bridge users more likely to stay
1124) connected?
1125) </li>
1126) 

1127) </ol>
1128) 

1129) <p>

1130) 如果你在以上任何一点取得了进展，请<a href="<page contact>">告诉我们</a>！

1131) </p>