Il dibattito pubblico sulla privacy digitale si è concentrato quasi ossessivamente sui cookie traccianti. Banner sempre più complessi, consensi granulari, CMP, rifiuti “necessari”, accettazioni forzate: l’utente medio ha imparato ad associare il concetto di tracciamento a quel pop-up che compare alla prima visita su un sito Web. Il messaggio implicito è chiaro: se rifiuto i cookie, sono al sicuro. La realtà tecnica, però, è molto diversa e l’Europa ha recentemente rimesso in discussione i banner Accetta/Rifiuta.
Va detto, infatti, che esiste una forma di identificazione silenziosa, persistente e spesso completamente invisibile all’utente, che non richiede consenso esplicito, non usa storage tradizionale e continua a funzionare anche quando i cookie vengono cancellati o bloccati. Si chiama browser fingerprinting ed è oggi uno dei principali strumenti con cui le visite dello stesso utente possono essere correlate nel tempo.
Progetti dimostrativi come What You Reveal sono interessanti non perché “rubano” dati, ma perché mostrano quanto il browser, semplicemente esistendo, esponga una quantità enorme di segnali che, combinati, diventano un identificatore stabile.
Il grande equivoco: privacy ≠ cookie
La regolamentazione (GDPR, ePrivacy, linee guida dei Garanti) ha portato enorme attenzione sui cookie perché sono facili da comprendere, facili da bloccare e facili da normare: sono dati scritti esplicitamente sul dispositivo dell’utente. Il fingerprinting, invece, funziona al contrario: non scrive nulla. Legge.
Ogni browser, nel tentativo di adattarsi al dispositivo, all’utente e al contesto, espone informazioni. Nessuna di queste è segreta, molte sono necessarie al funzionamento del Web moderno. Il problema nasce quando esse vengono aggregate.
Cos’è davvero il browser fingerprinting
Un fingerprint non è un valore magico né un ID univoco generato da qualche API “oscura”. È il risultato della combinazione di caratteristiche del sistema, configurazione del browser, capacità hardware e software, comportamenti di rendering, coerenze e incoerenze temporali e geografiche.
Il punto chiave è che la probabilità che due utenti abbiano la stessa combinazione completa è bassissima. Non serve conoscere il nome di una persona: basta riconoscere che “questo browser è lo stesso di ieri”.
Dal caricamento della pagina al contesto di rete: ciò che il server vede per primo
La prima interazione tra browser e sito avviene a livello di rete. Ancora prima che codice JavaScript sia caricato lato client, il server riceve una richiesta HTTP accompagnata da un insieme di informazioni. L’indirizzo IP pubblico è il dato più evidente: non è opzionale, perché è necessario per instradare la risposta. Da quell’IP, tramite database di rete e routing, è possibile derivare l’ISP, l’Autonomous System, la tipologia di connessione e derivare una localizzazione geografica stimata.
What You Reveal espone chiaramente questo livello mostrando IP, ASN, provider e una geolocalizzazione basata su GeoIP. Non si tratta di GPS né di una “posizione precisa”, ma di una stima sufficiente a collocare l’utente in una regione, spesso in una città. Questo passaggio è fondamentale dal punto di vista didattico, perché chiarisce un equivoco diffuso: la localizzazione non richiede permessi se è derivata dalla rete.
A questi dati si aggiungono misure temporali come latenza, jitter e RTT, che contribuiscono a caratterizzare la qualità e il tipo di connessione. Qui non si parla di dati personali in senso stretto, ma di contesto tecnico, che diventa parte integrante del fingerprint complessivo.
What You Reveal: progetto aperto e facilmente riproducibile
Uno degli aspetti più interessanti di What You Reveal è che non si limita a mostrare dei risultati, ma consente a chiunque di verificarli direttamente.
Il progetto è completamente open source (licenza MIT) e il codice è disponibile pubblicamente su GitHub, permettendo di ispezionare senza ambiguità quali API sono utilizzate, quali dati raccoglie il browser e in che modo sono presentati all’utente. Questa trasparenza è fondamentale quando si parla di fingerprinting: non ci si affida a un servizio opaco, ma a un’implementazione che può essere letta, modificata ed eseguita localmente.
Dal punto di vista tecnico, l’installazione è volutamente semplice. È sufficiente avere un ambiente di sviluppo moderno con Bun installato. Dopo aver clonato il repository dal repository GitHub ufficiale, si accede alla directory del progetto e si installano le dipendenze con il comando bun install.
Una volta completata l’installazione, il server di sviluppo può essere avviato con bun run dev. A questo punto l’applicazione è disponibile in locale e il browser può essere analizzato come se si stesse visitando il sito pubblico.
La modalità di utilizzo locale ha anche un valore didattico aggiuntivo: permette di osservare il comportamento del browser in un contesto controllato, di modificare il codice per testare singole tecniche di fingerprinting e di comprendere, passo dopo passo, quali informazioni sono effettivamente esposte a un server remoto e quali invece sono il risultato di inferenze successive.
Coerenza temporale e geografica
Un aspetto spesso trascurato del fingerprinting è la coerenza tra segnali diversi. What You Reveal mette in relazione l’orario locale del browser, il fuso orario, l’UTC e la posizione stimata dall’IP. Quando questi elementi risultano coerenti, rafforzano l’affidabilità del profilo; quando non lo sono, diventano comunque informativi.
Un browser che dichiara una timezone europea ma utilizza un IP associato a un altro continente non “smaschera” automaticamente l’uso di una VPN, ma genera un pattern osservabile. Il fingerprinting moderno non cerca certezze assolute: lavora per probabilità cumulative.
Informazioni di sistema: ciò che JavaScript può leggere senza permessi
Una volta che la pagina è caricata, entra in gioco il secondo grande livello di esposizione: le API accessibili via JavaScript. What You Reveal mostra quanto sia ampia questa superficie anche in assenza di qualsiasi autorizzazione esplicita.
Il browser espone informazioni sul numero di core logici, sulla memoria disponibile (spesso in forma approssimata), sulla presenza o meno di input touch, sul tipo di puntatore e sul supporto a eventi avanzati. Questi dati non sono progettati per identificare l’utente, ma per permettere alle applicazioni Web di adattarsi al dispositivo. Tuttavia, sono relativamente stabili e contribuiscono a distinguere un ambiente da un altro.
Un punto particolarmente interessante è la gestione della batteria. Storicamente, API come la Battery Status fornivano informazioni molto precise; oggi molti browser le hanno limitate o disabilitate proprio per ridurre il fingerprinting. What You Reveal evidenzia se queste informazioni sono ancora accessibili e in quale forma, mostrando concretamente l’evoluzione delle contromisure adottate dai browser.
GPU, WebGL e pipeline di rendering: il fingerprint più sottovalutato
Uno dei contributi tecnici più forti di What You Reveal è la sezione dedicata alla grafica. Attraverso WebGL non viene semplicemente verificato se il browser “supporta il 3D”, ma viene osservato come lo supporta.
Il vendor e il renderer riportati da WebGL, insieme ai limiti massimi di texture, viewport e buffer, descrivono indirettamente la GPU, i driver e lo stack grafico. Anche quando il browser tenta di mascherare il modello reale, il comportamento complessivo della pipeline rimane sorprendentemente distintivo.
Questo è un punto chiave da comprendere: non serve leggere un identificatore esplicito per creare il fingerprint di un sistema. È sufficiente far eseguire un’operazione e osservare il risultato. Le differenze nel rendering, anche minime, tendono a essere stabili nel tempo sullo stesso hardware.
Canvas e Audio fingerprinting: l’identità nelle imperfezioni
What You Reveal utilizza tecniche classiche di canvas e audio fingerprinting per dimostrare un concetto fondamentale: gli standard definiscono l’output logico, ma non eliminano completamente le differenze implementative.
Nel rendering canvas entrano in gioco antialiasing, sub-pixel rendering, font fallback e precisione numerica. Nell’audio contano filtri, gestione del buffer e floating-point. Il risultato è un hash che non rappresenta un “ID segreto”, ma una firma riproducibile dell’ambiente.
Dal punto di vista del server, questi hash sono estremamente utili perché sopravvivono alla cancellazione dei cookie e non richiedono storage persistente. What You Reveal li mostra esplicitamente per rendere evidente quanto siano facili da generare.
Locale, lingua e formati: il fingerprint culturale del browser
Un’altra area spesso sottovalutata è quella della configurazione regionale o internazionale. Il browser comunica lingua primaria, lingue secondarie, timezone, formati di data e numeri, regole plurali e impostazioni di localizzazione. Sono elementi che cambiano raramente e riflettono scelte consapevoli dell’utente o del sistema operativo.
What You Reveal aggrega queste informazioni in un fingerprint che, pur non essendo “sensibile” in senso stretto, contribuisce in modo significativo alla riconoscibilità del browser. È un esempio perfetto di come dati apparentemente innocui diventino potenti se combinati.
Font e superficie software: la storia del sistema in un elenco invisibile
La rilevazione dei font installati è uno dei vettori a più alta entropia. Un sistema accumula font nel tempo: quelli di default, quelli installati da applicazioni, quelli aggiunti per lavoro o per sviluppo. What You Reveal mostra non solo il numero di font rilevati, ma anche la varietà: font di sistemi diversi, font tecnici, font specialistici.
Ciò non permette di identificare una persona, ma rende il browser molto difficile da confondere con un altro. È uno degli esempi più chiari di fingerprinting “passivo”: il sito non fa nulla di invasivo, si limita a osservare ciò che è disponibile.
API supportate e permessi: il profilo funzionale del browser
L’insieme di API disponibili – WebUSB, WebHID, WebSerial, sensori, media, DRM – definisce una sorta di “profilo funzionale”. Due browser con versioni, configurazioni o politiche di sicurezza diverse espongono superfici diverse.
What You Reveal evidenzia anche lo stato dei permessi: concessi, negati o in attesa. Anche questo è un segnale osservabile, che non rivela il contenuto dei dati ma racconta come l’utente interagisce con il browser.
Identità composita: perché due visite possono essere collegate senza cookie
Il punto centrale che il progetto dimostra è questo: il fingerprinting non dipende da un singolo dato, ma dalla combinazione di tutti i livelli descritti.
Rete, tempo, hardware, grafica, locale, font, API. Ogni componente aggiunge un piccolo contributo. Insieme, rendono il browser riconoscibile nel tempo con una probabilità spesso sufficiente per correlare visite successive.
È il motivo per cui la sola attenzione ai cookie è insufficiente e fuorviante. Anche senza storage persistente, un server può stimare con buona affidabilità che due richieste provengano dallo stesso ambiente.
Perché What You Reveal è una leva didattica (non uno strumento di sorveglianza)
Il valore di What You Reveal non è nel “fare fingerprinting”, ma nel mostrarlo in modo esplicito. Rende visibile ciò che normalmente resta implicito, trasformando un insieme di segnali tecnici in una narrazione comprensibile.
Se usato correttamente, il progetto sposta il dibattito dalla domanda “quali cookie devo accettare?” a una molto più scomoda e più reale: “quanto del mio ambiente digitale viene esposto semplicemente per poter usare il web moderno?”
Finché la discussione sulla privacy resterà confinata ai banner, il fingerprinting continuerà a operare sotto i radar. Progetti come questo servono proprio a rompere questa illusione, mostrando che il tracciamento non è sempre una scelta attiva dell’utente, ma spesso una conseguenza strutturale del funzionamento del browser stesso.
Il problema reale: il fingerprinting è invisibile per design
Il quadro normativo europeo (GDPR + ePrivacy) non ignora il fingerprinting. Anzi, negli ultimi anni è stato chiarito più volte che:
- Il browser fingerprinting è un trattamento di dati personali quando consente l’identificazione diretta o indiretta dell’utente.
- Non è rilevante che non siano usati cookie o storage locale: ciò che conta è la finalità di tracciamento.
- Chi utilizza tecniche di fingerprinting deve informare l’utente, indicare le finalità e, salvo basi giuridiche alternative molto specifiche, ottenere un consenso valido prima dell’esecuzione del codice.
Il punto critico emerge quando si passa dal diritto alla tecnica. Un cookie è osservabile: è scritto sul dispositivo client; può essere ispezionato; può essere bloccato; lascia tracce evidenti. Il fingerprinting no.
Non scrive nulla, non c’è nulla di persistente, non lascia artefatti facilmente rilevabili. È spesso composto da normali chiamate ad API legittime, indistinguibili – a livello superficiale – da quelle usate per scopi funzionali.
Dal punto di vista del browser client:
- Una chiamata a WebGL può servire a disegnare una scena 3D.
- Una chiamata a Canvas può servire a generare un grafico.
- Una query sui font può servire a scegliere un fallback tipografico.
Dal punto di vista del server, però, gli stessi risultati possono essere correlati nel tempo e usati per generare identificativi univoci. La normativa guarda alla finalità, ma la finalità non è tecnicamente visibile nel codice.
Dal punto di vista dei controlli: cosa si riesce davvero a smascherare?
Nel caso del fingerprinting, è possibile intervenire quando è esplicito e documentato; viene usato da grandi piattaforme visibili; emerge da data breach, leak o audit interni; è accompagnato da altre violazioni evidenti.
Il fingerprinting “silenzioso”, distribuito, non dichiarato, integrato in librerie terze o in codice custom: è difficilissimo da individuare, è ancora più difficile da provare, quasi impossibile da misurare dall’esterno. E soprattutto: l’utente non ha strumenti per accorgersene.
È proprio in questo contesto che strumenti come What You Reveal diventano rilevanti, perché mostrano quanto materiale grezzo sia disponibile per il fingerpriting.
Il progetto non accusa, non presume finalità, non viola la normativa. Fa una cosa diversa e più sottile: dimostra che il browser fornisce già tutto ciò che serve per correlare visite, anche in assenza di cookie.