Why Web-Tracking.eu doesn't need a cookie banner

1. The legal basis: ePrivacy Directive Article 5(3)

The EU legal framework for storing or accessing information on a user's device is not the GDPR — it is the ePrivacy Directive (2002/58/EC), as amended by Directive 2009/136/EC. This directive predates the GDPR and is implemented separately by each EU member state (the so-called "cookie law").

The operative provision is Article 5(3):

"Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service."

Two things are worth noting. First, the trigger is technology-neutral: it covers cookies, localStorage, device fingerprinting, ETags, cache abuse, and any other mechanism that either stores information on or reads information from terminal equipment. Second, the rule applies regardless of whether the information is personal data. Even a non-personal identifier counts if it is stored on the device.

The logical consequence is equally important: if a service neither stores anything on the device nor accesses anything stored there, Article 5(3) simply does not apply. No consent is required under the ePrivacy Directive, and no consent banner is legally necessary for that specific processing activity.

2. What we store on your visitor's device

Nothing. Our tracker (t.js) performs a single fetch() or navigator.sendBeacon() call to our server and returns. It does not read anything from the device before sending, and it does not write anything back afterwards.

The only identifier we ever compute is a hash that lives entirely on our server. The browser never sees it, never stores it, and has no way to retrieve it. From the browser's perspective there is nothing to consent to — nothing has been written to or read from the device beyond the HTTP headers that are automatically sent with every request.

3. How hash-based visitor identification works

To count unique visitors without tracking them, we derive a deterministic hash server-side on each incoming request. The hash is built from request attributes that are already available to any web server, combined with the current UTC date and a per-day secret salt.

// Pseudo-code — runs on the Web-Tracking.eu edge, never in the browser
function visitorId(req, siteId) {
    const ip     = req.remoteAddr;          // discarded after hashing
    const ua     = req.headers['user-agent']; // discarded after hashing
    const date   = today('UTC');             // rotates at midnight UTC
    const salt   = dailySalt();              // random, rotates daily

    return sha256(`${ip}|${ua}|${siteId}|${date}|${salt}`);
}

Four design choices matter here:

• Daily rotation. The date component ensures that tomorrow's hash for the same visitor is different. We cannot follow a visitor across days.
• Per-day secret salt. Prevents rainbow-table attacks and ensures that even if hashes leaked, they could not be reversed to recover the input IP.
• Site scoping. Hashes from Site A cannot be correlated with Site B. A visitor showing up on two sites tracked by Web-Tracking.eu produces two unrelated hashes. No cross-site tracking is possible.
• Raw inputs are discarded. The IP address and User-Agent are used to compute the hash and are then dropped. They are never written to logs, databases, or backups.

This approach has been endorsed as an acceptable anonymisation technique by the Article 29 Working Party (now the EDPB) in Opinion 05/2014 on anonymisation techniques, provided that the hash cannot be linked back to an individual and cannot be used to single them out across sessions or contexts. Daily rotation combined with a rotating salt meets that bar.

4. Positions of EU Data Protection Authorities on analytics and consent

Interpretation of Article 5(3) is harmonised by the ePrivacy Directive, but enforcement and nuance differ between member states. Here is a brief survey of the most relevant positions. None of them contradicts the conclusion above: if nothing is stored on the device, no consent banner is needed.

CNIL (France)

The French supervisory authority publishes the most detailed guidance on analytics and consent. In its guidelines and recommendations on trackers and cookies (last consolidated in 2020 and still in force), CNIL recognises a "measurement exemption" for analytics tools that meet specific conditions: strictly limited to measuring audience on behalf of the publisher, no cross-site tracking, no sharing of data with third parties, anonymised IP addresses, limited retention. CNIL has explicitly listed certain cookieless or cookie-limited analytics configurations as exempt from consent. Since Web-Tracking.eu does not store anything on the device at all, we are straightforwardly outside the scope of Article 5(3) under French interpretation.

BayLDA / DSK (Germany)

German DPAs, coordinated through the Datenschutzkonferenz (DSK), adopt a strict reading of the German implementation of Article 5(3) in §25 TTDSG (now TDDDG). The Bavarian DPA (BayLDA) has historically been one of the most active enforcers against Google Analytics and similar cookie-based tools. §25 TTDSG mirrors the directive: consent is required for any storing or accessing of information on terminal equipment, except where strictly necessary. A tracker that never touches the device does not fall within §25 at all. The strictness of the German position actually works in favour of cookieless designs.

Datatilsynet (Denmark)

The Danish DPA follows the Danish cookie bekendtgørelse implementing Article 5(3). It has published specific guidance stating that technologies which do not set or read information on the user's device are not covered by the cookie rules. The only remaining question in that case is whether any processing that does occur (for example, of an IP address used momentarily to compute a hash) has a valid GDPR legal basis — which for analytics is routinely legitimate interest under Article 6(1)(f).

AP (Netherlands)

The Dutch Autoriteit Persoonsgegevens has issued guidance on analytics under the Dutch Telecommunications Act. Its position is that analytics tools which do not place or read cookies (or equivalents) fall outside the consent requirement of Article 11.7a of the Act. The AP has previously certified specific analytics configurations as consent-exempt where no identifiers persist on the user's device.

ICO (United Kingdom, post-Brexit)

The UK's Privacy and Electronic Communications Regulations (PECR) transpose Article 5(3) and remain in force after Brexit. The ICO's cookie guidance takes the same position: the law applies to anything that stores or reads information from the user's device. A purely server-side counting mechanism that does not touch the device is not in scope.

In short: there is no EU DPA that takes the position "cookieless analytics still requires consent." The controversy is entirely about tools that do set identifiers on the device (GA4 first-party cookies, Plausible's formerly-hashed localStorage, Meta Pixel, etc.). Our design sidesteps the debate entirely.

5. When you still need a consent banner

Switching to Web-Tracking.eu removes the analytics-related reason for a banner, but it does not automatically make your entire site consent-free. You still need a cookie consent banner if your site uses any of the following:

• Google Analytics (GA4) client-side via gtag.js. GA4 sets _ga and related cookies regardless of consent mode. Consent mode v2 only controls whether those cookies carry identifiers — it does not make them disappear.
• Google Tag Manager when loaded unconditionally. GTM itself sets a cookie and loads arbitrary third-party code.
• Meta Pixel, TikTok Pixel, LinkedIn Insight Tag — all set advertising cookies and require explicit consent.
• Hotjar, Microsoft Clarity, Mouseflow, FullStory — session replay and heatmap tools that store session identifiers and record user interaction.
• YouTube or Vimeo embeds using the default (non-privacy) mode. Use youtube-nocookie.com or a click-to-load placeholder to avoid setting cookies until the user interacts.
• Intercom, Drift, Crisp, HubSpot chat and similar customer messaging widgets that persist a session cookie or localStorage entry.
• A/B testing tools like Optimizely or VWO that store variant assignments in cookies or localStorage.
• Cloudflare Bot Management, reCAPTCHA v3 in its default configuration — both set persistent identifiers.

Audit your site honestly. Open DevTools, look at the Application tab, and list every cookie, localStorage entry and IndexedDB database set before the user has interacted with any consent UI. Anything non-essential there needs to go — or needs consent.

6. Comparison: what each analytics tool stores on the visitor's device

Cookieless analytics is no longer exotic. Several vendors — including us — have converged on the same architecture: compute a short-lived identifier server-side from request metadata, drop the raw inputs immediately, never touch the device. What differs is the detail of the hashing scheme, the retention period, and whether the vendor additionally avoids transmitting data outside the EU.

7. The GDPR angle (separate from ePrivacy)

Article 5(3) of the ePrivacy Directive is only one half of the analysis. Even when no consent is required under ePrivacy, any processing of personal data still needs a legal basis under Article 6 of the GDPR. For analytics, that basis is typically legitimate interest — Article 6(1)(f) — with a documented balancing test.

Web-Tracking.eu processes the visitor's IP address and User-Agent header momentarily to compute the daily hash, then discards them. The hashed output contains no personal data in a usable form: it cannot be used to re-identify a specific individual, it rotates every 24 hours, and it is scoped to a single site. Our legitimate interest assessment (available on request) concludes that this processing is proportionate and does not override the data subject's rights.

We do not claim that no personal data is processed at any point — the raw IP address exists in memory for milliseconds. We claim that the processing is minimal, purposeful, and protected by appropriate safeguards, and that the resulting stored data is not personal data under any reasonable reading of Article 4(1) GDPR.

8. Sources and further reading

• ePrivacy Directive 2002/58/EC (consolidated text)
• CNIL guidelines on cookies and other trackers
• CNIL list of audience measurement solutions exempted from consent
• Datenschutzkonferenz (DSK) Orientierungshilfen — Telemedien
• Datatilsynet (Danish Data Protection Agency)
• Autoriteit Persoonsgegevens (Dutch DPA)
• ICO guidance on PECR and cookies
• Article 29 WP Opinion 05/2014 on Anonymisation Techniques