80% of Cookie Reject Buttons Don't Actually Work — Here's the Proof

Ogni cookie banner fa la stessa promessa implicita: clicca "Rifiuta" e il tracciamento si ferma. Il banner scompare e navighi in pace. Questo è il patto su cui si fonda il modello del consenso -- l'idea che gli utenti abbiano una scelta significativa e applicabile.

Abbiamo testato questa promessa su 28.891 siti web dell'UE. Nell'80,4% dei casi, la promessa è infranta. Il tracciamento continua dopo che l'utente ha esplicitamente cliccato "Rifiuta". I cookie persistono. I pixel pubblicitari continuano a essere inviati. E su 1.642 siti, i cookie che l'azione di rifiuto inizialmente elimina ricompaiono al successivo caricamento della pagina -- un fenomeno che chiamiamo consent respawn.

Questo non è un risultato marginale riguardante pochi siti mal configurati. Indica un problema sistemico nel meccanismo su cui centinaia di milioni di residenti dell'UE fanno affidamento per i propri diritti alla privacy.

Cosa dovrebbe fare "Rifiuta" -- dal punto di vista legale

Il quadro giuridico è chiaro. Ai sensi dell'articolo 5(3) della Direttiva ePrivacy, memorizzare o accedere a informazioni sul terminale dell'utente richiede il consenso preventivo, con una ristretta eccezione per i cookie strettamente necessari per un servizio esplicitamente richiesto dall'utente. L'articolo 7(3) del GDPR aggiunge che revocare il consenso deve essere altrettanto facile quanto darlo, e il titolare del trattamento deve dare seguito a tale revoca.

Le Linee guida 05/2020 dell'EDPB sul consenso ai sensi del GDPR spiegano cosa questo significa per i pulsanti di rifiuto: se un sito web offre un'opzione "Accetta tutto", deve anche offrire un'opzione altrettanto visibile e altrettanto accessibile per rifiutare. E quel rifiuto deve essere effettivo -- deve effettivamente impedire il trattamento che il consenso avrebbe autorizzato.

La CGUE ha rafforzato questo principio nella sentenza Planet49 (C-673/17): il consenso richiede un atto positivo inequivocabile, e le caselle pre-selezionate non costituiscono consenso valido. Il corollario logico è che un rifiuto -- un atto negativo esplicito -- deve essere rispettato con la stessa definitività di un'accettazione. Se cliccare "Accetta" attiva il tracciamento, cliccare "Rifiuta" deve disattivarlo. Non parzialmente. Non temporaneamente. Completamente e in modo persistente.

Questo è ciò che dice la legge. I nostri dati mostrano cosa accade realmente.

Come testiamo il flusso di rifiuto

Il nostro test del flusso di rifiuto è progettato per essere il più vicino possibile all'esperienza di un utente reale che clicca "Rifiuta", con l'aggiunta di una strumentazione completa. Ecco il processo passo per passo:

Passo 1: Sessione browser pulita. Lo scanner avvia un'istanza Chromium pulita -- nessun cookie, nessun localStorage, nessuna risorsa in cache, nessuna cronologia di navigazione. Si tratta di un visitatore genuinamente alla prima visita, senza alcuno stato di consenso precedente. Passo 2: Navigazione e registrazione dello stato pre-consenso. Lo scanner carica l'URL di destinazione e attende che la pagina si stabilizzi. Prima di qualsiasi interazione, registra ogni cookie presente nel browser, ogni richiesta di rete effettuata e ogni dominio di terze parti contattato. Questa è la baseline pre-consenso -- ciò che il sito fa prima che l'utente abbia qualsiasi opportunità di fare una scelta. Passo 3: Rilevamento del banner di consenso. Utilizzando la nostra libreria di rilevamento che copre 45 CMP noti e euristiche generiche, lo scanner identifica il meccanismo di consenso e localizza il pulsante di rifiuto. Questo passaggio utilizza un approccio a strati: prima verifica le firme degli script CMP noti e le strutture DOM associate, poi ricorre al rilevamento generico di elementi a posizione fissa con testo relativo al consenso e etichette dei pulsanti come "Rifiuta tutto", "Decline", "Refuse" o equivalenti tradotti. Passo 4: Clic su "Rifiuta". Lo scanner clicca il pulsante di rifiuto e attende che la pagina si stabilizzi. "Stabilizzare" significa attendere che le richieste di rete in sospeso si completino, che le mutazioni del DOM cessino e che eventuali animazioni o transizioni finiscano. Utilizziamo timeout generosi per evitare falsi positivi da implementazioni CMP lente. Passo 5: Snapshot post-rifiuto. Lo scanner registra nuovamente lo stato completo: tutti i cookie, tutta l'attività di rete, tutti i domini di terze parti. Questo snapshot viene confrontato con la baseline pre-consenso per determinare cosa è cambiato. Passo 6: Ricaricamento e verifica del respawn. Lo scanner ricarica la pagina e attende nuovamente la stabilizzazione. Poi effettua uno snapshot finale. Questo passaggio è critico: rivela se l'azione di rifiuto è persistente (rispettata tra i caricamenti di pagina) o se i cookie e il tracciamento si riattivano quando la pagina viene caricata nuovamente. Se i cookie rimossi nel Passo 5 ricompaiono nel Passo 6, si tratta di consent respawn.

Ogni passaggio produce prove con timestamp archiviate: inventari completi dei cookie con nomi, valori, domini, date di scadenza e flag; log completi delle richieste di rete con URL, metodi, codici di risposta e tempistiche; screenshot a pagina intera. Questa catena di prove consente di verificare e contestare qualsiasi singolo risultato.

I risultati: 80,4% di fallimento

Dei 28.891 siti web su cui abbiamo completato con successo il test completo del flusso di rifiuto:

• 5.650 (19,6%) hanno superato il test. Dopo aver cliccato "Rifiuta", i cookie non essenziali sono stati rimossi, le richieste di tracciamento si sono fermate e il rifiuto è persistito tra i ricaricamenti della pagina.
• 23.241 (80,4%) hanno fallito. Il tracciamento è continuato in qualche forma dopo che l'utente ha esplicitamente cliccato "Rifiuta".

I fallimenti non sono uniformi. Rientrano in categorie distinte che si sovrappongono -- un singolo sito può presentare contemporaneamente più modalità di fallimento.

Cookie persistenti: 10.848 siti

Su 10.848 siti (37,5% di quelli testati), cookie non essenziali sono rimasti nel browser dopo il completamento del flusso di rifiuto. Si tratta di cookie classificati come analytics, marketing o relativi al tracciamento che avrebbero dovuto essere rimossi o impediti dopo un'azione di rifiuto.

I cookie persistenti più comuni appartengono a Google Analytics (`_ga`, `_gid`, `_gat`), Meta/Facebook (`_fbp`, `fr`) e varie piattaforme pubblicitarie. In molti casi, la CMP rimuove con successo alcuni cookie ma non riesce a intercettarli tutti -- suggerendo un'integrazione incompleta tra la piattaforma di gestione del consenso e l'intero roster di script di terze parti del sito.

La presenza di questi cookie dopo il rifiuto non è un problema meramente estetico. Ciascuno è un identificatore persistente che lega la sessione attuale dell'utente a visite passate e future. Il cookie `_ga`, ad esempio, è un identificatore univoco del client che Google Analytics utilizza per costruire un profilo longitudinale del comportamento dell'utente attraverso le sessioni. Se persiste dopo il rifiuto, la navigazione dell'utente continua a essere tracciata e aggregata indipendentemente dal rifiuto espresso.

Tracker persistenti: 14.547 siti

Su 14.547 siti (50,3% di quelli testati), i servizi di tracciamento sono rimasti attivi dopo il rifiuto -- il che significa che il browser ha continuato a effettuare richieste verso domini di tracciamento noti anche dopo che l'utente ha cliccato il pulsante di rifiuto.

Questa è una modalità di fallimento distinta dalla persistenza dei cookie. Un tracker può essere attivo senza impostare un cookie: richieste pixel, chiamate beacon e caricamenti di script trasmettono tutti informazioni (come minimo, l'indirizzo IP dell'utente, la pagina di provenienza e dati temporali) a server di terze parti indipendentemente dalla memorizzazione di un cookie. Questo è talvolta chiamato "cookieless tracking" ed è sempre più comune man mano che i browser inaspriscono le restrizioni sui cookie di terze parti.

Il divario tra il dato sui cookie (10.848) e quello sui tracker (14.547) è significativo. Significa che su circa 3.700 siti, l'azione di rifiuto ha eliminato con successo i cookie ma non ha impedito alle richieste di tracciamento di continuare. La CMP ha gestito la pulizia dei cookie ma non ha bloccato gli script che generano il traffico di tracciamento. Questo indica un problema architetturale comune: la CMP è configurata per gestire i cookie (eliminarli al rifiuto, impedirli al caricamento) ma non per gestire l'esecuzione degli script.

Consent respawn: 1.642 siti, 4.932 cookie

Il consent respawn è il pattern più preoccupante che abbiamo identificato. Su 1.642 siti web, i cookie che erano stati rimossi con successo dall'azione di rifiuto sono ricomparsi dopo il ricaricamento della pagina. Su quei siti, 4.932 singoli cookie hanno mostrato questo comportamento di respawn.

Il consent respawn non è un bug in una singola CMP o configurazione. È un problema strutturale nel modo in cui il consenso è implementato nell'intero stack web.

Come un cookie ritorna dopo l'eliminazione. Quando un utente clicca "Rifiuta", una CMP correttamente configurata fa due cose: elimina i cookie non essenziali esistenti (impostando la loro scadenza a una data passata) e aggiorna un record di consenso (di solito un cookie stesso o una voce nel localStorage) che dice alla logica di blocco della CMP di impedire l'esecuzione di script non essenziali ai successivi caricamenti di pagina. Se entrambe le operazioni funzionano, l'utente è pulito: nessun cookie di tracciamento, nessuno script di tracciamento.

Il consent respawn si verifica quando l'eliminazione ha successo ma il blocco fallisce. Lo scenario più comune:

1. La CMP elimina il cookie `_ga` quando l'utente clicca "Rifiuta".

2. La CMP imposta un cookie di stato del consenso che registra che l'utente ha rifiutato l'analytics.

3. Al successivo caricamento della pagina, la CMP verifica il suo stato di consenso e sa che l'utente ha rifiutato.

4. Ma: il tag script di Google Analytics è incorporato direttamente nel template della pagina (fuori dal tag manager) o è caricato da una regola del tag manager che non verifica lo stato del consenso.

5. Lo script GA si carica, non trova il cookie `_ga` e ne crea uno nuovo.

6. La decisione di rifiuto dell'utente è stata sovrascritta.

Le variazioni di questo pattern includono: script di terze parti caricati tramite tag `