Can we compile in WebRTC to allow QRCode bridge entry?

[mikeperry]

We should evaluate if we can re-enable the compilation of WebRTC in Tor Browser. There are two reasons for this:

1. Mozilla may remove the WebRTC compile time switch of WebRTC in future builds.
2. Enabling WebRTC at compile time may enable Tor Launcher to make use of the WebCam for scanning QRCodes of bridges (see #14837).

Mozilla's security team claims that setting media.peerconnection.enabled to false will completely disable content access to all WebRTC APIs, which should be sufficient for us. However, my review of the FF31 source showed that several other things get compiled in to the browser that may or may not be directly tied to the peerconnection APIs. For example RTSP and SCTP protocol support gets compiled in, and there may be other ways to use these protocols elsewhere in the browser. See: ​https://gitweb.torproject.org/tor-browser-spec.git/tree/audits/FF31_NETWORK_AUDIT

FWIW, simple PoC's such as ​https://diafygi.github.io/webrtc-ips/ fail if media.peerconnection.enabled is unset, but again, more investigation is needed.

[gk]

If we compile it in content has access to the devices as well (see: ​https://people.torproject.org/~gk/misc/webrtc_test.html for an example). I wonder if we would allow device fingerprinting that way and how bad it would be.

[mikeperry]

Hrmm, good point. However, I am able to disable this from content window by setting media.navigator.enabled to false. Though we should be sure there aren't other things we should pref off if we enable this, too.

[mikeperry]

Tag the set of things that are risky to debut in the 5.0-stable release without testing in a prior alpha.

[mikeperry]

Ensure all tbb-5.0a items are on the June radar.

[mikeperry]

Going to take this off the ff38 radar for now. We can consider this later.

[teor]

Set all open tickets without a severity to "Normal"

[teor]

Change tickets that are assigned to nobody to "new".