作者注：Firefox 最近添加了一些功能（在 Firefox 42 中），允许用户对 WebRTC RTCPeerConnections、用于连接它们的 IP 地址收集以及向 JS 应用程序公开哪些 IP 地址进行更多控制。有关此功能解决的问题和 Firefox 解决此问题的详细说明，请参阅我的 (Maire 的) 个人博客文章。有关问题、风险、权衡和推理的讨论最好在该博客文章中进行。本文介绍代码中的新功能以及如何访问它们。

Maire Reavy
WebRTC 工程经理

为了控制 IP 地址公开和 RTCPeerConnection 的使用，我们提供了方法来挂钩 createOffer/createAnswer，并添加了 about:config 首选项来控制 ICE 协商期间哪些候选人可用。此外，about:config 中已经存在一些控制措施。您可以在 Mozilla 的 关于 WebRTC 隐私的 wiki 页面 上了解更多关于可用控制措施的信息。

createOffer/createAnswer 挂钩允许扩展修改 PeerConnection 的行为，例如，添加一个门廊挂钩，类似于网站使用 getUserMedia API 访问摄像头和麦克风时出现的门廊挂钩。我们已经做了一个 概念验证扩展，以下是如何为仅使用 DataChannel 的网站进行操作：

从用户交互的角度来看，重要的是以用户可以理解的非吓人的方式请求访问权限。对于 getUserMedia，即访问用户的摄像头和麦克风，询问的问题是

您是否想与 webrtc.github.io 共享您的摄像头和麦克风？

该问题的含义非常清楚，因为该网站可以录制您的语音和视频，并可能将其发送给其他人。

示例扩展的门廊挂钩将在两种情况下弹出

• 该网站使用仅接收连接，即仅接收视频 - 您可以在 此处 进行测试。
• 该网站使用数据通道，而无需像 此示例 所示那样调用 getUserMedia。

对于网站已获得访问摄像头和麦克风的权限的情况，例如 Talky.io，不会再询问其他问题。这最大限度地减少了用户需要回答的问题数量，并保留了大部分现有行为。

对于仅接收的情况，询问问题会更尴尬。这里的使用场景是单向流媒体，例如网络研讨会。用户并不期望在此处被要求获得权限，因为观看 YouTube 上的录制视频不需要您授予类似的权限。

对于数据通道，存在许多不同的使用场景，从文件传输到游戏到点对点 CDN。对于文件传输，工作流程相当容易向用户解释 - 他们选择一个文件，门廊挂钩弹出，他们允许它，文件被传输。用户操作和弹出窗口之间存在直接联系。这同样适用于游戏。

点对点 CDN 使用场景比较困难。您开始播放视频，浏览器要求使用 DataChannel？！如果您是一名依赖此使用场景的开发人员，我们建议您尝试 示例扩展，并使用它围绕该使用场景开发良好的用户体验。我们很乐意听到您在现实世界中的反馈。

在最近报道的纽约时报略显 令人惊讶的 WebRTC 使用情况 中，开发人员将“欺诈检测”列为使用场景。WebRTC 不是为了解决这个问题而构建的，并且存在更好的工具和技术可以完成这项工作。我们敦促您使用这些工具和技术。

如果您是扩展开发人员，您可以查看 扩展的源代码 以了解实现此交互所需的内容；您基本上需要覆盖 webrtcUI.receiveMessage 处理程序中对 rtcpeer:Request 的处理。如果您有任何问题，请在评论中或在 github 上提交问题。