Fingerprint-testpagina’s tonen veel gegevens die websites sowieso kunnen uitlezen. Met deze zes controles vind je tegenstrijdigheden tussen browser, systeem, regio, netwerk en rendering, want botsende signalen vallen vaak meer op dan één ongebruikelijke waarde.
Open een willekeurige browserfingerprint-test en je ziet een lange lijst met velden: UA, scherm, tijdzone, lettertypen, Canvas-renderingresultaten en hardwareparameters. Veel mensen kijken eerst naar de “uniciteit”, maar dat is juist het minst belangrijke onderdeel. Belangrijker is of al deze gegevens logisch bij elkaar passen.
Wat websites sowieso kunnen uitlezen
Een fingerprint wordt niet opgeslagen zoals een cookie. Cookies kun je verwijderen, blokkeren of omzeilen met privébrowsen; een fingerprint ontstaat uit de configuratie van de browser en het apparaat zelf. De UA bevat het browsertype en de versie, plus het besturingssysteem en de versie daarvan. Andere signalen zijn geïnstalleerde plugins, schermresolutie en kleurdiepte, lettertypen, tijdzone en voorkeurstaal, CPU-type, GPU-model en geheugen, IP-adres, provider en verbindingstype, en renderingresultaten van HTML5-interfaces zoals Canvas en WebGL. Samen vormen deze velden een identificatiepatroon dat meestal nauwelijks verandert wanneer je van IP wisselt, cookies wist of privémodus gebruikt. Platforms gebruiken hetzelfde basisprincipe om te beoordelen of accounts mogelijk met elkaar samenhangen.
Controleer eerst drie dingen tegen het systeem
De User Agent is een goed startpunt, omdat de browser daarmee zichzelf beschrijft. Kopieer de UA van de testpagina, controleer de browserversie in de browserinstellingen en de versie van het besturingssysteem in de systeeminstellingen. Als het systeem of de kernelversie die de UA meldt niet overeenkomt met de echte machine, of duidelijk achterloopt op gangbare actuele versies, is dat een van de makkelijkste inconsistenties om te herkennen.
De tijdzone moet passen bij de regio van de netwerkuitgang. Testpagina’s tonen de huidige tijdzone meestal direct, en een eenvoudig script om de tijdzone op te vragen geeft dezelfde waarde. Gebruik daarnaast een IP-zoekpagina om te zien aan welke regio de uitgangs-IP is gekoppeld. Wijzen die twee naar verschillende regio’s, dan moet die mismatch worden aangepakt.
Taal en regio zijn afzonderlijk zwakke signalen, maar samen wel bruikbaar. Bekijk de waarden van navigator.language en navigator.languages en vergelijk ze met talen die gebruikelijk zijn in de regio van de uitgang. Een Amerikaanse tijdzone, Chinees als taal en een uitgang in Europa vallen samen meer op dan elk onderdeel afzonderlijk.
Scherm, netwerkuitgang en renderingkenmerken
Bij scherm- en hardwaregegevens kijk je naar twee dingen: zijn de waarden gebruikelijk en passen ze bij het apparaattype dat de UA opgeeft? Resolutie, pixelratio, beschikbare schermruimte, aantal CPU-kernen en geheugen kun je samen beoordelen. Een telefoonachtige resolutie gecombineerd met een desktop-UA is een klassieke tegenspraak.
WebRTC moet je apart controleren, omdat het echte netwerkinformatie kan blootleggen. Testpagina’s tonen dit meestal als afzonderlijk onderdeel. Kijk of er een lokaal netwerkadres wordt teruggegeven, bijvoorbeeld beginnend met 192.168 of 10, of zelfs het echte publieke uitgangsadres. Als je een proxy gebruikt maar het echte adres toch verschijnt, loopt dat verkeer niet via de proxy. Dit heeft de hoogste prioriteit.
Bij Canvas en WebGL controleer je of de resultaten stabiel zijn en of ze passen bij het opgegeven GPU-model. Eén detail is belangrijk: als meerdere omgevingen op dezelfde machine tegelijk exact dezelfde renderingwaarden teruggeven, zijn ze makkelijker aan elkaar te koppelen dan wanneer de waarden enige variatie of ruis bevatten.
Tegenstrijdigheden vallen meer op dan onvolmaakt realisme
Platforms verwachten niet dat elk apparaat volledig uniek is. Ze beoordelen vooral of de hele set gegevens eruitziet alsof die van een normale machine komt. Eén waarde die niet heel “realistisch” is, zoals een ongebruikelijke resolutie, is meestal slechts een zwak signaal. Wanneer meerdere velden elkaar tegenspreken, wordt de afwijking veel eenvoudiger zichtbaar. De UA zegt Windows, maar de lettertypen lijken op macOS; de tijdzone staat op de VS, de taal is Chinees en de uitgang ligt in Europa; de resolutie hoort bij een telefoon, maar de UA meldt een desktopbrowser. Eén zo’n combinatie kan veel fijnafstelling elders tenietdoen. Daarom zoek je bij een zelfcontrole eerst naar harde tegenstrijdigheden en kijk je pas daarna naar details van afzonderlijke parameters.
Als je maar drie dingen wilt aanpassen
WebRTC-lekken staan bovenaan, omdat ze echte netwerkinformatie blootleggen. Op de tweede plaats komt de consistentie van tijdzone en taal met de uitgangsregio, omdat zulke afwijkingen zich makkelijk opstapelen tot een opvallend profiel. Daarna komen Canvas en WebGL, zodat dezelfde machine niet rechtstreeks een stabiele en unieke renderingwaarde prijsgeeft.
Er is ook een praktische grens: JavaScript uitschakelen of sterk beperken kan een deel van de verzameling blokkeren, maar vermindert de bruikbaarheid van veel websites duidelijk. Privacygerichte browsers hebben ingebouwde bescherming en zijn vaak voldoende voor dagelijks gebruik, maar zijn minder flexibel wanneer je langdurig meerdere niet-gerelateerde identiteiten moet onderhouden.
Meerdere omgevingen onderhouden
Het doel is niet om elke keer een volledig willekeurige fingerprint te maken. Elke omgeving moet intern stabiel blijven en tegelijk verschillen van de andere. Met PurpleMark kun je voor elk account een aparte browseromgeving maken, parameters zoals Canvas afzonderlijk behandelen en daarna elke omgeving op een testpagina controleren op interne consistentie. Een omgeving die die controle doorstaat, is geschikt om langdurig te gebruiken.
Uiteindelijk heeft fingerprint-testing maar twee doelen: zien welke informatie je blootlegt en controleren of die informatie onderling klopt. Uniciteit is het onderdeel waar je je het minst druk om hoeft te maken.
