Evercookie: a tracking browser cookie you can't delete

Samy Kamkar, an open source developer whose motto is "think bad, do good" has released an API called "evercookie." Evercookie sets a nigh-undeletable tracking cookie in your browser, storing the information in eight separate ways; if you try to delete it but leave even one copy of the data around, it will repopulate itself using that last shred. Evercookies can even spread between browsers on the same system. The point of the project is to show that browsers are lagging behind privacy-invaders when it comes to cookie management, and to spur the organizations that publish browsers into creating better tools for privacy management.
"I hope evercookie simply demonstrates to people what types of methods are being employed to track them and to decide whether or not they want to prevent those methods," he said. "evercookie took less than a day to create for me as a security hobbyist, so I can only imagine the technology that funded developers are producing."

Kamkar says he doesn't actually use evercookie to track people--it exists largely as a proof of concept, and he's not using technologies that are particularly bleeding edge in the developer world.

"None of these are new techniques," he told Ars, "but an API like this is awesome at raising awareness."

Of course, the mere fact that evercookie exists (and exists as an open source project that anyone can use) means that there will be some evil Web developers who make use of it, but that's almost the point. We're supposed to be scared.

Kamkar sees his project as a kind of litmus test to see whether people really are up to protecting themselves from being tracked by persistent cookies that anyone could implement, but he also understands that the "average" Internet user is hardly aware of traditional cookies, much less Flash cookies and beyond. Deleting the data from all eight (or more) storage mechanisms can be a pretty daunting task even for the relatively experienced surfer.

Zombie cookie wars: evil tracking API meant to "raise awareness"

(Image: Peanut Butter Cookies, a Creative Commons Attribution (2.0) image from veganfeast's photostream)


  1. “…storing the information in eight separate ways; if you try to delete it but leave even one copy of the data around, it will repopulate itself using that last shred.”

    And he didn’t choose to call it a horcrux? I’m sorely disappointed.

    1. Simple solution: symlink the cookies file to /dev/null . Cookies work for as long as the browser is open, but once the browser is closed (program exited), the cookie data is gone. Next time the browser is started it has a blank cookie data file!

  2. Thanks for featuring this sort of stuff on BB. This kinda white-hat work is what we need more of – the kind that raises broad awareness and makes people ask questions. Questions like “why has the toolkit I use, as a non-techie, to access the WWW, not evolved so that I am equipped to defend myself against these ubiquitous threats?”

  3. If his motto really is “think bad, do good”, shouldn’t he also have developed an open source API that let people undo the damage his other API is likely to cause? Or would that not be as much fun?

  4. Awesome philosophy. I’m going to start mugging people and then blame them for being strong or well-armed enough to fend me off. Thanks for the brilliant idea!

  5. Anon is more or less correct, a properly configured No-script add on can help with this. I also strongly recommend for people that are concerned that they check out the Firefox add-on called “Better Privacy”. It is an excellent LSO manager even in its default state. Not sure if anything like no-script or Better Privacy are available in other browsers, or how they work with different OS’s.

    Another common solution is to run all web activity within a “Temp” VM, which can return to original state when the session is terminated. I am sorry I don’t have time to grab the link, but the Slashdot post on this same subject may also be very helpful for people who are worried.

  6. I’m assuming that flash is the vector for cross-browser contamination… I’m sure some of these techniques are quite tricky but flash cookies, and the difficulty in deleting them, is certainly a major privacy issue.

  7. “Evercookie sets a nigh-undeletable tracking cookie in your browser, storing the information in eight separate ways; if you try to delete it but leave even one copy of the data around, it will repopulate itself using that last shred. Evercookies can even spread between browsers on the same system.”

    We have these already and they’re called viruses.

  8. This is sort of like saying “I found out how to break into your home just to prove that your home security isn’t good enough. I also gave every burglar in town the tools to do it, just to make the point that you should improve your security. I’m helping you.”

    Somehow that doesn’t seem like such a great thing. Prove the flaws, sure, but please don’t go releasing an open source API giving everyone on the internet the tools to make all of our lives suck more.

    1. The difference is that your home security doesn’t get free upgrades from the manufacturer.

      The purpose of this is, I would imagine, to light a fire under Mozilla, Apple, Google, and Opera’s asses (Well, and Microsoft too, but let’s be realistic here).

  9. Is this the same Samy Kamkar whose Wikipedia entry reads in part:

    “Samy (also known as JS.Spacehero)[1] was an XSS Worm developed to propagate across the MySpace social-networking site. At the time of release it gained significant media attention.
    Samy Kamkar entered a plea agreement on January 31, 2007 to a felony charge.[2] The action resulted in Kamkar being sentenced to three years probation, 90 days community service and an undisclosed amount of restitution.”

    If so, he’s been good at getting publicity and at “thinking bad.”

  10. Great. More crap to infest our systems. Between all the garbage like this, the 55 billion YouTube videos of idiots whacking themselves or each other in the crotch, and the Google search “results” totally flooded with irrelevant crap, I’m about ready to just go back to making plain old phone calls and manually typing letters on an Olivetti portable. No compatibility issues, no teenaged sociopaths, no constant updates and upgrades, and EVERYBODY has an address that I can track them to if they screw with me. Oh, yeah, and no whirling/flashing/spinning/blinking/screaming ADS. My internet is about to go the way of my TV set: GARAGE SALE!

  11. The ethics of making exploit code available is a constant question in security. On the one hand, even making a description of how to exploit the defect can quickly lead to the black hats taking advantage of it. Making a one-click script that exercises it is often worse, because your average child can exploit it at that point. On the other hand, it’s hard to understand and fix an exploit what you don’t really know how it works. It’s also a great boon to the rest of the security community to understand what kind of issues exist, so that they can be avoided and protected against.

    Then there’s the business end of things. There are many classic examples of exploits that were found and reported, but still existed many months later. Companies prioritize issues based on their expected importance: if a defect exists in an old program, isn’t currently being exploited, and would take even a measurable amount of resources to fix, it’s likely to be ignored completely. Of course, it’s hard to tell if black hats are secretly exploiting these defects or not. Sometimes the only way to get a company to fix a glaring mistake is to show it to the world. Once the threat of black hats getting a hold of it becomes real, companies will move quickly to save their reputations.

    So it really comes down to an ethical dilemma. Is a possible exploit really an issue if nobody is exploiting it? If companies refuse to fix a known defect, is a person justified in forcing their hand by making the exploit available? Do we blame the company for not fixing the issue when they knew about it, or do we blame the discoverer for making the exploit available?

    The common theme that most white hats agree with is that the defect should always be reported first so that companies have a reasonable opportunity to address the issue, mitigating the damage when the exploit is finally released. How long to wait, and whether to release an exploit if the company refuses to fix it, is always an open question. Even for a fixed defect, releasing the defect can still cause damage, because people rarely update when they should, and these are often the same businesses and governments that stand to lose the most from a security breach.

  12. “One exception he knows of is Apple’s Safari browser. Enabling the Private Browsing feature on that application blocks all the evercookie methods, though Kamkar admits he has not tested his cookie against other leading Web browsers.”


    So Safari blocks it, and he hasn’t bothered testing any other browsers, and that makes it “nearly impossible to remove”?

    Sounds like FUD to me.

  13. Faux Robin-Hooding for the sake of attention. Subversion for “look-how cool-I-am” kicks, masquerading (poorly) as a good deed.

  14. Great. Now we’re going to have to hunt down and eliminate his evercookies from our computers. His @$$ should get to sit in jail until all the computers he just left open to attack get fixed.

    Where the previous commenter asked if he had developed an API to remove it, I’m sure he has one up his sleeve. He’s created the problem, now he can make his money fixing the problem he created.


  15. Many thanks for this post. I went straight to the Arstechnica comments, perused same, and added quite a few add-ons to my Firefox.

    We just have to keep making our cookie monsters better.

Comments are closed.