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

为什么 WebRTC 属于隐私策略

WebRTC 让网页支持通话、会议、在线客服和点对点媒体，也让浏览器拥有一条独立的网络身份信息面。页面可以获得与连接相关的候选地址，并在会话进行时看到统计信息。即使普通页面请求使用代理，这些信息仍然具有隐私价值。

关键问题不是要不要存在 WebRTC。许多人需要它来参加会议或进行协作。关键问题是 WebRTC 展示的网络信息，是否与当前会话选择的网络身份一致。隐私策略应当明确这个选择，写清楚取舍，并让一个浏览器上下文在整个生命周期内保持可解释的结果。

BotBrowser 提供三种策略状态：profile、real 和 disabled。profile 让 WebRTC 网络信息与浏览器配置文件保持协调。real 使用主机环境的网络身份。disabled 在工作流不需要实时通信时关闭 WebRTC 能力。它们没有统一适用于所有场景的答案，选择应由会话目的和组织接受的隐私边界决定。

这项策略围绕数据最小化和网络身份一致性，重点关注 candidate 与 statistics 地址的一致关系。可先阅读 WebRTC 泄漏防护，再查看 网络功能 的整体说明。

浏览器可能透露什么

准备 WebRTC 会话时，浏览器会整理可用于媒体通信的路径。candidate 记录可能包含本地接口地址、映射后的公共路径或中继地址。会话运行时，statistics 还可能提供另一种地址视图。它们的用途不同，但都属于同一个隐私边界。

地址信息可能把浏览器会话与网络、地区、机构或家庭联系起来。私有地址可以显示本地网络的形状，公共地址可能标识主机的出口，中继地址可能指向通信服务或地区。单项信息未必敏感，组合起来却可能形成稳定的关联线索。

普通页面请求和 WebRTC 通信路径有关联，但不是同一条路径。代理可以让页面请求使用一个公共身份，而 WebRTC 可能使用另一路由。只检查页面流量并不能说明整个会话的隐私状态。策略也应当考虑 WebRTC 可以提供的地址信息。

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

三种策略状态

Profile：与选定身份协调

profile 适用于已经定义网络身份的浏览器上下文。WebRTC 仍然可用，同时浏览器提供的地址信息与该身份保持协调。candidate 和 statistics 应当描述同一条选定路线。

当工作流需要通话，又希望拥有清晰的网络边界时，这通常是直接的起点。它保留浏览器通信能力，也减少独立 WebRTC 视图显示主机路线的机会。策略仍然依赖网络配置质量，配置文件不能替代对代理提供方、地区和数据处理规则的审查。

profile 的重点是协调。页面请求、candidate 和 statistics 被看作同一网络身份的不同部分，而不是互不相关的设置。代理更换或配置文件变更时，应当把它们当作新的隐私决定，避免一个长期上下文同时包含两条路线的观察结果。

Real：使用主机网络身份

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

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

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

Disabled：移除不需要的能力

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

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

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

Candidate 与 statistics 为什么要一致

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

所以一致性是策略属性，不是显示细节。profile 要求两种视图与配置文件路线相容。real 要求两种视图都被理解为主机拥有的信息。disabled 则不应存在产生这两种视图的 WebRTC 通信能力。目标不是某个固定地址，而是所选状态与可暴露信息之间有清楚的关系。

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

可执行的治理方式

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

接着定义 candidate 和 statistics 的预期关系。可以只写高层规则：两种视图都应与同一个选定身份相容。除非经过批准，不要保留比运营需要更多的地址细节。记录访问应遵循与 Cookie、账户资料及会话状态相同的数据最小化原则。

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

常见问题

代理会自动保护 WebRTC 吗？

不会。代理可以控制普通页面请求，而 WebRTC 使用独立的通信路径。需要确认的是，所选状态是否让 candidate 和 statistics 地址与预期网络身份相容。

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

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

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

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

为什么要比较 candidate 和 statistics？

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

网络能在会话中变化吗？

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

结语

WebRTC 隐私本质上是网络身份决策。profile、real 和 disabled 提供了三种清楚的选择。只要有意识地选择，并让 candidate 与 statistics 表达同一个状态，策略就更容易维护。需要通信时，profile 协调可以保留能力并明确边界；主机路线有意使用时，real 让暴露成为明确决定；通信不需要时，disabled 可以移除多余的能力。

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