WebRTC 网络身份与隐私：如何选择策略

BotBrowser 支持受控的 WebRTC 网络身份设置，可以把 WebRTC 网络信息与已加载的配置文件协调起来；但它不会让对等连接匿名，也不保证该上下文之外的隐私。

摘要

WebRTC 会收集页面代理看不到的地址。为每个上下文选定一种状态（profile、real 或 disabled）并记录下来。在 WebRTC 连接中检查 ICE candidate 与 getStats()，再通过获准的外部服务单独查询公网地址；这是两种不同的观察结果。

目录

• 为什么 WebRTC 属于隐私策略
• 浏览器可能透露什么
• 三种策略状态
• 如何解读 candidate 与 statistics 记录
• 可执行的治理方式
• 实践结论

为什么 WebRTC 属于隐私策略

WebRTC 让网页支持通话、会议、在线客服和点对点媒体，也让浏览器拥有一条独立的网络身份信息面。页面可以获得与连接相关的候选地址，并在会话进行时看到统计信息。即使普通页面请求使用代理，这些信息仍然具有隐私价值。在受控的上下文中，BotBrowser 可以让 WebRTC 网络信息与已配置的配置文件保持协调；它不能让对等连接匿名，也不能保证该上下文之外的隐私。

关键问题不是要不要存在 WebRTC。许多人需要它来参加会议或进行协作。关键问题是所选上下文策略下，WebRTC API 会暴露哪些地址信息。隐私策略应明确状态与取舍，并在路线变化时重新审查观察结果。

BotBrowser 提供三种策略状态：profile、real 和 disabled，分别对应配置文件策略、主机网络和 WebRTC 不可用。在 profile 下，已配置的 SDP 与 ICE 控制旨在让 WebRTC 地址信息符合声明的配置文件身份；应核对适用的代理和 UDP 条件，不能把这一设计目标当作公网出口测量。它们没有统一适用于所有场景的答案，选择应由会话目的和组织接受的隐私边界决定。

这项策略围绕数据最小化，并要求谨慎解读 candidate 与 statistics 记录。可先阅读 WebRTC 泄漏防护，再查看 网络功能 的整体说明。

浏览器可能透露什么

准备 WebRTC 会话时，浏览器会整理可用于媒体通信的路径。candidate 带有 candidate 类型：host 表示本地接口，srflx 表示服务器反射映射，relay 表示 TURN 地址，此外还包括地址本身（见 RFC 8445）。会话运行时，RTCPeerConnection.getStats() 会给出 local-candidate、remote-candidate 和 candidate-pair 记录；选中的 pair 标识当前承载媒体的路线（见 WebRTC 统计）。这些记录可用于把 WebRTC 路由观察与上下文策略对照，但不能独立测量页面请求使用的公网出口。

地址信息可能把浏览器会话与网络、地区、机构或家庭联系起来。私有地址可以显示本地网络的形状，公共地址可能标识主机的出口，中继地址可能指向通信服务或地区。单项信息未必敏感，组合起来却可能形成稳定的关联线索。关于 mDNS 主机候选如何改变页面能够了解的本地网络信息，请参阅WebRTC mDNS 候选与本地网络隐私，其中介绍了 mDNS 候选与 RFC 8828 的隐私目标。

普通页面请求和 WebRTC 通信路径有关联，但不是同一条路径。代理可以让页面请求使用一个公共身份，而 WebRTC 可能使用另一路由。只检查页面流量并不能说明整个会话的隐私状态。策略也应当考虑 WebRTC 可以提供的地址信息。关于如何让代理路由、DNS 与 WebRTC 在整个工作流中保持一致，请参阅代理、DNS 与 WebRTC 的浏览器身份一致性，其中介绍了代理、DNS、时区与 WebRTC 的一致性。

隐私工作还要考虑可用性。禁止所有通信能力会减少暴露面，却可能影响会议、客服和协作。较好的做法是先明确上下文用途，再选择状态，并让会话负责人知道剩余暴露范围。

三种策略状态

Profile：检查配置的身份策略

profile 为上下文提供明确的网络策略，供审查者与 candidate、statistics 记录对照。如果 SOCKS5 代理支持 UDP ASSOCIATE 且 BotBrowser 成功建立关联，STUN 可以经该代理传输，ICE candidate 也可能反映代理地址。选中的 candidate pair 描述 WebRTC 媒体路线，不是对页面请求公网出口的独立测量。组织应记录每个上下文的分配路线，并把两类观察结果分别与该路线核对。

当工作流需要通话和有记录的隐私边界时，这种状态可能适用。它保留 WebRTC 能力并应用已配置策略；实际结果仍取决于代理和网络条件。配置文件不能替代对代理提供方、地区和数据处理规则的审查。关于 QUIC 与 WebRTC 的 UDP 流量如何遵循同一份代理方案，请参阅UDP over SOCKS5：QUIC 与 WebRTC 隐私路由，其中介绍了按上下文设置的 TCP 与 UDP 代理策略。

profile 让团队可以把明确的上下文策略与 candidate、statistics 记录一起审查，但不能证明页面请求与 WebRTC 使用相同路线。代理、配置文件或路线变化时，应记录新的决定，并在不假定观察结果一致的情况下比较它们。

Real：使用主机网络身份

real 明确选择主机环境提供的网络身份。它可以用于本地开发、内部验证，或明确需要主机路线的通信工作流。它不是隐私保护状态，主机网络可能被通信另一端或接收 WebRTC 地址信息的服务看到。

把选择写成 real 比让它保持隐含更容易管理。主机可能有多个接口，公共路线可能变化，企业网络也可能有自己的披露规则。组织应记录该网络的负责人，以及将主机地址用于此会话是否合适。

在授权的本地环境中，real 也可用于排查连接问题。排查会话应有负责人、有限的使用期限和明确的记录，不能因为一次排查就把主机身份带入其他隐私工作流。

Disabled：移除不需要的能力

当工作流不需要浏览器实时通信时，disabled 可以减少页面可用的信息面。它也意味着通话、媒体共享及依赖 WebRTC 的其他功能无法使用。

Disabled 应该是明确的产品决定，而不是故障造成的意外结果。用户需要知道会议为什么无法启动，团队也不应把 disabled 上下文当作通用浏览环境。如果以后需要通信，应切换到有文档说明的 profile 或 real 上下文。

这个状态有可用性代价。有些网页在没有实时通信时会改变体验。当隐私要求高于通信要求时，这种代价可以接受，但应记录下来，让支持人员能区分策略和故障。

如何解读 candidate 与 statistics 记录

两个视图可能各自看起来合理，却表达不同的网络故事。candidate 记录可能描述一条路线，statistics 随后描述另一条路线。页面请求使用代理，而通信路径显示主机，或者配置文件指向一个地区而地址来自另一个地区，都会扩大页面可以关联会话的信息量。

比较是检查策略的方法，并不保证两个 API 视图一定一致。profile 状态下，检查 candidate 和实际选用的 pair，再结合上下文分配的路线解读。real 状态下，把暴露的地址视为主机网络信息。disabled 状态下，确认 WebRTC 能力不可用。结果可作为审查依据，但不保证某个具体地址或路线。

网络切换、代理替换或配置文件变化都可能改变路线。发生变化时，应重新审查上下文的隐私决定。共享机器不代表必须共享网络身份，但每个上下文都应有独立且可解释的状态。

状态	ICE candidate 类型	getStats() 视图	适用场景
profile	跟随已加载配置	检查实际选用的 candidate 与 pair 记录	通话必须在声明的浏览器身份下可用
real	主机接口地址（host、srflx）	检查主机 candidate 与 pair 记录	主机路由就是预期身份
disabled	没有 WebRTC candidate	WebRTC transport 不可用	工作流完全不需要实时媒体

可执行的治理方式

多数团队只需要一份简短策略。先为工作流指定用途，例如通信、本地开发、内部验证或隐私敏感浏览。记录是否需要 WebRTC，再选择 profile、real 或 disabled，同时写明路线负责人。

接着确定要检查哪些 candidate 和 statistics 记录。把观察结果与上下文策略对照，但不要预设它们必然一致，也不要认为它们能标识公网出口。除非经过批准，不要保留比运营需要更多的地址细节。记录访问应遵循与 Cookie、账户资料及会话状态相同的数据最小化原则。

维护阶段要把代理、配置文件、网络接口和通信需求的变化视为策略变化。用户开始通话时，应知道会话使用配置文件路线、主机路线，还是没有 WebRTC 能力。打开 disabled 上下文时，也应得到清楚的产品说明，而不是反复重试。

常见问题

代理会自动保护 WebRTC 吗？

不会。代理可以控制普通页面请求，而 WebRTC 使用独立的通信路径。应分别检查 ICE candidate 与实际选中 candidate pair 的统计，再依据上下文策略解读；这些视图本身都不能测量公网出口。

每个上下文都应该使用 profile 吗？

不一定。需要 WebRTC 且已经定义网络身份时，profile 很合适。主机路线明确属于工作流时可以选择 real，不需要通信时可以选择 disabled。状态应跟随用途，而不是成为不加区分的全局设置。

disabled 是否总是隐私最好的选择？

它减少了一个通信面，却同时移除了合法的浏览器能力。如果用户需要会议，disabled 可能促使人们寻找未经管理的替代方案。需要通信时，有文档的 profile 策略通常更容易平衡可用性与隐私。

为什么要比较 candidate 和 statistics？

它们是通信路径的不同视图。比较它们的隐私含义，有助于判断上下文是否呈现一个连贯的网络身份，或是否混入了不同路线的信息。审查应在组织控制的流程中进行，并尽量减少不必要的数据收集。

网络能在会话中变化吗？

可以。接口、路由和用户所在网络都可能变化。变化发生时，应重新审查上下文状态，避免把属于不同路线的观察结果合并理解。

隐私审查应该保留什么？

保留所选状态、上下文用途、路线负责人和审查决定。地址细节只在有已批准的操作需要时才写入记录，访问权限应与会话状态保持同等限制。

来源

• RFC 8445：Interactive Connectivity Establishment
• RFC 8828：WebRTC IP 地址处理要求
• W3C WebRTC 统计
• W3C WebRTC 1.0

实践结论

WebRTC 隐私本质上是网络身份决策。profile、real 和 disabled 提供了三种清楚的选择。选择状态后，检查 candidate 和 statistics 记录，并按上下文策略解读，不要预设它们必然一致或能揭示公网出口。需要通信时，profile 协调可以保留能力并明确边界；主机路线有意使用时，real 让暴露成为明确决定；通信不需要时，disabled 可以移除多余的能力。

可继续阅读 WebRTC 泄漏防护 和 网络功能，把选择的状态与每个工作流一起记录。

把每个上下文的状态写进运行记录。在获准的测试页面中检查 ICE candidate 和 getStats() 记录，再用获准的外部服务单独查询公网地址。把 real 上下文当作有意选择的主机网络决定，而不是疏漏；把 disabled 上下文当作 WebRTC API 不可用的工作流。网络切换、代理轮换或浏览器大版本更新后，重新做这两项核对。