In the dark old days of not long ago, most web-based interactive content was delivered via ActiveX or NPAPI browser plug-ins (ex: Java, Flash, etc.). The danger of browser plug-ins is that once installed, they can do just about anything with your computer (read files, install viruses, alter system files, etc.).
With the rise of WebKit-based browsers, high-performance Javascript, HTML5, and CSS3—browser plug-ins have been on the decline—if not excluded entirely (like on iOS Safari).
While this has substantially reduced system-wide infections via web browser, it has done very little to improve the user’s privacy.
Several examples:
3rd Party Cookies
The powers that be have successfully pressured all of the major browser projects to enable 3rd Party Cookies by default. An ordinary cookie is used by the site you are visiting to persist information between pages (like a shopping cart or automatic login). A 3rd party cookie is written by a different site than the one you are visiting, and is readable by that site–even if you never navigated to that site directly.
For example:
- I visit blog.com. Blog.com writes a cookie for blog.com, and it features an image loaded from advertisers.com. When that image is loaded, another cookie for advertisers.com is created or updated with identifying information.
- Then I visit shop.com. Shop.com writes a cookie for shop.com, and it also features a video clip loaded from advertisers.com. When that video is loaded, the advertisers.com cookie created when I visited blog.com is read.
- By repeating this process with any site in their affiliate network, advertisers.com now has a way to track my browsing habits–even though I have never intentionally visited their website or volunteered my information.
Maybe I’m being a hard-ass here, but allowing 3rd party cookies should not be a default that can be disabled. Allowing 3rd party cookies is a bug that should be fixed.
New HTML5 Features
New HTML5 features like Web Storage and Canvas, along with the traditional functionality of browser cache can also be exploited to serve the same function as 3rd party cookies, but in a more powerful and permissive way.
WebRTC
WebRTC is a peer-to-peer application programming interface (API) that is baked into newer web browsers like (Edge, Chrome, Firefox, Opera). Peer-to-peer is a more efficient approach for direct user-to-user communication (ex: voice chat, video chat, remote desktop, file sharing). Sound’s great! What’s not to like?
Plenty.
- WebRTC uses fairly traditional methods of navigating its way through firewalls. Since traditional methods of doing this are not 100% effective, WebRTC may have to fall back to using a TURN server. TURN servers are used to relay traffic when a true peer-to-peer connection cannot be established. Traffic that flows through a TURN server can be snooped by the TURN server.
- WebRTC can be used expose user information to 3rd parties. This information has been used by the New York Times to track users. It has also been used to compromise the security of VPN tunnels.
- There is an option to disable WebRTC in Firefox. There is no built-in option to disable it in Google Chrome.
Using something like TOR, SOCKS, HTTP Proxy, or VPN to safeguard your privacy is not a bad idea. The problem is that the overwhelming majority of web browsers–including all of the popular ones–can leak information despite your best efforts.
Recommendations
- Disable 3rd Party Cookies
- If privacy is crucial, it probably shouldn’t be done in a web browser.
- If privacy is crucial, and it has to be done in a web browser, a simple text-based browser like Lynx, w3m, or ELinks (with cookies disabled) would probably be a better choice than any of the popular graphical browsers (IE, Edge, Firefox, Chrome, Opera).
- If you have to use one of the popular browsers, do it in "privacy mode" or "incognito mode".
- Regularly clear your cookies and browser cache.
- Many people use web-based e-mail. Web-based e-mail is subject to the same vulnerabilities. Accessing your mail with IMAP or POP, and disabling images in your e-mail client is safer.
Tsahi,
My primary point here is that modern browsers have a lot of stuff in them. No matter how smart the guys you have working on them, mistakes are going to be made, holes are going to be left open. Add to that the fact that most major contributors have financial incentives diametrically opposed to the user's privacy, and sometimes the holes are actually features. So, if you're doing something super-sensitive, a modern browser may not be the best tool for the job.
As for WebRTC, mandatory encryption is nice, but it's not everything. Consider the variable number of places that get to know who you're talking to.
Even if we take the signaling service (party 3) as a necessary given, we may have to do an ICE/STUN (party 4). Say ICE/STUN doesn't come through. Now it's time for TURN (party 5). Now there are potentially two parties above bare minimum who know who I was trying to reach and when. Perhaps they're all part of the same group that I happen to trust, or perhaps 4 & 5 are outside affiliates that are being used to track user patterns across properties 3rd-party-cookie style.
Encryption-or-not, the NYT has already used this to snag local IPs. In your article you downplayed the value of that information, but value is in the eye of the beholder. If I wanted a more fine-grained tracking of users behind a NAT, that would be a nifty piece of info to have. Information is power. I think it would be better if people had a little more control over how much these browsers share today.
Thanks for the feedback!