I cookie sono piccole quantità di dati che il browser memorizza per conto di un sito web e che possono essere utilizzate nelle richieste successive. Servono, per esempio, a mantenere una sessione di login, ricordare una preferenza, conservare lo stato di alcune funzioni oppure riconoscere un browser per finalità statistiche o pubblicitarie.
Il punto importante è che cookie non significa automaticamente tracciamento, così come terza parte, persistenza e profilazione non sono sinonimi. Sono classificazioni che descrivono aspetti differenti: chi imposta il dato, quanto dura e per quale finalità viene utilizzato.
Capire questa distinzione permette di rispondere meglio anche alla domanda che compare ogni volta che un sito mostra un banner: cosa stai realmente accettando o rifiutando?
Il Garante per la protezione dei dati personali li definisce come stringhe di testo che possono essere archiviate nel dispositivo dell’utente da un sito visitato o da soggetti terzi e successivamente ritrasmesse.
Dal punto di vista del Web è quindi più preciso parlare di dati memorizzati dal browser che di programmi o codice eseguibile.
Un valore può essere molto semplice:
session_id=abc123
Il nome session_id indica il tipo di informazione, mentre abc123 è il valore associato.
A questa coppia possono essere aggiunti attributi che stabiliscono come il browser deve trattarla:
Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax
In questo caso vengono definite anche condizioni relative alla sicurezza e all’invio.
Come funziona lo scambio tra browser e server
Il modello più facile da capire è quello di una sessione web.
Quando apri una pagina, il browser effettua una richiesta a un server. Il server può rispondere chiedendo al browser di memorizzare un valore attraverso l’header HTTP Set-Cookie.
Alle richieste successive, se le condizioni previste lo consentono, il browser può inviare nuovamente quella coppia nome-valore.
Il flusso semplificato diventa:
browser → richiesta al sito server → risposta + Set-Cookie browser → memorizza il valore browser → nuova richiesta + valore memorizzato server → riconosce lo stato associato
Questo meccanismo risolve un problema fondamentale di HTTP: le singole richieste non possiedono, da sole, una memoria permanente delle interazioni precedenti.
L’identificatore memorizzato può quindi rimandare a uno stato conservato altrove. Un ecommerce, per esempio, non deve inserire nel browser tutti i prodotti presenti nel carrello: può salvare un identificatore e conservare i dettagli effettivi nel database lato server.
Cosa viene memorizzato realmente
Non è necessario che nel browser finiscano direttamente nome, email, cronologia completa o altre informazioni immediatamente leggibili.
Spesso viene conservato semplicemente un identificatore, un valore di preferenza o un token casuale che il sistema collega a informazioni gestite lato server.
Questo cambia molto la lettura del problema privacy: una stringa apparentemente incomprensibile può comunque diventare rilevante se permette di distinguere un browser e collegarlo ad altre informazioni.
Gli attributi disponibili possono inoltre stabilire:
- durata;
- dominio o host di riferimento;
- percorso per il quale il dato deve essere inviato;
- possibilità di utilizzo in contesti cross-site;
- invio esclusivo attraverso HTTPS;
- accessibilità da JavaScript;
- archiviazione partizionata.
La documentazione di MDN sull’header Set-Cookie descrive nel dettaglio questi attributi e il relativo comportamento.
È un file, un codice o una stringa di dati?
Nel linguaggio comune sentirai spesso parlare di “file cookie”. È una semplificazione comprensibile, perché il browser deve comunque conservarne i dati.
Tecnicamente è però più corretto considerarli piccole informazioni strutturate gestite dal browser, non programmi installati sul computer.
Non vengono eseguiti come un’applicazione e non sono, di per sé, virus.
Questo non significa che siano sempre irrilevanti sul piano della sicurezza o della privacy. Un identificatore di sessione può essere molto sensibile; un valore utilizzato per riconoscere lo stesso browser nel tempo può contribuire a un sistema di tracciamento.
La distinzione utile è quindi:
cookie = tecnologia utilizzata per memorizzare e scambiare uno stato
tracking = finalità o processo che può utilizzare anche questa tecnologia
Sono concetti collegati, ma non equivalenti.
A cosa servono: esempi pratici
Le funzioni possibili sono molto diverse. Alcune sono necessarie per il servizio richiesto dall’utente, altre riguardano preferenze, misurazione o pubblicità.
È proprio la finalità a determinare molte delle conseguenze tecniche e normative.
Login e gestione delle sessioni
Dopo l’autenticazione, un’applicazione deve sapere che le richieste successive appartengono ancora all’utente che ha effettuato il login.
Una soluzione comune consiste nell’assegnare al browser un identificatore di sessione.
Il server può così riconoscere lo stato autenticato senza chiedere username e password a ogni nuova pagina.
Questo non significa che nel browser debba essere salvata direttamente la password. Anzi, memorizzare credenziali sensibili in chiaro sarebbe una progettazione insicura. Normalmente viene utilizzato un token o un identificatore associato alla sessione gestita dal sistema.
Preferenze, lingua e personalizzazione
Un sito può ricordare una scelta effettuata dall’utente, per esempio:
- lingua;
- valuta;
- modalità chiara o scura;
- preferenze dell’interfaccia;
- stato di alcuni controlli;
- scelta espressa nel sistema di consenso.
Sono informazioni che possono rendere più coerente l’esperienza tra una pagina e l’altra o tra visite successive.
Non tutte queste funzioni richiedono necessariamente la stessa tecnologia. Un’applicazione può utilizzare altri sistemi di storage o conservare alcune preferenze lato server.
In altre parole, il browser può avere memoria in più modi.
Carrello ecommerce e continuità della navigazione
Il carrello è un buon esempio perché mostra la differenza fra dato memorizzato e informazione applicativa.
Un ecommerce può assegnare al visitatore un identificatore e collegarlo a uno stato del carrello conservato nel database. Il browser permette di ritrovare quello stato; non è necessario che contenga l’intero elenco dei prodotti.
L’implementazione precisa dipende dalla piattaforma e dalla configurazione.
Per questo affermare che “senza cookie qualsiasi carrello sparisce a ogni pagina” sarebbe troppo assoluto: esistono architetture differenti. È però vero che identificatori di sessione e altri meccanismi equivalenti sono comunemente utilizzati per dare continuità alle interazioni.
Statistiche, misurazione e pubblicità
Gli stessi meccanismi possono contribuire a distinguere visite, sessioni o browser per produrre statistiche.
Qui la classificazione diventa più delicata.
Un sistema come Google Analytics 4 può utilizzare identificatori e segnali differenti in base alla configurazione, allo stato del consenso e alle funzionalità implementate.
Un sistema come Matomo può essere configurato con approcci differenti, compreso, in determinati scenari, un funzionamento senza i classici identificatori analytics persistenti.
La conseguenza pratica è importante: non puoi determinare il regime privacy guardando soltanto il nome dello strumento. Devi verificare configurazione, finalità, dati e modalità di raccolta.
Uno degli errori più frequenti è mettere nello stesso elenco “tecnici”, “persistenti” e “di terze parti”.
Non appartengono allo stesso livello di classificazione.
Un singolo elemento può contemporaneamente essere:
persistente + di prima parte + tecnico
oppure:
persistente + di terze parti + utilizzato per profilazione
Per orientarti conviene separare almeno quattro domande.
| Criterio | Possibili categorie | Cosa descrive |
|---|---|---|
| Durata | sessione / persistente | Per quanto tempo può rimanere memorizzato |
| Provenienza o contesto | prima parte / terza parte | Chi lo imposta o utilizza rispetto al sito visitato |
| Finalità | tecnico / analytics / profilazione | Per quale scopo viene utilizzato |
| Modalità di storage | normale / partizionato | In quale contesto il browser rende disponibile lo stato |
Questa distinzione evita parecchi equivoci.
Sessione e persistenza
Un elemento di sessione non specifica normalmente una scadenza persistente ed è legato alla sessione definita dal browser.
Non conviene però tradurre automaticamente “sessione” con “viene sicuramente cancellato non appena chiudo una finestra”. I browser possono ripristinare le sessioni e il comportamento effettivo dipende dal client.
Un valore persistente possiede invece una durata determinata, generalmente attraverso attributi come Expires o Max-Age.
Persistente non significa profilante.
Una preferenza linguistica può essere conservata per lungo tempo senza avere finalità pubblicitarie.
Allo stesso modo, un dato di sessione non diventa automaticamente privo di rilevanza privacy solo perché dura meno.
Prima parte e terze parti
Questa distinzione riguarda il rapporto tra il contesto visitato e il soggetto che imposta o utilizza l’informazione.
Nel primo caso il dato appartiene al contesto del sito che stai visitando.
Nel secondo entra in gioco un soggetto esterno incorporato o coinvolto nella pagina.
Questa seconda categoria è diventata particolarmente importante perché uno stesso provider presente su molti siti può, in determinate configurazioni, riconoscere lo stesso browser attraverso domini differenti.
È una delle basi storiche del cross-site tracking.
Tecnici, analytics e profilazione
Qui cambia il criterio: parliamo della finalità.
Gli strumenti tecnici sono quelli necessari per effettuare una comunicazione o fornire una funzione richiesta dall’utente, secondo il quadro descritto dal Garante.
Gli analytics servono invece a produrre statistiche.
La profilazione viene utilizzata per ricondurre comportamenti e preferenze a profili impiegabili, per esempio, nella personalizzazione pubblicitaria.
C’è però una precisazione decisiva: analytics non significa automaticamente tecnico.
Il Garante chiarisce che gli strumenti statistici possono essere assimilati a quelli tecnici solo quando rispettano determinate condizioni, legate tra l’altro a finalità statistica, aggregazione o minimizzazione e, quando intervengono terze parti, limiti agli utilizzi ulteriori.
Prima parte e terze parti: qual è davvero la differenza
Questa distinzione viene spesso utilizzata come scorciatoia per separare strumenti “buoni” e “cattivi”.
È una semplificazione sbagliata.
Perché “prima parte” non significa automaticamente innocuo
Un sito può impostare direttamente un identificatore e utilizzarlo per finalità che vanno molto oltre la semplice gestione tecnica.
La provenienza non determina da sola:
- finalità;
- quantità di dati associati;
- durata;
- eventuale profilazione;
- regime applicabile.
Per valutarne l’impatto devi quindi chiederti che cosa permette di fare, non soltanto chi lo ha impostato.
Perché “terza parte” non significa automaticamente profilazione
La situazione opposta è altrettanto importante.
Un servizio esterno può essere utilizzato per molte funzioni differenti: video, mappe, pagamenti, sicurezza, distribuzione dei contenuti, autenticazione, analytics o advertising.
La presenza di una terza parte segnala che devi capire quale soggetto entra nella comunicazione e quali dati riceve, ma non dimostra da sola una finalità di pubblicità comportamentale.
È per questo che origine e finalità vanno tenute separate.
Privacy: quali dati possono essere associati
Un identificatore può contenere direttamente un’informazione oppure funzionare come chiave che permette di recuperarla altrove.
È questa seconda possibilità a rendere fuorviante giudicarlo semplicemente guardando il valore.
Una stringa apparentemente casuale può consentire al sistema di collegare:
- sessione;
- account;
- preferenze;
- eventi;
- acquisti;
- segmenti;
- storico delle interazioni.
Non significa che ogni identificatore svolga tutte queste funzioni. Significa che l’impatto privacy dipende dall’intero trattamento, non dalla dimensione della stringa memorizzata.
Identificatori, sessioni e dati lato server
Prendiamo questo esempio:
visitor=8f2ac91
Quel valore, isolato, dice poco.
Se però il sistema possiede nel database una relazione del tipo:
8f2ac91 → preferenze → visite → acquisti → account
l’identificatore consente di collegare informazioni molto più ricche.
È anche il motivo per cui cookie ID e altri identificatori online possono, a seconda del contesto, rientrare nel trattamento di dati personali.
Per il quadro generale è utile distinguere questa disciplina dalla tecnologia specifica: nella guida al GDPR abbiamo approfondito dati personali, basi giuridiche, ruoli e responsabilità senza ridurre la compliance al solo banner.
Quando nasce il tracciamento
Il tracking diventa possibile quando un identificatore o un insieme di segnali permette di osservare e collegare attività nel tempo.
Può avvenire:
- all’interno dello stesso sito;
- tra servizi dello stesso soggetto;
- tra siti differenti;
- collegando dati del browser con account o altri identificatori.
La memorizzazione nel browser è solo uno dei mezzi possibili.
Non è quindi corretto ragionare come se eliminarla eliminasse automaticamente ogni capacità di tracciamento.
Lo stesso Garante include esplicitamente tra le tecniche da considerare altri strumenti di tracciamento, compreso il fingerprinting.
Cookie e dati personali non sono sinonimi
Un altro errore è sostenere che ogni valore memorizzato sia necessariamente un dato personale in qualunque contesto.
La valutazione dipende dalle informazioni contenute o associate e dalla possibilità di ricondurle a una persona identificata o identificabile.
Per questo i due estremi sono entrambi imprecisi:
“ogni cookie è sempre un dato personale”
e
“è solo una stringa tecnica, quindi non riguarda mai la privacy”
Il dato va interpretato nel sistema in cui viene utilizzato.
Accettare o rifiutare: cosa succede davvero
Quando premi “Rifiuta”, normalmente non stai chiedendo al sito di funzionare senza qualunque forma di memoria.
Stai esprimendo una scelta rispetto alle categorie e alle finalità per le quali quella scelta è prevista.
Gli strumenti tecnici necessari possono quindi continuare a essere utilizzati.
Cosa può continuare a funzionare
Le funzionalità strettamente necessarie al servizio richiesto dovrebbero rimanere disponibili.
A seconda del sito possono comprendere:
- gestione della sessione;
- sicurezza;
- carrello;
- bilanciamento delle richieste;
- memorizzazione della scelta sul consenso;
- altre funzionalità tecniche necessarie.
Il rifiuto di advertising o profilazione non dovrebbe quindi equivalere automaticamente a “sito inutilizzabile”.
Cosa può cambiare dopo il rifiuto
Alcune funzionalità opzionali possono cambiare o non essere disponibili.
Un contenuto incorporato da una piattaforma esterna, per esempio, potrebbe richiedere un’interazione separata prima di essere caricato.
Anche le misurazioni disponibili al gestore possono cambiare in base al sistema analytics e alla configurazione adottata.
Questo non significa che il sito debba forzarti ad accettare qualsiasi trattamento per poter leggere una pagina.
Perché “rifiuta tutti” non significa necessariamente “nessun cookie”
Il wording dei banner può creare confusione.
Quando l’interfaccia offre “Accetta tutti” e “Rifiuta tutti”, il secondo comando normalmente riguarda gli strumenti opzionali soggetti alla scelta, non quelli strettamente necessari.
Per questo sarebbe spesso più preciso leggere mentalmente il comando come:
rifiuta tutti gli strumenti opzionali
Un valore tecnico utilizzato per ricordare che hai rifiutato il tracciamento può addirittura essere necessario proprio per evitare di chiederti la stessa scelta a ogni pagina.
Cookie e GDPR sono collegati, ma non sono la stessa cosa.
Il GDPR disciplina il trattamento dei dati personali. I sistemi di memorizzazione e altri strumenti di tracciamento sono coinvolti anche da norme specifiche relative alle comunicazioni elettroniche e dal Codice Privacy.
Per una spiegazione operativa rivolta a chi gestisce siti italiani, la fonte primaria da verificare è la FAQ del Garante sui cookie.
Quali strumenti non richiedono normalmente consenso preventivo
Per quelli tecnici necessari non è richiesto il consenso preventivo previsto per le finalità ulteriori, pur restando gli obblighi informativi applicabili.
È importante soffermarsi sulla parola finalità.
Non basta chiamare un elemento “necessario” nel pannello della CMP per trasformarlo giuridicamente in uno strumento tecnico. La classificazione deve corrispondere a ciò che fa realmente.
Il caso particolare degli analytics
Gli strumenti statistici meritano una sezione separata proprio perché vengono spesso semplificati.
Il Garante precisa che non sono tecnici per definizione. Possono però essere assimilati ai tecnici quando vengono utilizzati nel rispetto delle condizioni previste.
Quando interviene una terza parte, assumono particolare rilievo la minimizzazione preventiva dei dati e il fatto che le informazioni non vengano combinate con ulteriori elaborazioni o trasmesse ad altri soggetti per finalità incompatibili.
Quindi:
analytics ≠ automaticamente consenso
ma anche:
analytics ≠ automaticamente esente dal consenso
La configurazione concreta conta più dell’etichetta.
Cosa deve permettere il banner
Quando è necessario raccogliere una scelta per profilazione o altri strumenti di tracciamento, il Garante indica un modello nel quale il banner consenta di:
- ricevere l’informazione iniziale;
- accettare;
- mantenere le impostazioni predefinite che escludono gli strumenti non tecnici;
- accedere a un livello più dettagliato;
- scegliere categorie, funzionalità e terze parti;
- modificare successivamente le preferenze.
Il Garante precisa inoltre che il semplice scrolling non costituisce, da solo, un consenso valido. Anche il cookie wall è soggetto a condizioni molto restrittive e non può essere considerato automaticamente lecito.
Questa sezione fornisce il modello generale, non una consulenza legale sul singolo sito: configurazioni e trattamenti concreti vanno verificati caso per caso.
La risposta breve è: non in modo uniforme e non secondo la vecchia narrativa della “fine definitiva”.
Negli anni i browser hanno adottato strategie differenti per ridurre il cross-site tracking. La situazione va quindi letta browser per browser.
Cosa è successo ai piani di Chrome
Per molto tempo Google aveva pianificato la progressiva eliminazione del supporto ai cookie di terze parti in Chrome.
Quel piano è cambiato.
Google ha successivamente comunicato che Chrome avrebbe mantenuto l’approccio basato sulla possibilità per gli utenti di scegliere come gestire i cookie di terze parti nelle impostazioni, senza introdurre la nuova richiesta autonoma che era stata prospettata.
La conseguenza editoriale è importante: qualsiasi guida che presenti ancora come certo un imminente spegnimento generalizzato di questa tecnologia in Chrome è da aggiornare.
Questo non significa che tutto sia tornato come prima. Il browser continua ad avere protezioni specifiche, applica restrizioni in determinati contesti e permette agli utenti di gestire o bloccare l’accesso di terze parti.
Le istruzioni correnti sono disponibili nella guida ufficiale di Chrome.
Firefox e l’isolamento dello stato
Firefox utilizza un approccio differente.
La Total Cookie Protection crea contenitori separati per sito, in modo da limitare la possibilità che lo stesso stato venga utilizzato per seguire l’utente da un dominio all’altro.
Mozilla mantiene inoltre protezioni specifiche contro il tracking cross-site nella documentazione dedicata ai cookie di terze parti e alle protezioni antitracciamento.
Il punto non è che Firefox abbia eliminato questa tecnologia.
Il browser cerca piuttosto di limitare il contesto nel quale determinati identificatori possono essere riutilizzati.
Safari e il tracking cross-site
Safari adotta da tempo protezioni contro il monitoraggio tra siti.
Nelle impostazioni Privacy è disponibile la funzione che limita il tracking cross-site; Apple ne documenta il comportamento nella guida ufficiale di Safari.
Anche qui la lettura corretta non è “Safari non usa cookie”, ma “Safari applica restrizioni specifiche al riutilizzo cross-site”.
Cookie partizionati e CHIPS
Un’evoluzione particolarmente interessante è quella degli identificatori partizionati.
Con CHIPS — Cookies Having Independent Partitioned State — un dato utilizzato in un contesto di terze parti può essere conservato in una partizione legata anche al sito di primo livello.
In pratica, uno stesso servizio incorporato in due domini diversi non ottiene automaticamente lo stesso contenitore globale da utilizzare per riconoscere l’utente tra i due siti.
L’attributo HTTP è:
Partitioned
e richiede Secure.
MDN documenta il meccanismo nella guida dedicata ai cookie partizionati e CHIPS.
Questa evoluzione mostra bene la direzione dei browser moderni: non necessariamente eliminare ogni meccanismo di memorizzazione, ma ridurre la possibilità di utilizzare uno stato condiviso per il tracking tra siti non correlati.
Sicurezza: Secure, HttpOnly e SameSite
Un cookie non è malware, ma alcuni valori possono diventare obiettivi molto importanti per un attaccante.
Un token di sessione rubato, per esempio, può consentire di impersonare una sessione autenticata finché il sistema non la invalida.
La sicurezza dipende dall’intera applicazione, ma alcuni attributi riducono specifiche superfici di rischio.
A cosa serve Secure
L’attributo:
Secure
indica al browser di inviare il dato attraverso connessioni HTTPS, con le eccezioni tecniche previste dagli ambienti locali.
È una misura importante contro l’esposizione attraverso connessioni non cifrate.
Non significa però che la sessione diventi automaticamente sicura contro qualsiasi attacco.
Per capire perché il trasporto cifrato conta, puoi approfondire la differenza tra HTTP e HTTPS.
Perché HttpOnly protegge gli identificatori di sessione
Con:
HttpOnly
il valore non è accessibile attraverso API JavaScript come document.cookie.
Questo riduce la possibilità che uno script malevolo, per esempio in presenza di una vulnerabilità XSS, lo legga direttamente.
È importante non eccedere nella promessa: HttpOnly mitiga uno specifico vettore di furto, ma non elimina una vulnerabilità XSS né tutti i suoi possibili effetti.
Come SameSite riduce alcuni rischi cross-site
L’attributo SameSite stabilisce in quali contesti cross-site il browser può inviare il dato.
I valori più importanti sono:
SameSite=Strict SameSite=Lax SameSite=None
Strict applica la limitazione più forte.
Lax permette alcuni scenari di navigazione cross-site mantenendo maggiori restrizioni rispetto a None.
None consente l’invio anche in contesti cross-site e richiede Secure.
Configurato correttamente, SameSite può contribuire a ridurre il rischio di alcune forme di Cross-Site Request Forgery, ma deve essere scelto in base al comportamento realmente necessario all’applicazione.
La configurazione di una sessione non dovrebbe quindi nascere da una formula copiata:
Secure + HttpOnly + SameSite
Bisogna capire quale informazione stai proteggendo e come deve funzionare l’applicazione.
I browser permettono di visualizzare e gestire i dati salvati dai siti.
Le voci dell’interfaccia possono cambiare nel tempo, quindi per i passaggi operativi conviene utilizzare la documentazione ufficiale anziché affidarsi a screenshot vecchi.
Chrome
Chrome consente di gestire i cookie di terze parti globalmente e di definire eccezioni per siti specifici.
La documentazione corrente è disponibile nella guida di Google Chrome alla gestione dei cookie.
Puoi inoltre eliminare i dati memorizzati da singoli siti o cancellare più ampiamente i dati di navigazione.
Dopo la cancellazione è normale che alcuni siti dimentichino preferenze o richiedano un nuovo login.
Firefox
Firefox concentra queste funzioni nell’area Privacy e sicurezza e affianca alla normale gestione dei dati le proprie protezioni antitracciamento.
Mozilla spiega anche come vengono gestiti i cookie di terze parti e il tracking cross-site.
Safari
Su Safari per macOS, Apple documenta la funzione Blocca tracciamento cross-site nell’area Privacy.
La procedura aggiornata è disponibile nella guida ufficiale.
Cosa succede quando li cancelli
Eliminare i dati non equivale a “ripulire completamente il computer”.
Può comportare:
- logout dagli account;
- perdita di preferenze salvate localmente;
- eliminazione di identificatori;
- ricomparsa di banner o configurazioni già gestite.
Inoltre cookie e cache sono tecnologie differenti.
La cache conserva copie di risorse per velocizzare il caricamento; i primi memorizzano piccoli stati e identificatori utilizzati dall’applicazione.
Cancellare l’una non equivale automaticamente a cancellare gli altri.
localStorage, sessionStorage e fingerprinting: cosa cambia
I cookie non sono l’unico modo per conservare informazioni nel browser.
Le Web Storage API mettono a disposizione soprattutto:
localStorage sessionStorage
Una differenza strutturale importante è che i dati di Web Storage non vengono automaticamente inviati al server a ogni richiesta HTTP.
Cookie vs Web Storage
localStorage conserva dati associati all’origine e può mantenerli anche dopo la chiusura e riapertura del browser.
sessionStorage mantiene invece uno storage legato alla sessione della pagina o della scheda secondo il modello definito dal browser.
Sono strumenti spesso utilizzati per:
- stato dell’interfaccia;
- configurazioni;
- preferenze;
- dati applicativi lato client.
Non rappresentano però una scorciatoia per uscire automaticamente dal quadro normativo.
Se una tecnologia viene utilizzata per accedere o memorizzare informazioni sul terminale e per realizzare tracciamento, la valutazione non scompare perché il dato si trova in localStorage invece che in un cookie.
Il Garante parla infatti esplicitamente di cookie e altri strumenti di tracciamento.
Il fingerprinting segue un’altra logica
Il browser fingerprinting non richiede necessariamente il recupero di un identificatore precedentemente memorizzato.
Può combinare caratteristiche osservabili del browser o del dispositivo per creare un’impronta sufficientemente distintiva.
A seconda della tecnica possono entrare in gioco:
- caratteristiche del browser;
- sistema operativo;
- configurazione grafica;
- lingua;
- dimensioni dello schermo;
- font e capacità disponibili;
- altri segnali tecnici.
Il fingerprinting dimostra perché cookieless non significa automaticamente trackingless.
Puoi eliminare una tecnologia di memorizzazione e continuare ad avere sistemi in grado di riconoscere o distinguere dispositivi.
E, contrariamente a una semplificazione diffusa, non è corretto sostenere che il fingerprinting sia automaticamente fuori dalle regole sul consenso: il Garante lo cita espressamente tra gli strumenti che possono raggiungere finalità di tracciamento.
Se gestisci un sito WordPress: cosa devi controllare
Su WordPress il problema pratico non è scegliere un banner esteticamente gradevole.
È sapere che cosa viene realmente caricato dal sito prima e dopo la scelta dell’utente.
Plugin, tema, embed, video, sistemi analytics, advertising, CAPTCHA, chat, mappe e integrazioni esterne possono modificare il comportamento della pagina.
Per questo la gestione dovrebbe partire da un inventario.
1. Individua cookie, storage e richieste esterne
Apri il sito in una sessione pulita e controlla:
- dati salvati;
localStorageesessionStorage;- richieste di rete;
- domini esterni contattati;
- script caricati;
- iframe ed embed;
- comportamento prima della scelta sul banner.
Gli strumenti per sviluppatori del browser sono molto utili perché consentono di osservare Application/Storage e Network direttamente.
Non limitarti però a leggere il nome dell’elemento trovato: devi capire chi lo crea e per quale funzione.
2. Ripeti il test dopo il rifiuto
Ricarica il sito in condizioni pulite e rifiuta gli strumenti opzionali.
Verifica nuovamente le richieste.
La domanda da fare non è:
“Il banner ha registrato il rifiuto?”
ma:
“I servizi che avrebbero dovuto attendere la scelta sono effettivamente rimasti bloccati o hanno modificato correttamente il loro comportamento?”
È una differenza sostanziale.
Un’interfaccia può sembrare perfetta mentre gli script sottostanti partono comunque.
3. Controlla analytics e marketing separatamente
Se utilizzi analytics, verifica l’implementazione concreta.
Non classificare automaticamente un servizio come tecnico solo perché serve a produrre statistiche.
Se utilizzi strumenti Google, controlla anche come vengono gestiti tag e stati del consenso. La guida a Google Tag Manager spiega la distinzione tra CMP/banner, Consent Mode e attivazione dei tag.
Il principio resta:
la CMP raccoglie la scelta
la configurazione tecnica deve rispettarla
4. Ricontrolla dopo ogni modifica importante
Il punto debole dei siti WordPress è la loro capacità di cambiare senza che il gestore modifichi direttamente il template.
Può bastare:
- aggiungere un plugin;
- attivare un modulo;
- incorporare un video;
- integrare una chat;
- collegare un servizio marketing;
- modificare la configurazione analytics.
Dopo interventi di questo tipo, ripeti l’inventario e il test del consenso.
La conformità non è un’etichetta che il sito ottiene una volta per sempre. È il risultato di configurazione + verifica + manutenzione.
I cookie sono pericolosi?
Non di per sé. Sono dati gestiti dal browser. Il rischio dipende dal modo in cui vengono progettati e utilizzati. Un identificatore di sessione configurato male può aumentare un rischio di sicurezza; un altro utilizzato per tracking può avere implicazioni privacy. La tecnologia, da sola, non determina la pericolosità.
Devo accettare tutti i cookie per navigare?
No. Gli strumenti tecnici necessari possono essere utilizzati senza la stessa scelta richiesta per quelli opzionali. Un sito non dovrebbe presentare “accetta tutto” come unica possibilità quando il consenso è richiesto per finalità ulteriori.
Cancellare i cookie elimina anche la cache?
No. Cookie e cache svolgono funzioni differenti. Puoi eliminare i primi senza necessariamente cancellare tutte le risorse memorizzate nella cache, e viceversa.
I cookie contengono le password?
Un’applicazione ben progettata non dovrebbe memorizzare una password in chiaro. Può invece conservare identificatori o token di sessione che, proprio perché permettono di riconoscere una sessione autenticata, devono essere protetti adeguatamente.
La navigazione in incognito elimina il tracking?
No. La modalità privata limita soprattutto la persistenza locale di cronologia e altri dati della sessione e può applicare protezioni aggiuntive del browser. Non rende invisibile la connessione, non impedisce automaticamente a un sito di ricevere dati tecnici e non equivale ad anonimato.
Un sito cookieless non utilizza dati degli utenti?
Non necessariamente. “Cookieless” descrive l’assenza o la riduzione di una particolare tecnologia. Il sito può comunque utilizzare Web Storage, identificatori server-side, dati di account, fingerprinting o altre tecniche.
La domanda corretta non è soltanto “usa cookie?”, ma quali dati raccoglie, come li raccoglie e per quale finalità?
Conclusione
Il modo più utile per capire i cookie è smettere di dividerli in “buoni” e “cattivi”.
Bisogna invece fare quattro domande:
quanto dura l’identificatore?
chi lo imposta o lo utilizza?
per quale finalità serve?
a quali informazioni permette di collegarsi?
Da qui diventano più chiare quasi tutte le distinzioni importanti.
Un dato di prima parte non è automaticamente tecnico. Uno di terze parti non è automaticamente pubblicitario. La persistenza non implica automaticamente tracking. Un sistema analytics non è automaticamente esente dal consenso. E un sito senza i classici cookie non è necessariamente un sito senza tracciamento.
Per chi naviga, questa distinzione aiuta a capire che cosa accettare, rifiutare o cancellare.
Per chi gestisce un sito, porta a una conclusione ancora più pratica: non basta installare un banner. Devi sapere quali tecnologie sono realmente presenti, quando vengono attivate e che cosa accade dopo ogni scelta dell’utente.