Protect against WebRTC leaking private IP address

[alexristich]

@cooperq @ghostwords @pde Here's the updated implementation of WebRTC protection.

A few points of note:

1. Changing the setting to default_public_interface_only hides the local IP address.
2. Having this setting enabled doesn't in any way seem to effect the ability to use Google Hangouts, etc. (as per testing with Cooper)
3. In uBlock, the callback contains a call to check chrome.runtime.lastError, saying lastError needs to be checked or Chrome complains (see Chromium gets error from ublock0 with hyperlink auditing and locks up the extension. gorhill/uBlock#875), but from my testing this doesn't seem to be an issue anymore.
4. There are 4 possible settings: default, default_public_and_private_interfaces, default_public_interface_only and disable_non_proxied_udp. I think that this last option might end up breaking some things, so the 3rd option seems safe. In case the user already has this fourth option selected, I've followed uBlock's approach and kept their setting as is.

You can test this on https://diafygi.github.io/webrtc-ips/ and https://ipleak.net/.

[ghostwords]

Given the dates in https://en.wikipedia.org/wiki/Google_Chrome_version_history, we should probably be good supporting Chrome 48+ only (when webRTCIPHandlingPolicy was introduced) ...

[ghostwords]

@gorhill notes there are some issues when this setting is enabled. Is that no longer the case?

Generally speaking, what are the downsides of setting WebRTC's IP handling policy to "default_public_interface_only"? Less efficient communication when all peers are on the same network?

[alexristich]

@cooperq and I tested Google Hangouts with it enabled, and didn't encounter any issues. I haven't yet noticed any issues running it with this setting enabled, so perhaps we can wait for some reports to come in if it is an issue for certain users. Also, you guys can potentially run with it for a bit and see if anything breaks, though my initial test drive hasn't revealed anything.

As to the downsides, that's essentially my understanding of it. The specification goes into greater detail about the four modes (which correspond to the four settings that Chrome offers as mentioned above):

Mode 1 Enumerate all addresses: WebRTC will bind to all interfaces
individually and use them all to ping STUN servers or peers.
This will converge on the best media path, and is ideal when
media performance is the highest priority, but it discloses
the most information. As such, this should only be performed
when the user has explicitly given consent for local media
access, as indicated in design idea #3 above.

Mode 2 Default route + the single associated local address: By
binding solely to the "any" address, media packets will flow
through the same route as normal HTTP traffic. In addition,
the associated private address is discovered through
getsockname, as mentioned above. This ensures that direct
connections can still be established even when local media
access is not granted, e.g. for data channel applications.

Mode 3 Default route only: This is the the same as Mode 2, except
that the associated private address is not provided, which
may cause traffic to hairpin through NAT or fall back to the
application TURN server, with resulting quality implications.

Mode 4 Force TCP and proxy: This is disables any use of UDP and
forces use of TCP to connect to the TURN server or peer. If
a proxy server is configured, the TCP traffic will be sent
through the proxy, with resulting quality implications.

I took a closer look into how others are handling this, and found that Yan Zhu from Brave decided to pick disable_non_proxied_udp for their most private mode (brave/browser-laptop#260 (comment)):

I did some testing and it appears that with Tor as my system SOCKS proxy on OS X, both Brave and Chrome 51.0.2704.103 leak true public/private IP address on https://diafygi.github.io/webrtc-ips/. So I am going to tie fingerprinting protection to the disable_non_proxied_udp setting, since default_public_interface_only apparently reveals the true public IP.

I think for us this might be overkill, as we plan to release this without the ability to toggle the setting initially, and picking the most private option which has the largest impact on quality might be overkill (note that Brave doesn't have WebRTC protection on by default, and only enables it when "Fingerprint Protection Mode" is turned on).

[cooperq]

@groovecoder can you look up how to do this in firefox?

[cooperq]

Needs to have code added to support firefox in web extensions mode. @groovecoder is looking into this.

[cooperq]

Needs doc comment

[groovecoder]

Firefox has not implemented the Web Extensions privacy API yet. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1312802 for it.

uBlock uses the media.peerconnection.ice.default_address_only config to achieve the same effect. Firefox does not (yet) have a way for Web Extension add-ons to set config values.

I would hate to block this improvement for Chrome users, so I suggest we go ahead and approve this PR and file a follow-up issue for Firefox? Are we filing Firefox/Web Extension issues here, or in the Firefox repo? Ignoring the Web Extension code for now ... I could make a corresponding PR to the Firefox repo too maybe?

[alexristich]

@groovecoder Thanks for looking into this! @cooperq put the Firefox repo on a feature freeze, so any new changes can be included here. Since Web Extensions doesn't yet support this, is it possible for us to add support for Firefox directly within this function call, or would it have to go somewhere else in the code to be compatible?

[groovecoder]

It would have to go somewhere else in the code. We won't be able to set the related pref in web extension code. 😢 I sent #975 to this branch to at least remove the Firefox error. I also filed #976 as a follow-up to implement WebRTC protection for Firefox when the API is implemented.

[alexristich]

Good to know! The check for chrome.privacy should ensure we avoid any errors on non Chrome browsers, at least until Web Extensions implements the appropriate APIs.

[ghostwords]

Retitled to make more clear this doesn't protect against WebRTC-powered tracking, just local/private IP address leakage.

[groovecoder]

@cooperq I sent #975 and filed #976. The chrome.privacy API bug for Firefox was prioritized as P2. Is that Good Enough™ to approve this PR for merge?

[cooperq]

LGTM

[groovecoder]

FWIW, I plan to try implementing chrome|browser.privacy API in Firefox using the new WebExtensions Experiments technique. Hope to have it done the week of Dec 5-9.

[cooperq]

@groovecoder cool! Let us know when you have done that!

[groovecoder]

I sat with WebExtensions Experiments gurus here at Mozilla work-week and it's not possible right now. :( But it needs to be possible for many reasons, so I'll keep on it.

[alexristich]

Thanks for the update on this, and thanks for continuing to push for the implementation of this API!