WebRTC on the New York Times – Not as an Article or a Video Chat Feature

July 13, 2015

WebRTC has been mentioned with regards to the New York Times. It isn’t about an article covering it – or a new video chat service they now offer.

I was greeted this weekend by this interesting tweet:

I haven’t been able to confirm it – didn’t find the culprit code piece in the several minutes I searched for it, but it may well be genuine.

The New York Times may well be using WebRTC to (gasp) find your private IP address.

In the WebRTC Forum on Facebook, a short exchange took place between Cullen Jennings (Cisco) and Michael Jerris (FreeSWITCH):

Cullen: I’ve been watching this for months now – Google adds served on slash dot for example and many other sites do this. I don’t think it is to exactly get the local ip. I agree they get that but I think there is more interesting things gathered as straight up fingerprinting.

Michael: local ip doesn’t seem that useful for marketers except as a user fingerprinting tool. They already have your public ip, this helps them differentiate between people behind nat. it’s a bit icky but not such a big deal. This issue blows up again when someone starts using it maliciously, which I’m sure will happen soon enough. I don’t get why exactly we don’t just prompt for this the same way we do camera and mic, it wouldn’t be a huge deal to work that into the spec. That being said, I don’t think it’s actually as big of a deal as it has been made either

Cullen: It’s not exactly clear to me exactly how one uses this maliciously. I can tell you most peoples IP address right now and knowing that a large percentage of the world has that local IP does directly help you hack much. To me the key things is browsers need to not allow network connections to random stuff inside the firewall that is not prepared to talk to a browser. I think the browser vendors are very aware of this and doing the righ thting.

My local IP address is which is also quite popular.

In recent months, we’ve seen a lot of FUD going on about WebRTC and the fact that it leaks local IP addresses. I’ve been struggling myself in trying to understand what the fuss is. It does seem bad, a web page knowing too much about me. But how is that hurting me in any way? I am not a security expert, so I can’t really say, but I do believe the noise levels around this topic are higher than they should be.


When coming to analyze this, there are a couple of things to remember:

  • As Cullen Jennings points out, for the most part, the local IP address is mostly known. At least for the consumers at home
  • We are already sharing so much about ourselves out of our own volition, then I don’t see how this is such an important piece of information we are giving away now
  • The alternative isn’t any good either: I currently have installed on my relatively new laptop at least 4 different communication apps that have “forced” themselves on my browser. They know my local IP address and probably a lot more than that. No one seems to care about it. I can install them easily on most/all enterprise machines as well
  • Browser fingerprinting isn’t new. It is the process of finding out who you are and singling you out when you surf across the web through multiple websites. Does it need WebRTC? Probably not. Go on and check if your browser have a unique fingerprint – all of the 4 browsers I checked (on 3 devices, including my smartphone’s) turned out rather unique – without the use of WebRTC
  • The imminent death of plugins and the commonality of browsers on popular smartphones means that browser fingerprints may become less unique, reducing their usefulness. WebRTC “fixes” that by adding the coupling of the additional local and public IP address information. Is that a good thing? A bad thing?

One thing is clear. WebRTC has a lot more uses than its original intended capability of simply connecting a call.

You may also like

WebRTC predictions for 2023

WebRTC predictions for 2023

Your email address will not be published. Required fields are marked

  1. Explosives has so many beneficial use cases. Still we practice caution and safety. A similar thing is applicable for WebRTC as well. Instead of dismissing out of hand, it might be worth to consider on ways to address the concern, especially when the fix is simple: ICE will send local address only if server/peer reflexive address pass connectivity check and that address matches own public IP address.

    For a long time, we all used the priority weights suggested by ICE RFC when evaluating different ICE candidates. Lately we have learnt that many messaging applications immediately use relay addresses to establish media path and only subsequently check for other more optimal paths. Likewise, the change I am suggesting will eventually be found acceptable.

    1. chrome.privacy.network.webRTCMultipleRoutesEnabled.set({value: false})
      does exactly that. It’s not enabled by default however.

  2. Advertisers want a super cookie and a local IP is not very interesting for fingerprinting. This is going after what I view as a bug in one of the browsers. Protecting a local v4 address in a world moving to v6 is solving the wrong problem.

    1. Cullen,

      That would depend on who you target and what are the buying/surfing habits. For many that would simply be an iPad behind a home Wi-Fi network – as good as a static local IP address.

      As for protecting local IP addresses (I am refraining from use of v4 or v6 here on purpose), it will be hard to root the semblance of security people get by the fact they have an address that is presumably private. How do you tell people that their IP address on their private network is as good as the public IPv6 address? Will they stay around to listen to the explanation why this is so?

      1. For some reason I hadn’t read this article yet, I must have been busy. 🙂

        You brought up IPv6 and privacy. I think it is much more interesting to talk about IPv6 privacy than IPv4 in the WebRTC context.

        At first glance I would say there is a real problem there (but I haven’t checked browser implementations yet).

        If browsers also send the IPv6 link-local address then even a host with only an IPv4 Internet connecting has a privacy problem !

        With normal web-surfing pretty much every desktop/laptop operating system (I assume it’s the same with smartphones) IPv6 privacy wise should be fine. Because they have ‘IPv6 privacy-extenstions’* enabled by default.

        What I would like to know is:

        Do WebRTC browsers on hosts with IPv6 enabled send the MAC-address-derived IPv6-addresses (link-local and/or SLAAC-/DHCPv6-address*) when they are trying to establish WebRTC-connections ?

        If so, this really could be a way to track you on the public IPv6-Internet by asking to regularly establish WebRTC-connections.

        It gets even more interresting if browsers also send the IPv6 link-local address. Because it’s MAC-derived, thus static in every network you connect to and even exist even if you are not connected to an IPv6-enabled network.

        Tsahi or Cullen do you know of a demo which shows the information that is send during establishment of WebRTC-connections ? I wouldn’t mind to take a look what is send.

        I assume at least the IPv6 link-local address isn’t send.


        * Explanation of IPv6 privacy-extenstions and IPv6 link-local Address:

        When a host like a laptop machine has IPv6-enabled it will generate a IPv6 link-local address based on the MAC-address of the interface of the laptop. It does this by appending the Ethernet MAC-address in a well defined way to a fe80::/10 link-local-network-range.

        Something similar happends when a IPv6-enabled host connects to an IPv6 (Ethernet/WiFi) network which uses SLAAC or DHCPv6 (if DHCPv6 isn’t used to assign a ‘static’ addresses) it will notice which subnet is being used (based on IPv6 router announcements) and generate it’s own IPv6 address based on the MAC-address of the interface of the laptop machine. To do this it appends it’s MAC-address to the subnet address.

        That IPv6-address is also your public IPv6-address because IPv6 doesn’t use NAT. This means when you connect your laptop to different networks the last part of your public IPv6-address is the same. Which means you can be tracked on the public Internet. Aka Not Good.

        IPv6 privacy-extenstions means when your browser connects to a host (like website) your operating system will generate a random temporary IPv6 address for the same IPv6-subnet and use that to connect to the host. This temporary address is reused for new connects for a predefined time. So you don’t need a new address to connect to every single host on the Internet. And you regularly get a new address.

        This also means your laptop machine has multiple IPv6 addresses at the same time: the IPv6 link-local address, the IPv6-subnet-specific address and maybe 1 or multiple temporary privacy addresses.

  3. its metadata. We cannot predict how metadata will be used to exploit something later we can only decide if we are willing to take the risk. More important than the ubiquitous local ip, if someone is on several networks at once including VPNs or other private networks in a public environment where just knowing the network topology can give you a hint how to gain access, then getting that information can be useful to a third party.

    1. Anthony,

      We started off with NATs and private networks as a way to solve the IPv4 address space problem (not having enough of them) which is going to be obsoleted by the introduction of IPv6 anyway. Do these devices ever really gave us privacy by obscurity or is that just a psychological thing we’re clinging to?

      1. Thanks, I just started to look into WebRTC because of these news. From what I read in the (WebRTC) Javascript Session Establishment Protocol draft-ietf-rtcweb-jsep-03 I wonder if this method could be used to assign users a unique ID.
        This ID would be independent of browser cookies and could track users despite changing their IP address.

        IETF draft: “With rehydration, the current signaling state is persisted somewhere outside of the page, perhaps on the application server, or in browser local storage. The page is then reloaded, the saved signaling state is retrieved, and a new PeerConnection object is created for the session. The previously obtained MediaStreams are re-acquired, and are given the same IDs as the original session; this ensures the IDs in use by the remote side continue to work.”

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}