The Register Guide on how to stay anonymous (part 2)
The Evercookie: Like trying to kill Steven Seagal
In part one of this series, I explored the privacy threats presented by targeted advertising, and asked why we should care. Browser referral, social media buttons and cookies were examined as examples of basic methods used to track our movements across the internet.
I also explored why advertisers track us, and examined browser plugins that allow us to prevent it. Those plugins come in a few flavours, depending on the threat they are countering and whether or not they trust advertisers to play ball and honour our polite requests not to be tracked.
Not all advertisers play by the rules. Some legitimate websites belong to organisations that gather your personal information not for their corporate advertising use, but to sell it at a profit. These companies rarely play nice, and they certainly don’t limit themselves to the basic tracking methods discussed in part one.
This then is an examination of the internet privacy arms race: where do we stand, how bad is it, and what threats are on the horizon?
Locally Stored Objects
Locally Stored Objects (LSOs) have been around since March 2002, debuting with Adobe Flash Player 6. They have been considered a privacy concern for quite some time and their use has embroiled companies in lawsuits.
For all intents and purposes, they are cookies that are created by applications rather than the browser. While LSOs began with Flash, nearly all major multimedia browser plugins are capable of creating their own, and all require special care and configuration to manage.
These “super cookies" are often cross-browser – create an LSO while browsing in Internet Explorer and a website you browse in Firefox or Chrome could read it – and merge your browse history to obtain a more complete picture.
The existence of these LSOs leads inevitably to the existence of zombie cookies and inevitably to the frightening evercookie. Zombie cookies are cookies that come back from the dead. They do this by storing themselves in more than one location. Clear your browser cookies, but forget to clear your Flash LSO storage, and the browser cookie can be rebuilt from the Flash LSO.
I say we take off and nuke the site from orbit. It's the only way to be sure
The evercookie takes this to an extreme. In addition to browser cookies, the evercookie makes use of Flash and Silverlight LSOs, your web history, HTTP ETags, your web cache contents, window.name caching, IE user data storage, the HTML 5 session, and local, global and database storage.
The evercookie also stores a cookie hidden in the RGB values of an auto-generated force-cached PNG file. The PNG file then uses the HTML5 Canvas tag to read the pixels (thus the stored cookie information) back out.
If you miss clearing any one of these storage locations, and when you next visit a website run by the organisation that stored one of these digital horrors on your computer, the evercookie will automatically repopulate the information to all of the other storage locations.
Clearing cookies on your browser won’t clear LSOs. The standard plugins you rely on to manage your browser cookies won’t deal with LSOs. These little scumbags require special attention.
KISSmetrics – used by Hulu until just recently – is one example of a company that built a tracking network based on this nearly impossible to kill technology. They eventually climbed down from that position.
How to tackle those hard-to-shift LSOs
If you have been hit by LSOs, zombie cookies or even the evercookie, don’t lose hope. There are techniques available to deal will all levels of browser-initiated privacy invasion.
LSOs either have to be dealt with plugin by plugin, blocked from creation altogether or managed by a dedicated plugin. As with plugins covering the basic privacy vulnerabilities, each browser requires its own tool. Unfortunately, tools to cope with LSOs are not available covering all add-ons in all browsers.
Ghostery is a critical tool. While Ghostery does not provide a method to manage your LSOs, and it only manages LSOs from the organisations for which it has profiles, it works across all browsers and can be configured to delete both Flash and Silverlight super cookies when the browser closes.
TACO (Firefox) performs a similar service, but adds in the ability to manage HTML5 DOM objects. Better Privacy (Firefox) handles only Flash and Silverlight cookies, but presents you with a beautiful management interface. It can kill LSOs on command or upon browser exit, and gives you a little popup informing you when a new one has been created.
Click&Clean (Firefox, Chrome) deserves an honourable mention. At the moment, the Chrome version is more advanced than the Firefox version, and it does not support other browsers.
The Chrome version however is quite something special. It is the only in-browser tool I have found that clears Flash and Silverlight cookies, Java cache, Google Gears data, extensions' local storage, traditional browser cookies and SQL databases. This is very close to being not simply an LSO cleaner, but an evercookie killer. (More on that later.)
When in doubt about your ability to nuke existing cookies of all forms, you can always rely on the big guns. Bleach Bit (Linux, Windows) will kill the evercookie. Jeremiah Grossman has information on cleaning Chrome, while Dominic White has you covered in Safari.
In most cases, you shouldn’t have to worry about more than cleaning out Flash and Silverlight LSOs. Most browsers can restrict HTML5 DOM calls in one form or another, and modern browsers by default ask before allowing any third-party HTML5 DOM calls.
Java: Just say no
Java is just so unbelievably broken, it's truly irresponsible to put it on any computer that doesn’t absolutely require it. This security threat must be disabled (Firefox, IE, Chrome, Safari, Opera) in every browser, full stop. There is no reason to allow Java to execute from a browser, ever.
If you run an outdated corporate application that absolutely requires Java in a browser, that browser should be viciously locked down and preferably running inside a specially configured and heavily fortified virtual machine. Allowing Java to remain enabled on internet-facing web browsers without some form of click-to-activate security plugin borders on criminal negligence.
So with Java out of the picture, and browsers at least beginning to take care of HTML5 DOM storage, the average user should be able to clean up most third-party cookies. But what if the cookies are placed on your website not by some third-party advertising network, but rather by the very website you are visiting? Infected websites are becoming more and more common, and some websites even use these technologies by choice.
Prevention is better than the cure
None of these tools however prevent the LSOs from being created in the first place. This is because in order to do so, you have to prevent the add-ins from running. For that you need something like QuickJava.
QuickJava is a fairly high maintenance plug-in; it requires you to maintain your own lists, but it is far less intrusive than the alternative.
The alternative, of course, is NoScript. NoScript's approach to browser security is to nuke a site from orbit. It's the only way to be sure.
NoScript does not allow any scripts to run by default. You must allow each domain from which you want to approve scripts to run. Any third-party tracking elements – any script, or application that uses a (non-whitelisted) domain name – will have to be manually enabled. Domains can be whitelisted permanently or temporarily, and it can be further locked down to provide absolutely complete preventative security. It even includes clickjacking protection.
And yet, it moves
All of the above presupposes things work as advertised. Unfortunately, this is rarely the case. Browsers – and especially multimedia add-ons – have bugs in them. Pulling a random example out of a hat, here’s a Flash privilege escalation bug from earlier this year. The long and the short of it is that if I were to write an appropriately evil Flash app, I could do anything on your computer that the user running the browser could do.
My favourite example is simply that of reading, writing and modifying files. I might get away with using Flash to plant a trojan or other form of malware, but so what? The public is completely inured to such risks and nobody is going to take that seriously. The far more shocking – but entirely possible – hack is simply to use this power to overwrite Flash’s own default settings file. From here, I can set Flash not to pop up a warning when it turns the webcam and microphone on.
Suddenly, Adobe Flash is literal spyware.
That very same trick could be used to change browser settings. This includes reenabling Java so that even more havoc can be wrought, disabling all your carefully assembled plugins and more.
On the horizon
HTML5 is a huge threat to privacy, and both browser makers and web standards bodies are slow to respond. The European Network and Information Security Agency has identified 50 problems so far, and more are sure to follow with further research.
The online privacy arms race has only just begun. ®