Il sistema di identificazione di TRACIO genera un identificatore di visitatore stabile a partire da oltre 130 segnali del browser. L'identificatore persiste tra le sessioni, in modalità incognito, ai cambi di VPN e alla cancellazione dei cookie. Questa pagina illustra l'intera pipeline di identificazione.
Il client raccoglie oltre 130 segnali distinti del browser suddivisi in 10 categorie. Ogni segnale sonda un aspetto diverso del browser e del dispositivo, dalle caratteristiche hardware al comportamento di rendering.
| Gruppo | Segnali | Stabilità | Esempi |
|---|---|---|---|
| Hardware | 12 | Molto alta | Risoluzione schermo, memoria del dispositivo, concorrenza hardware, supporto touch |
| Rendering | 9 | Alta | Fingerprint del canvas (testo + geometria), renderer WebGL, elaborazione audio |
| Font | 5 | Alta | Font di sistema disponibili (69 famiglie testate), preferenze font, rendering MathML |
| Piattaforma | 25 | Media | User-Agent, proprietà del navigator, fuso orario, lingua, vendor |
| Motore CSS | 10 | Media | Risposte alle media query (schema di colore, HDR, movimento ridotto, forced colors) |
| Storage | 10 | Media | Supporto cookie, localStorage, sessionStorage, quota di storage |
| WebGL | 9 | Alta | Vendor GPU, renderer (unmasked), precisione shader, supporto estensioni |
| Rete | 3 | Bassa | RTT della connessione, TURN probe, versione app |
| Indicatori bot | 15 | N/D | Flag webdriver, framework di automazione, lunghezza di eval, marcatori headless |
| Personalizzati | 14 | Variabile | Fingerprint matematico, funzionalità WASM, rilevamento dell'architettura |
Non tutti i segnali sono ugualmente utili all'identificazione. I segnali sono classificati per stabilità:
Tier 1 (Frozen): segnali hardware e di rendering che quasi non cambiano mai. Fingerprint del canvas, renderer WebGL, fingerprint audio, parametri GPU, enumerazione dei font, operazioni matematiche, byte di architettura.
Tier 2 (Semi-stabile): segnali che cambiano con gli aggiornamenti del browser o le modifiche di configurazione. User-Agent, Client Hints, plugin, media query CSS, capacità di storage.
Tier 3 (Volatile): segnali che cambiano di frequente. Risoluzione schermo (cambio di monitor), fuso orario (viaggi), preferenze di lingua, proprietà della connessione.
L'ID visitatore viene calcolato usando un sistema di hashing a tre livelli che bilancia stabilità ed estensibilità:
Visitor ID = [Tier1Hash][Tier2Hash][Tier3Hash] 20 chars 10 chars 10 chars ──────── ──────── ──────── base62 base62 base62Il Tier 1 usa solo segnali frozen intrinseci all'hardware e al motore di rendering. Questi segnali cambiano solo quando l'utente passa a un dispositivo fisico diverso o apporta modifiche hardware significative.
Segnali inclusi: hash del fingerprint del canvas, renderer WebGL (unmasked), vendor WebGL (unmasked), fingerprint audio, hash dell'enumerazione dei font, hash dei parametri WebGL, hash delle operazioni matematiche, byte di architettura (ARM vs x86).
Algoritmo:
key1=value1|key2=value2|... (chiavi ordinate alfabeticamente)Il Tier 1 è intenzionalmente frozen. Non vengono mai aggiunti nuovi segnali al Tier 1, così che il nucleo di identità rimanga stabile tra gli aggiornamenti del server.
Il Tier 2 cattura l'ambiente del browser e del sistema operativo. Questi segnali cambiano quando l'utente aggiorna il browser, installa estensioni o modifica le impostazioni di sistema.
Segnali inclusi: dati User-Agent, Client Hints (brand, piattaforma, architettura), proprietà del navigator (vendor, piattaforma, lingue), elenco dei plugin, profondità di colore dello schermo, memoria del dispositivo, concorrenza hardware.
Il Tier 3 cattura segnali volatili che possono cambiare tra una sessione e l'altra. Sono usati per il calcolo del punteggio di confidenza e per il fuzzy matching, ma non incidono sul nucleo di identità.
Segnali inclusi: risoluzione schermo, fuso orario, lingua, DOM blocker, capacità di storage, risposte alle media query CSS, proprietà della connessione.
Ogni livello viene sottoposto a hash con MurmurHash3-x64-128, una funzione di hash veloce e non crittografica che produce un output a 128 bit. L'algoritmo:
MurmurHash3 offre una distribuzione eccellente (ogni bit dell'input influenza ogni bit dell'output) ed è abbastanza veloce per il calcolo in tempo reale. Non è crittograficamente sicuro, ma ciò non è richiesto per l'hashing dei fingerprint.
Input: "canvas=abc123|webgl_renderer=ANGLE|audio=0.04852" ↓ MurmurHash3-x64-128Output: 0x7f4a8c2d1e3b5f6a 0x9d8c7b6a5e4f3d2c ↓ base62 encodeResult: "X7fh2Hg9LkMn3pQr5tBv"Il punteggio di confidenza (da 0.0 a 1.0) rappresenta quanto il sistema è certo dell'identificazione del visitatore:
Quando il cookie _vid_t corrisponde a un visitatore noto, la confidenza è impostata a 1.0. Il cookie contiene lo UID del visitatore, che il server convalida rispetto ai propri record. È il percorso di identificazione più rapido e affidabile.
I nuovi visitatori senza record precedenti ricevono un punteggio di confidenza di 0.90. Non c'è alcun rischio di corrispondenza errata, poiché non esistono record da confrontare.
Per i visitatori di ritorno senza cookie match, il sistema calcola la confidenza a partire da:
Ponderazione per frequenza dei segnali (IDF): i segnali più unici nella popolazione globale ricevono un peso maggiore. Un renderer WebGL raro è più identificante di una comune risoluzione schermo.
Fuzzy matching: il sistema confronta il fingerprint corrente con i fingerprint memorizzati usando la distanza di Hamming a livello di bit. I segnali sono raggruppati per livello e il punteggio di corrispondenza di ciascun livello è ponderato in modo indipendente.
Coerenza storica: se i segnali di un visitatore sono rimasti stabili attraverso più visite, la confidenza aumenta. Se i segnali fluttuano di frequente, la confidenza diminuisce.
| Scenario | Punteggio tipico | Spiegazione |
|---|---|---|
| Cookie match | 1.000 | UID del cookie _vid_t verificato lato server |
| Prima visita | 0.900 | Nessun record precedente da confrontare |
| Corrispondenza forte del fingerprint | 0.990-0.999 | Tutti i segnali Tier 1 corrispondono, la maggior parte dei Tier 2 corrisponde |
| Corrispondenza parziale (aggiornamento browser) | 0.950-0.989 | Il Tier 1 corrisponde, il Tier 2 è cambiato (nuovo UA) |
| Corrispondenza debole (modifiche significative) | 0.850-0.949 | Alcuni segnali Tier 1 sono cambiati |
| Ambigua | 0.500-0.849 | Più corrispondenze possibili nel database |
TRACIO usa un cookie first-party (_vid_t) per mantenere l'identità del visitatore tra le sessioni:
_vid_tSameSite=Lax e Secure su HTTPS (non HttpOnly — l'agent lo legge lato client)Il cookie viene emesso sia lato server (tramite l'header di risposta Set-Cookie) sia lato client dall'agent, e lo UID viene inoltre replicato in localStorage come fallback quando i cookie sono bloccati.
Il server tenta di impostare il cookie su ambiti di dominio progressivamente più ampi:
app.example.com → example.com → comViene usato il dominio più ampio su cui il cookie viene impostato con successo. Ciò garantisce che il cookie persista attraverso i sottodomini.
TRACIO può identificare la stessa persona su browser diversi dello stesso dispositivo quando i segnali di Tier 1 producono hash corrispondenti. Poiché il Tier 1 si basa su caratteristiche hardware e di rendering (canvas, WebGL, audio, font), questi segnali sono spesso identici tra i browser basati su Chromium sulla stessa macchina e si degradano tra i motori (Chromium vs Firefox vs Safari). Non ci si aspetta la corrispondenza tra un visitatore desktop e uno mobile — le superfici hardware e di rendering sono diverse.
La corrispondenza cross-browser è per sua natura un'operazione a confidenza inferiore ed è trattata come tale nel calcolo del punteggio.