Google Has a Fix for WebRTC VPN-related Privacy Issue
It is always nice to report some good news and this is one of those instances. For those of you who may remember, a few weeks ago there was a major uproar about the revelation that the New York Times site could leverage WebRTC to track the private IP address of visitors without their permission. That obviously got more than a few people upset when it became public—despite the fact that as far back as February of this year this was uncovered by security researchers as an issue.
Just as a refresh, the problem from a technical perspective is that when WebRTC was used on a website in combination with a STUN server it became possible to reveal those private IP addresses from people coming to the website using a VPN connection. In short, so much for privacy!
As mentioned, there is good news to report since this has been a bit of a rolling thunder operation as multiple browsers were involved leading up to Google taking care of the problem in Chrome. Thanks to the good folks at softpedia.com it can be documented that the fixes are in. They include:
- Firefox told users that putting "media.peerconnection.enabled" to "false" in their "about:config" page would help.
- For Chrome users, BrowserLeaks.com provided an extension to disable WebRTC support in the browser.
- Rentamob also published a Chrome extension that tried to fix the issue without disabling WebRTC completely, but according to TorrentFreak, this caused some WebRTC functions like VoIP not to work correctly.
Google with the release of WebRTC Network Limiter has seemingly come to the rescue. Here is what the www.webrtc.org posting about the fix has to say:
What it does:
This configures WebRTC to not use certain IP addresses:
- IP addresses not visible to the public internet (e.g. addresses like 192.168.1.2)
- any public IP addresses associated with network interfaces that are not used for web traffic (e.g. an ISP-provided address, when browsing through a VPN).
Once the extension is installed, WebRTC will only use public IP addresses associated with the interface used for web traffic, typically the same addresses that are already provided to sites in browser HTTP requests.
This extension may affect the performance of applications that use WebRTC for audio/video or real-time data communication. Because it limits the potential network paths, WebRTC may pick a path that results in significantly longer delay or lower quality (e.g. through a VPN). We are attempting to determine how common this is.
At the top it was noted that this is good news. What should have been added is that this is good news with a caveat which is spelled out in the “Notes” section. So the good news is that you don’t have to completely disable WebRTC if you want to be on the safe side of this challenge. The caveat is that line about performance of apps being impacted when using a VPN.
The other good news is that at least the browser developers after a slow start are finally taking this seriously. Much has been made about the utility of WebRTC for enterprise use. Let’s just say that performance issues surrounding what happens when the user is coming in via a VPN are not just a security issue but a performance issue as well and this certainly would/could be a red flag for IT departments.
Obviously this is a work in progress and we’ll keep you posted.
Edited by Dominick Sorrentino