Evercookie: A Persistent Tracking Mechanism
Evercookie is a JavaScript technique that creates persistent identifiers in a browser. This article explains how Evercookie works, its value for tracking users, its limits, and what users can do to protect themselves.
What is an Evercookie?
An Evercookie is a tracking method that writes the same value to multiple storage mechanisms in a user’s browser. Unlike regular cookies, Evercookies are difficult to remove and can restore themselves after deletion.
How Does Evercookie Work?
- Storing Data in Multiple Places: Evercookie writes the same value to several browser storage options, including standard HTTP cookies, Local Shared Objects, and HTML5 storage.
- Rebuilding Mechanism: If one location is cleared, Evercookie reads the remaining copies to recreate the missing ones.
- Persistent Tracking: This redundancy and rebuilding logic enable long-term user tracking.
Value of Evercookie for Tracking
Evercookie supports tracking because of its:
- Persistence: Copies can remain after deletion attempts.
- Cross-Session Tracking: It can link activity across multiple browsing sessions.
- Resistance to Blocking: Traditional cookie blockers may not cover all storage paths Evercookie uses.
Limitations of Evercookie
- Privacy Concerns: Its persistence can be invasive.
- Regulatory Restrictions: Some jurisdictions restrict or regulate persistent tracking technologies.
- Browser Support: Not all browsers expose every storage mechanism Evercookie relies on.
Protecting Against Evercookie
You can reduce exposure to Evercookie by:
- Using Privacy-focused Browsers: Tor or browsers with strict privacy settings can reduce these traces.
- Disabling Flash and Other Plugins: Disable plugins that expose additional storage vectors.
- Regularly Clearing Browser Data: Clear cookies and other storage mechanisms on a regular schedule.
Conclusion
Evercookie enables persistent tracking and creates real privacy risks. Understanding how it works, and applying protective measures, helps you keep control of your browsing data and privacy.
Frequently asked questions
How long should we retain an Evercookie identifier used for fraud checks?
Start with session-only storage. If fraud investigations show a need to link repeat activity, use 30 days as a reviewable starting limit, then extend only for a documented purpose under an approved retention rule. Longer retention increases privacy exposure and can preserve stale associations, especially on shared devices.
Should we use Evercookie or a standard first-party identifier for repeat fraud checks?
Prefer a standard first-party identifier with a clear purpose and expiry. Use Evercookie-style storage only if a specific fraud problem justifies the extra persistence and your privacy review approves it. Rebuilding an identifier after deletion can conflict with user expectations, and browser support varies, so the added complexity may not produce a dependable signal.
How can we tell whether a browser identifier improves fraud decisions enough to keep it?
Test the identifier in shadow mode against your current fraud process, then compare incremental fraud detection at the same false-positive rate. Check results across the browsers and applicant groups you serve, and account for shared devices, cleared storage and blocked storage. Keep the identifier only if the measured improvement justifies its privacy and operational costs.