It would be preferable to make --disable-webrtc into a preference rather than a compiler flag - this would make it easier for Tor Browser to track Firefox and perform testing on WebRTC-disabled mode. Adding this to the tor whiteboard for future tracking.

Does "media.peerconnection.enabled" cover your need? Without ability to create a peerconnection, you can't initiate ICE. You can also disable getUserMedia with "media.navigator.enabled" (horrible name, sorry - file a bug to rename it media.navigator.getusermedia.enabled"); and you can turn off video gUM while leaving audio.

Pass to Arthur and Georg! =)

(In reply to Randell Jesup [:jesup] from comment #1) > Does "media.peerconnection.enabled" cover your need? Without ability to > create a peerconnection, you can't initiate ICE. > > You can also disable getUserMedia with "media.navigator.enabled" (horrible > name, sorry - file a bug to rename it > media.navigator.getusermedia.enabled"); and you can turn off video gUM while > leaving audio. I think we would want to ensure that, with these prefs disabled, the WebRTC JS API is not still fingerprintable, and that there is no proxy bypass of any sort when WebRTC is enabled, etc. There's also some chance we would enable WebRTC in the future once it has been thoroughly inspected.

Basically what Arthur said. And, yes, we have some ideas for using WebRTC actually: https://trac.torproject.org/projects/tor/ticket/14836 https://trac.torproject.org/projects/tor/ticket/16221 Back then we investigated this a bit (in #14836) and found that "media.peerconnection.enabled" alone is probably not enough due to device fingerprinting. Setting "media.navigator.enabled" to "false" seemed to do the trick after cursory code inspection. However, if would need some test assurance at least that there is no proxy bypass possible. This might tie into bug 1314793.

Mass wontfix for bugs affecting firefox 52.

See bug 1364975 comment 9 for how "media.navigator.enabled" and "media.peerconnection.enabled" are connected.

Hello Tom, since our plan now is to build a Fennec with Tor using compile flags (and prefs), should we set this bug to WONTFIX?

(In reply to Jonathan Hao [:jhao] from comment #7) > Hello Tom, since our plan now is to build a Fennec with Tor using compile > flags (and prefs), should we set this bug to WONTFIX? No, this bug affects more than Fennec, it's going to be necessary for Tor's (and our) plans for ESR59 too. That said, I think this is a P2, rather than a P1. I also think this might be something you wind up passing to me. Ethan I assume you're okay changing this to P2?

Thanks, Tom. Passing this bug to you.

(In reply to Tom Ritter [:tjr] from comment #8) > No, this bug affects more than Fennec, it's going to be necessary for Tor's > (and our) plans for ESR59 too. Just wanna make it clear. You mean Tor Desktop will need this bug, don't you?

(In reply to Ethan Tseng [:ethan] from comment #10) > (In reply to Tom Ritter [:tjr] from comment #8) > > No, this bug affects more than Fennec, it's going to be necessary for Tor's > > (and our) plans for ESR59 too. > > Just wanna make it clear. You mean Tor Desktop will need this bug, don't > you? Yea, it affects both Desktop and Fennec.

Mass change P2->P3 to align with new Mozilla triage process.

(In reply to Georg Koppen from comment #4) > Back then we investigated this a bit (in #14836) and found that > "media.peerconnection.enabled" alone is probably not enough due to device > fingerprinting. Setting "media.navigator.enabled" to "false" seemed to do > the trick after cursory code inspection. However, if would need some test > assurance at least that there is no proxy bypass possible. This might tie > into bug 1314793. Yes, "media.peerconnection.enabled" alone does not appear to be enough. Using a WebRTC fingerprinting test [1], I could prevent leaking of my local IP address by setting "media.peerconnection.enabled" to false. To prevent media device enumeration, however, I had to set *both* "media.peerconnection.enabled" and "media.navigator.enabled" to false. Setting only "media.navigator.enabled" to false was *not* enough to prevent media device enumeration. [1] https://browserleaks.com/webrtc