The Cookie Law Is No Longer About Cookies: What Article 5(3) Now Covers

The phrase "cookie law" was always a misnomer. Article 5(3) of the ePrivacy Directive never used the word cookie — it talks about "storing information, or gaining access to information already stored, in the terminal equipment of a subscriber or user." For two decades, regulators applied that text mostly to cookies because cookies were the dominant storage mechanism. That period is over.

In October 2024 the European Data Protection Board finalized Guidelines 2/2023 on the technical scope of Article 5(3). The guidelines are technology-neutral and explicitly cover tracking pixels, URL-based tracking, IP-only tracking, and unique identifiers. In April 2026 the French CNIL and the Italian Garante translated that framework into binding national guidance on email pixel tracking. The direction is unambiguous: if a technique lets a server read identifying signals from a visitor's device, consent is required, whether or not anything is written back.

What "gaining access" now means

Article 5(3) hangs on two operative concepts: storage and gaining access. Most existing compliance work treats only storage as the trigger — if you do not set a cookie, you assume no consent is needed. The guidelines reject that reading.

Gaining access is satisfied when a server actively instructs the device to send back values. A tracking pixel triggers a request whose query string carries identifiers. A unique URL embedded in a newsletter resolves the recipient. An IP address, when used to follow the same device across sessions, is also access — the value originates from the device's network stack and is sent in every request.

The mechanism is what matters, not the persistence format. A fingerprint stored in a server-side database is treated identically to a cookie stored in the browser.

Why this rewrites the analytics tooling map

Many privacy-focused analytics tools market themselves as cookie-free while still relying on patterns the guidelines now cover:

• Server-side cookies and CHIPS-style partitioned identifiers. Moving the cookie to a partitioned context or to a first-party server-side store does not change the access question. If the same identifier reaches the analytics server across visits, it is still access.
• IP-derived visitor IDs. Tools that hash the IP and use the hash as a stable identifier across days are accessing information that originates from the device. The EDPB advice is explicit: this requires consent unless the controller can demonstrate the IP did not originate from the user's terminal equipment.
• Pixel-based open and view tracking. The CNIL's Decision No. 2026-042 (April 14, 2026) and the Garante's April 17, 2026 guidelines require explicit, separate consent for individual open tracking in email — before the email is sent.

The shared pattern is a stable identifier that survives across visits, sessions, or messages. Whatever the storage layer, it creates the same regulatory exposure as a cookie.

The technical test for compliant collection

The guidelines leave a narrow corridor: aggregate signals where no value the server stores resolves back to a specific device across time. A request to a collection endpoint carries values that fall into three categories:

1. Transport-layer values (IP, User-Agent) the server cannot avoid receiving
2. Contextual values (path, referrer domain, country derived from IP)
3. Derived values the server chooses to produce and store

Category 1 is unavoidable in TCP/HTTP. The question is what category 3 looks like. If a derived value is a persistent identifier — even hashed, even salted — it is access. If a derived value resets within a bounded window and cannot be correlated across windows, the EDPB analysis treats it as aggregate.

The Monoid daily visitor hash is engineered against this test:

visitor_hash = SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

The IP and User-Agent are used only in memory to compute the hash and then discarded. The date input means the same visitor produces a different hash tomorrow — there is no cross-day identifier to access, by construction. Within a single day the hash deduplicates a visitor for aggregate counts; across days there is nothing for an adversary or regulator to reconstruct.

The headers that matter on the collection endpoint

Two HTTP headers carry most of the privacy surface on a first-party edge collector and should be set deliberately.

Referrer-Policy: strict-origin-when-cross-origin is the modern Chrome default and sends only the origin on cross-origin requests. Avoid unsafe-url and no-referrer-when-downgrade — both leak path information unnecessarily.

Permissions-Policy should explicitly deny features the analytics tracker does not need:

Permissions-Policy: geolocation=(), microphone=(), camera=(),
  payment=(), usb=(), interest-cohort=()

A tracker that cannot request location, audio, or device sensors cannot be coerced into doing so by a compromised third-party script sharing the page.

What developers should audit this quarter

Three questions move the audit forward:

1. Does any value the analytics server stores allow it to identify the same visitor across a 25-hour window? If yes, the deployment likely now requires Article 5(3) consent.
2. Are pixel and URL identifiers used in transactional or marketing email? Under the CNIL and Garante guidance, individual open tracking requires separate, explicit consent before the email is sent.
3. Does the collection endpoint set a strict Referrer-Policy and a deny-by-default Permissions-Policy?

The "cookie banner" question is downstream of a more basic one: does the data model produce a cross-session identifier at all. When the answer is no, the entire Article 5(3) machinery — consent, withdrawal, records of processing — does not engage, because the regulation's technical trigger was never pulled.