几件每个人都可以做的事:
- 请考虑运行一台中继帮助 Tor 网络成长。
- 告诉你的朋友！请他们运行中继。请他们运行隐匿服务。请他们告诉他们的朋友。
- 如果你认同 Tor 的目标，请花一些时间捐助以支持 Tor 的后继开发。 我们正在寻求资助与赞助商，如果你还知道任何需要匿名、私有、通信安全的公司、非政府组织、 代理商或其他组织，把我们告诉他们。
- 我们在寻找一些使用 Tor 的好的例子。 如果你使用 Tor 的目的和方式我们还不了解，我们会很高兴你能告诉我们你的故事。
支撑应用
- 我们需要更多更好的办法拦截 DNS 请求，这样，当我们想要匿名时，DNS 请求就不会泄露给本地的窃听者。 （会发生这种情况是因为应用程序在使用 SOCKS 代理之前进行了 DNS 解析。）
- Tsocks/dsocks 相关：
- 我们需要应用 我们所有的 tsocks 补丁并维护一个新的分支。如果你需要，我们将提供空间。
- 我们应该修补 Dug Song 的“dsocks”程序，令其从控制接口使用 Tor 的 mapaddress 命令， 这样我们就不用浪费连接前在 Tor 内部作解析的整个时间。
- 我们需要使我们的 torify 脚本检测安装的是 tsocks 还是 dsocks，并恰当地调用它们。 这或许意味着统一它们的接口，也许还包括在它们之间共用代码或弃用其中之一。
- 运行中继的志愿者告诉我们他们想在一天中的某个时间段限制一种速率，在其他的时间段限制另一种速率。 我们应当写一个脚本通过 Tor 控制接口修改带宽限制，而不是把代码加入 Tor。 Unix 和 Mac 已经有了这样的一个脚本（它使用了 bash 和 cron），但是 Windows 用户仍缺少解决方案。
- 我们反审查机制的目标包括防止攻击者 从普通 SSL 传输中区分 Tor 数据包。很明显，我们不可能既做到完美的隐藏又保持可用性，但是， 首先，我们希望能够阻止攻击者仅仅观察几个数据包就可以取得成功。在这些攻击中，有一个我们没有进行太多测试的 问题是，Tor 的数据包是以512字节为单位的，因此，传输的数据包可以是512字节的倍数。在物理线路上， TLS 记录中的这种定量传输能够在多大程度上受到影响？如果 Tor 使用不同的缓冲策略会有所影响吗？作一些填充是否 会有所帮助，或者这是我们必须接受的攻击？
- Tor 电路一次建立一跳，因此理论上我们能够使一些数据流在第二跳退出，一些数据流在第三跳退出，等等。 这看上去不错因为这样一台中继就不能知道退出数据流是哪些了。但是如果要保证每个数据流都是安全的， 以我们现在的逻辑最短的路径至少需要三跳，其余的将更长。我们需要权衡这种方法的性能与安全。
- 拒绝服务（DoS）Tor 中继或权威目录并不难。客户端难题（puzzles）是正确的答案吗？ 还有什么其他的实用方法？如果它们能兼容现有的 Tor 协议就更好了。
- Programs like Torbutton aim to hide your browser's UserAgent string by replacing it with a uniform answer for every Tor user. That way the attacker can't splinter Tor's anonymity set by looking at that header. It tries to pick a string that is commonly used by non-Tor users too, so it doesn't stand out. Question one: how badly do we hurt ourselves by periodically updating the version of Firefox that Torbutton claims to be? If we update it too often, we splinter the anonymity sets ourselves. If we don't update it often enough, then all the Tor users stand out because they claim to be running a quite old version of Firefox. The answer here probably depends on the Firefox versions seen in the wild. Question two: periodically people ask us to cycle through N UserAgent strings rather than stick with one. Does this approach help, hurt, or not matter? Consider: cookies and recognizing Torbutton users by their rotating UserAgents; malicious websites who only attack certain browsers; and whether the answers to question one impact this answer.
- Right now Tor clients are willing to reuse a given circuit for ten minutes after it's first used. The goal is to avoid loading down the network with too many circuit extend operations, yet to also avoid having clients use the same circuit for so long that the exit node can build a useful pseudonymous profile of them. Alas, ten minutes is probably way too long, especially if connections from multiple protocols (e.g. IM and web browsing) are put on the same circuit. If we keep fixed the overall number of circuit extends that the network needs to do, are there more efficient and/or safer ways for clients to allocate streams to circuits, or for clients to build preemptive circuits? Perhaps this research item needs to start with gathering some traces of what connections typical clients try to launch, so you have something realistic to try to optimize.
- How many bridge relays do you need to know to maintain reachability? We should measure the churn in our bridges. If there is lots of churn, are there ways to keep bridge users more likely to stay connected?
如果你在以上任何一点取得了进展，请告诉我们！