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.comBlog.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.comShop.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.

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.

← Older   Newer →

Responses (2)

  • I think you are taking the analysis and risks of privacy by WebRTC a tad too far... TURN servers may well be used to relay media, but: 1. The traffic that flows through them with WebRTC is encrypted end-to-end, so they can't really "see" it 2. This server is part of the service you are consuming already, so there's this trust thing where you decided to do a call through a service, but now don't trust it to carry your call... The VPN issue has been given a special treatment in WebRTC to solve it. And nefarious uses will exist for everything out there, so why stop here?

    Reply
    • 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!

Leave a Reply


<a href="" title="">, <abbr title="">, <acronym title="">, <b>, <blockquote cite="">, <cite>, <code>, <del datetime="">, <em>, <i>, <q cite="">, <s>, <strike>, <strong>