This reminded me of something I haven't thought about in awhile: evercookie - https://github.com/samyk/evercookie
In Using a date-modified header to detect unique visitors without using cookiessamyk
evercookie
JavaScript2013–2022
samyk / evercookie
evercookie
Produces persistent, respawning "super" cookies in a browser, abusing over a dozen techniques. Its goal is to identify users after they've removed standard cookies and other privacy data such as Flash cookies (LSOs), HTML5 storage, SilverLight storage, and others.
19Distinct people
20Mentions
0Explicit recommenders
4.7KGitHub stars
What to know before exploring
What it is
Produces persistent, respawning "super" cookies in a browser, abusing over a dozen techniques. Its goal is to identify users after they've removed standard cookies and other privacy data such as Flash cookies (LSOs), HTML5 storage, SilverLight storage, and others.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year20 dated mentions
Observed mentions: 2013-06-18 12:28:45 UTC to 2022-11-30 20:56:57 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Evercookie
Evercookie is a Javascript API 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.
This is accomplished by storing the cookie data on as many browser storage
mechanisms as possible. If cookie data is removed from any of the storage
mechanisms, evercookie aggressively re-creates it in each mechanism as long as
one is still intact.
If the Flash LSO, Silverlight or Java mechanism is available, Evercookie can even propagate cookies
between different browsers on the same client machine!
By Samy Kamkar, with awesome contributions from others
Browser Storage Mechanisms
Client browsers must support as many of the following storage mechanisms as
possible in order for Evercookie to be effective.
Standard HTTP Cookies
Flash Local Shared Objects
Silverlight Isolated Storage
CSS History Knocking
Storing cookies in HTTP ETags (Backend server required)
Storing cookies in Web cache (Backend server required)
HTTP Strict Transport Security (HSTS) Pinning (works in Incognito mode)
window.name caching
Internet Explorer userData storage
HTML5 Session Storage
HTML5 Local Storage
HTML5 Global Storage
HTML5 Database Storage via SQLite
HTML5 Canvas - Cookie values stored in RGB data of auto-generated, force-cached PNG images (Backend server required)
HTML5 IndexedDB
Java JNLP PersistenceService
Java exploit CVE-2013-0422 - Attempts to escape the applet sandbox and write cookie data directly to the user's hard drive.
To be implemented someday (perhaps by you?):
TLS Session Resumption Identifiers/Tickets (works in Incognito mode)
Generating HTTP Public Key Pinning (HPKP) certificates per user
Caching in HTTP Authentication
Google Gears
Using Java to produce a unique key based off of NIC info
Other methods? Please comment!
The Java persistence mechanisms are developed and maintained by Gabriel Bauman
over here.
Backend Server
Some of the storage mechanisms require a backend server. This package comes with PHP implementation of the etag, cache and png backend servers.
For Node.js version, please visit node-evercookie.
For Django version, please visit Django Evercookie
Caveats
Be warned! Evercookie can potentially cause problems for you or your users.
Some storage mechanisms involve loading Silverlight or Flash in the client
browser. On some machines this can be a very slow process with lots of disk
thrashing. On older mobile devices this can render your site unusable.
CSS History Knocking can cause a large number of HTTP requests when a cookie
is first being set.
In some circles, it is considered rude to use Evercookie. Consider your
reputation and your audience when using Evercookie in production.
Browser vendors are doing their best to plug many of the holes exploited by
Evercookie. This is a good thing for the Internet, but it means what works
today may not work so well tomorrow.
You are responsible for your own decision to use Evercookie. Choose wisely.
Got an idea?
Open a pull request!
Read the full README on GitHubWhat Hacker News says
20 sourcesEvercookie is a Javascript project that produces respawning super cookies:
https://github.com/samyk/evercookie
It's quite dead now, stopped working around 2017:
https://github.com/samyk/evercookie/issues/125
In Firefox 85 cracks down on supercookiesI first saw ETAG method on evercookie project. HTML5 Canvas is also a funny/smart technique that I saw there.
https://github.com/samyk/evercookie
One of the purposes of the evercookie project was to have a collection of tracking methods that browser vendors can test against their implementation.
In Show HN: Server-Side Tracking Without Cookies in GoThis is really in response to the irresponsible use of APIs for trackers. Evercookie is a stunning example of how far it can go... From their repo:
- Standard HTTP Cookies
- Flash Local Shared Objects
- Silverlight Isolated Storage
- CSS History Knocking
- Storing cookies in HTTP ETags (Backend server required)
- Storing cookies in Web cache (Backend server required)
- HTTP Strict Transport Security (HSTS) Pinning (works in Incognito mode)
- window.name caching
- Internet Explorer userData storage
- HTML5 Session Storage
- HTML5 Local Storage
- HTML5 Global Storage
- HTML5 Database Storage via SQLite
- HTML5 Canvas - Cookie values stored in RGB data of auto-generated, force-cached PNG images (Backend server required)
- HTML5 IndexedDB
- Java JNLP PersistenceService
- Java exploit CVE-2013-0422 - Attempts to escape the applet sandbox and w
Read the rest
rite cookie data directly to the user's hard drive.
https://github.com/samyk/evercookie
In short, everything and more can be used for tracking, and that has really killed the party for the many people who have created responsible, useful applications of these browser APIs.
Evercookie's a great resource for dubious techniques to track people - look at the HTML canvas example for how it's done with a PNG: https://github.com/samyk/evercookie/blob/6d44cb8ad1eda23c9a5...
Luckily, the partitioning of browser caches on a per domain basis as pioneered by Safari has now made its way to Firefox (I think it's been released) and I presume will eventually be turned on by default in Chromium: https://www.chromestatus.com/feature/5730772021411840
In We Wasted $50K on Google Ads So You Don't Have To (2019)> what caused you to write this library?
On smaller devices, a few kb of important data in LocalStorage was periodically deleted without user intervention.
> do you believe it will be used for nefarious purposes?
If one is nefarious of heart, https://github.com/samyk/evercookie supersedes ImmortalDB.
In ImmortalDB – A resilient key-value store for the browserIt's based on Evercookie https://github.com/samyk/evercookie
which is a little less... friendly.
In ImmortalDB – A resilient key-value store for the browser> save all values everywhere: why not select the one that would last the longest (that people delete least often)?
For improved resiliency.
You can also configure IronDB to only use any two datastores of your choice, if
you so desire: IronStorage's constructor takes an Array of storage
implementations of your choice. See https://github.com/gruns/irondb#api.
> So you delete data when the user wants to delete data. Which database doesn't have this feature?
A database where the data therein can be deleted without warning. Browsers
unceremoniously delete IndexedDB, LocalStorage, and SessionStorage under storage
pressure. See
https://developers.google.com/web/fundamentals/instant-and-o...
> doesn't use Flash, Silverlight, or Java -- which do?
Evercookie, a similar library, uses Flash, Silverlight, and/or Java.
See https://github.com/samyk/ever
Read the rest
cookie.
> No offence to the author but all this sound malicious. Perhaps this is why evercookie isn't maintained?
No offense taken.
Thank you for your feedback, kreetx. Don't hesitate to let me know if I can answer any other questions, or if there's anything else I can do for you.
This goes beyond just identification to actual data leakage, but ties into a larger point about GDPR and other regulations that we've been discussing ad nauseum here, which is questions like: "Why don't the GDPR regs just tell me what I need to do?"
The GDPR being deliberately vague is a response to issues like these, it serves neither the interests of the users or the regulation to say "Get consent before getting cookies and only cookies" only to have sites and services turn around and use methods like this, or:
BrowserFingerprinting - https://panopticlick.eff.org/
Super/Ever Cookies - https://github.com/samyk/evercookie
HSTS identification - https://www.owasp.org/index.php/HTTP_Strict_Transport_Securi...
or whatever the new sneaky identification via browser features hack happens to be.
In Side-channel attacking browsers through CSS3 featuresJavaScript API for (excessively) persistent cookies
2 points · Open discussionIt makes it another place that they can store the tracking cookie and have your browser give it back out to them. Deleting the cookies or other such things wouldn't remove the tracking ID as long as the browser continues to use the cached immutable resource. Similar to how this[1] works by using multiple storage methods.
https://github.com/samyk/evercookie
In HTTP Immutable ResponsesEvercookie – A cookie that undeletes itself
2 points · Open discussionI didn't realize PoisonTap's creator, Samy, is also the creator of the Evercookie[0], a persistent identifying cookie that remains sharded(then recombines) in your system even after clearing your cookies. While a very cool project, it has some scary implications on users not trained in their removal.
[0] https://github.com/samyk/evercookie
In PoisonTap, a $5 tool that invades password-protected computersEvercookie – Fingerprint for a Browser
1 points · Open discussionShowing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.