N.B.: This is a personal blog post. The opinions expressed here represent my own and not those of Mozilla.
In the last few months, I’ve had many people reach out to me 1:1 because they are worried about the privacy aspects of WebRTC — largely because they heard discussions about “IP disclosure” (which sounded really scary and confusing to them), and I want to provide a coherent, higher level summary of what the real issues are and aren’t.
So with the help of my friends and colleagues at Mozilla and in the greater WebRTC community, I’m going to summarize the concerns and what Mozilla is doing about them. The Chrome team is also addressing these concerns.
First some background for folks who are new to WebRTC and the topic of IP address gathering:
Real-time applications such as VoIP, video calls and online games work best when media flows directly between the endpoints, producing the lowest latency and the best user experience. In order to establish direct communications, WebRTC uses a technology called ICE. ICE works by collecting every IP address which might be used to reach your browser and shares this with the JS application.
Most user’s computers are behind some type of NAT/router/”home gateway”, which has an external IP address on the internet, and a Local Area Network (LAN) that your machines and devices connect to. Each machine will have a local IP address on the LAN, which is normally not visible to external sites you connect to. When a user connects to a site, the external IP address of their NAT is normally visible to the site.
However, aside from legitimate uses for real-time communications, sites can also use these IP addresses to fingerprint users and in some cases expose an external IP address the user didn’t expect to expose.
Who does this “exposure” affect?
A browser exposes an external IP address to each server that it contacts. Learning the local IP address of your machine on your local network (LAN) is not particularly useful information since these addresses are rarely unique: most LANs use one of a small number of private address ranges. It adds no significant additional fingerprinting exposure — and blocking determined fingerprinting is very hard to do in a normal browser, if possible at all. Someone may be able to use the local IP address to figure out who a user is when they are on a large network behind a NAT, but correlating that to a user’s identity typically requires access to the network logs for that NAT.
VPNs and anonymity
Some people attempt to use Virtual Private Networks (VPNs) to conceal their IP address. (The type of VPN use typical here creates a “tunnel” for your internet traffic to the VPN provider, making it appear when you browse that you’re located wherever the VPN provider is.) A good (if extreme) example of this is someone hiding from a government. Many such users assume that using a VPN will obscure all their browsing and their real external IP address, which could be used to locate them.
However many VPN configurations don’t properly disable local interfaces, and so users of those VPNs might be surprised to learn that their real external IP addresses are exposed by ICE. This behavior isn’t new or unique to WebRTC: Flash, which is enabled in the vast majority of browsers, contains an ICE-like NAT traversal technology with similar properties.
For cases like this, we’ve added several new privacy controls for WebRTC in Firefox 42. These controls allow add-on developers to build features that give users the ability to selectively disable all or part of WebRTC, and which allow finer control over what information is exposed to JS applications, especially your IP address or addresses. None of these features are enabled by default due to the considerable cost of enabling them to most users (most of them can be also enabled via about:config). There’s a Hacks blog post that discusses exactly how to use these.
It is important to realize that a VPN on its own is a poor system for protecting user anonymity. On top of that, many VPNs have serious flaws that can leak your address such as this IPV6 issue.
Even when a VPN is configured so that other IP addresses (interfaces) are disabled, other information about your browser or your computer can be used to reveal your identity. In general, it is not possible to defend against deanonymizing techniques like fingerprinting (see here) without taking extraordinary steps. And if attackers can fingerprint you while you’re using the VPN, they can then match that fingerprint to browsing you do with the VPN off and trivially find your “real” external IP address (and thus know who/where you are, given the assumption they control or have access to your ISP’s logs). This is one of several reasons a VPN alone isn’t a real safety-net for anonymization from strong attackers, like a government.
If your concern is weaker attackers (such as the NY Times), they can also use fingerprinting to infer your real external IP and likely location (and in many cases tons of information on you tied to the fingerprint – potentially including email, real name, and snail-mail addresses).
Is WebRTC dangerous to users in certain countries?
People whose physical safety relies on anonymity should not be depending on a VPN alone for that anonymity. There are a myriad of ways to fingerprint and de-anonymize VPN users (see some of the links above for details). If there were one message that could get out to these users as a result of these debates and discussions, I hope it would be “VPNs will not protect you. They aren’t capable of doing so by themselves.”
People at physical risk due to disclosure should be using the Tor Browser. Advocates for these users should be encouraging this, and work to build a set of “best practices” and publish it widely.
Other related privacy features
Another privacy feature Firefox added is the ability to hide your external IP address from other users of WebRTC services you use. This feature is intended for users who are trying to avoid a specific other person finding them. They may want to avoid exposing their external IP address to the other party in a WebRTC call, since it could be used to locate them physically. For this case (and some other use cases), we’ve added a pref that forces all WebRTC connections to use relay (“TURN”) servers, so that no traffic goes directly between the two browsers (the service would still know who and where you are, but the other user would not). You can also use existing prefs to force all traffic through a specific TURN server instead of one controlled by the website using WebRTC.
Future work
These are just the first set of changes. In coming releases, we will likely refine what controls we provide for WebRTC to balance usability and privacy. We are working with both the W3 and IETF working groups to find better ways to address these issues. I invite constructive suggestions on how best to do this. Here are some proposals we’re trying to think through and flesh out:
- Should some of these be the enabled by default in Private browsing windows?
- Should we add a control in Customize you can drag out into the menubar which shows a list of active WebRTC RTCPeerConnections?
- How can WebRTC be improved and leveraged to help provide secure and hard-to-block communication between users?
Users who need maximum anonymity protection will have to make some significant usability and performance sacrifices, which should probably include using a more comprehensive system, such as the Tor Browser. Firefox and other browsers designed for mainstream users are not the best choice for that set of users, but most users don’t fall into this category. We want your help in making smart, practical choices that add value for users and give them control over their web experience without sacrificing default quality and usability. Please send email with your suggestions to the dev-media mailing list (subscribe) or comment here.
