Waarom zijn Client Hints na het bevriezen van de User-Agent het nieuwe fingerprintsignaal? Van UA naar CH uitgelegd

De afgelopen jaren hebben grote browsers hun privacybeleid steeds verder aangescherpt: Safari introduceerde ITP, Firefox Total Cookie Protection en Chrome zette officieel door met User-Agent freezing (UA Reduction). Veel mensen denken nog steeds dat “de UA aanpassen” genoeg is om een apparaat anders te laten lijken, terwijl de UA inmiddels sterk is vereenvoudigd en steeds minder detail bevat. De rol van belangrijk signaal voor apparaatherkenning wordt steeds meer overgenomen door Client Hints (CH).

Dit artikel leert geen methode om “detectie te omzeilen”. Het bespreekt uitsluitend de technische principes en maakt drie zaken duidelijk: waarom wordt de UA bevroren? Wat zijn Client Hints precies en waarom gelden ze als hoog-entropische fingerprintsignalen? En waarom is “fingerprintconsistentie” uiteindelijk de kern? Dit helpt begrijpen waarom modern beheer van browseromgevingen, vooral bij isolatie van meerdere accounts, parameters als één samenhangend geheel moet behandelen in plaats van als losse velden.

1. Waarom is de UA-string niet langer voldoende?

Lange tijd was User-Agent het belangrijkste gegeven waarmee websites browsers en apparaten herkenden. Het onthult onder andere browsermerk en -versie, besturingssysteem en apparaatarchitectuur. Omdat UA-strings lang en stabiel waren, konden ze gemakkelijk voor fingerprinting worden gebruikt. Chrome kondigde daarom expliciet aan de UA geleidelijk te reduceren: alleen basisinformatie zoals de hoofdversie behouden en meer detail onderbrengen in een nieuw mechanisme, Client Hints.

Het directe gevolg van UA freezing is dat alleen de UA vervalsen niet meer overtuigt. Systemen vertrouwen niet langer uitsluitend op de UA, maar controleren ook of andere velden ermee overeenkomen. De duidelijkste signalen zijn tegenstrijdige parameters, bijvoorbeeld:

• De UA vermeldt macOS 14, maar het platformversieveld geeft macOS 13 aan;
• De UA zegt dat het om een mobiel apparaat gaat, terwijl de mobiele vlag nog steeds ?0 is;
• De hardwarearchitectuur meldt arm64, terwijl waarden zoals navigator.hardwareConcurrency meer op x86 lijken.

In systemen voor apparaatherkenning kunnen zulke tegenstrijdigheden snel aangeven dat het profiel niet van een echt apparaat afkomstig is. Daarom werkt “alleen de UA wijzigen” in het tijdperk van UA freezing niet meer.

2. Wat zijn Client Hints en waarom zijn het hoog-entropische fingerprints?

Client Hints (CH) zijn gegevens over apparaatcapaciteiten die een browser op verzoek via HTTP-verzoeken of de JavaScript-omgeving aan een server kan doorgeven. Ze verschillen op twee belangrijke punten van de UA:

1. Ze bevatten hoog-entropische velden (High Entropy Values). Hoge entropie betekent dat de combinatie van deze gegevens sterk onderscheidend en moeilijk te raden kan zijn, zoals de exacte platformversie, een volledige lijst van merken en versies en de apparaatarchitectuur. Echte browsers geven deze gegevens op verzoek terug in plaats van alles in één keer bloot te leggen.

2. CH wordt niet afzonderlijk beoordeeld, maar samen met andere fingerprints gecontroleerd. Echte apparaatherkenningssystemen kijken vaak of CH en UA overeenkomen, of CH en transportlaagfingerprints zoals TLS JA3/JA4 bij dezelfde browserfamilie passen, of CH coherent is met JavaScript-eigenschappen zoals navigator.platform, concurrency en device pixel ratio (DPR), en of CH overeenkomt met kenmerken van het besturingssysteemplatform.

Daaruit volgt een belangrijk principe: het moeilijke is niet één veld aanpassen, maar alle velden laten lijken alsof ze van hetzelfde echte apparaat afkomstig zijn. Bijna elk afzonderlijk veld kan los worden gewijzigd. De echte uitdaging is om merk, platformversie, UA, DPR, geheugen, architectuur, TLS-fingerprint en andere signalen samen één logisch apparaatprofiel te laten vormen. Daarom kunnen configuraties waarin “alle velden netjes zijn ingevuld” toch meteen inconsistent overkomen.

3. Welke fingerprintfouten vallen het vaakst op?

Zodra duidelijk is dat consistentie de sleutel is, wordt ook begrijpelijk waarom veel parameterconfiguraties misgaan. Veelvoorkomende fouten zijn:

• CH en UA komen niet overeen (het meest voorkomend): de UA vermeldt macOS 14.1, maar CH geeft een platformversie terug die feitelijk niet bestaat;
• Een mobiele UA met mobiele vlag ?0: op een echt mobiel apparaat hoort hier normaal ?1 te staan;
• Onjuiste afleiding van de volledige versielijst: de hoofdversie van de browser is bijvoorbeeld 120, maar de volledige versie-eigenschappen lijken op een oudere 115-versie;
• DPR, geheugen of andere waarden passen niet bij het echte apparaattype: bijvoorbeeld een Apple-apparaat met een abnormaal lage pixelratio of een gewone Windows-pc die slechts 1 GB geheugen meldt;
• Browserspecifieke verschillen worden genegeerd: bijvoorbeeld een veld afdwingen in een browser die het niet ondersteunt, of een engine een waarde laten teruggeven die die engine in werkelijkheid nooit zou leveren.

Deze tegenstrijdigheden zijn opvallend in systemen voor apparaatherkenning. In essentie ontstaan ze allemaal doordat de omgeving niet als één coherent geheel wordt beheerd.

4. Wat betekent een “juiste configuratie” dan precies?

In plaats van te spreken over “velden invullen” is het beter om te spreken over het onderhouden van een coherent omgevingsprofiel. Gewoonlijk betekent dat:

• CH aan de UA koppelen: de bijbehorende CH-waarden voor merk, platform en versie afleiden volgens de werkelijke regels van de browserengine en -versie, in plaats van willekeurige waarden samen te voegen;
• De terugkeerstrategie van hoog-entropische velden volgen: standaard laag-entropische informatie leveren, hoog-entropische waarden alleen op verzoek teruggeven zoals een echte browser dat doet en geen velden retourneren die de huidige browser niet ondersteunt;
• JS-eigenschappen, HTTP-headers en systeemkenmerken onderling consistent houden: DPR moet passen bij de schermresolutie, geheugen bij het platformtype, de mobiele vlag bij de UA en de architectuur bij de logica van het gehele systeemprofiel;
• Transportlaagfingerprints meenemen: kenmerken zoals TLS/JA3/JA4 moeten eveneens passen bij de opgegeven browserversie.

Kort samengevat: de echte uitdaging is CH, UA, de JavaScript-omgeving en systeemkenmerken samen één coherent browsergedragsprofiel te laten vormen, niet zoveel mogelijk velden vullen.

5. Wat heeft dit te maken met beheer van multi-accountomgevingen?

Mensen die actief zijn in internationale e-commerce, socialmedia-advertising of zelfstandige webshops vragen zich misschien af wat deze techniek te maken heeft met “aparte browseromgevingen voor verschillende zakelijke accounts”. Het verband is direct: omgevingsbeheer werkt alleen goed wanneer elke omgeving intern coherent is.

• Bij veel accounts en regio’s is het handmatig samenstellen van UA, besturingssysteem, resolutie en andere parameters per omgeving onnodig foutgevoelig. Een tool kan op basis van het gekozen systeem en de engineversie automatisch onderling afgestemde parameters genereren, zodat tegenstrijdige losse wijzigingen en herstelwerk worden beperkt.
• Zakelijke accounts voor verschillende regio’s en platformen horen afzonderlijke omgevingen met intern coherente parameters te hebben, in plaats van allemaal dezelfde “sjabloonparameters” te delen en daardoor op apparaatniveau onnatuurlijk veel op elkaar te lijken.
• Bij het wisselen van een proxy naar een andere regio sluit het meer aan bij het gedrag van een echt apparaat wanneer systeemversie, apparaatmodel en andere kenmerken binnen dezelfde omgeving logisch blijven, dan wanneer “alleen het IP verandert en alle andere parameters precies hetzelfde blijven”.

Dat zijn precies de consistentieproblemen die tools voor multi-account browseromgevingen proberen op te lossen. Bij het maken van een omgeving biedt PurpleMark één configuratiepunt voor besturingssysteem, Chromium-engineversie, User-Agent, resolutie, tijdzone, taal, CPU/geheugen, Canvas, WebGL, TLS en andere fingerprint- en apparaatparameters. Na keuze van een regio en accountdoel kan de omgeving volgens één samenhangend schema worden gegenereerd, in plaats van bij elke login parameters ter plekke te combineren. Wat werkelijk wordt beheerd is de totale consistentie en herbruikbaarheid van account, browseromgeving en netwerkconfiguratie in één werkruimte, niet het omzeilen van een specifieke detectiemethode.

6. Samenvatting

UA freezing markeert een nieuwe fase in browserfingerprinting: het gaat niet langer alleen om welke velden bestaan, maar vooral om de vraag of die velden onderling kloppen. Nu Client Hints de UA opvolgen als hoog-entropische fingerprintsignalen, is inzicht in de relatie tussen CH, UA, systeemkenmerken en transportfingerprints belangrijker dan het onthouden van een lange lijst veldnamen.

Als je slechts enkele echte, legitieme zakelijke accounts beheert, is het niet nodig om energie te steken in het bestrijden van detectie. Praktischer is het om met een omgevingsbeheertool zoals PurpleMark de regio-, systeem- en browserparameters van ieder account duidelijk, coherent en herbruikbaar te houden, zodat problemen door tegenstrijdige instellingen al bij de bron worden verminderd.

(Opmerking: dit artikel is uitsluitend bedoeld als technische uitleg over browserfingerprinting. Werk altijd volgens de servicevoorwaarden van ieder platform en gebruik legitieme accounts.)