Evercookies

Extremely persistent browser cookies:

evercookie is a javascript API available that produces extremely persistent cookies in a browser. Its goal is to identify a client even after they’ve removed standard cookies, Flash cookies (Local Shared Objects or LSOs), and others.

evercookie accomplishes this by storing the cookie data in several types of storage mechanisms that are available on the local browser. Additionally, if evercookie has found the user has removed any of the types of cookies in question, it recreates them using each mechanism available.

Specifically, when creating a new cookie, it uses the following storage mechanisms when available:

  • Standard HTTP Cookies
  • Local Shared Objects (Flash Cookies)
  • Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
  • Storing cookies in Web History (seriously. see FAQ)
  • HTML5 Session Storage
  • HTML5 Local Storage
  • HTML5 Global Storage
  • HTML5 Database Storage via SQLite

And the arms race continues….

EDITED TO ADD (9/24): WARNING—When you visit this site, it stores an evercookie on your machine.

Tags: , , ,

Posted on September 23, 2010 at 11:48 AM • 65 Comments

Comments

Dan • September 23, 2010 12:00 PM

Tried this on a Mac with Safari and FireFox; doesn’t do what he claims. Of course, that could just me more misdirection…

Greg • September 23, 2010 12:42 PM

A combination of FlashBlock and perhaps RequestPolicy, combined with caching set to 0 and a block on the ever cookie creator domain results in no ever cookies being successfully set on FF 3.6.10 on RHEL 5.4

If I don’t block the domain cookie creation then just a standard cookie is created.

andy • September 23, 2010 12:48 PM

None of these are completely new, but the combination of these does make for one tough cookie :-).

Some of theme are on the verge of genious on their own, but not of particular usefullness (I’m looking at you web history!). Most of them are easily defeated on their own (turn off javascript and cookies and half of them are gone), but to defeat all of them it would take either an out of date browser or some serious thinking (and probably accepting a little loss of features wrt HTML5).

Perseid • September 23, 2010 1:21 PM

@ a
“Can one prevent this by running a Javascript blocker?”

Yes, with NoScript pretty few of them work (normal cookies keep working of course). But that is an easy to overcome obstacle. If a site doesn’t work like I expect it to I immediately (temporally) allow the site.

I was surprised that even if I clear the last hour of my history (Firefox 3.6) historyData and pngData still remain. And if I clear all my history, the pngData still doesn’t go away. Frightening.

Robertson • September 23, 2010 1:25 PM

So, would somebody please post a simple description of how to delete all the stuff that ever cookie creates?  Anything it can create, surely we can delete or overwrite?

Paranonymous • September 23, 2010 1:40 PM

One trick, for users with a modicum of technical skill, is to create a pristine profile for Firefox, with all required settings, bookmarks, etc and back its directory tree up to a tar or zip archive.

Then wrap a script around Firefox that destroys the profile’s directory tree on exit and reinstantiates it from the archive on browser start.

Best combined with cookies off, scripts and flash off, adblock etc and linking ~/.adobe and ~/.macromedia to /dev/null.

It doesn’t entirely prevent these attacks on privacy, but it will ameliorate them to a large extent, if the user is not too profligate with tabs, and periodically restarts the browser.

For the truly pissed off, there is also the option to create a VM on virtualbox, qemu, vmware, or whatever, and reinstantiate that from a known clean snapshot each time a browser is required – possibly combined with an anonymising proxy.

Of course what the above tricks really need, is a good, simple and intuitive, graphical skin for unskilled users on multiple platforms.

Wes P • September 23, 2010 1:51 PM

According to the article, private browsing modes will clear these cookies when the browser window is closed.

billswift • September 23, 2010 2:00 PM

This is one place where security by obscurity works.

The problem is that obscurity doesn’t work for very long, not that it doesn’t work at all.

Besides, what I think you are getting at isn’t obscurity, it is “security by being a low-value target”.

jrr • September 23, 2010 2:22 PM

I had to enable Javascript for his exploit to even drop the cookies in the first place, which I normally do only very cautiously until the functions I actually need just barely work.
Once that was done, simply restarting my Firefox (with Better Privacy loaded to clear the LSO) and clearing cookies took care of it.

jeff • September 23, 2010 2:23 PM

At what point does it become criminal computer trespass for a website to take great steps to contaminate my machine when I am, by my actions, making it abundantly clear that I don’t want those things on my computer?

If I did to the server what these guys are doing to my client, I’d have the FBI at the door.

Will • September 23, 2010 2:24 PM

All these things have been known to those in the browser privacy side of things forever.

The value of this excellent open-source demonstration of the techniques is to bring the issues to wider attention and start a debate.

The bad guys don’t make open source demonstrations, they keep the code to themselves.

EscapedWestOfTheBigMuddy • September 23, 2010 2:25 PM

Malicious code.

It attempts to store data that I may not approve of on my computer and make it hard for me to either set policy to prevent it or remove it.

Malicious by definition.

lazlo • September 23, 2010 2:35 PM

The thing that I wonder, (and I could probably figure it out by looking at the source code sufficiently) is what this does if you modify one of the cookies it sets. Does it then regenerate both the valid cookie and your “cooked” cookies in all places?

Magic Johnson • September 23, 2010 3:35 PM

Doesn’t work with OpenBSD, FF3 in private browsing, cookies disabled & noscript enabled.

@Paranonymous at September 23, 2010 1:40 PM uses a technique very close to mine. You can also use multiple profiles… for example, a Facebook profile, a gmail profile, one for general browsing, etc., all with individual about:config settings.

Chasmosaur • September 23, 2010 8:08 PM

I’d be worried, but I’m guessing CCleaner will be all over this – one more step for them to clean.

David Sheeks • September 23, 2010 10:03 PM

These are just the type of things the HOSTS file is good for. Mapping any domains using this technique to a non-routed IP makes them go away. Unfortunately it’s a never ending battle…

Albireo • September 24, 2010 2:19 AM

Does not work with Firefox 3.6.10 with Adblock plus 1.2.2 and BetterPrivacy 1.48.3 and Firefox set to “Keep cookies until Firefox closes”.

Creating the evercookie, closing Firefox and revisting the page yelds all nulls.

Winter • September 24, 2010 3:41 AM

Copy a clean firefox directory into tmpfs on startup. then mount it on a directory in .mozilla_firefox. Add every place that might record something to it.

After you reboot everything is gone.

This obviously ONLY works when you reboot your system from time to time. But you could umount/mout the tmpfs

If you want to keep recording bookmarks and installed plugins, handle them by way of links.

http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs

< anonymous • September 24, 2010 8:10 AM

Does not persist on uzbl. My guess is the only cookies that would are the classical type. These are purged when uzbl is closed.

< anonymous • September 24, 2010 8:16 AM

Sorry for triple post, if the moderator wants to merge my posts I’m fine with that.

Here’s the output form the example when I try to recover the cookie,

Cookie found: uid = undefined

pngData mechanism: null
etagData mechanism: null
userData mechanism: undefined
cookieData mechanism: null
localData mechanism: null
globalData mechanism: undefined
sessionData mechanism: null
historyData mechanism: undefined
dbData mechanism: null
lsoData mechanism: undefined

yak • September 24, 2010 9:26 AM

I was wondering when bruce would cover these. I use better privacy for the LSO’s and I am told that using a virtual machine for every session and dumping it after will keep stuff out, but you guys are the computer experts, I’ll look here for tips.

I own my hard drive, if anyone else want to use it for their purposes, either they pay rent to me every month or they are illegal squatters tresspassing on my property.

jrb • September 24, 2010 10:11 AM

google used to try to have a near never-ending cookie back in the day. It was frowned upon by the early privacy activists.

now they just tie all your information to a single account, it’s a lot more effective. i can’t see big business using such nefarious techniques, if only because actual user account implied information between accounts and services is a lot more efficient, and privacy is a more public issue these days.

i guess if the underworld (porn, et al) get hold of this, and get it working properly it’ll be something to be feared.

Paeniteo • September 24, 2010 11:05 AM

@yak: “I use better privacy for the LSO’s and I am told that using a virtual machine for every session and dumping it after will keep stuff out, but you guys are the computer experts, I’ll look here for tips.”

The “attack” is just a little Javascript that combines the currently-known ways to place persistent information on a user’s PC into one integrated approach.
No magical VM-escape or whatever involved.

cu, Paeniteo

Ward S. Denker • September 24, 2010 1:28 PM

Most modern browsers can be configured such that this isn’t a problem, with the exception of persistent storage and flash cookies.

For several browsers (Chrome, Firefox, and Opera) the FlashBlock user script (greasemonkey) will work to reject unwanted flash applications. That will take care of flash cookies for most of us (unless you elect to run the flash application that sets them).

I’m an Opera user and I cannot seem to disable persistent storage, but all of the rest are prevented by a few user settings.

Nick P • September 24, 2010 2:47 PM

This can be prevented using the web surfing method I recommend to clients. Well, it will be limited rather than prevented. I recommend doing the web surfing in an isolated virtual machine with a very controlled method of sharing persistent or local documents. The latter is somewhat of a trade secret but I’m sure you could come up with it.

The virtual machine should be running a hardened version of Linux and the browser data on a RAM drive. A read-only, RAM-based Linux distro on a dedicated machine with KVM switch works as well. Every time the VM is reset to the snapshot, all data is erased. The more you do it, the more resistance you have to persistent malware. The only way to defeat the system is to find a vulnerability in the TCB. This is the processor, firmware, BIOS, hypervisor and a few trusted apps. More in some hypervisors. That’s better than having the entire Linux stack as the TCB.

Recent developments that make this setup easier are QubesOS. QubesOS is Joanna Rutowska’s project that uses Xen hypervisor, a trusted GUI, and Linux VM’s to separate certain activities. You could have a regular desktop and then one or more VM’s for web surfing. Use one to surf while the other is restoring to snapshot, if it has that capability. I haven’t used it yet but I like its design. The use of Xen and it’s console-guest model’s huge TCB makes the assurance questionable.

orange dot • September 24, 2010 7:59 PM

this site:

http://view.samurajdata.se/

converts PDFs freely online, works better than Adobe’s on-line conversion page, has no ads, you don’t download the PDF prior to converting.

should you decide you’re stupid enough to download pdfs, convert them with “pdftohtml”, never, I repeat never load them with any software, whether mac, pc, linux, etc…..

Nick P • September 25, 2010 12:57 AM

@ orange dot

“should you decide you’re stupid enough to download pdfs, convert them with “pdftohtml”, never, I repeat never load them with any software, whether mac, pc, linux, etc…..”

That statement reeks of stupidity itself. Never download your college course materials and open them. Never download PDF’s from trusted sources that virtually never have an infection. (ACM, IEEE and Citeseer are examples on my end.) Never download and open mandated PDF forms from government sites.

Wow, your warning says to act on the ultimate state of paranoia regardless of the risk involved or utility in opening PDF’s. Fortunately, most people reading and posting here are smart enough to know security is about risk management. Threats + Likelihood of Occurrence = Risk. Risk vs Reward vs Prevention/Recovery Costs = Decision on how to deal with it. Usually, opening PDF’s from good sources poses no problems. Even people I know who continuously download PDF books via BitTorrent from reliable sources (w/ RSS feeds and such) say they haven’t ever been infected. So, determine risk and trustworthiness of source, then choose to open or not. Don’t freak out over every PDF you encounter. That’s just nonsense.

mat • September 25, 2010 1:35 PM

A private browsing could be done by :

$ HOME=/tmp/fire firefox
[enjoy surf]
$ rm -rf /tmp/fire

But this rely on sofware using $HOME. Some try to be clever (like glib) and get the real home from passwd…

Stephan Sokolow • September 25, 2010 2:21 PM

@orange dot

Generally, it’s sufficient risk management to open PDFs in something not based on any Acrobat components and with Javascript disabled. Most Linux PDF readers fit the bill and throw in free “Ignore DRM” checkboxes.

As for evercookie, you can basically neuter all of evercookie’s current and planned methods without making your browsing any more bothersome by using this combination of of Firefox extensions and tweaks:

  • Unset “Accept third-party cookies”, set “Keep until ‘I close Firefox'”, and install CS Lite. (CS Lite gives you NoScript-style convenience for setting cookie exceptions on trusted sites so they can remember you between sessions)
  • Install BetterPrivacy (Whitelist-based Flash LSO and DOMStorage removal)
  • Set “Clear history when Firefox closes” and make sure “Cache” is set in the “Settings…” button for it. (Forces the pngData and etagData portions to session-only)
  • Install NoScript and make sure “Apply these restrictions to whitelisted sites too”, “Forbid Java™”, “Forbid Adobe® Flash®”, and “Forbid Microsoft® Silverlight™” are checked in the Embeddings tab. You can set “Scripts Globally Allowed” if you want. What’s important is the strong FlashBlock-like protection against his planned Silverlight and Java tracking mechanisms (especially Java since it’ll use your MAC address rather than generating a new random ID each time) and the second layer of protection against Flash LSOs. Theoretically, you can also unset “Forbid Adobe® Flash®” as long as you’ve got BetterPrivacy, but why rely on only one layer of security… especially when it’s a more reliable alternative to the FlashBlock extensions.

  • Set “browser.sessionstore.privacy_level” to 2 in about:config to ensure that none of your “session-only” stuff gets persisted by crash recovery or session-saver extensions.

  • Make sure you’re running a version of Firefox new enough to have the getComputedStyle() :visited patch. This kills off web history storage. (The bug tracker seems to say it’s landing in Firefox 4, but I’ve got it blocked in 3.6.9, so maybe NoScript or BetterPrivacy is doing some runtime patching for it)

userData is IE-only, so Firefox users need not worry about it. HTML5 Database Storage was only implemented in WebKit before they changed their mind about enshrining SQLite in a standard, so same thing. As far as I can tell, “window.name” should be made session-only by the browser.sessionstore.privacy_level tweak, so these instructions cover all present and future storage mechanisms currently announced.

The secret to dealing with things like evercookie is looking at each storage mechanism as its own problem so you don’t get distracted by the combined product when looking for solutions.

Aryeh Gregor • September 26, 2010 12:45 PM

The types of storage here fall into four categories, as far as I can tell.

1) Stuff that browsers treat like cookies: cookies, session storage, local storage, database storage. These are all basically equivalent to long-lived cookies: when the user clears cookies, the browser will clear them too. Using all of them instead of just one doesn’t help store things longer, at least in principle.

2) History storage. This is related to a well-known history-sniffing attack. Firefox 4 is currently the only browser to fix it, but others probably will too at some point. (Using it to store data is novel, though, AFAIK.)

3) Flash cookies, and possibly some of the other non-standard things listed. Flash cookies are a well-known problem; most users never clear them, and they aren’t cleared via browser UI.

4) The crazy cache-based thing.

(4) is the only really new thing, I think. It’s an interesting attack — I don’t see how browsers could defend against it without disabling caching entirely. The first three give you nothing better than just setting a cookie in Firefox 4 with Flash disabled, and nothing better than just setting a Flash cookie in Firefox 4 with Flash enabled. The PNG caching thing will still work even then, unless you use private browsing.

A Reader • September 27, 2010 10:23 PM

With the Safari browser on the iPod Touch platform, at least with version 4.0.2 of the iPod Touch OS, the following information may be of interest. Under the Safari preferences, it is possible to delete cookies, the browser cache contents, and the browsing history. If a Web page has stored data in an offline database, the Safari preferences will have a “Databases” option below the “Accept Cookies” option. (If no data has been stored in an offline database, the “Databases” option will not appear.)

At the same time, there appears to be a “local data” storage mechanism that is separate from the “databases” mechanism. (On the evercookie page, the “localData mechanism:” entry seems to refer to this.) To clear the “local data” for a specific domain, one possibility is to load a valid URL for that domain, and then to load the following JavaScript URL:

javascript:document.cookie=”;sessionStorage.clear();localStorage.clear();document.location=”http://example.com”;

Roger • September 28, 2010 9:36 AM

SO, with the massive security nightmare that Flash is becoming[1], does anyone out there not run a flash-blocker?

(And am I the only one who found it ridiculously difficult to do the super-urgent critical Flash patch on Firefox? Why the heck doesn’t it work just like a standard add-on?)

Paranoiac • September 28, 2010 7:37 PM

I went to Samy.pl/evercookie and did his tests, as well as downloading and running BleachBit 0.8.1, today. Passing the Samy.pl tests wasn’t too hard: BleachBit eliminated the trial cookie and all references to it, as did my simple DOS script (I use Windows Vista – I know, I know …) to wipe out the Flash Player directory and its contents, in concert with the Clear-Recent-History option in my browser (Firefox 3.6.10).

Unfortunately, it looks like neither method eliminated the Schneier 9/24 cookie mentioned above (“WARNING — When you visit this site, …”). I had come to this page earlier in the day using the “Posted on September 23, 2010 at 11:48 AM” link on the Schneier blog, and when I came back just now, the link was still grayed out. I can’t be sure that’s from the Evercookie (since I can’t FIND the Evercookie), but I suspect it is. That also isn’t an indictment of BleachBit, as I may not be using the program correctly, but I will agree with the other commentators: “Frightening.”

“And the arms race continues….”: You bet. Where there’s a market, there’s a way. Just follow the money.

Andrew Ziem • September 28, 2010 10:54 PM

Paranoiac: The link “Posted on September 23, 2010 at 11:48 AM” should always grey (meaning visited) because it points back to the same page it is listed on.

Paranoiac • September 29, 2010 5:45 PM

Andrew Ziem:

Thanks. Good to know. There must be something wrong with my browser (or the residue of my compulsive cookie-clearing), then, because the link “Posted on September 23, 2010 at 11:48 AM” is pretty consistently blue when I come directly to this page, and gray when I click on the link on the master blog that leads here. I have some more sophisticated experiments I want to run on Evercookie (“sophisticated” meaning “time-consuming”), and will add this low-intensity problem to the investigation regime.

Dale • October 8, 2010 1:33 PM

I’m fairly confident that none of those
methods worked with Lynx either. It
isn’t normally bothered by Javascript.

Veit • October 13, 2010 3:58 AM

This is frightening. I try to remove those ones step by step. Now, does anybody have a clue on how to remove the globalData section using javascript (meaning: a bookmarklet)? What I have working so far is:
javascript:localStorage.clear();sessionStorage.clear();
but globalStorage.clear() does not work for me.

Ziggurat • October 13, 2010 10:42 PM

“It doesn’t work if I don’t use flash or javascript blah blah derp!”

It also doesn’t work if I don’t use a computer!

check • October 17, 2010 5:23 AM

I use MAXA Cookie Manager (http://www.maxa-tools.com) to manage all kinds of persistent cookies (Http, Flash, Silverlight, HTML5 DOM, …) and clear my browser history+cache. That’s enough to get rid of “evercookie”.

pork rinds • November 23, 2010 11:37 AM

NeverCookie for Firefox is available, beta right now, takes care of the evercookie.

Requires a new Firefox profile where your old bookmarks will not be in case you want to use it all the time.

Uncheck the “Do not show again” so the profile selection window shows when Firefox is restarted or have to research how to enable Firefox profiles for your OS.

http://nevercookie.anonymizer.com/

See Slashdot article about NeverCookie.

HMT • April 6, 2011 12:56 PM

If you black out all the add-ons (including disable JavaScript and Java) in Firefox, you can eliminate evercookie. BUT sometimes, you have to enable some of add-ons and JavaScript. In this case, the best defense for evercookie is to use virtualization environment, such as thinstall or ThinApp. First you need to have a clean system without Firefox installed. Install Firefox in the virtual environment. Configure the Firefox after installation. When finished, keep this original copy in a secure place. Each time you need it for a mission, make a copy from the original one. When you finish the mission, delete the copy.

Roland • November 4, 2013 12:20 AM

Got this on Slashdot a while back, I run them every evening
after shutting down firefox:
1)create a bash function:
clean-firefox ()
{
for i in ~/.mozilla/firefox/.default/.sqlite;
do
sqlite3 $i “vacuum;”;
done
}
2)create an alias:
alias cleanflash=’rm -rf ~/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys/* ~/.macromedia/Flash_Player/#SharedObjects// ~/.adobe////‘

Gnu Tzu • November 6, 2014 10:37 AM

Should be a violation of the DMCA.

Oh, wait; the DMCA is to protect corporations from having their chosen protections circumvented. When people chose to protect their privacy, corporations get to circumvent that all they want.

But, what do we call it when someone says “no” to something, and it’s done to them anyway. Remember that saying: “no means no!”

If I chose to draw the curtains, and someone peers around them, isn’t that called “voyeurism”? If I choose not to get intimate with someone and I say “no”, but they still force themselves on me, then isn’t that called “rape”?

If I knowingly choose to accept cookies, then so be it. But, if I choose to draw the curtain and say “no” to cookies, then just leave me alone. And, if a corporation chooses to not to let me see their content because I don’t accept cookies, that’s fine as well. That’s what agreements are about. But, if I say “no” and you deliberately use a technology to circumvent accepted methods of agreement, then you are violating the basic principal of consent. And, don’t try to bury some disclaimer in in the fine print of a long, legalese ridden EULA, because that’s still failing to acknowledge that by refusing to accept cookies I’ve already said “no”. Circumvention of privacy settings is still forcing yourself on someone.

Technology designed to circumvent my privacy controls is as immoral as voyeurism and rape. It should be illegal, and there should be a law with equal or greater force than that of the DMCA.

Igor • May 1, 2017 9:58 PM

Well, imagine a case you run a website with hundreds of registrations every day. Between those registered are also famous spammers from nigeria, ghana, etc. Even they are unable to register automatically by using bots, because I already implemented mechanisms to prevent it, there are still some who registers manually and once in members area they are able to keep posting their spam.
Would you still suppose to be unethical to set evercookie into spammers system to be able to identify a user who was previously banned from site for spam?
I don’t think so. As same as users have right for their privacy, the same has the website owner right to know digital identity of his website users.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.