Web browsers like Google Chrome, Mozilla Firefox and Safari allow us to view web-based content on all of our devices. As users, we expect them to act as our “agents” and protect us as we navigate an Internet increasingly filled with malware and other security and privacy-related threats[1] – and they generally do, as increased adoption of HTTPS shows[2]. What happens, however, when the browser cannot both display web content and keep the connection secure and private? The browser has to choose between showing a webpage and potentially exposing the user to a privacy risk, or showing the user warnings that they have to click through. How should the browser approach this potential trade-off and empower the user to make an informed choice, between securing their privacy and enabling their full access to information through the Internet?
Our ability to access information and fully engage with the web as a space for freedom of expression depends on our ability to do so securely, so how browsers approach these privacy and access balances has important implications. In this blog, we’ll look at how browsers manage this balance in the implementation of WebRTC, which, while enabling multimedia content, can also be used for purposes which violate users’ privacy rights, such as tracking.
What is WebRTC?
WebRTC is a widely-used set of protocols and open-source software that gives browsers and web apps the ability to talk to each other, thus enabling “Real-Time Communication on the Web”. WebRTC specifications for implementation are standardized across browsers through the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF).
The idea is that users interested in calling and video chatting with their friends over the Internet should not need to install proprietary browser plugins like Adobe’s Flash and Microsoft’s Silverlight, which are often exploited in attacks[3], are unstable, and (by their nature) do not function across platforms[4]. Instead, audio and video communication should be a native feature of browsers – it should just work. And that’s just what WebRTC enables – at Internet scale! Ever used Google Hangouts? Discord? Facebook Messenger or Live? Jitsi? Then you’ve used WebRTC in some shape or form. All you need is a WebRTC compliant browser – and there are plenty of those. Chrome, Firefox, Opera and Safari all support it. Not all of them, however, implement WebRTC the same way – with implications for online privacy.
Privacy risks with WebRTC
WebRTC is a peer-to-peer protocol – to provide the best media experience possible, data is streamed directly between two parties. Given the complexity of today’s networks, establishing a direct connection between two machines is not an easy task – how do I know which one of the billions of devices on the messy interconnected computer networks we lovingly call the Internet I have to send my packets of video? The answer is Interactive Connectivity Establishment (ICE).
When I connect to Google Hangouts and want to make a call to my friend, the code running on the web page (unbeknownst to me) tries to establish a WebRTC connection between my friend’s device and mine. But the website can only see my public IP address. Given the mess of routers and public and private IP addresses,[5] how does it establish a direct connection between us? ICE to the rescue. Through a process called Candidate Gathering, ICE figures out my private IP address (and other things) and provides this to the web page, so that it can connect me directly with my friend; through the same process, the website obtains my friend’s private IP address as well. After it has obtained our private IP addresses, the website can then connect me to my friend. And there’s the rub.
Ostensibly, a legitimate website like Google Hangouts would only use this information to connect me to my peer. However, this same process could be used by an unscrupulous website to figure out my private IP address. As a visitor on evil-website.com, I have no idea that my private IP address is being leaked by WebRTC to the website. This could be especially dangerous for users who care deeply about not being identified, such as whistleblowers. Even users seeking to protect themselves by connecting through a virtual private network (VPN) could still have their private IP address exposed in this way[6].
It gets worse. By looking at usage stats, it turns out that WebRTC is used by web pages for IP address gathering 15 times more than needed for its intended purpose of enabling video and audio calls[7]. The NY Times infamously was reportedly tracking users using this technique[8]. And on StackOverflow, the most upvoted way to harvest a private IP addresses in a Chrome Extension is to use WebRTC.[9]
The consent approach
So an Internet technology that is intended to provide a better web experience is being used by some websites maliciously to violate users’ privacy, with potentially dangerous consequences for those most at risk. If any website can run WebRTC code as long as your browser supports it, and the browser can’t determine the legitimacy of the private IP address gathering, should your browser offer you the choice of disabling WebRTC for that website to protect your private IP address?
On first glance, the answer might seem obvious: of course! But it’s more complicated than that – if every time a user tried to video chat with their friend on Google Hangouts or Facebook Messenger a privacy warning popped up saying “Warning! This website is gathering your private/local IP address! Press OK to continue”, it could be misleading and confusing, reducing users’ access and eventually leading to warning-fatigue. Most users lack a full understanding of what their IP address even is, and will just click through – is this real consent? Given this complexity around user consent, some browsers argue that the benefits of WebRTC outweigh the privacy risks around leakage of private IP addresses.
Apple’s Safari has a different approach. Safari was late to the WebRTC game, announcing support only as of June 2017. Safari only allows private IP address gathering if the user gives consent to audio or video recording. It’s worth noting that this approach, while providing information to the user that the website is trying to perform an action with privacy consequences, still isn’t perfect. Asking for camera/microphone permission causes problems for some legitimate uses of WebRTC – for example, broadcast streaming of video as in a webinar. In such a case, the user would be asked for camera/microphone recording permissions without them actually ever being used, and might deny permission and thus be denied access to the webinar.
A better way?
Ultimately, the best option would be if the user did not need to choose between providing consent (or not, and being denied access) and making themselves vulnerable to privacy violations – if instead WebRTC could be used without any IP address leakage whatsoever. The good news is this will soon be possible![10]. Safari is proposing a new way of gathering IP addresses that obfuscates the address before sending it to the other party, thus reducing the potential for it being used for tracking. To their credit, Chrome has expressed interest in adopting this mechanism, which would hopefully push more web browsers to take the user privacy element of this problem seriously[11].
Browsers are tasked with protecting us as we use the Internet. Ideally, there would always be a right way of doing things when it comes to our security and privacy, but sometimes browsers have to ask us to choose a potentially dangerous action. As new technologies arise that enhance our experience on the Internet, this kind of trade-off will only get harder for browsers to convey and will complicate the question of whether consent is meaningful, and whether users really understand the risks to their privacy they are enabling through basic web features. For this reason, the collaboration of browser developers in Internet standards bodies such as the IETF around ensuring that Internet protocols respect privacy by default is to be commended and encouraged. If more browsers can engage on these complex questions, and make greater efforts to work collectively to protect user privacy and ensure full access to the Internet for their users, hopefully in time we won’t need to see privacy and access existing in a trade-off.
See for yourself!
To check out how different browsers understand user consent around WebRTC differently, head over to https://ntblk.github.io/webrtc-privacy/. The browser will ask you for video permission. Try seeing what happens when you deny or give permission on Chrome, Firefox or Safari. You’ll notice that Chrome and Firefox do not care about media permissions, whereas Safari will not display your private IP address if you do not give consent to camera/microphone privileges. If interested in the source code of this page, check out https://github.com/ntblk/webrtc-privacy.
[1] Symantec Threat Report: https://www.symantec.com/security-center/threat-report
[2] A Secure Web Is Here To Stay: https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html
[3] Brian Krebs has often blogged about the issues and the associated patches for Silverlight and Flash: https://krebsonsecurity.com/tag/microsoft-silverlight/, https://krebsonsecurity.com/tag/adobe-flash-player/
[4] For the longest time, Netflix used Microsoft Silverlight – which meant that you couldn’t watch Netflix on a Linux-based system because Silverlight does not support Linux: https://www.makeuseof.com/tag/netflix-doesnt-run-linux/
[5] Public IP address is the IP address of your router or Internet service provider (ISP). This is the IP address that websites see when you connect to them. Other devices connected to your router would have the same public IP address. Collectively, all these devices behind an external router form a local area network (LAN). But how does your router know that it’s you that requested facebook.com, and not your roommate? Simple – every device on this LAN also has a private IP address. Your router acts as a translator between the devices on a LAN (private IP addresses) and the wider Internet (public IP addresses). This mapping process is called NAT, or Network Address Translation.
[6] Huge Security Flaw Leaks VPN Users’ Real IP-Addresses – https://torrentfreak.com/huge-security-flaw-leaks-vpn-users-real-ip-addresses-150130
[7] ~0.6% of all page loads in Chrome (as of May 31, 2018) call the method that allows for private IP address gathering, according to Chrome statistics: https://www.chromestatus.com/metrics/feature/timeline/popularity/1054. In contrast, only ~0.03% of all page loads called the WebRTC method to actually establish the connection: https://www.chromestatus.com/metrics/feature/timeline/popularity/1057\
[8] NYTimes using WebRTC to track users – https://webrtchacks.com/dear-ny-times/
[9] For more information on how your private IP address can be used maliciously, check out W3C’s wiki page on privacy aspects of IP address leakage through WebRTC.
[10] Using Multicast DNS to protect privacy when exposing ICE candidates – https://tools.ietf.org/html/draft-mdns-ice-candidates-00
[11] Justin Uberti’s (Chrome team) tweet about IP address obfuscation draft – https://twitter.com/juberti/status/1019433514465480704