Privacy and compliance · WhiskerJS 0.1.0

Fingerprinting without cookies

How a fingerprint differs from a cookie, why the privacy rules still apply, and who stores what. Informational, not legal advice.

In plain words

A cookie is a small label a website leaves in your browser so it can read it back later. A fingerprint leaves nothing behind: it measures the browser and device each time and recognises them by how they look. “No cookies” therefore sounds more private than it is. It means nothing is stored on the device, not that the privacy rules stop applying.

Informational, not legal advice. This page explains concepts and points to the legal questions they raise. It does not tell you what applies to your site. Take advice from a qualified lawyer or your data protection officer for your own case.

Cookies and fingerprints side by side

Cookie Device fingerprint (WhiskerJS)
What is on the device an identifier the site wrote nothing
How the device is recognised the site reads its own identifier back the device is measured again and the measurements are compared
What the user can do delete cookies, block third-party cookies, use a private window change settings or browser, use a privacy browser; nothing to delete
How exact it is an exact identifier until deleted a description of a browser setup; identical setups can match and updates can change it
Where the memory is in the browser (and on the server) only on the server, if the site stores the result

Two sets of rules usually matter, and neither is about cookies as such.

  • Rules on access to the device. In the EU, Article 5(3) of the ePrivacy Directive covers storing information on a user’s device and gaining access to information already stored there. European regulators read “gaining access” as covering scripts that read device properties, which includes fingerprinting. The UK has an equivalent rule in PECR. Consent is required unless an exemption applies. See GDPR and ePrivacy.
  • Data protection law. A fingerprint that singles out a device, especially one linked to an account, is likely personal data or personal information under the GDPR, POPIA and the CCPA. That brings a purpose, a lawful basis or permission, transparency, security and limited retention. See POPIA and CCPA and CPRA.

Because users cannot see or delete a fingerprint the way they can a cookie, regulators tend to stress transparency for fingerprinting. Telling users clearly, and limiting the purpose, matters at least as much as for cookies.

What WhiskerJS stores, and what your site stores

WhiskerJS stores nothing. It does not use cookies, localStorage, sessionStorage or IndexedDB. The storage component only checks whether those APIs exist; it never reads or writes them. load() keeps no state between collect() calls, so two calls are fully independent. For a moment during a call the page holds some hidden elements (measuring spans, content-blocker baits and one blank iframe); all are removed before collect() resolves.

WhiskerJS sends nothing. It has no network code. The result exists only in your page until your own code sends it, for example with the login form.

Your site decides what is remembered. If your server stores the visitorId, the structuredId or the components, that storage is yours: you choose what to keep, link it to accounts or not, and decide how long to keep it. That is where the privacy obligations bite.

Who Stores Where Your control
WhiskerJS nothing none not applicable
The demo page on this site your run history your browser’s local storage, on your device only “Clear my history” on the demo
Your site whatever you choose from the result your server purpose, retention, deletion, access requests

Good practice for a cookieless setup

  1. Collect only at the moments that need it (login, sign-up, payment), not on every page.
  2. Keep the purpose narrow, such as security and fraud prevention, and say so.
  3. Drop components you do not need with collect({ exclude }).
  4. Store the minimum per event, with idVersion and signalsVersion, and delete it on a schedule.
  5. Do not reuse device results for advertising or analytics.
  6. Update your privacy notice. See What a privacy notice should say.

A note on privacy browsers

Some browsers randomise or normalise exactly the values fingerprinting reads: Brave adds per-site, per-session noise (“farbling”), and Firefox with resistFingerprinting (also Tor Browser) reports fixed values. WhiskerJS does not try to defeat these protections; it excludes the affected components for those browsers. Users who choose these browsers get less distinct ids, by design. See Brave and Firefox resistFingerprinting and Tor Browser.

Questions and answers

If WhiskerJS sets no cookies, do I still need a cookie banner?

The question is not about cookies as such. In the EU and UK the rule covers accessing information on the device, which can include reading device properties with a script. Whether you need consent depends on your case; see the GDPR and ePrivacy page.

Can users clear a fingerprint like they clear cookies?

No, there is nothing on the device to clear. That is why transparency, a narrow purpose and short retention on your server matter more, not less.

Does WhiskerJS remember a device between visits?

No. It stores nothing and keeps no state between calls. Any memory of a device is in your own server's storage, under your control and your retention rules.