Should block IP leakage via WebRTC

[elijh]

WebRTC allows access via Javascript to the user's real IP address, even when using Tor or a VPN.

It makes a lot of sense for PrivacyBadger to block this by default, since leaking your IP is quite unexpected behavior.

For Firefox, blocking this behavior is easy: set media.peerconnection.enabled to false. This will prevent direct device-to-device WebRTC calls but will also keep your IP private.

As an added enhancement, PrivacyBadger could smartly detect if this measure should be deployed. If the browser's apparent IP address does not match its actual IP address, then the user is probably using Tor or a VPN and would definitely want to prevent IP leakage via WebRTC.

[elijh]

Apologies if this is a duplicate issue. I see that there is a WebRTC issue open for PB for Chrome, but I didn't see one for firefox.

[cooperq]

Not a duplicate issue, thanks! I agree that we should block webRTC, though I would probably limit it more in scope to only blocking third party webRTC. First party webRTC can actually be quite useful for certain peer to peer services. We could also consider trying to show a popup if a first party wants to use webRTC, blocking until the user consents. But I would uncomfortable blocking first party webRTC by default. (Though it is of course a good idea if one is using tor, which is why TBB is always reccomended.)

[elijh]

I think there is a lot to be said for "block by default" instead of annoying the user. The user has enough annoying things to worry about without needing to educate themselves on yet another privacy problem with the browsers.

• This is a stupid feature of WebRTC that never should have been implemented.
• Most people don't use WebRTC peer to peer anyway, and won't notice if WebRTC is "fixed".
• This is why god created STUN servers, which solve this problem in a better way.

[pde]

Excuse my ignorance, but how does use of a STUN server prevent IP address revelation in a P2P protocol?

In my view it's very good news that WebRTC is facilitating P2P applications in web browsers; there are a lot of cool things that should be implementable as a result.

Hiding the user's IP address isn't part of Privacy Badger's mission, except insofar as we can determine that an origin/IP is tracking the user and providing no functionality they expect, in which case Privacy Badger shuts down all communication with that origin.

As a result, it seems that the correct aim is to ensure that any possible tracking via WebRTC is identified as such by Privacy Badger, and if domains are redlisted then WebRTC can't be used as an alternative way to talk to them.

The larger aim you have (preventing WebRTC from leaking an IP that is supposed to be hidden by Tor or a VPN) is probably best implemented in Tor Button, or some variant/alternative that's designed for VPN usage.

[pde]

I suppose I wouldn't be completely opposed to adding a "VPN mode" to Privacy Badger, which was off by default unless there's some reason to believe that the user is behind a VPN. But that would be a significantly new objective for the project, and it'd be worth asking whether PB was the best home for that objective.

[elijh]

Excuse my ignorance, but how does use of a STUN server prevent IP address revelation in a P2P protocol?

Sorry, I should not have said that. The precise problem here is actually caused by how the browser's handle stun servers: the browser reports to the stun server it's non-public IP addresses, which then javascript can query.

STUN servers are of course very useful for P2P, and typically don't result in any privacy problems because the STUN server is not typically aware of non-public IPs, afaik.

[elijh]

Hiding the user's IP address isn't part of Privacy Badger's mission, except insofar as we can determine that an origin/IP is tracking the user and providing no functionality they expect, in which case Privacy Badger shuts down all communication with that origin.

Privacy Badger may have initially been conceived of focusing exclusively on blocking tracking parties, but the code now includes some sensible elements that modify the browser's behavior when that behavior risks unexpected leakage of potentially personally identifiable information (for example, blocking referrer for domains that are cookie blocked). PB also turns on 'do no track'.

Maybe you don't want PB to be an extension that forces the browser into reasonable privacy-respecting behavior in general, but it seems like that horse has already left the stable. Alternately, perhaps there is need for a new extension called PrivacyHoneyBadger? (PrivacyHoneyBadger don't give a shit, it just blocks what it wants).

[cooperq]

I think that having privacy badger take actions to fix privacy problems in the browser is definitely on mission. I do get a bit jumpy about making those things happen by default, because it tends to make people upset when you block things they expect to have (see EFForg/privacybadger#141 and EFForg/privacybadger#253).

I looked at the changes in ublock re: this and asked @gorhill about it here, and the setting that @elijh pointed at appears to maybe just block IP leakage from webRTC without disabling it entirely, which could be a desired feature, modulo the concerns pointed out by @gorhill. We could have this as an experimental feature which is turned off by default to begin with until we get more user feedback / testing on it.

The other option is to only block webRTC for third parties who are cookieblocked, this doesn't address the VPN leakage problem, but it does address the use of webRTC as a fingerprinting vector.

Probably we should just do both of these things to give both the best default protection and the best options for further protection.

[cooperq]

via @michael-oneill

The problem is that WebRTC can be used for invisible tracking, bypassing
third-party cookie blocks and blocking extensions. It is not only the local
IP address that can be secretly ascertained and blabbed, although that is
bad enough, but also a unique identifier that can single-out the user and
used to report their web history. This can be done in numerous ways
including, as is reported on the ublock list, establishing STUN servers with
wildcard DNS entries.

There is also discussion on the W3C PING list
http://lists.w3.org/Archives/Public/public-privacy/2015AprJun/ about
reporting unique deviceIDs in MediaDeviveInfo via drive-by (user is unaware
it is happening) JS.

It would be good if we can get to a situation where WebRTC can still be used
but the user is in control of it, having the ability to authorise it case by
case. Tracker blockers can then help by enforcing good behaviour if the
browsers do not.

[pde]

Just to be super clear: it isn't okay for Privacy Badger to break normal uses of P2P WebRTC.

@elijh When you say "private IP" presumably you don't really mean a private IP like 192.168.0.0/16, but a public IP that the VPN was supposed to hide, right?

If WebRTC's dependence on UDP + STUN creates a path for public IP address leakage, it only makes sense to deploy a mitigation if the user is actually using a VPN or overlay that would otherwise hide that IP. And in that case we should ask, why Privacy Badger, rather than TorButton or an extension specifically designed to perform that kind of task?

It sounds like there's a separate issue with supercookies being possible in the WebRTC protocol. In that case, we should implement code to detect such attacks on the user, and blocklist any domains that perform them.

[gunesacar]

I looked at the changes in ublock re: this and asked @gorhill about it here, and the setting that @elijh pointed at appears to maybe just block IP leakage from webRTC without disabling it entirely, which could be a desired feature, modulo the concerns pointed out by @gorhill.

For Firefox, uBlock seems to toggle the media.peerconnection.enabled pref, which disables the RTCPeerConnection completely (i.e. you cannot use Firefox Hello or other cool P2P stuff).

@elijh When you say "private IP" presumably you don't really mean a private IP like 192.168.0.0/16, but a public IP that the VPN was supposed to hide, right?

I'm not sure what was really meant by @elijh, but the discovery of local IP addresses may serve as a fingerprint if the user has multiple network I/Fs. The demo at https://diafygi.github.io/webrtc-ips/ lists four local IP addresses for me (on Firefox), containing the ones that belong to virtual machines/LXC containers/Docker boxes I've installed previously.

[taravancil]

IMO, disabling WebRTC is something many PB users would desire, but it's best left to another extension dedicated specifically to that purpose. The IP leak issue affects a specific subset of users: Windows users on a VPN, and I think having WebRTC disabled would be an unwelcome surprise for those who it does not affect.

However, if PB were to address the fingerprinting issue by letting users opt in to turn off WebRTC on cookieblocked sites, I would be on board with that.

[cooperq]

I'm pretty much in agreement at this point, I think we certainly shouldn't block first party webRTC, that can be the job of another addon. However As @taravancil blocking 3rd party webRTC for cookieblocked sites is desirable.