WebRTC privacy

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.

7 thoughts on “WebRTC privacy

  1. Pingback: Controlling WebRTC PeerConnections with an extension ✩ Mozilla Hacks – the Web developer blog

  2. Law Student

    The thing for me is,… I choose firefox over any other browser because of its (past) commitment to privacy. I know there are certain situations that expose my IP or other identifiers.

    Privacy was always the one factor that separated Firefox from any of the other browsers IMO. I see this fading.

    I wish that Mozilla would stick to their past promise of privacy and value every hardcoded “addon”/addition to the browser in it. Is there a chance this new feature exposes our customers privacy?! If there is, make it an optional addon, people can install if they actually want it. I dont want Hello. I dont want Pocket. Sure I can disable it but I cannot remove it.

    Sure there might be a communicty and maybe a fraction of people actually using it. But I think those would still use the functionality if it came as an addon.

    In my opinion, privacy sensitive additions to the browser should be opt-in and not opt-out, meaning make it available as an addon and not shove it down peoples throats.

    I will for sure give Edge a more than serious look once it gets addon support and may not be looking back.

    1. I’m sorry you feel that way. Mozilla is still very much committed to privacy.

      WebRTC is not a feature that can work well as an ‘addon’ and would not be useful to users in the same way if you tried. Ubiquity and functionality matter, and WebRTC lets users communicate directly (with end-to-end encryption) without relying on desktop-installed applications or plugins with fuzzy or hard to verify levels of privacy protection and no source available to vet/build.

      See https://wiki.mozilla.org/Media/WebRTC/Privacy (linked to in the post) – you can disable all of WebRTC (and Hello) easily. The Hacks blog post linked to lets you intercept all uses of createOffer/Answer so that you can ask the user if they want to do this. So the option is available to you — but making that the default would effectively kill the feature, for a limited and arguable gain as discussed in the post.

      All the parties involved in WebRTC would love to find a better (overall) solution; we just don’t have one yet.

  3. LA-MJ

    There are a few things I don’t like with this post. You go into a two massive segway about browser fingerprinting, VPN security etc and lose/overlook the essence of the problem.

    1) Even if fingerprinting is massive problem and this doesn’t add much to it that does not mean that it’s OK to divulge this information.
    2) Privacy issues aside, revealing ethernet address is also an additional security risk for router hacking, intranet CSRF and all sorts of other nasty things. While it is true that local IPv4 address range is not as wide as one would like, any and all customization makes attacker’s life harder so they are better off looking for easier targets. Divulging this information deprives us of even this most trivial defence and just adds to the pattern of broken web[1].

    [1] http://queue.acm.org/detail.cfm?id=2390758

    1. I think we have different opinions on what the essence of the problem is. If we lock things down, what price are browser/web users paying in terms of usability and functionality for as you say the “most trivial defense”? If this made a non-trivial difference in the ability to fingerprint or to block router hacking, that would change the discussion significantly.

      I do believe we (the web) can do better, and we’re actively discussing smart approaches to improve on what we’ve already done. We are having more discussions about how we can make things better without over-correcting and throwing the proverbial baby out with the bath water.

  4. ploxiln

    You argue that VPNs generally don’t work for privacy. But really, if you do just a couple things (which smart users were doing anyway for performance and general security), they work against everyone but the US or Chinese spy agencies.

    1. Disable all plugins, optionally enable flash but use click-to-play functionality of the flash-block extension, just for the main content item on sites you trust.
    2. Use a blocker like ghostery or ublock. It’ll requests to the most common trackers and ad networks.
    3. If your VPN doesn’t support ipv6, make sure you disable all ipv6 on your system. This is actually the only step that doesn’t apply to all web users anyway!

    That’s pretty much it, VPN works. Oh except now for WebRTC, just another thing to add to the checklist. Can you even disable it right now in firefox? Or is it a “privacy 0-day” that won’t be fixed for months?

  5. Fabian

    I am astonished by your position. There is always a trade off between convenience and security but I think exposing real IP is really a big security hole. I’m quite sure that most people using VPN (including me until I read the news about the IP exposure) trust that their real IP is hidden from web servers.

    I find it rather disappointing for an organisation that distinguishes itself on security.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s