La Cookie Law Non Riguarda Più Solo i Cookie: Cosa Copre Ora l'Articolo 5(3)

L'espressione "cookie law" è sempre stata un termine improprio. L'articolo 5(3) della Direttiva ePrivacy non ha mai usato la parola cookie — parla di "archiviare informazioni, o accedere a informazioni già archiviate, nell'apparecchiatura terminale di un abbonato o di un utente". Per due decenni, le autorità di regolamentazione hanno applicato quel testo principalmente ai cookie perché i cookie erano il meccanismo di archiviazione dominante. Quel periodo è finito.

Nell'ottobre 2024 l'European Data Protection Board ha finalizzato le Linee Guida 2/2023 sull'ambito tecnico dell'articolo 5(3). Le linee guida sono tecnologicamente neutrali e coprono esplicitamente i pixel di tracciamento, il tracking basato su URL, il tracking basato solo sull'IP e gli identificatori univoci. Ad aprile 2026 la CNIL francese e il Garante italiano hanno tradotto quel quadro in linee guida nazionali vincolanti sul tracciamento via pixel nelle email. La direzione è inequivocabile: se una tecnica consente a un server di leggere segnali identificativi dal dispositivo di un visitatore, il consenso è richiesto, indipendentemente dal fatto che qualcosa venga scritto di ritorno.

Cosa significa ora "accedere"

L'articolo 5(3) si fonda su due concetti operativi: archiviazione e accesso. La maggior parte del lavoro di compliance esistente tratta solo l'archiviazione come trigger — se non imposti un cookie, presumi che non sia necessario alcun consenso. Le linee guida rifiutano questa lettura.

L'accesso è soddisfatto quando un server istruisce attivamente il dispositivo a restituire valori. Un pixel di tracciamento attiva una richiesta la cui query string contiene identificatori. Un URL univoco incorporato in una newsletter risolve il destinatario. Un indirizzo IP, quando viene usato per seguire lo stesso dispositivo attraverso le sessioni, è anch'esso accesso — il valore origina dallo stack di rete del dispositivo e viene inviato in ogni richiesta.

Ciò che conta è il meccanismo, non il formato di persistenza. Un fingerprint memorizzato in un database lato server viene trattato in modo identico a un cookie memorizzato nel browser.

Perché questo riscrive la mappa degli strumenti di analytics

Molti strumenti di analytics orientati alla privacy si commercializzano come privi di cookie pur basandosi ancora su pattern che le linee guida ora coprono:

• Cookie lato server e identificatori partizionati in stile CHIPS. Spostare il cookie in un contesto partizionato o in uno store lato server di prima parte non cambia la questione dell'accesso. Se lo stesso identificatore raggiunge il server di analytics attraverso le visite, è ancora accesso.
• ID visitatore derivati dall'IP. Strumenti che hashano l'IP e usano l'hash come identificatore stabile attraverso i giorni stanno accedendo a informazioni che originano dal dispositivo. Il parere dell'EDPB è esplicito: ciò richiede consenso a meno che il titolare non possa dimostrare che l'IP non proveniva dall'apparecchiatura terminale dell'utente.
• Tracking di apertura e visualizzazione basato su pixel. La Decisione n. 2026-042 della CNIL (14 aprile 2026) e le linee guida del Garante del 17 aprile 2026 richiedono un consenso esplicito e separato per il tracciamento di apertura individuale nelle email — prima che l'email venga inviata.

Il pattern condiviso è un identificatore stabile che sopravvive attraverso visite, sessioni o messaggi. Qualunque sia il livello di archiviazione, crea la stessa esposizione normativa di un cookie.

Il test tecnico per una raccolta conforme

Le linee guida lasciano un corridoio stretto: segnali aggregati in cui nessun valore memorizzato dal server si risolve in uno specifico dispositivo nel tempo. Una richiesta a un endpoint di raccolta porta valori che rientrano in tre categorie:

1. Valori del transport layer (IP, User-Agent) che il server non può evitare di ricevere
2. Valori contestuali (path, dominio di referrer, paese derivato dall'IP)
3. Valori derivati che il server sceglie di produrre e memorizzare

La categoria 1 è inevitabile in TCP/HTTP. La domanda è come appare la categoria 3. Se un valore derivato è un identificatore persistente — anche hashato, anche con salt — è accesso. Se un valore derivato si reimposta entro una finestra limitata e non può essere correlato attraverso le finestre, l'analisi dell'EDPB lo tratta come aggregato.

L'hash giornaliero del visitatore di Monoid è progettato contro questo test:

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

L'IP e lo User-Agent vengono usati solo in memoria per calcolare l'hash e poi scartati. L'input data significa che lo stesso visitatore produce un hash diverso domani — per costruzione non c'è alcun identificatore cross-day a cui accedere. Entro un singolo giorno l'hash deduplica un visitatore per i conteggi aggregati; attraverso i giorni non c'è nulla che un avversario o un'autorità di regolamentazione possa ricostruire.

Le intestazioni che contano sull'endpoint di raccolta

Due header HTTP portano la maggior parte della superficie di privacy su un edge collector di prima parte e dovrebbero essere impostati deliberatamente.

Referrer-Policy: strict-origin-when-cross-origin è il valore predefinito moderno di Chrome e invia solo l'origin nelle richieste cross-origin. Evita unsafe-url e no-referrer-when-downgrade — entrambi divulgano informazioni sul path inutilmente.

Permissions-Policy dovrebbe negare esplicitamente le funzionalità di cui il tracker di analytics non ha bisogno:

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

Un tracker che non può richiedere posizione, audio o sensori del dispositivo non può essere costretto a farlo da uno script di terze parti compromesso che condivide la pagina.

Cosa dovrebbero verificare gli sviluppatori questo trimestre

Tre domande fanno avanzare l'audit:

1. Qualsiasi valore memorizzato dal server di analytics gli consente di identificare lo stesso visitatore in una finestra di 25 ore? Se sì, il deployment ora richiede probabilmente il consenso ex articolo 5(3).
2. Pixel e identificatori URL vengono usati in email transazionali o di marketing? Secondo le linee guida di CNIL e Garante, il tracciamento di apertura individuale richiede un consenso separato ed esplicito prima dell'invio dell'email.
3. L'endpoint di raccolta imposta una Referrer-Policy rigorosa e una Permissions-Policy di tipo deny-by-default?

La questione del "cookie banner" è a valle di una più basilare: il modello dati produce affatto un identificatore cross-session? Quando la risposta è no, l'intero apparato dell'articolo 5(3) — consenso, revoca, registri di trattamento — non si attiva, perché il trigger tecnico della regolamentazione non è mai stato premuto.