Media/WebRTC/Privacy

This page gathers information related to privacy in WebRTC. This is a Work-In-Progress and more categories need to be added.

Note: this page is for documenting options, not for discussion.

Address leakage and VPNs

Undocumented

A lot has yet to be documented, and a lot has been and has yet to be implemented. In the vacuum, prefs like media.peerconnection.ice.proxy_only_if_behind_proxy are getting 'documented' like this.

Test

• a test for WebRTC leaks (partial?)

Prefs that control ICE Candidate generation

All of these can be set from about:config, or controlled via an extension

• media.peerconnection.ice.force_interface -- string (default "") -- interface name to match for ICE (Firefox 43, uplifted to 42, requested for 41) -- bug 1189040
  • If set, and there is no interface that matches exactly, NO candidates will be generated
  • If set and there is a match, that interface will be used solely for ICE. Local (LAN) and external IP addresses for that interface will be used for ICE candidates. This can be pointed at a single external interface to hide/ignore internal (VM) interfaces, unconnected interfaces or VPNs (e.g. work VPNs). It can also be set to a VPN interface, and then ICE will only use the VPN (and if the VPN is down, ICE will fail).
• media.peerconnection.ice.relay_only - boolean (default false) -- only generate relay (TURN) candidates for ICE (Firefox 42) -- bug 1189030
  • This can be used to block all local (LAN) and external IP addresses from being generated as candidates.
  • An example use-case would be avoiding exposing your external IP address to a caller (such as when avoiding disclosing you're in town Xxxxx when having a call with someone you have a protection order against; roughly the equivalent of blocking outgoing caller-id on the PSTN bug *-whatever)
  • NOTE: does not hide your external IP address from the TURN server itself (see use_document_iceservers and default_iceservers to restrict to a TURN of your choice).
• media.peerconnection.use_document_iceservers -- boolean (default true) -- use STUN/TURN servers provided by the page (all recent Firefox versions)
  • If set to false and media.peerconnection.default_iceservers is set to the server(s) you want to use, only those servers will be used, and no server provided by the page will be used.
  • This can be useful for corporate 'gateway' TURN servers, or for a TURN server hosted by a VPN provider.
• media.peerconnection.ice.default_address_only -- boolean (default false) -- limit ICE candidates to the default interface only (Firefox 43, uplifted to 42) -- bug 1189041
  • The default interface used for general routing is identified and only that address is used for candidate generation
  • LAN IP addresses are not generated, the external IP address for that interface is (for a VPN, the exit portal of the VPN)
  • If your router does not support 'hairpinning', a within-LAN call will end up being routed through an external TURN server
• media.peerconnection.ice.no_host -- boolean (default false) -- eliminate all local addresses from the candidates (Firefox 51) -- bug 1297416
• media.peerconnection.enabled -- boolean (default true) -- enables/disabled ability to create RTCPeerConnection objects (all recent Firefox versions)

For easier comparison of the different options:

Pref	Local candidates	External candidates	Relay candidates	No candidates	Interfaces gathered
force_interface	Yes	Yes	Yes	If pointing to non-existing interface	Only the configured interface
relay_only	No	No	Yes	If no TURN server is provided	All interfaces will be used to try to connect to the relay
use_document_iceservers	Yes	Yes	Yes	N/A	All interfaces will be used to try to connect to the relay
default_address_only	Yes	Yes	Yes	N/A	Only the interface with the default route
no_host	No	Yes	Yes	N/A	All interfaces will be used
peerconnection.enabled	No	No	No	Always	N/A

Note 1: the comments in the table assume that the pref in each row has been altered from its default value.
Note 2: 'External candidates = Yes' always requires a STUN server to be configured.
Note 3: 'Relay candidate = Yes' always a TURN server to be configured.

Hooks to control access to createOffer/createAnswer

With the removal of old-style add-ons in Firefox 57, the following information is no longer applicable. An equivalent WebExtensions API is under development, but not yet complete. See bug 1281833 for details.

Firefox 43 (uplifted to 42) supports hooks that allow an extension to allow or deny calls to createOffer and createAnswer -- bug 1189060

  // Add-ons can override stock permission behavior by doing:
  //
  //   var stockObserve = WebrtcUI.observe;
  //
  //   webrtcUI.observe = function(aSubject, aTopic, aData) {
  //     switch (aTopic) {
  //      case "PeerConnection:request": {
  //        // new code.
  //        break;
  //      ...
  //      default:
  //        return stockObserve.call(this, aSubject, aTopic, aData);
  //
  // See browser/modules/webrtcUI.jsm for detail

Example extension: http://hancke.name/tmp/verhueterli.xpi (source: https://github.com/fippo/plumber). Note: unsigned extensions require flipping a pref to use (and can't be used in Beta 41).