Can we compile in WebRTC to allow QRCode bridge entry?
We should evaluate if we can re-enable the compilation of WebRTC in Tor Browser. There are two reasons for this:
- Mozilla may remove the WebRTC compile time switch of WebRTC in future builds.
- 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.
Change History (12)
Description: |
modified (diff)
|
Keywords: |
tbb-usability-stoppoint-wizard removed
|
Keywords: |
tbb-5.0a-highrisk added
|
Keywords: |
TorBrowserTeam201506 added
|
Keywords: |
MikePerry201506 added
|
Owner: |
changed from tbb-team to mikeperry
|
Status: |
new →
assigned
|
Keywords: |
ff38-esr tbb-5.0a-highrisk TorBrowserTeam201506 MikePerry201506 removed
|
Cc: |
mikeperry added
|
Owner: |
mikeperry deleted
|
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.