Come funziona il tracciamento dell'impronta digitale sotto il cofano

Ogni dispositivo che si connette a internet lascia una scia di artefatti tecnici — un'impronta digitale. In tracio.ai ricostruiamo questa impronta a partire da oltre 300 segnali passivi raccolti durante un singolo caricamento di pagina, senza che l'identificazione dipenda da cookie o da qualsiasi altra forma di archiviazione lato client persistente. Questo articolo spiega esattamente come funziona quel processo.

Lo strato di raccolta dei segnali

Quando il nostro agente JavaScript si carica nel browser di un visitatore, inizia a raccogliere segnali simultaneamente attraverso più categorie. Il rendering del canvas, le query dei parametri WebGL, l'elaborazione AudioContext, l'enumerazione dei font e le letture delle proprietà navigator vengono tutti eseguiti in parallelo, ciascuno delimitato da un proprio timeout, così che una sonda lenta non trattenga le altre. La durata dell'intero passaggio dipende dal dispositivo del visitatore, e i numeri riportati sotto sono quelli che misuriamo sui nostri.

L'intuizione chiave è che ogni segnale cattura un aspetto diverso dello stack hardware e software del dispositivo. Il rendering del canvas riflette la GPU, il driver e il motore di rendering dei font. I parametri WebGL espongono il modello e le capacità della scheda grafica. AudioContext rivela le differenze nel modo in cui il DSP audio elabora le operazioni in virgola mobile. Le proprietà navigator riportano i core della CPU, la memoria, la piattaforma e le impostazioni della lingua.

Il nostro team ha effettuato questa misurazione su 2 miliardi di eventi il mese scorso: il tempo di raccolta mediano è stato di 38ms e il 99° percentile di 52ms. In realtà abbiamo provato prima l'approccio naïf — raccogliere i segnali in sequenza. Era 40 volte più lento. La raccolta parallela con una barriera di timeout è stata una delle prime decisioni architetturali che abbiamo azzeccato.

Fingerprinting TLS: il primo strato

Prima ancora che il nostro JavaScript venga eseguito, il browser ha già rivelato informazioni significative attraverso l'handshake TLS. Il messaggio Client Hello contiene le suite di cifratura supportate dal browser, le estensioni TLS che utilizza, le curve ellittiche che preferisce e gli algoritmi di firma che accetta. Queste informazioni sono determinate dalla libreria TLS del browser e variano significativamente tra famiglie di browser, versioni e sistemi operativi.

Catturiamo questo fingerprint TLS usando l'hashing JA4 — un sostituto moderno di JA3 che offre una granularità migliore e una stabilità cross-version. Il solo hash JA4 può distinguere Chrome da Firefox da Safari, e spesso restringe l'identificazione a un intervallo di versioni specifico del browser. Combinato con i nostri segnali lato client, fornisce uno strato di cross-validazione estremamente difficile da falsificare.

Fingerprinting di canvas e GPU

Il fingerprinting del canvas sfrutta il fatto che GPU diverse eseguono il rendering delle stesse istruzioni di disegno con sottili differenze a livello di pixel. La Canvas API ci permette di disegnare una scena progettata con cura — stringhe di testo specifiche in più font, forme geometriche con coordinate particolari e gradienti con precisi punti di arresto del colore — per poi calcolare un hash dei dati dei pixel risultanti.

Le differenze di rendering derivano dalle variazioni negli algoritmi di anti-aliasing, nel rendering sub-pixel, nella fusione dei colori e nell'hinting dei font tra i modelli di GPU e le versioni dei driver. Anche due dispositivi con lo stesso modello di GPU possono produrre output di canvas diversi se eseguono versioni di driver o sistemi operativi differenti. Questo rende l'hash del canvas uno dei nostri segnali più distintivi.

Profilazione hardware WebGL

La WebGL API espone informazioni dettagliate sul sottosistema grafico che vanno ben oltre le stringhe di renderer e vendor. Interroghiamo le dimensioni massime delle texture, i formati di precisione degli shader, le estensioni supportate, le dimensioni del viewport e decine di altri parametri che variano tra i modelli di GPU e le configurazioni dei driver.

La combinazione di questi parametri crea un profilo hardware dettagliato. Un dispositivo con una NVIDIA RTX 4070, per esempio, riporterà dimensioni massime delle texture diverse, una precisione degli shader diversa e un supporto delle estensioni diverso rispetto a un dispositivo con una AMD RX 7800 XT. Questo profilo hardware è intrinsecamente stabile: non cambia con gli aggiornamenti del browser, ma solo con le modifiche all'hardware o ai driver.

Fingerprinting dell'elaborazione audio

La Web Audio API fornisce un'altra fonte di segnali dipendenti dall'hardware. Creiamo un nodo oscillatore, lo colleghiamo a un compressore di dinamica e misuriamo il buffer di output. Le differenze nella precisione in virgola mobile, nell'implementazione del DSP e negli algoritmi di ricampionamento tra l'hardware audio e i sistemi operativi producono variazioni misurabili nell'output.

I fingerprint audio hanno un'unicità moderata ma una stabilità eccezionale. La pipeline di elaborazione audio cambia raramente, a meno che l'utente non cambi l'hardware audio o reinstalli il sistema operativo. Questo rende i segnali audio ancore preziose nel nostro sistema di identificazione multilivello.

Fusione dei segnali e risoluzione dell'identità

I segnali grezzi vengono cifrati e trasmessi al nostro server, dove il motore di identificazione del dispositivo li elabora attraverso un sistema di hashing a tre livelli. I segnali a livello hardware (canvas, WebGL, audio) formano il Livello 1 — l'identità di base stabile. I segnali a livello browser (feature detection, proprietà CSS, capacità multimediali) formano il Livello 2, elaborato tramite il matching cross-sessione per gestire la deriva prevista dagli aggiornamenti del browser. I segnali volatili (user agent, fuso orario, lingua) formano il Livello 3, contribuendo al punteggio di confidenza senza guidare le decisioni sull'identità.

L'algoritmo di fusione pondera ogni segnale in base alla sua unicità e stabilità. Una corrispondenza su un raro hash di canvas ha un peso di gran lunga maggiore rispetto a una corrispondenza su una comune risoluzione dello schermo. Questo approccio ponderato garantisce che l'identificazione rimanga accurata anche quando un sottoinsieme di segnali cambia.

Cosa memorizziamo e perché l'identificazione non ne dipende

Un principio di progettazione fondamentale del nostro sistema è che l'identificazione non dipende dall'archiviazione lato client. Il visitor ID è derivato dalle caratteristiche intrinseche del dispositivo — l'hardware, lo stack software, la configurazione di rete — ed è per questo che l'identificazione sopravvive alla cancellazione dei cookie, alla modalità incognito e persino alla reinstallazione del browser.

È un'affermazione sulla dipendenza, non sull'astinenza, e la differenza merita di essere detta chiaramente. Un cookie di prima parte lo impostiamo eccome: _vid_t, che contiene un identificatore opaco con scadenza a 365 giorni, e rispecchiamo lo stesso valore in localStorage. Quello che non facciamo è impostare cookie di terze parti, scrivere qualcosa che funzioni tra siti diversi o leggere cronologia di navigazione, dati dei moduli o IndexedDB. Il cookie esiste perché è la risposta più economica possibile alla domanda «abbiamo già visto questo browser?»: quando sopravvive, la corrispondenza è immediata e certa. Quando non sopravvive, non si rompe nulla: i segnali del dispositivo ricostruiscono l'identificatore da soli, con una confidenza leggermente inferiore. Un visitatore che cancella tutto viene comunque riconosciuto; un sistema costruito solo sull'archiviazione lo avrebbe perso.

Privacy fin dall'architettura

Poiché raccogliamo solo attributi tecnici del browser — nessuna cronologia di navigazione, nessun dato dei moduli, nessun contenuto personale — l'impatto sulla privacy è minimo. La W3C Fingerprinting Guidance delinea le best practice per un uso responsabile dei segnali del browser, e la nostra architettura si allinea a questi principi. L'elaborazione avviene nel nostro cloud gestito, con localizzazione dei dati nell'UE o negli Stati Uniti a seconda della regione che sceglie. Questa architettura rende semplice la conformità con GDPR, CCPA e altre normative sulla privacy.