Tor Browser 很容易被说坏。"Private browsing" 会让它听起来像一个更强的无痕窗口。"The dark web browser" 又会把一件范围宽得多的隐私工具压成小报式道具。"A VPN alternative" 则遮住了最关键的架构差异:Tor 不是一个需要你信任的代理。它是一整套协议设计、relay 选择、浏览器加固、审查绕过、洋葱服务语义和用户纪律的组合,只有这些部分保持在一起时,整套隐私能力才成立。[1][6]

这个组合本身就是项目。浏览器是用户看得见的表面,但它的价值来自许多隐私决策已经替用户预先完成。它会把网页流量送入 Tor circuits。它会努力降低用户之间的可区分度。它会为受审查网络暴露网桥设置。它让洋葱服务拥有一条一等路径。它同时也划出清楚界线:Tor Browser 之外的活动不会自动匿名化,浏览器之内的行为仍然会破坏威胁模型。[3][4][5][6]

图片语境:题图显示 Roger Dingledine 在 DEF CON 2023 的现场。它与本文相关,因为 Tor Browser 应被理解为一个长期研究与运维项目的产物,而不是通用浏览器里的单个隐私开关。[8]

网络边界是一条电路

Tor 最初的设计论文把 Tor 描述为面向交互式互联网使用的低延迟、基于电路的匿名系统。客户端会从 relays 中选择一条路径并建立 circuit,每个 relay 只知道自己的前一个节点和后一个节点,不知道完整路径。流量以固定大小的 cells 移动,每一跳移除一层 relay 加密。Tor 的核心分布式信任属性就在这里:单个 relay 不应该同时看见用户是谁,以及用户最终抵达哪个目的地。[1]

这也是为什么把它从 "VPN alternative" 讲起会偏离重点。VPN 把信任转移给一个提供商。Tor 把信任分散到一条路径上,并试图阻止任何单点掌握完整图像。这样的设计没有魔法。那篇设计论文对取舍说得很明白:Tor 面向低延迟使用,因此不宣称能击败一个同时监视连接两端并关联时间或流量体积的强对手。更窄也更有用的实践安全主张是:Tor 通过把路由知识拆散到多个 relays 上,让普通流量分析变得更难。[1]

现代规范工作之所以重要,是因为这条边界必须能被实现,而不只是停留在传闻里。Tor specifications 对协议作出足够详细的描述,让兼容实现可以不阅读源代码也能开发出来;它也提醒读者,规范会滞后于当前实现细节,未来协议版本还会改变兼容性假设。[2] 对 operators 和工程师来说,这正是严肃 OSS 项目的信号:行为不仅存在于代码库,也存在于一份公开协议契约中,可供审阅、更新和质疑。

浏览器是匿名集合的一部分

Tor Browser 的第二条重要边界在应用层。网络可以隐藏路由信息,但浏览器仍会从字体、屏幕尺寸、语言、user agent、APIs、cookies、持久状态和用户自定义中泄露身份。因此,Tor Browser 的反指纹工作属于匿名模型的中心组成部分,远超过装饰性加固。[3]

项目支持文档把目标讲得很清楚:让用户更难被分进独一无二的浏览器指纹桶。Letterboxing 会把内容窗口归整到常见尺寸组;user-agent 处理会减少醒目的平台信号;first-party isolation 及相关防护会尽量阻止跟踪状态变成跨站标识符。这些措施不能让每个用户完全相同。目标在于防止浏览器把 relay 网络的匿名集合拆成一堆一人一份的指纹。[3]

重度自定义也因此会带来反效果。在普通浏览器里,扩展、字体、窗口尺寸、语言设置和插件行为看起来只是无害的个人偏好。放进 Tor Browser 里,过多个人化就会变成信标。用户安装少见扩展,或者在不了解指纹后果的情况下改变设置,即使接入了正确网络,也会让自己更加突出。

实际采用规则很简单:把 Tor Browser 当作一件专用设备使用时,它表现最好。保持更新。避免把它变成日常浏览器 profile。审慎使用安全等级和网站权限。当匿名性很重要时,浏览器那些乏味的默认设置属于安全架构的一部分,不是入门训练轮。

网桥把审查变成连接问题

Tor 还必须能在公共 relay 网络被封锁的地方工作。网桥就在这里出现。Tor bridges service 把 bridges 描述为帮助用户绕过审查的 Tor relays,并说明网桥分发可以通过浏览器流程和替代渠道完成。[4] 在受审查网络里,这改变了第一公里问题:用户不仅需要对目的地保持隐私,还需要先找到抵达 Tor 的办法。

最近的 Tor Browser 工作显示,可用性和抗审查已经变成同一个工程问题。Tor Browser 14.5 release 在早先桌面端工作的基础上,把 Connection Assist 引入 Android;面对严格审查的用户在直连 Tor 失败时,可以让浏览器尝试寻找并使用 bridges。同一份 release note 还描述了后端重构,目标是减少跨平台 legacy 与冗余代码,并提到后续围绕 circuit display 和 Arti integration 的工作空间。[7]

这是很有用的项目信号。成熟隐私工具一旦要求处在压力中的用户自行调试传输策略,就会失效。网桥分发、连接诊断和平台整合都不是旁支任务。它们决定协议能否被最需要它的人真正用起来。

边界条件在于,bridges 是审查规避工具,不是隐身保证。bridge 可以在公共 Tor relays 被封锁时帮助用户连接。它不会让危险行为变得安全,也不会抹掉某人曾经寻求 Tor access 的全部历史网络证据。更准确的心智模型要收窄一些:门被挡住时,bridges 是穿过这道门的方法。

洋葱服务不只是 "dark web"

洋葱服务是另一个公共叙事经常扭曲工程事实的地方。Tor hidden-service specification 描述的是一条不同于普通 Tor 浏览的隐私边界。在普通 Tor 连接中,客户端获得匿名性,目的地服务器仍是公共互联网端点。洋葱服务追求双向匿名:服务运营者和用户通过 introduction 与 rendezvous 机制通信,同时避免把服务器的普通网络位置暴露给用户。[5]

当前 v3 onion-service design 也改变了旧版 hidden services 的密码学和目录假设。规范提到的改进包括:用 SHA3、ed25519 和 curve25519 替换旧的 SHA1、Diffie-Hellman 和 RSA1024 组件;减少 directory servers 能学到的信息;提高 onion address 抵抗冒充的安全性;并加入 offline keys 与 restricted discovery modes 支持。[5]

这一点重要,是因为洋葱服务并非与 web 分离的另一个地下世界。它是一项 responder-anonymity 功能,有正当用途:whistleblowing endpoints、抗元数据发布、在监视压力下更安全地访问服务,以及以位置隐私为重点的基础设施实验。它也会被滥用,正如任何通用网络功能都会被滥用。工程主张并不是说每一个 onion service 都是好的。主张在于,这套机制给服务器提供了一条不同于普通托管的暴露边界。

对开发者来说,即使从不运营洋葱服务,也值得研究它。它展示了 Tor 的设计词汇如何从“向目的地隐藏客户端”延伸到“向客户端和网络隐藏服务位置”。这个区别在随意的隐私讨论里经常丢失。

Tor Browser 适合放在哪里

当威胁模型关心的是把浏览行为与真实网络身份解绑、降低 tracker 可见度、在监视压力下阅读或发布、抵达被封锁信息,或者避免把浏览元数据交给单一公司保管时,Tor Browser 最适合进入讨论。Electronic Frontier Foundation 的 Surveillance Self-Defense 指南给出了最清楚的用户侧边界:Tor Browser 可以让通过 Tor 进行网页浏览变得更容易,但只有 Tor Browser 里的活动会被 Tor Browser 匿名化。安装它不会让另一个浏览器、聊天应用、torrent client、文档查看器或操作系统后台流量自动匿名。[6]

这个限制体现的是诚实的产品边界,并非缺陷。Tor Browser 服务于网页活动这一条谨慎路径,整台机器的隐私保护不在它的承诺范围内。如果用户登录个人账号、上传可识别身份的文件、打开会回连的下载文档、启用高风险浏览器功能,或者把敏感工作转移到非 Tor apps 里,relay 路径救不了这些操作失误。[6]

工程上的启发在于,当团队抵抗那些会压塌边界的便利功能时,Tor Browser 最强。项目需要在兼容性、速度、抗审查、可访问性和匿名集合纪律之间取得平衡。摩擦太多会流失用户,用户变少又会削弱匿名性。自定义太多会让用户变得独特。文档太少会让人作出危险假设。这就是为什么 Tor Browser 最重要的设计工作常常并不耀眼:默认设置、网桥流程、指纹桶、circuit 可见性、发布纪律,以及用平实语言写出的警告。

对 OSS 评估者来说,Tor Browser 不适合被当作工具观光式选择。它是一项关于打包组合的案例研究。协议需要浏览器。浏览器需要网络。网络需要志愿 relays 和网桥分发。洋葱服务需要比 "dark web" 更清楚的语言。用户需要明白说出的限制。在这个项目里,隐私呈现为一组必须保持对齐的边界,超过单项设置本身。

来源

  1. Roger Dingledine、Nick Mathewson 和 Paul Syverson,"Tor: The Second-Generation Onion Router",Tor Project 归档的设计论文,涵盖 circuits、relays、directory servers、threat model 和可部署性取舍。
  2. Tor Project,"Tor specifications":说明公开协议规范及其面向实现兼容性的目的。
  3. Tor Project Support,"How Tor Browser protects you against browser fingerprinting":涵盖 letterboxing、user-agent handling、first-party isolation,以及通过减少醒目浏览器指纹来维持匿名集合的目标。
  4. Tor Project,"Tor bridges":解释 bridges 作为用于审查规避的 Tor relays,并列出网桥分发路径。
  5. Tor Specifications,"Hidden services: overview and preliminaries":涵盖 bidirectional anonymity、hidden-service roles、introduction points、HSDirs,以及 v3 onion-service improvements。
  6. Electronic Frontier Foundation,Surveillance Self-Defense,"How to: Use Tor":解释 Tor Browser 的实践边界、收益和用户安全限制。
  7. Tor Project Blog,"New Release: Tor Browser 14.5",2025 年 4 月 16 日:涵盖 Android 上的 Connection Assist、网桥可用性、shared backend refactoring,以及未来 circuit-display/Arti 的后续工作展望。
  8. Wikimedia Commons,"Roger Dingledine DEFCON 2023 presentation.jpg":本文题图所用的真实照片。