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) 

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

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

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

88) </ol>
89) 

90) 

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

94) 

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

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

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

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

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

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

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

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

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

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

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

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

943) <ol>

944) 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1002) 

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

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

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

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

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

1039) </li>
1040) 

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

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

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

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

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

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

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

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

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

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

1076) </li>
1077) 
1078) 

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

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

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

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

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

1129) </ol>
1130) 

1131) <p>

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

1133) </p>