User-Agent explicat: De la șiruri de UA și amprente ale browserului până la Client Hints

Deschide panoul de rețea în uneltele de dezvoltare ale browserului tău și aproape întotdeauna vei găsi un User-Agent antet. Pare o scurtă introducere: care browser face cererea, pe ce sistem de operare rulează și ce versiune pretinde că are.

Asta face tentant să tratezi antetul ca pe un ID de dispozitiv — sau să presupui că schimbarea unei linii poate transforma un browser într-un alt dispozitiv. Ambele idei sunt doar parțial corecte.

Un șir User-Agent, sau UA, este informația de compatibilitate declarată de client. Nu este o acreditare de identitate de încredere, iar clientul o poate modifica. Totuși, nu există izolat. Un site poate compara UA cu Client Hints, API-urile JavaScript, proprietățile ecranului, fonturile, Canvas, WebGL, contextul rețelei și comportamentul. Întrebarea utilă nu este, așadar, doar dacă un UA poate fi modificat, ci și ce rol joacă acesta în suprafața completă observabilă a browserului.

Acest articol folosește standardele HTTP și cercetarea amprentelor browserului pentru a răspunde la patru întrebări:

1. De ce arată un șir de UA ca o lucrare de arheologie a browserului?
2. Câtă informație identificantă poate UA aduce și cum ar trebui să interpretăm cercetarea?
3. De ce schimbarea doar a UA poate crea o inconsistență mai evidentă?
4. Ce au schimbat UA Reduction și User-Agent Client Hints de fapt?

În acest articol, UA se referă în principal la antetul cererilor HTTP User-Agent. De asemenea, discutăm despre navigator.userAgent și navigator.userAgentData în JavaScript. Aceste interfețe sunt legate, dar nu identice permanent în fiecare browser și context.

1. Ce este un User-Agent?

Secțiunea 10.1.5 din RFC 9110 definește User-Agent ca un câmp care conține informații despre agentul utilizator care a generat cererea. Gramatica sa simplificată este:

User-Agent = product *( RWS ( product / comment ) )
product    = token [ "/" product-version ]

În limbaj simplu, șirul începe cu un nume de produs și poate include o versiune. Pot urma mai multe produse sau comentarii. Standardul recunoaște utilizări precum soluții de interoperabilitate, diagnostice și analize, dar recomandă și implementărilor să nu dezvăluie detalii inutile: o UA mai lungă și mai specifică crește atât dimensiunea cererii, cât și riscul de amprentare.

Un Chromium desktop modern UA ar putea arăta astfel:

Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36

Împărțirea șirului în spații dezvăluie mai multe nume care par să nu aibă legătură cu Chrome:

Token	Ce înseamnă, în general, astăzi	O interpretare greșită frecventă
Mozilla/5.0	Un token istoric de compatibilitate	Browserul trebuie să fie Firefox sau un produs Mozilla
Windows NT 10.0	O categorie Windows platformă; un UA redus nu poate distinge în mod fiabil Windows 10 de 11	Calculatorul trebuie să ruleze Windows 10
Win64; x64	Un indiciu că acesta este Windows pe 64 de biți pe o arhitectură x86-64	Dovedește exact modelul fizic al procesorului
AppleWebKit/537.36	O linie de succesiune a motorului și un token de compatibilitate	Chrome folosește încă implementarea completă a Safari
KHTML, like Gecko	Limbaj de compatibilitate istorică	Atât KHTML, cât și Gecko rulează
Chrome/145.0.0.0	Familia Chrome/Chromium și versiunea majoră; Componentele versiunilor inferioare pot fi reduse	Dezvăluie versiunea exactă a patch-ului
Safari/537.36	Un token păstrat pentru compatibilitate cu site-urile mai vechi	Browserul trebuie să fie Safari

UA a devenit vorbăreț deoarece site-urile timpurii se ramificau adesea după nume de browsere. Browserele noi trebuiau să pretindă compatibilitate cu produse mai vechi pentru a primi pagina corectă. Aceste declarații s-au acumulat în timp, creând o evidență istorică care nu poate fi citită literal.

Prima regulă a analizării UA este simplă: este un protocol de compatibilitate, nu o descriere strictă a dispozitivului.

2. De ce folosesc site-urile web încă UA?

UA nu este folosit doar pentru urmărire. Utilizările legitime includ:

• servind ca rezervă pentru un browser mai vechi cu o problemă cunoscută de compatibilitate;
• selectarea unui format de instalator sau descărcare adecvat;
• găsirea defecțiunilor specifice versiunilor în jurnalele de diagnostic;
• măsurarea distribuțiilor largi de familii de browsere, platforme și versiuni majore;
• identificarea combinațiilor imposibile în traficul automatizat sau malițios.

Problema începe când UA sniffing trece de la o soluție de compatibilitate restrânsă la capacitatea de a ghici după numele produsului. Codul poate vedea Chrome și poate presupune că există un anumit API. Această presupunere poate eșua într-un WebView integrat, într-un browser derivat din Chromium, într-un browser cu o politică de întreprindere, într-un UA blocat sau într-un client care și-a schimbat antetul.

O ordine mai robustă a operațiilor este:

1. Testează API-ul sau comportamentul necesar ori de câte ori detectarea capabilităților este posibilă.
2. Când identificarea browserului este inevitabilă, folosește un parser întreținut în locul unei expresii regulate ad-hoc.
3. Depozitează doar categoriile grosiere de care produsul chiar are nevoie.
4. Oferă o soluție de rezervă pentru mărci necunoscute, versiuni necunoscute și câmpuri lipsă.

3. Este UA amprentă a browserului?

Mai precis, UA este o singură intrare la amprenta browserului, nu de obicei amprenta completă.

Amprentarea browserului nu necesită un număr de serie secret. Măsoară o colecție de atribute relativ stabile, distinctive, expuse de browser. UA oferă indicii despre familia browserelor, versiunea și platforma. Dimensiunile ecranului, fonturile, fusul orar, Canvas, WebGL, AudioContext și alte interfețe adaugă informații suplimentare.

Sondajul realizat de Laperdrix și colegii săi, Browser Fingerprinting: A Survey, discută aceste tehnici ca o formă de recunoaștere fără stat. Un site nu trebuie neapărat să scrie mai întâi un Cookie; Poate încerca să asocieze vizitele de atributele expuse de un browser. "Fără stare" nu înseamnă că serverul nu stochează nimic. Aceasta înseamnă că materialul de recunoaștere nu depinde de un identificator persistent pe partea clientului.

1. Ce înseamnă rezultatul de 10 biți al hârtiei?

În studiul Panopticlick din 2010 How Unique Is Your Web Browser?, Peter Eckersley a analizat aproximativ 470.000 de amprente ale browserelor. Ziarul a raportat că:

• amprenta completă purta în medie aproximativ 18,1 biți de informații de identificare în acea probă;
• Spus intuitiv, o amprentă medie a apărut aproximativ o dată în 286.777 de browsere;
• tabelul raporta aproximativ 10,0 biți de informație medie doar pentru șirul UA;
• dintre browserele cu Flash sau Java activat, 94,2% dintre amprentele complete erau unice.

Auto-informația este de obicei scrisă astfel:

I(x) = -log₂ P(x)

Dacă un anumit UA apare cu probabilitate 1/1024 într-o populație, observarea ei oferă 10 biți de informație. Aceasta nu înseamnă că UA are exact 1.024 de valori posibile sau că identifică în mod unic o persoană. Descrie câtă incertitudine elimină, în medie, observația.

2. De ce rezultatul din 2010 nu este o constantă pentru web-ul de astăzi?

Rezultatul rămâne important, dar are nevoie de cel puțin trei calificări:

• vizitatorii unei pagini de testare a confidențialității nu erau un eșantion aleatoriu al tuturor utilizatorilor de internet;
• Diversitatea browserelor, pluginurilor și versiunilor UA în 2010 diferă mult de ecosistemul actual;
• UA Reduction, suprafețele de plugin care se micșorează și protecțiile anti-amprentă au schimbat distribuția atributelor observabile.

Studiul susține afirmația că UA și alte atribute pot contribui cu informații distinctive măsurabile. Nu susține afirmația că un UA are întotdeauna exact 10 biți de entropie astăzi. Puterea de amprentare depinde de populație, fereastra de timp, politicile browserului și combinația semnalelor.

4. De ce schimbarea doar UA se poate întoarce împotriva lor?

UA este o declarație a clientului fără dovadă criptografică. Un server nu poate citi adevărul din fabrică al unui dispozitiv din acest antet. Totuși, poate verifica dacă observațiile diferite sunt rezonabil compatibile.

Să presupunem că un UA pretinde că este un browser mobil, dar pagina nu observă niciun punct de contact, o fereastră care seamănă constant cu un ecran desktop și Client Hints care raportează o platformă desktop. Orice observație poate avea o excepție legitimă. Mai multe contradicții stabile împreună pot forma totuși un tipar clasificabil.

Lucrarea Panopticlick documenta deja cazuri comparabile: unele browsere pretindeau că sunt iPhone în timp ce suportau Flash, iar unele Firefox UA au apărut împreună cu funcții de stocare disponibile doar în Internet Explorer. Studiul [FP-Scanner] din 2018(https://www.usenix.org/conference/usenixsecurity18/presentation/vastel) a examinat această problemă sistematic. Unele extensii anti-amprentă și unelte de falsificare au introdus inconsistențe între interfețe, permițând unui detector să identifice atribute modificate și, în unele cazuri, să deducă browserul original sau familia sistemului de operare.

Nu orice inconsecvență este răutăcioasă. Desktop-urile la distanță, instrumentele de accesibilitate, politicile enterprise, straturile de compatibilitate și hardware-ul neobișnuit pot crea toate combinații neobișnuite. Un sistem atent de risc ar trebui să trateze o inconsistență ca dovadă probabilistică, nu ca pe un motiv automat pentru a bloca un utilizator.

Pentru gestionarea profilurilor browserului, contează trei proprietăți:

• Consistență internă: UA, Client Hints, platformă, arhitectură, tactile și semnalele de ecran nu ar trebui să se contrazică direct.
• Stabilitate în timp: Un profil de lungă durată nu ar trebui să se schimbe dramatic la fiecare lansare fără un motiv.
• Diversitatea plauzibilă: Profilurile pot diferi, dar combinațiile rare generate mecanic nu sunt neapărat mai sigure.

Studiul FP-STALKER a arătat, de asemenea, că schimbarea atributelor nu împiedică automat legătura. Un model poate folosi atribute stabile și modificări plauzibile ale versiunii pentru a conecta amprente anterioare și ulterioare.

5. Ce problemă abordează UA Reduction?

Un UA tradițional este trimis aproape la fiecare cerere. Orice endpoint de primă parte sau terță parte care primește cererea o poate citi pasiv. Cu cât șirul este mai precis, cu atât fiecare destinatar obține în mod implicit mai multe informații distinctive.

Planul User-Agent Reduction al lui Chromium reduce această granularitate implicită:

• începând cu Chrome 101, versiunile desktop minor, build și patch au fost reduse la 0.0.0;
• fazele ulterioare versiuni unificate ale sistemului de operare desktop, detalii CPU și informații Android dispozitive;
• Un Android UA redus folosește valori fixe de platformă și model precum Android 10; K;
• Site-urile care chiar necesită mai multe detalii pot solicita User-Agent Client Hints.

Formatul redus poate fi rezumat astfel:

Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36

Reducerea scade suprafața pasivă de amprentare a UA moștenită. Nu elimină amprentarea browserului. Versiunea majoră, platforma largă și starea mobilă pot rămâne vizibile, în timp ce alte API-uri, proprietăți de rețea și comportament pot oferi în continuare informații.

6. Cum funcționează User-Agent Client Hints?

Mecanismul general este definit în RFC 8942, în timp ce WICG User-Agent Client Hints draft descrie domenii specifice UA. Abordarea împarte informațiile care odinioară au existat într-un șir nestructurat în câmpuri structurate, distingând indiciile cu entropie scăzută care pot fi trimise implicit de indiciile cu entropie ridicată pe care site-ul le solicită în mod normal explicit.

O cerere inițială simplificată poate arăta astfel:

GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"

Dacă serverul are cu adevărat nevoie de arhitectură și bitness pentru a selecta un instalator, poate răspunde cu:

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness

Când browserul suportă mecanismul și cerințele de securitate și politici sunt îndeplinite, o cerere ulterioară poate include:

Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"

UA Client Hints comune includ:

Câmp	Scop tipic	Nivel informațional
Sec-CH-UA	Listă de marcă și versiuni majore	De obicei entropie mică
Sec-CH-UA-Mobile	Dacă clientul preferă o experiență mobilă	De obicei entropie mică
Sec-CH-UA-Platform	Categorie largă de platforme	De obicei entropie mică
Sec-CH-UA-Arch	Arhitectura CPU	Entropie ridicată; cerere când este nevoie
Sec-CH-UA-Bitness	Bitness-ul arhitecturii	Entropie ridicată; cerere când este nevoie
Sec-CH-UA-Platform-Version	Versiunea platformei	Entropie ridicată; cerere când este nevoie
Sec-CH-UA-Full-Version-List	Versiuni complete pentru mărcile raportate	Entropie ridicată; cerere când este nevoie
Sec-CH-UA-Model	Model de dispozitiv	Entropie ridicată; cerere când este nevoie

Trei detalii inginerești sunt ușor de trecut cu vederea.

1. Client Hints nu sunt toate trimise automat

Indiciile cu entropie scăzută pot apărea implicit. Indiciile cu entropie ridicată necesită de obicei un răspuns Accept-CH. Navigarea inițială, subresursele, politica de permisiuni, transportul securizat și suportul browserului pot influența toate ce ajunge. Un server trebuie să lase absența tuturor câmpurilor opționale.

2. Lista de mărci testează în mod deliberat robustețea parzorului.

Sec-CH-UA poate conține mai multe mărci și o marcă sintetică folosită pentru testarea compatibilității. Codul nu trebuie să presupună că prima intrare este întotdeauna numele produsului și nu trebuie să eșueze când apare o marcă necunoscută. Analizează câmpul structurat, ignoră intrările pe care nu le recunoști și lasă loc pentru viitoarele branduri.

3. Răspunsurile care variază la indicii necesită gestionarea corectă a cache-ului

Dacă arhitectura, platforma sau un alt indiciu schimbă răspunsul, configurează corect Vary sau o strategie echivalentă de cheie cache. În caz contrar, un cache partajat poate servi conținut generat pentru o clasă de dispozitiv către alta.

7. Sunt Client Hints mai private decât UA tradiționale?

Ele îmbunătățesc modul în care informațiile sunt expuse, dar nu oferă imunitate împotriva amprentelor.

UA tradițional dezvăluie un pachet mare nestructurat pasiv și implicit. Client Hints împărți acel pachet în câmpuri, fac cererile pentru informații cu entropie mai mare mai explicite și oferă browserului oportunitatea de a aplica controale privind politicile, permisiunile sau bugetul de confidențialitate.

Totuși, arhitectura, versiunile complete, versiunile de platformă și modelele dispozitivelor pot crește în continuare diferențiabilitatea. RFC 8942 tratează explicit confidențialitatea și performanța ca constrângeri de proiectare. Dezvoltatorii ar trebui să întrebe:

• Această funcție necesită cu adevărat acest domeniu?
• Poate detectarea capabilităților sau o alegere a utilizatorului să o înlocuiască?
• Poate aplicația stoca doar o categorie grosieră?
• Cât timp sunt păstrate valorile brute și cine le poate accesa?
• Vor primi resursele terțe aceleași indicii?

8. Ghiduri inginerești pentru manipularea UA pe partea de server

1. Nu folosiți niciodată UA ca dovadă a identității sau autorității

UA poate susține opțiuni de prezentare și opțiuni de compatibilitate. Nu ar trebui să determine identitatea, autorizarea, trustul de plată sau o limită de securitate. O valoare controlată de client nu poate servi drept acreditare de control al accesului.

2. Preferă detectarea capabilităților în locul listelor de browser

Când un front-end are nevoie de un API, testează direct acea capabilitate:

if ('share' in navigator) {
  // Offer the system share feature.
} else {
  // Fall back to copying a link.
}

Detecția capabilităților gestionează browserele derivate, funcționalitățile experimentale, politicile enterprise și versiunile viitoare mai bine decât o regulă precum "activează acest lucru pentru Chrome 145."

3. Acceptarea UA, Client Hints și state necunoscute moștenite

În timpul migrării, un server poate primi doar UA vechi, atât UA, cât și Client Hints, sau forme foarte reduse ale ambelor. Modelul de date ar trebui să permită unknown, în loc să ghicească, un model exact de sistem de operare sau dispozitiv pentru a umple fiecare câmp.

4. Reducerea granularității logaritmică

Dacă analiza are nevoie doar de desktop versus mobil, familie de browser și versiune majoră, nu păstrați șiruri brute de UA și fiecare indiciu cu entropie ridicată la nesfârșit. Minimizarea datelor reduce riscul de confidențialitate și împiedică ca o rețea de analiză să trateze variațiile minore ca o dimensiune semnificativă.

5. Tratarea anomaliilor ca probe, nu ca verdicte

Un UA care susține Windows în timp ce un API se comportă diferit este, în cel mai bun caz, un singur semnal de risc. Mediile enterprise, virtualizarea, sesiunile la distanță, straturile de compatibilitate și tehnologiile asistive pot genera anomalii legitime. Transformarea unei nepotriviri într-o decizie automată de fraudă creează rezultate false pozitive.

9. Cum ar trebui UA configurat în medii multi-profil?

Pentru testarea interregională, previzualizări publicitare, operațiuni ale contului și izolarea confidențialității, scopul nu ar trebui să fie crearea celor mai neobișnuite UA. Un profil trebuie să fie explicabil, stabil și compatibil cu mediul înconjurător.

Revizuiți următoarele în ordine:

1. Versiunea browser: versiunea UA majoră ar trebui să fie plauzibilă pentru motorul propriu-zis și capabilitățile sale.
2. Sistem de operare: Platforma UA, Client Hints platformă și categoria JavaScript-vizibilă a platformei ar trebui să fie compatibile.
3. Arhitectură și bitness: UA, Client Hints și mediul executabil nu ar trebui să facă afirmații direct contradictorii.
4. Factorul de formă al dispozitivului: O declarație mobilă ar trebui să aibă sens alături de suportul tactil, viewport, raport de pixeli și tiparele de interacțiune.
5. Context regional: limba, fusul orar, geolocalizarea și ieșirea proxy-ului nu trebuie să corespundă mecanic, dar ar trebui să aibă sens pentru fluxul real de lucru.
6. Stabilitatea profilului: Când un cont sau identitate de test reutilizează un profil de lungă durată, evitați să schimbați platforma și versiunea majoră fără un motiv.

Conversia profilului curentă a PurpleMark mapează sistemul de operare selectat pe o platformă UA și încearcă mai întâi să extragă versiunea browserului dintr-un token Chrome/ sau CriOS/ configurat. Când nu există o versiune utilizabilă, aceasta derivă o rezervă rezonabilă față de versiunea principală a motorului actual. Scopul nu este de a falsifica un șir izolat, ci de a plasa UA configurație într-un model coerent de profil de browser.

Izolarea profilurilor și consistența parametrilor pot reduce corelațiile tehnice și biasul de testare. Nu pot garanta că conturile nu vor fi niciodată legate și nu înlocuiesc regulile platformei, datele conturilor, informațiile despre plăți sau practicile operaționale responsabile. Folosește aceste capabilități doar pentru protecția confidențialității legale, testare legală și activități de afaceri conforme.

10. Întrebări frecvente

Întrebarea 1: Schimbarea UA transformă browserul într-un alt browser?

Nu. Schimbă o parte din ceea ce declară clientul. Nu înlocuiește motorul JavaScript, pipeline-ul de randare, stiva de rețea sau API-urile web suportate.

Întrebarea 2: Poate un site web să citească "adevărata UA"?

Nu există un "UA real universal la nivel hardware, pe care orice site web îl poate citi cu ocolirea browserului. Totuși, un site poate compara Client Hints, teste de capacitate și alte semnale de amprentă, poate găsi afirmații incompatibile și poate face o inferență probabilistică.

Întrebarea 3: Poate un UA redus să distingă Windows 10 de Windows 11?

Moștenirea redusă UA în mod normal nu poate face acest lucru în mod fiabil deoarece ambele pot raporta Windows NT 10.0. Un browser care suportă UA Client Hints poate oferi informații mai detaliate despre versiunea platformei după ce site-ul le solicită. Serverele trebuie să gestioneze în continuare câmpurile lipsă și diferențele de mapare.

Întrebarea 4: Dezactivarea JavaScript oprește UA expunere?

Nu complet. HTTP User-Agent este un antet de cerere și poate fi trimis împreună cu cererea de pagină înainte ca pagina JavaScript să fie rulată. Dezactivarea JavaScript elimină unele suprafețe de colectare, dar întrerupe și părți substanțiale ale web-ului modern.

Întrebarea 5: Va Client Hints înlocui complet User-Agent?

Nu presupune asta pe termen scurt. Mulți clienți și servere încă depind de UA vechi, în timp ce suportul UA Client Hints variază. Tratați Client Hints ca pe o îmbunătățire progresivă: preferați informații structurate când sunt disponibile, dar păstrați rezerve pentru stările UA vechi și necunoscute.

Întrebarea 6: Un UA generat aleatoriu îmbunătățește anonimatul?

Nu neapărat. Randomizarea unui câmp poate crea contradicții cu semnalele de versiune, platformă, tact și randare. Pentru un profil de lungă durată, o configurație comună, stabilă și intern compatibilă este de obicei mai ușor de apărat decât schimbările aleatorii frecvente.

11. Concluzie

User-Agent nu este nici o acreditare de identitate de încredere, nici un șir irelevant. Se află la intersecția compatibilității web, confidențialității și analizei riscurilor. Pentru dezvoltatori, este o intrare de compatibilitate împovărată de istorie. Pentru cercetătorii în amprente, este un atribut cu informații statistice măsurabile. Pentru furnizorii de browsere, este o suprafață de expunere implicită care trebuie redusă.

Ideile cheie se încadrează în trei afirmații:

• Nu citi un UA literal; Conține multe jetoane istorice de compatibilitate.
• Nu evaluați UA izolat; Recunoașterea practică vine din combinațiile de semnale și evoluția lor de-a lungul timpului.
• Nu te gândi la Client Hints doar ca la "mai UA domenii"; valoarea lor constă în dezvăluirea structurată, orientată de cereri și guvernabilă.

Când un sistem trece de la identificarea numelui unui browser la testarea capabilității de care are nevoie — și de la colectarea fiecărui detaliu disponibil la solicitarea doar a ceea ce este necesar — UA revine la rolul său propriu: un indiciu de compatibilitate, nu un adevăr de identitate.

Referințe și standarde

1. Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
2. Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
3. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
4. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
5. IETF. RFC 9110: HTTP Semantics, 2022.
6. IETF. RFC 8942: HTTP Client Hints, 2021.
7. WICG. User-Agent Client Hints, Draft Community Group Report.
8. Chromium. User-Agent Reduction.
9. Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.