webRTC block for PB

[ghost]

Request : webRTC Block to be integrated in Privacy Badger

See this site to find out if your browser is giving away your local and public IP address ..
https://diafygi.github.io/webrtc-ips/

See this extension for a solution to the problem ..
https://chrome.google.com/webstore/detail/webrtc-block/nphkkbaidamjmhfanlpblblcadhfbkdm?hl=en

Request similar solution included in Privacy Badger

I understand Firefox has a setting to turn this off, probably defaults to letting it happen, but some chrome browsers notably the current Comodo Dragon leaks this information.

[cooperq]

I think this would be a pretty good feature, I think that we should probably just outright block third party webrtc and use it to add to the heuristic. We could probably pop up a warning for first party webrtc. I don't know when I iwll have time to get to this so if you want to submit a patch please do!

[rbhitchcock]

The extension linked in this issue is not truly effective at blocking STUN requests (see: https://github.com/diafygi/webrtc-ips), and its protection mechanism is trivially bypassed. Do either of you know of some other avenues that may potentially work? I've done some searching around on the Internet, but at this point I've yet to find anything that looks very promising. I'd be happy to submit a patch for this functionality, but at this point I can't think of any plausible solutions. Thoughts?

[ghost]

I do not have the knowledge to address this.

[cooperq]

@rbhitchcock I haven't looked into this problem at all so I don't have any good suggestions for you, but that is a really good point. I will look into this problem further. I would be happy to accept a patch if you can come up with a solution!

[elijh]

uBlock has an experimental fix for leaking IP in WebRTC in chrome: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3-dev.2

Once it is stable, maybe that code can be copied.

[pde]

By "private IP address", do you mean a local network IP (192.168.0.0/16 etc) or do you mean a public IP address that's supposed to be VPN'd but isn't? Definitely I'd agree that we should protect against leakage of the former; the latter is a special case that only makes sense to worry about if the user is actually behind a VPN.

I suspect that the real underlying problem there is VPNs (including Tor) that don't support UDP, since UDP is what you need to punch P2P through most firewalls.

[elijh]

By "private IP address", do you mean a local network IP... or public IP address that's supposed to be VPN'd

In this case, both: the browser reports both to the stun server and makes these available to in-page javascript.

I suspect that the real underlying problem there is VPNs (including Tor) that don't support UDP, since UDP is what you need to punch P2P through most firewalls.

Having the browser report to the STUN server all its IPs hardly improves this, eh? I would say the real underlying problem is the browser reporting it's IPs to the STUN server. The STUN server should decide for itself what the IP of connecting clients are. This is how wikipedia says it works:

The basic protocol operates essentially as follows: the client sends a message (known as a binding request) to a STUN server on the public Internet. The STUN server responds with a success response that contains in its payload the IP address and port of the client, as observed from the server's perspective

https://en.wikipedia.org/wiki/STUN

I don't know why it is working so differently in this case.

[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.

[cooperq]

to keep the debate in one place lets continue commenting in EFForg/privacybadgerfirefox-legacy#394

[pde]

OK, I was wrong, WebRTC does actually send RFC 1918 addresses to servers. Is that in order to facilitate local network VOIP connections?

[cooperq]

closing this one for now so we can keep the conversation to the other issue, will re-open later

[alexristich]

Finished this in #969, adding toggle button to Settings page in #986.