Study how many separate storage mechanisms exist in a browser by examining Evercookie's source code.
Test your browser's privacy tools by seeing which storage locations survive a cookie-deletion pass.
Use as a reference to understand which browser APIs can be exploited for persistent storage.
Build a privacy-auditing tool that checks which Evercookie storage mechanisms your browser has already patched.
Some mechanisms require a PHP server for ETag, cache, and canvas PNG backends, Java cross-browser features need a companion repository.
Evercookie is a JavaScript library that creates extremely persistent tracking identifiers in a browser. It stores a unique value across as many browser storage locations as possible at once, so that even if a user deletes their standard cookies, Flash cookies, or HTML5 storage, the identifier can be restored from any copy that survives. The approach works by writing the same value to more than a dozen different places: standard HTTP cookies, HTML5 local and session storage, IndexedDB, Flash Local Shared Objects, Silverlight isolated storage, HTTP ETags, browser cache, canvas PNG data, and more. If any one of those copies survives a cleanup, evercookie reads it and re-writes the value to all the others. The result is that clearing cookies in the usual way does not actually remove the identifier. Some mechanisms require a server-side component. The repository includes PHP scripts for the ETag, cache, and canvas PNG backends. Node.js and Django ports exist as separate projects. The Java-based mechanisms, which can even share identifiers across different browsers on the same machine, are maintained in a companion repository. The library is a research and demonstration project by Samy Kamkar. The README is direct about the risks: some mechanisms load Flash or Silverlight on page load, which can slow older machines significantly, and the CSS history approach can trigger a large number of HTTP requests. The author notes that using evercookie on real websites can damage user trust and reputation. Browser vendors have steadily closed many of the storage loopholes this project relies on, so a number of mechanisms no longer work in modern browsers. Several future ideas are listed in the README as unimplemented. The project is best understood as a technical demonstration of how many separate browser storage locations exist, rather than a tool meant for production use.
← samyk on gitmyhub — every repo by this author, as a profile.
Verify against the repo before relying on details.