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 130 segnali passivi raccolti durante un singolo caricamento di pagina, senza affidarci a cookie, localStorage o qualsiasi 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. L'intero processo di raccolta si completa in meno di 50 millisecondi su hardware moderno.

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.

Nessuna archiviazione, nessun cookie

Un principio di progettazione fondamentale del nostro sistema è che l'identificazione non dipende da alcuna forma di archiviazione lato client. Non impostiamo cookie, non scriviamo su localStorage e non usiamo IndexedDB a scopo di tracciamento. Il visitor ID è derivato interamente dalle caratteristiche intrinseche del dispositivo — l'hardware, lo stack software, la configurazione di rete. Questo significa che l'identificazione sopravvive alla cancellazione dei cookie, alla modalità incognito e persino alla reinstallazione del browser.

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. Con il deployment in cloud, tutta l'elaborazione avviene sulla sua infrastruttura. Nessun dato dei visitatori raggiunge mai i nostri server. Questa architettura rende semplice la conformità con GDPR, CCPA e altre normative sulla privacy.