Online Privacy is Dead... If You Let it Die

Posted by Josh Dukes on October 11, 2011 at 10:11 AM

Privacy Facebook cookie tracking habits and recent developments like "frictionless sharing" have (again) put a lot of focus on Facebook and the way they handle privacy. Such information has caused some users to express a fear of the organization. It's easy to lose track of the fact that "frictionless sharing" is opt-in (for now), and (if you believe Facebook and ignore the recent user tracking patent application) the cookie tracking was less Orwellian than a simple bug in the log-out system.

The thing is that the Facebook debacle is not worth the focus. The micro-debate over how Facebook uses what data, and that they may or may not violate your privacy is a distraction from the foremost problem of our privacy culture: it is that, in essence, we don't have one.

Nik Cubrilovic really hit the mark: "Privacy today feels like what security did 10-15 years ago... The risks around privacy today are just as serious as security leaks were then - except that there is an order of magnitude more users online and a lot more private data being shared on the web."

In security we have the concepts of "white-listing instead of blacklisting" and "principle of least privilege." We assume that anything that isn't necessary or known good is potentially dangerous. We learned this through years of trial and error (and error, and error...) Instead of looking for things that could be abused and blocking those, we assume that anything could be abused and only allow the minimal set of things (because it's just not worth the time to enumerate all the bad things at the risk of missing one).

Currently privacy is conceptually the reverse. "What could it hurt to share x, y, or z?" we say, instead of "Why is the benefit of sharing x, y, or z worth the potential risk?" By changing the way the discussion is framed we see beyond the petty argument about if Facebook is really tracking you, and return to the real discussion of what information we give up and why.

Lets look at the Facebook cookie issue again with fresh eyes. Much of the time when you go to a website that contains a social networking badge (Facebook Like, twitter tweet, Google+ +1, etc.) a connection is made to back to the social networking site. This may be used to retrieve content, but it could also be used to identify you and track your browsing habits. This isn't unique to social networking, however.

Many modern sites make cross domain requests so that the content of one site can be transparently embedded in another. Other requests will be made for the sake of analytics. The apparently seamless integration however risks your privacy, and analytics often openly violate it. Facebook is just one site doing something that lots of sites do in lots of ways. Facebook isn't the problem; the problem is that we give up our information all the time - and frequently we aren't even aware that it's happening.

Any time a request is made to a site, information is sent to that site in the form of headers. By embedding content in multiple sites, organizations like Facebook can track your browsing habits. Cookies make this much easier but other headers such as User Agent can provide enough information to uniquely identify you (This is called Browser Fingerprinting.) Some sites require content from other sites in order to function properly, but many of these requests are not needed and can be entirely avoided.

The good news is that there's an easy fix for this specific problem.

A Firefox plug-in (similar to NoScript) called Request Policy protects you against this type of data leakage by blocking all requests that aren't from the domain you expressly requested, a subdomain of that, or otherwise explicitly whitelisted. Not only does this help protect privacy, it also has the added benefit of helping prevent other security problems such as Cross-site Request Forgery.

When using Request Policy some sites will break. Digg.com, for example, loads content from diggstatic.com. Because requests from digg.com to diggstatic.com are blocked by default, the content and layout won't load without user interaction. Once diggstatic.com is expressly whitelisted the page will load properly and will continue to load properly unless Digg decides to change they way they host their content.

Many sites work without any interaction at all, unfortunately some require more work to view properly. Many sites will store content on a CDN (Content Delivery Network) like Akamai, others will include content from a parent site or another content site like twitter or Wordpress.

Security and privacy are at times inconvenient, but we've learned that it makes sense to actively defend our privacy rather than be unpleasantly surprised. The more we as users push sites to respect our privacy, the easier it becomes to spot sites that violate it. Also, the more experience we have defending ourselves, the better we get at it and the harder it is to take advantage of us. Freedom and privacy are not given, they're taken. Maintaining our rights is an active effort that requires collaborative focus and dedication. Plug-ins like Request Policy won't fix the privacy problem alone but they're definitley a step forward.

As would be expected, some of the sites referenced in this article are broken by Request Policy: The PC World article requires staticworld.net for images. nikcub.appspot.com does not appear to load properly in Firefox 7 at all, but is no worse off with Request Policy as far as I can tell. Scripting.com loads, but requires disqus.com for comments. Panopticlick.eff.org, www.requestpolicy.com, addons.mozilla.org, and wikipedia.org have no outside dependencies and load properly without any interaction. Gizmodo.com loads images from gawkerassets.com. (Oh yeah, and, last.fm loads images from lst.fm and requires googleapis.com to run... but the command line version might have less cross domain dependencies. ;)

Topics: privacy

Josh Dukes

Written by Josh Dukes