samy's home page || follow my twitter || email me || samy kamkar


October 11, 2010: Reported on the front page of the New York Times
Find the latest details, code, and implementations on github @


    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
    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
     - HTTP Strict Transport Security (HSTS) Pinning
     - Local Shared Objects (Flash Cookies)
     - Silverlight Isolated Storage 
     - 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 
     - Storing cookies in HTTP ETags 
     - Storing cookies in Web cache 
     - caching
     - Internet Explorer userData storage
     - HTML5 Session Storage 
     - HTML5 Local Storage 
     - HTML5 Global Storage 
     - HTML5 Database Storage via SQLite
     - HTML5 IndexedDB
     - Java JNLP PersistenceService
     - Java CVE-2013-0422 exploit (applet sandbox escaping)
    TODO: adding support for:
     - Caching in HTTP Authentication 
     - Using Java to produce a unique key based off of NIC info
     - Google Gears
    Got a crazy idea to improve this? Email me! 


    Cookie found: uid = currently not set 
    Click to create an evercookie. Don't worry, the cookie is a
    random number between 1 and 1000, not enough for me to track
    you, just enough to test evercookies.
Now, try deleting this "uid" cookie anywhere possible, then or


    evercookie is written in JavaScript and contains portions
    in Java, SWF/ActionScript (Flash) and C# (Silverlight).
    Some backend pieces in PHP, but also available in Node.js and Django.
    Get the latest source from github: 


	What is the point of evercookie? 
	Evercookie is designed to make persistent data just that, persistent. By
	storing the same data in several locations that a client can access, if
	any of the data is ever lost (for example, by clearing cookies), the data
	can be recovered and then reset and reused.
	Simply think of it as cookies that just won't go away.
	PRIVACY CONCERN! How do I stop websites from doing this? 
	Great question. So far, I've found that using Private Browsing 
	in Safari will stop ALL evercookie methods after a browser restart.
	What if the user deletes their cookies? 
	That's the great thing about evercookie. With all the methods available,
	currently thirteen, it only takes one cookie to remain for most, if not all,
	of them to be reset again.
	For example, if the user deletes their standard HTTP cookies, LSO data,
	and all HTML5 storage, the PNG cookie and history cookies will still
	exist. Once either of those are discovered, all of the others will
	come back (assuming the browser supports them).
	Why not use EFF's Panopticlick? 
	Panopticlick is an awesome idea, however the uniqueness really only
	helps in consumer machines and typically not systems running in a
	business or corporation. Typically those systems are virtually
	identical and provide no difference in information where a home
	user's laptop would. Evercookie is meant to be able to store the
	same unique data a normal cookie would.
	Does this work cross-browser? 
	If a user gets cookied on one browser and switches to another browser,
	as long as they still have the Flash Local Shared Object cookie, the
	Silverlight Isolated Storage, the Java JNLP PersistenceService or the
	Java CVE-2013-0422 exploit cookie, the cookie should reproduce in both
	Does the client have to install anything? 
	No, the client simply uses the website without even knowing about the
	persistent data being set, just as they would use a website with standard
	HTTP cookies.
	Does the server have to install anything? 
	The server must at least have access to the JavaScript evercookie file.
	Additionally, to use Local Shared Object (Flash Cookies) storage, the
	evercookie.swf file must be present, and to use the auto-generated PNG
	caching, standard caching and ETag storage mechanisms, PHP must be
	installed and evercookie_(png|etag|cache).php must be on the server.
	All of these are available in the download.
	Is evercookie open source? 
	Yes, evercookie is open source. The code is in readable format without
	any obfuscation. Additionally, the PHP files are open source as is the
	FLA (Flash) code used to generate the SWF Flash object. You can compile
	the Flash object yourself or use the pre-compiled version (evercookie.swf).
	How does the PNG caching work? 
	When evercookie sets a cookie, it accesses evercookie_png.php with a special
	HTTP cookie, different than the one used for standard session data. This
	special cookie is read by the PHP file, and if found, generates a PNG file
	where all the RGB values are set to the equivalent of the session data to
	be stored. Additionally, the PNG is sent back to the client browser with
	the request to cache the file for 20 years.
	When evercookie retrieves this data, it deletes the special HTTP cookie,
	then makes the same request to the same file without any user information.
	When the PHP script sees it has no information to generate a PNG with, it
	returns a forged HTTP response of "304 Not Modified" which forces the web
	browser to access its local cache. The browser then produces the cached
	image and then applies it to an HTML5 Canvas tag. Once applied, evercookie
	reads each pixel of the Canvas tag, extracting the RGB values, and thus
	producing the initial cookie data that was stored.
	How does the Web History storage work 
	When evercookie sets a cookie, assuming the Web History caching is enabled,
	it Base64 encodes the data to be stored. Let's assume this data is "bcde"
	in Base64. Evercookie then accesses the following URLs in the background:
	These URLs are now stored in history.
	When checking for a cookie, evercookie loops through all the possible Base64
	characters on, starting with "a" and moving up,
	but only for a single character. Once it sees a URL that was accessed, it
	attempts to brute force the next letter. This is actually extremely fast
	because no requests are made to theserver. The history lookups are simply
	locally in JavaScript using the CSS History Knocker. Evercookie knows it has
	reached the end of the string as soon as it finds a URL that ends in "-".


    <script type="text/javascript" src="evercookie.js"></script>
    var ec = new evercookie(); 
    // set a cookie "id" to "12345"
    // usage: ec.set(key, value)
    ec.set("id", "12345"); 
    // retrieve a cookie called "id" (simply)
    ec.get("id", function(value) { alert("Cookie value is " + value) }); 
    // or use a more advanced callback function for getting our cookie
    // the cookie value is the first param
    // an object containing the different storage methods
    // and returned cookie values is the second parameter
    function getCookie(best_candidate, all_candidates)
        alert("The retrieved cookie is: " + best_candidate + "\n" +
        	"You can see what each storage mechanism returned " +
    		"by looping through the all_candidates object.");
    	for (var item in all_candidates)
    		document.write("Storage mechanism " + item +
    			" returned: " + all_candidates[item] + "<br>");
    ec.get("id", getCookie); 
    // we look for "candidates" based off the number of "cookies" that
    // come back matching since it's possible for mismatching cookies.
    // the best candidate is most likely the correct one


    csshack, best website ever 


    See CONTACT.


    Questions or comments, email me:
    Visit for more awesome stuff.

evercookie, by Samy Kamkar, 09/20/2010