Cum funcționează urmărirea amprentei digitale în profunzime

Fiecare dispozitiv care se conectează la internet lasă în urmă o dâră de artefacte tehnice — o amprentă digitală. La tracio.ai, reconstruim această amprentă din peste 300 de semnale pasive colectate în timpul unei singure încărcări de pagină, fără ca identificarea să depindă de cookie-uri sau de vreo altă formă de stocare persistentă pe partea de client. Acest articol explică exact cum funcționează acest proces.

Stratul de colectare a semnalelor

Când agentul nostru JavaScript se încarcă în browserul unui vizitator, începe să colecteze semnale din mai multe categorii simultan. Randarea canvas, interogările parametrilor WebGL, procesarea AudioContext, enumerarea fonturilor și citirea proprietăților navigatorului rulează toate în paralel, fiecare fiind limitată de propriul timeout, astfel încât o sondă lentă să nu le țină pe loc pe celelalte. Cât durează întreaga trecere depinde de dispozitivul vizitatorului, iar cifrele de mai jos sunt cele pe care le măsurăm pe al nostru.

Ideea-cheie este că fiecare semnal captează un aspect diferit al stivei hardware și software a dispozitivului. Randarea canvas reflectă GPU-ul, driverul și motorul de randare a fonturilor. Parametrii WebGL expun modelul plăcii grafice și capabilitățile acesteia. AudioContext dezvăluie diferențe în modul în care DSP-ul audio procesează operațiile în virgulă mobilă. Proprietățile navigatorului raportează numărul de nuclee CPU, memoria, platforma și setările de limbă.

Echipa noastră a măsurat acest lucru pe 2 miliarde de evenimente luna trecută: timpul median de colectare a fost de 38 ms, iar percentila 99 a fost de 52 ms. De fapt, am încercat mai întâi abordarea naivă — colectarea semnalelor secvențial. A fost de 40 de ori mai lentă. Colectarea în paralel cu o barieră de timeout a fost una dintre primele decizii arhitecturale pe care le-am luat corect.

Amprentarea TLS: primul strat

Înainte ca JavaScript-ul nostru să se execute măcar, browserul a dezvăluit deja informații semnificative prin handshake-ul TLS. Mesajul Client Hello conține suitele de cifruri pe care browserul le suportă, extensiile TLS pe care le folosește, curbele eliptice pe care le preferă și algoritmii de semnătură pe care îi acceptă. Aceste informații sunt determinate de biblioteca TLS a browserului și variază semnificativ între familiile de browsere, versiuni și sisteme de operare.

Capturăm această amprentă TLS folosind hashing-ul JA4 — un înlocuitor modern al JA3 care oferă o granularitate mai bună și o stabilitate mai mare între versiuni. Hash-ul JA4 în sine poate distinge Chrome de Firefox de Safari și adesea restrânge identificarea la un anumit interval de versiuni de browser. Combinat cu semnalele noastre de pe partea de client, oferă un strat de validare încrucișată extrem de greu de falsificat.

Amprentarea Canvas și GPU

Amprentarea canvas exploatează faptul că GPU-uri diferite randează aceleași instrucțiuni de desenare cu diferențe subtile la nivel de pixel. Canvas API ne permite să desenăm o scenă atent proiectată — anumite șiruri de text în mai multe fonturi, forme geometrice cu coordonate specifice și gradienți cu opriri de culoare precise — apoi să calculăm un hash al datelor de pixeli rezultate.

Diferențele de randare provin din variații ale algoritmilor de anti-aliasing, randarea la nivel de sub-pixel, amestecarea culorilor și hinting-ul fonturilor între modelele de GPU și versiunile de driver. Chiar și două dispozitive cu același model de GPU pot produce ieșiri canvas diferite dacă rulează versiuni de driver sau sisteme de operare diferite. Acest lucru face ca hash-ul canvas să fie unul dintre cele mai distinctive semnale ale noastre.

Profilarea hardware prin WebGL

WebGL API expune informații detaliate despre subsistemul grafic, care merg mult dincolo de șirurile de renderer și vendor. Interogăm dimensiunile maxime de textură, formatele de precizie a shaderelor, extensiile suportate, dimensiunile viewport-ului și zeci de alți parametri care variază între modelele de GPU și configurațiile de driver.

Combinația acestor parametri creează un profil hardware detaliat. Un dispozitiv cu un NVIDIA RTX 4070, de exemplu, va raporta dimensiuni maxime de textură diferite, precizie a shaderelor diferită și suport pentru extensii diferit față de un dispozitiv cu un AMD RX 7800 XT. Acest profil hardware este inerent stabil — nu se schimbă odată cu actualizările de browser, ci doar cu schimbări de hardware sau de driver.

Amprentarea prin procesarea audio

Web Audio API oferă o altă sursă de semnal dependentă de hardware. Creăm un nod oscilator, îl conectăm la un compresor de dinamică și măsurăm buffer-ul de ieșire. Diferențele în precizia virgulei mobile, în implementarea DSP și în algoritmii de reeșantionare între hardware-ul audio și sistemele de operare produc variații măsurabile în ieșire.

Amprentele audio au o unicitate moderată, dar o stabilitate excepțională. Fluxul de procesare audio se schimbă rareori, cu excepția cazului în care utilizatorul schimbă hardware-ul audio sau reinstalează sistemul de operare. Acest lucru face ca semnalele audio să fie ancore valoroase în sistemul nostru de identificare pe mai multe niveluri.

Fuziunea semnalelor și rezolvarea identității

Semnalele brute sunt criptate și transmise către serverul nostru, unde motorul de identificare a dispozitivelor le procesează printr-un sistem de hashing pe trei niveluri. Semnalele la nivel de hardware (canvas, WebGL, audio) formează Nivelul 1 — nucleul stabil al identității. Semnalele la nivel de browser (detectarea funcționalităților, proprietăți CSS, capabilități media) formează Nivelul 2, procesate prin potrivire între sesiuni pentru a gestiona derivele așteptate de la actualizările de browser. Semnalele volatile (user agent, fus orar, limbă) formează Nivelul 3, contribuind la scorarea încrederii fără a determina deciziile de identitate.

Algoritmul de fuziune cântărește fiecare semnal în funcție de unicitatea și stabilitatea sa. O potrivire pe un hash canvas rar are o pondere mult mai mare decât o potrivire pe o rezoluție de ecran comună. Această abordare ponderată asigură că identificarea rămâne exactă chiar și atunci când o parte din semnale se schimbă.

Ce stocăm și de ce identificarea nu depinde de asta

Un principiu de proiectare esențial al sistemului nostru este că identificarea nu depinde de stocarea pe partea de client. ID-ul vizitatorului este derivat din caracteristicile inerente ale dispozitivului — hardware-ul, stiva software, configurația de rețea — și tocmai de aceea identificarea supraviețuiește ștergerii cookie-urilor, modului incognito și chiar reinstalării browserului.

Este o afirmație despre dependență, nu despre abstinență, iar diferența merită spusă răspicat. Setăm, într-adevăr, un cookie first-party, _vid_t, care păstrează un identificator opac cu o valabilitate de 365 de zile, iar aceeași valoare o oglindim în localStorage. Ce nu facem: nu setăm cookie-uri terțe, nu scriem nimic care să funcționeze între site-uri și nu citim istoricul de navigare, datele din formulare sau IndexedDB. Cookie-ul există fiindcă e cel mai ieftin răspuns posibil la întrebarea „am mai văzut acest browser?” — când supraviețuiește, potrivirea este imediată și sigură. Când nu supraviețuiește, nu se rupe nimic: semnalele dispozitivului reconstruiesc identificatorul singure, cu o încredere puțin mai mică. Un vizitator care șterge tot este în continuare recunoscut; un sistem clădit doar pe stocare l-ar fi pierdut.

Confidențialitate prin arhitectură

Deoarece colectăm doar atribute tehnice ale browserului — fără istoric de navigare, fără date din formulare, fără conținut personal — impactul asupra confidențialității este minim. Ghidul W3C privind amprentarea prezintă bune practici pentru utilizarea responsabilă a semnalelor de browser, iar arhitectura noastră se aliniază cu aceste principii. Procesarea are loc în cloud-ul nostru gestionat, cu rezidența datelor în UE (Frankfurt). Această arhitectură face ca respectarea GDPR, CCPA și a altor reglementări privind confidențialitatea să fie simplă.