User-Agent Uitgelegd: Van UA strings en browservingerafdrukken tot Client Hints

Open het Netwerkpaneel in de ontwikkelaarstools van je browser en je vindt bijna altijd een User-Agent header. Het lijkt een korte introductie: welke browser doet het verzoek, op welk besturingssysteem draait het, en welke versie het beweert te zijn.

Dat maakt het verleidelijk om de header als een apparaat-ID te behandelen—of aan te nemen dat het veranderen van één regel een browser in een ander apparaat kan veranderen. Beide ideeën zijn slechts gedeeltelijk correct.

Een User-Agent string, of UA, is compatibiliteitsinformatie die door de client wordt opgegeven. Het is geen vertrouwd identiteitsbewijs, en een klant kan het aanpassen. Toch bestaat het niet geïsoleerd. Een site kan de UA vergelijken met Client Hints, JavaScript API's, schermeigenschappen, lettertypen, Canvas, WebGL, netwerkcontext en gedrag. De nuttige vraag is dus niet alleen of een UA kan worden veranderd, maar welke rol het speelt in het volledige waarneembare oppervlak van de browser.

Dit artikel gebruikt HTTP standaarden en onderzoek naar browservingerafdrukken om vier vragen te beantwoorden:

1. Waarom lijkt een UA string op een stukje browserarcheologie?
2. Hoeveel identificerende informatie kan UA bijdragen, en hoe moeten we het onderzoek interpreteren?
3. Waarom kan het veranderen van alleen de UA een duidelijkere inconsistentie veroorzaken?
4. Wat hebben UA Reduction en User-Agent Client Hints eigenlijk veranderd?

In dit artikel bedoelt UA voornamelijk de HTTP User-Agent request-header. We bespreken ook navigator.userAgent en navigator.userAgentData in JavaScript. Deze interfaces zijn verwant, maar niet permanent identiek in elke browser en context.

1. Wat is een User-Agent?

Sectie 10.1.5 van RFC 9110 definieert User-Agent als een veld met informatie over de user agent die het verzoek heeft gestart. De vereenvoudigde grammatica is:

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

In gewone taal begint de string met een productnaam en kan een versie bevatten. Meer producten of reacties kunnen volgen. De standaard erkent toepassingen zoals interoperabiliteitsworkarounds, diagnostiek en analyse, maar adviseert ook implementaties om geen onnodige details te onthullen: een langere, specifiekere UA verhoogt zowel de grootte van verzoeken als het risico op vingerafdrukken.

Een moderne Chromium desktop UA zou er zo uitzien:

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

Het splitsen van de string door ruimtes onthult verschillende namen die niet gerelateerd lijken te zijn aan Chrome:

Token	Wat het tegenwoordig over het algemeen betekent	Een veelvoorkomende misinterpretatie
Mozilla/5.0	Een historische compatibiliteitstoken	De browser moet Firefox zijn of een Mozilla product
Windows NT 10.0	Een Windows platformcategorie; Een gereduceerde UA kan Windows 10 niet betrouwbaar onderscheiden van 11	De computer moet draaien Windows 10
Win64; x64	Een aanwijzing dat dit 64-bits Windows is op een x86-64 architectuur	Het bewijst het exacte fysieke CPU-model
AppleWebKit/537.36	Een engine-afstammings- en compatibiliteitstoken	Chrome gebruikt nog steeds de volledige implementatie van Safari
KHTML, like Gecko	Historische compatibiliteitstaal	Zowel KHTML als Gecko draaien
Chrome/145.0.0.0	De Chrome/Chromium familie en hoofdversie; Lagere versiecomponenten kunnen worden verminderd	Het onthult de precieze patchversie
Safari/537.36	Een token behouden voor compatibiliteit met oudere sites	De browser moet Safari

De UA werd omslachtig omdat vroege websites vaak vertakkingen op browsernamen. Nieuwe browsers moesten beweren compatibiliteit met oudere producten te hebben om de juiste pagina te ontvangen. Deze verklaringen stapelden zich in de loop van de tijd op en creëerden een historisch verslag dat niet letterlijk kan worden gelezen.

De eerste regel van UA parsing is daarom eenvoudig: het is een compatibiliteitsprotocol, geen strikte apparaatbeschrijving.

2. Waarom gebruiken websites nog steeds UA?

UA wordt niet alleen gebruikt voor tracking. Legitieme toepassingen zijn onder andere:

• het bieden van een fallback naar een oudere browser met een bekend compatibiliteitsprobleem;
• het selecteren van een geschikt installer- of downloadformaat;
• het vinden van versie-specifieke storingen in diagnostische logboeken;
• het meten van brede browserfamilie-, platform- en hoofdversiedistributies;
• het identificeren van onmogelijke combinaties in geautomatiseerd of kwaadaardig verkeer.

Het probleem begint wanneer UA sniffing van een beperkte compatibiliteitsval verandert in het raden van mogelijkheden op productnaam. Code kan Chrome zien en aannemen dat er een bepaalde API bestaat. Die aanname kan mislukken in een embedded WebView, een Chromium-afgeleide browser, een browser met een enterprise-beleid, een bevroren UA of een client die zijn header heeft gewijzigd.

Een robuustere volgorde van bewerkingen is:

1. Test de vereiste API of het vereiste gedrag direct wanneer capaciteitsdetectie mogelijk is.
2. Wanneer browseridentificatie onvermijdelijk is, gebruik dan een onderhouden parser in plaats van een ad hoc reguliere expressie.
3. Bewaar alleen de grove categorieën die het product echt nodig heeft.
4. Bied een vangnet voor onbekende merken, onbekende versies en ontbrekende velden.

3. Is UA een browservingerafdruk?

Preciezer gezegd is UA één invoer in een browservingerafdruk, meestal niet de volledige vingerafdruk.

Browservingerafdrukken vereisen geen geheim serienummer. Het meet een verzameling relatief stabiele, onderscheidende kenmerken die door de browser worden blootgesteld. UA levert aanwijzingen over browserfamilie, versie en platform. Schermafmetingen, lettertypen, tijdzone, Canvas, WebGL, AudioContext en andere interfaces voegen extra informatie toe.

De enquête van Laperdrix en collega's, Browser Fingerprinting: A Survey, bespreekt deze technieken als een vorm van stateloze herkenning. Een site hoeft niet per se eerst een Cookie te schrijven; Het kan proberen bezoeken te koppelen van de attributen die een browser blootlegt. "Stateless" betekent niet dat de server niets opslaat. Het betekent dat het herkenningsmateriaal niet afhankelijk is van een persistente client-side identifier.

1. Wat betekent het 10-bit resultaat van het artikel?

In de Panopticlick-studie van 2010 How Unique Is Your Web Browser? analyseerde Peter Eckersley ongeveer 470.000 browservingerafdrukken. De krant meldde dat:

• De volledige vingerafdruk bevatte gemiddeld ongeveer 18,1 bits aan identificerende informatie in dat monster;
• Intuïtief gezegd kwam een gemiddelde vingerafdruk ongeveer eens voor in 286.777 browsers;
• De tabel gaf ongeveer 10,0 bits aan gemiddelde informatie voor alleen de UA string;
• van browsers met Flash of Java ingeschakeld was 94,2% van de volledige vingerafdrukken uniek.

Zelfinformatie wordt gewoonlijk als volgt geschreven:

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

Als een bepaald UA met kans 1/1024 in een populatie voorkomt, levert het observeren ervan 10 bits informatie op. Dit betekent niet dat UA precies 1.024 mogelijke waarden heeft of dat het een persoon uniek identificeert. Het beschrijft hoeveel onzekerheid die observatie gemiddeld wegneemt.

2. Waarom is het resultaat van 2010 geen constante voor het web van vandaag?

Het resultaat blijft belangrijk, maar het vereist minstens drie kwalificaties:

• Bezoekers van een privacy-testpagina waren geen willekeurige steekproef van alle internetgebruikers;
• Browser-, plugin- en UA-versiediversiteit in 2010 verschilden sterk van het huidige ecosysteem;
• UA Reduction, kleiner wordende pluginoppervlakken en anti-fingerprinting bescherming hebben de verdeling van observeerbare attributen veranderd.

De studie ondersteunt de bewering dat UA en andere eigenschappen meetbare onderscheidende informatie kunnen opleveren. Het ondersteunt niet dat een UA vandaag altijd precies 10 bits entropie heeft. De vingerafdrukkracht hangt af van de populatie, tijdsvenster, browserbeleid en de combinatie van signalen.

4. Waarom kan alleen veranderen UA averechts werken?

UA is een clientverklaring zonder cryptografisch bewijs. Een server kan de fabriekswaarheid van een apparaat niet uit deze header lezen. Het kan echter wel controleren of verschillende waarnemingen redelijk compatibel zijn.

Stel dat een UA beweert een mobiele browser te zijn, maar de pagina geen contactpunten ziet, een venster dat consequent lijkt op een desktopdisplay, en Client Hints die een desktopplatform rapporteren. Elke enkele observatie kan een legitieme uitzondering hebben. Verschillende stabiele tegenstellingen samen kunnen nog steeds een classificeerbaar patroon vormen.

Het artikel Panopticlick documenteerde al vergelijkbare gevallen: sommige browsers beweerden een iPhone te zijn terwijl ze Flash ondersteunden, en sommige Firefox UA's verschenen naast opslagfuncties die alleen beschikbaar waren in Internet Explorer. De studie van 2018 FP-Scanner onderzocht dit probleem systematisch. Sommige anti-fingerprinting extensies en spoofingtools introduceerden inconsistenties tussen interfaces, waardoor een detector aangepaste attributen kon identificeren en in sommige gevallen de originele browser- of besturingssysteemfamilie kon afleiden.

Niet elke inconsistentie is kwaadaardig. Remote desktops, toegankelijkheidstools, bedrijfsbeleid, compatibiliteitslagen en ongebruikelijke hardware kunnen allemaal ongebruikelijke combinaties creëren. Een zorgvuldig risicosysteem zou een inconsistentie als probabilistisch bewijs moeten beschouwen, niet als automatische reden om een gebruiker te blokkeren.

Voor het beheer van browserprofielen zijn drie eigenschappen belangrijk:

• Interne consistentie: UA, Client Hints, platform, architectuur, touch en schermsignalen mogen elkaar niet direct tegenspreken.
• Stabiliteit in de loop van de tijd: een langlopend profiel zou niet bij elke lancering drastisch moeten veranderen zonder reden.
• Plausibele diversiteit: profielen kunnen verschillen, maar zeldzame mechanisch gegenereerde combinaties zijn niet per se veiliger.

De FP-STALKER-studie toonde ook aan dat het veranderen van attributen niet automatisch koppeling voorkomt. Een model kan stabiele attributen en plausibele versiewijzigingen gebruiken om eerdere en latere vingerafdrukken te verbinden.

5. Welk probleem pakt UA Reduction aan?

Bij bijna elk verzoek wordt een traditionele UA meegestuurd. Elk eerste-partij of derdepartij-eindpunt dat het verzoek ontvangt, kan het passief lezen. Hoe preciezer de string, hoe meer onderscheidende informatie elke ontvanger standaard krijgt.

Chromium's User-Agent Reduction plan vermindert deze standaard granulariteit:

• Vanaf Chrome 101 werden desktop-, bij- en patchversies teruggebracht tot 0.0.0;
• latere fasen verenigden desktopbesturingssysteemversies, CPU-details en Android apparaatinformatie;
• een gereduceerde Android UA gebruikt vaste platform- en modelwaarden zoals Android 10; K;
• Sites die echt meer details vereisen, kunnen User-Agent Client Hints aanvragen.

Het gereduceerde formaat kan worden samengevat als:

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

Vermindering vermindert het passieve vingerafdrukoppervlak van de legacy UA. Het elimineert browservingerafdrukken niet. De hoofdversie, brede platform- en mobiele status kunnen zichtbaar blijven, terwijl andere API's, netwerkeigenschappen en gedrag nog steeds informatie kunnen leveren.

6. Hoe werken User-Agent Client Hints?

Het algemene mechanisme is gedefinieerd in RFC 8942, terwijl de WICG User-Agent Client Hints concept UA-specifieke velden beschrijft. De aanpak splitst informatie die ooit in een ongestructureerde string stond in gestructureerde velden, waarbij hints met lage entropie die standaard verzonden worden worden onderscheid gemaakt van aanwijzingen met hoge entropie die een site normaal expliciet opvraagt.

Een vereenvoudigd eerste verzoek kan er als volgt uitzien:

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"

Als de server echt architectuur en bitness nodig heeft om een installer te selecteren, kan hij reageren met:

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

Wanneer de browser het mechanisme ondersteunt en aan de beveiligings- en beleidsvereisten is voldaan, kan een later verzoek het volgende omvatten:

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

Veelvoorkomende UA Client Hints zijn:

Veld	Typisch doel	Informatieniveau
Sec-CH-UA	Merk- en hoofdversielijst	Meestal lage entropie
Sec-CH-UA-Mobile	Of de klant nu een mobiele ervaring prefereert	Meestal lage entropie
Sec-CH-UA-Platform	Brede platformcategorie	Meestal lage entropie
Sec-CH-UA-Arch	CPU-architectuur	Hoge entropie; verzoek indien nodig
Sec-CH-UA-Bitness	Architectuurbitheid	Hoge entropie; verzoek indien nodig
Sec-CH-UA-Platform-Version	Perronversie	Hoge entropie; verzoek indien nodig
Sec-CH-UA-Full-Version-List	Volledige versies voor gerapporteerde merken	Hoge entropie; verzoek indien nodig
Sec-CH-UA-Model	Apparaatmodel	Hoge entropie; verzoek indien nodig

Drie technische details zijn makkelijk te missen.

1. Client Hints worden niet allemaal automatisch verzonden

Hints met lage entropie kunnen standaard verschijnen. Hints met hoge entropie vereisen meestal een Accept-CH reactie. Initiële navigatie, subresources, permissiebeleid, veilig transport en browserondersteuning kunnen allemaal invloed hebben op wat er binnenkomt. Een server moet toestaan dat elk optioneel veld ontbreekt.

2. De merkenlijst test bewust de parserrobuustheid

Sec-CH-UA kan meerdere merken bevatten en een synthetisch merk dat wordt gebruikt om compatibiliteit te testen. De code mag er niet van uitgaan dat de eerste vermelding altijd de productnaam is, en mag niet falen wanneer er een onbekend merk verschijnt. Ontleed het gestructureerde veld, negeer vermeldingen die je niet herkent en laat ruimte voor toekomstige merken.

3. Antwoorden die variëren in hints vereisen correcte cache-afhandeling

Als architectuur, platform of een andere hint het antwoord verandert, configureer dan Vary of een equivalente cache-key strategie correct. Anders kan een gedeelde cache content die voor de ene apparaatklasse is gegenereerd aan de andere serveren.

7. Zijn Client Hints privé dan de traditionele UA?

Ze verbeteren de manier waarop informatie wordt blootgesteld, maar bieden geen immuniteit tegen vingerafdrukken.

De traditionele UA onthult passief en standaard een grote ongestructureerde bundel. Client Hints splitsen dat pakket op in velden, maken verzoeken om informatie met een hogere entropie explicieter en geven de browser de kans om beleids-, toestemmings- of privacybudgetcontroles toe te passen.

Architectuur, volledige versies, platformversies en apparaatmodellen kunnen echter nog steeds de onderscheidbaarheid vergroten. RFC 8942 behandelt privacy en prestaties expliciet als ontwerpbeperkingen. Ontwikkelaars zouden moeten vragen:

• Vereist deze functie echt het vakgebied?
• Kan capability-detectie of een gebruikerskeuze dit vervangen?
• Kan de applicatie alleen een grove categorie opslaan?
• Hoe lang worden ruwe waarden behouden en wie kan er toegang toe hebben?
• Zullen externe bronnen dezelfde hints ontvangen?

8. Technische richtlijnen voor server-side UA afhandeling

1. Gebruik UA nooit als bewijs van identiteit of autoriteit

UA kan presentatiekeuzes en compatibiliteits-fallbacks ondersteunen. Het mag geen identiteit, autorisatie, betalingstrust of een beveiligingsgrens bepalen. Een door de client gecontroleerde waarde kan niet dienen als toegangscontrole-credential.

2. Verkiezen capaciteitsdetectie boven browserlijsten

Wanneer een front-end een API nodig heeft, test dan direct op die mogelijkheid:

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

Capability-detectie behandelt afgeleide browsers, experimentele functies, bedrijfsbeleid en toekomstige releases beter dan een regel zoals "enable this for Chrome 145."

3. Accepteer legacy UA, Client Hints en onbekende staten

Tijdens migratie kan een server alleen de legacy UA ontvangen, zowel UA als Client Hints, of sterk gereduceerde vormen van beide. Het datamodel zou unknown moeten toestaan in plaats van te raden dat een exact besturingssysteem of apparaatmodel elk veld vult.

4. Log-granulariteit verminderen

Als analytics alleen desktop versus mobiel, browserfamilie en hoofdversie nodig heeft, bewaar dan niet de ruwe UA strings en elke high-entropie hint oneindig. Dataminimalisatie vermindert het privacyrisico en voorkomt dat een analysepijplijn kleine variaties als een betekenisvolle dimensie kan behandelen.

5. Beschouw anomalieën als bewijs, niet als vonnissen

Een UA die beweert Windows terwijl één API zich anders gedraagt, is hooguit één risicosignaal. Bedrijfsomgevingen, virtualisatie, externe sessies, compatibiliteitslagen en ondersteunende technologieën kunnen legitieme afwijkingen veroorzaken. Het omzetten van één mismatch in een automatische fraudebeslissing veroorzaakt valse positieven.

9. Hoe moet UA worden geconfigureerd in multi-profile omgevingen?

Voor cross-region testen, advertentiepreviews, accountoperaties en privacyisolatie moet het doel niet zijn om de meest ongebruikelijke UA te creëren. Een profiel moet uitlegbaar, stabiel en compatibel zijn met de omgeving.

Bekijk het volgende in volgorde:

1. Browserversie: De UA hoofdversie zou plausibel moeten zijn voor de daadwerkelijke engine en de mogelijkheden ervan.
2. Besturingssysteem: De categorie UA platform, Client Hints platform en JavaScript-zichtbaar platform moet compatibel zijn.
3. Architectuur en bitheid: UA, Client Hints en de uitvoerbare omgeving mogen geen direct tegenstrijdige claims maken.
4. Apparaatvormfactor: Een mobiele declaratie zou logisch moeten zijn naast touch-ondersteuning, viewport, pixelverhouding en interactiepatronen.
5. Regionale context: taal, tijdzone, geolocatie en proxy-uitgang hoeven mechanisch niet overeen te komen, maar ze zouden logisch moeten zijn voor de echte workflow.
6. Profielstabiliteit: Wanneer één account of testidentiteit een langlopend profiel hergebruikt, vermijd dan het wisselen van platform en hoofdversie zonder reden.

De huidige profielconversie van PurpleMark koppelt het geselecteerde besturingssysteem aan een UA platform en probeert eerst de browserversie te extraheren uit een geconfigureerd Chrome/ of CriOS/-token. Wanneer er geen bruikbare versie bestaat, wordt er een redelijke vangnet afgeleid van de huidige grote versie van de engine. Het doel is niet om één geïsoleerde string te spoofen, maar om UA configuratie binnen een consistent browserprofielmodel te plaatsen.

Profielisolatie en parameterconsistentie kunnen technische correlatie en testbias verminderen. Ze kunnen niet garanderen dat rekeningen nooit gekoppeld zullen worden, en ze vervangen geen platformregels, accountgegevens, betalingsinformatie of verantwoordelijke bedrijfsvoering. Gebruik deze functies uitsluitend voor wettelijke privacybescherming, juridische tests en conforme bedrijfsactiviteiten.

10. Veelgestelde vragen

V1: Verandert het wijzigen UA de browser in een andere browser?

Nee. Het verandert een deel van wat de cliënt aangeeft. Het vervangt de JavaScript-engine, renderingpijplijn, netwerkstack of ondersteunde web-API's niet.

V2: Kan een website de "echte UA" lezen?

Er is geen universeel hardwareniveau "real UA" dat elke website de browser kan omzeilen om te lezen. Een site kan echter Client Hints, capaciteitstests en andere vingerafdruksignalen vergelijken, incompatibele claims vinden en een probabilistische afleiding trekken.

V3: Kan een gereduceerde UA Windows 10 onderscheiden van Windows 11?

De verminderde legacy UA kan dit normaal gesproken niet betrouwbaar doen omdat beide Windows NT 10.0 kunnen rapporteren. Een browser die UA Client Hints ondersteunt, kan meer gedetailleerde informatie over de platformversie geven nadat een site hierom heeft gevraagd. Servers moeten nog steeds omgaan met ontbrekende velden en verschillen in mapping.

V4: Stopt het uitschakelen van JavaScript UA blootstelling?

Niet helemaal. De HTTP User-Agent is een verzoekheader en kan samen met het paginaverzoek worden verzonden voordat pagina JavaScript wordt uitgevoerd. Het uitschakelen van JavaScript verwijdert sommige verzameloppervlakken, maar breekt ook aanzienlijke delen van het moderne web.

V5: Zullen Client Hints User-Agent volledig vervangen?

Ga er niet van uit dat je dat op korte termijn doet. Veel clients en servers zijn nog steeds afhankelijk van de legacy UA, terwijl UA Client Hints ondersteuning varieert. Behandel Client Hints als progressieve verbetering: geef de voorkeur aan gestructureerde informatie wanneer beschikbaar, maar behoud vangmogelijkheden voor legacy UA en onbekende toestanden.

V6: Verbetert een willekeurig gegenereerde UA de anonimiteit?

Niet per se. Het willekeurig maken van één veld kan tegenstrijdigheden veroorzaken met versie-, platform-, touch- en renderingsignalen. Voor een langlopend profiel is een gemeen, stabiele, intern compatibele configuratie meestal beter te verdedigen dan frequente willekeurige wijzigingen.

11. Conclusie

User-Agent is noch een betrouwbare identiteitsbevoegdheid, noch een irrelevante string. Het bevindt zich op het stippunt van webcompatibiliteit, privacy en risicoanalyse. Voor ontwikkelaars is het een compatibiliteitsinvoer die belast is door geschiedenis. Voor fingerprinting-onderzoekers is het een eigenschap met meetbare statistische informatie. Voor browserleveranciers is het een standaard blootstellingsoppervlak dat moet worden verkleind.

De kernideeën passen in drie uitspraken:

• Lees een UA niet letterlijk; het bevat veel historische compatibiliteitstokens.
• Beoordeel UA niet op zichzelf; Praktische herkenning komt voort uit combinaties van signalen en hun evolutie in de loop van de tijd.
• Zie Client Hints niet slechts als "meer UA vakgebieden"; Hun waarde ligt in gestructureerde, op verzoeken gestuurde, beheersbare openbaarmaking.

Wanneer een systeem overgaat van het identificeren van een browsernaam naar het testen van de benodigde functionaliteit—en van het verzamelen van alle beschikbare details naar alleen vragen wat nodig is—keert UA terug naar zijn juiste rol: een compatibiliteitsaanwijzing, geen identiteitswaarheid.

Referenties en standaarden

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.