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.
Next page: How to tackle those hard-to-shift LSOs
A fully up-to-date Java probably isn't a much bigger threat than an up to date flash. But the problem is that java is often not updated! It is usually less up-to-date than flash, in many cases due to compatibility with critical applications.
During 2010, java exploits skyrocketed. Many researchers claimed they had in fact surpassed flash's astounding list of vulnerabilities. Sandboxed (in theory) or not, Java has become THE way to use an exploit to drop malware on a windows PC.
If there is enough interest, I'd be happy to write a quick summary article talking about the research. Suffice it to say that no, I'm not a paid shill for anyone here - why would Microsoft, aspiring cloudmongler of extraordinaire – hire a sysadmin? They are busy spending billions trying to ensure my kind are completely unnecessary!
I am willing to bet that Silverlight, Flash and Java have a roughly equal number of bugs with roughly equal severity per line of code. The issues that lead to their risk level are a combination of distribution and patching.
As discussed above, Java is the one that is least updated amongst the bunch, and who really cares about malware on the PCs of both Silverlight users? As near as I can tell, Silverlight is used for Microsoft properties, small handful of other websites to display video and storing evercookies.
So no, I’m not promoting or demoting one technology over another here. I am saying that allowing Flash/Java/Silverlight (or anything remotely similar) to simply launch on any website they feel like launching is bad. Not only is it a privacy issue, but it is a security hole by which fun things can take over your PC.
Use a plug-in to force them to ask for each and every website whether or not they have permission to execute.
If you don’t believe me about Java, then there is a safe, simple experiment you can run. Set the Java console to enabled at startup. (http://download.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/console.html) Every time Java is launched from a webpage, a popup will appear that shows you “hey, something is activating Java…and this is what it is doing.”
Browse around the web for a few months with it on. You’ll be quite surprised how many websites use Java that you didn’t know about, and how many are trying to exploit vulnerabilities. The largest problem behind Java isn't that it is vulnerable, it is that nobody seems to realise how broken it really is.
We all defend against Flash. It's time to do the same against Java.
Yes a rant
The problem with Java according to the evidence presented seems to be poor auto-updating and a large install base of old versions so that old and vunerable versions of java are frequently available for exploit.
This is a real problem for the internet as a whole but not an indication that up-to-date versions are inherently less secure than up-to-date versions of other plug-ins.
@Destroy All Monsters
Is it, really? I thought the point of browser-side Java was to provide me an applet that performed a service. Either it was a game, or it was a file browser, or some other useful widget. The browser-side java something-or-other should be obvious. Something visible that provides the user a benefit.
What it shouldn’t be is a 1px dot somewhere under a div, hidden away whose sole purpose is to plant a cookie, read files off your PC, or drop malware via an exploit.
Browser-side java can be a good thing. In the real world however the bad guys are using it a heck of a lot more than the good guys. What’s worse, when the good guys do use it, they are typically slow to update, requiring older versions of java (with known exploits!) to be used if you want to use that one critical java app on that one website.
Any browser plug-in, be it Java, Flash or Silverlight should be obvious when in use. It should ask the user “do you want to use this third-party software that may screw up your computer, kick your dog and end the world as we know it?” It should warn you each and ever time that it kicks in if your version of the plug-in is out of date.
Browsers – by and large – are secure. Yes, there are exploits discovered for each of the main browsers every year. But far more as discovered – and regularly exploited – for these “common browser extensions” than the underlying browsers themselves.
Browser extensions should never be activated without your knowledge. Especially risky ones like Java that have a great deal of access to your PC. The idea of browser-side java is to provide the end-user with a useful applet that does something the user wants it to do.
Not to operate – ever – without the user’s knowledge.