Fingerprint-parameters randomiseren? Waarom meer random juist misgaat

'Ik zette voor elke omgeving de parameters op random, want dat leek me het veiligst. Het account hield het geen drie dagen vol.' Wie meerdere accounts draait, heeft zoiets vaker gehoord. De intuïtie ligt voor de hand: als de parameters elke keer veranderen, zou een platform je toch niet meer herkennen. In de praktijk komt er meestal het omgekeerde uit. Hoe randomer, hoe sneller een account misloopt.

De richting klopte vanaf het begin niet. Een platform vraagt nooit of jij veranderd bent. Het vraagt of je op een echt apparaat lijkt. En een echt apparaat blijft staan.

Eerst de conclusie: parameters hoeven niet expres random te zijn. Of een omgeving standhoudt, hangt aan drie dingen: of elke parameter echt is, of tientallen parameters elkaar kunnen verklaren, en of de parameters van één account een controle over tijd doorstaan. Randomisatie raakt het eerste aan en beschadigt de andere twee. Hieronder wat 'isolatie' en 'random' elk regelen, een rondgang langs de fingerprint-parameters, en waar randomisatie stukgaat.

Zijn een geïsoleerde omgeving en random parameters hetzelfde?

Eerst het meest voorkomende misverstand. Wie net begint, denkt vaak: als elke omgeving geïsoleerd is, moeten de parameters toch random zijn, anders zijn de omgevingen toch identiek?

Isolatie regelt de grens. Twee omgevingen delen geen login-status en geen websitegegevens, en wat in omgeving A gebeurt, komt nooit bij omgeving B terecht. Dat doet de isolatietechniek, en met de waarden van parameters heeft het niets te maken. Randomisatie regelt de waarden. Die bepalen als wat voor apparaat elke omgeving wordt gelezen.

De verdeling past in één zin: Tussen verschillende accounts hoort een grens, binnen één account hoort continuïteit. De grens komt van isolatie, de continuïteit van stabiliteit. Randomisatie past een grensbehoefte toe op de continuïteit en haalt alles binnen een account ondersteboven wat had moeten blijven staan.

Welke fingerprint-parameters bestaan er, en hoe leest een site ze?

Een browser legt ruim twintig fingerprint-parameters bloot waarover gepraat wordt. Je hoeft ze niet uit je hoofd te leren. Sorteer ze op hoe een site ze krijgt, en er blijven twee groepen over. De eerste meldt de browser zelf, één verzoek is genoeg:

De tweede groep vraagt een site niet, die meet ze zelf. Canvas en WebGL zijn het duidelijkste geval: de site laat de browser een afbeelding tekenen en een 3D-scène renderen, verschillende videokaarten en stuurprogramma's geven net andere resultaten, en met dat resultaat controleert de site de identiteit die de browser zelf opgaf.

Zelf gemelde parameters moet een site dus slikken zoals ze komen. Gemeten resultaten ontstaan ter plekke: die kun je niet aanpassen, alleen vervalsen. Daar zit precies de oorzaak van het randomisatieprobleem.

Waarom gaan random parameters zo makkelijk mis?

Randomisatie-extensies raken precies die twee groepen, en elke groep heeft zijn eigen manier om te kantelen.

Eerst de zelf gemelde groep. Trek User-Agent, resolutie en lettertypelijst los van elkaar random, en het resultaat past vaak niet in elkaar tot een machine die bestaat. Een Windows-lettertypelijst naast een macOS-zelfbeschrijving. De resolutie komt uit op een telefoonmaat, terwijl de opgegeven identiteit nog steeds een desktop is. Risicomodellen hebben enorme hoeveelheden echte apparaatgegevens gezien, en zo'n onsamenhangende combinatie valt meteen op.

Er is een nog verborgen variant. Om werk te sparen zet een randomisatie-extensie dezelfde parameter voor alle gebruikers op één populaire waarde. Vanaf genoeg gebruikers trekt een reeks volstrekt onafhankelijke accounts met dezelfde kenmerkwaarde door het web. Het platform hoeft ze niet één voor één te herkennen. Die waarde kennen is genoeg.

Nu de gemeten groep. Een extensie met ruis geeft bij elke uitlezing van Canvas en vergelijkbare zaken een iets ander resultaat: dezelfde afbeelding levert vandaag één waarde en morgen een andere. Een echt apparaat doet dat niet. Op één computer blijft de uitlezing in normaal gebruik staan, en twee metingen die niet overeenkomen zijn op zichzelf al een afwijking.

Platforms kennen ook het tempo van echte apparaten. Een grote browserupdate, een herinstallatie van het systeem: een handvol keer per jaar, en het hele web gaat mee. Random veranderingen hebben dat ritme niet. Ze kunnen bij elk bezoek gebeuren. Alleen jij verandert.

Randomisatie verandert parameterwaarden. Ze verandert niet of je op een echt apparaat lijkt.

Fingerprint bekijken: waarom is de score niet genoeg?

Veel mensen halen hun vertrouwen in randomisatie uit scoringtools: parameters aanpassen, test draaien, 90 of 100 zien, live gaan. Hier zit een gat waar je zo in stapt. Een scoringtool meet losse posten. Een platform kijkt naar verbanden.

Een hoge score per post zegt alleen dat die post op zichzelf in orde is: schoon IP, geen zeldzame waarde, geen zichtbaar lek. Bij de vraag naar samenhang toetst het platform echter of tientallen posten elkaar kunnen verklaren. Wat het besturingssysteem zegt, klopt niet met wat de videokaart meldt. Wat de taal zegt, klopt niet met wat het IP zegt. Eén enkele tegenspraak is genoeg voor een tweede blik.

Dat onderling bevestigen van parameters is een relationeel oordeel, en geen enkele scoringtool toetst het. Daar zit precies het gevaar van een perfecte omgeving: elke post ziet er goed uit, en samen vormt het toch een apparaat dat niet bestaat.

Een score bewijst dat niet. Hij geeft alleen valse zekerheid.

Bij het controleren van een omgeving telt de volgorde dus zwaarder dan de score, in drie lagen: eerst of tientallen parameters samen elkaar verklaren; dan post voor post of de gelezen waarde bij de ingestelde past; en tot slot een hertest na een paar dagen, of twee metingen overeenkomen. Drie stappen zijn genoeg:

1. Doe eerst de consistentietest. Tools als CreepJS zoeken precies naar parameters die elkaar tegenspreken: wat de UA zegt, wat de videokaart zegt, wat de lettertypen zeggen, allemaal naast elkaar.
2. Kijk dan naar lekken per post. BrowserLeaks zet elke gemelde waarde per categorie op een rij, zodat je ze één voor één tegen je apparaatinstellingen legt.
3. Kijk als laatste naar de historie. Test dezelfde omgeving een paar dagen later opnieuw. Beide metingen horen gelijk te zijn. Zo niet, dan wordt er ruis uitgelezen.

Hoe gaat MostMate om met de keuze tussen echt en random?

Na de theorie terug naar de openingsvraag: welke waarden moeten parameters krijgen? **MostMate is een antidetect browser die echte, consistente en stabiele waarden in de standaardinstellingen bouwt.** De parametermodus kent drie standen, Real, Random en Custom, en de standaard landt op Real. Schermresolutie, CPU-kernen en werkgeheugen nemen de werkelijke kenmerken van het huidige apparaat over. Canvas en WebGL volgen de echte uitvoer, zonder extra samenstelwerk en zonder ruis. De installatievoorbeeld op de site beschrijft dit als het automatisch opbouwen van een plausibele, realistische en logisch kloppende browseromgeving, en 'logisch kloppend' wijst precies op het onderling bevestigen van hierboven.

Regiogebonden posten zoals tijdzone en taal hangen standaard aan 'Op basis van IP': waar de uitgang ligt, daar richten ze zich op, zodat je nooit een lijn in het ene en een klok in het andere gebied krijgt. Waarom de principes echt en consistent zo zijn vastgelegd, staat in de vier MostMate-ontwerpprincipes.

Met de gebouwde omgeving is ook de grens getrokken. De site noemt een omgeving een Profile, en elk Profile bewaart een eigen set parameters, zodat twee Profiles op dezelfde computer als aparte fingerprints worden gelezen die elkaar nooit vermengen. Hoe je het formulier van boven naar beneden invult, staat op volgorde in de vier stappen van installatievoorbeeld naar je eerste omgeving; loop daarna op de site de vergelijking van handmatige fingerprint-instelling en de aanbevolen configuratie langs en bevestig de stand van elke post.

Wat dit gereedschap in multi-accountbeheer aanstuurt, staat volledig op de productpagina.

Wanneer mogen fingerprint-parameters veranderen?

Stabiliteit betekent niet bevroren. Verandering vraagt een echte reden.

Een grote browserupdate is een normale verandering en vraagt niets. Alle gebruikers gaan binnen een week of twee mee, platforms kennen dat ritme, en een omgeving die echte apparaten volgt, loopt niet mis.

Nieuwe hardware of een nieuwe lijn verzet de hele set. Nieuwe parameters vormen één samenhangende groep, regiogebonden posten lijnen samen met de nieuwe lijn uit, en de wissel gebeurt terwijl het account rustig is, in één keer. De losse sprong is gevaarlijk. Een complete vervanging niet.

Als een account net een afwijking vertoont of de cijfers schommelen, stop dan. Elke parameteraanpassing vergroot het risico. Bij twijfel eerst opnieuw testen: zodra de tegenspraken op nul staan en beide metingen overeenkomen, ga je verder.

Veelgestelde vragen

Zijn random parameters volledig onbruikbaar?

Ze blijven beschikbaar. Wat ze niet kunnen zijn, is de standaardstrategie van een account. MostMate houdt de stand Random in de parametermodi, geschikt voor tests en het opsporen van fouten waar geen blijvende identiteit nodig is. Voor accounts die langdurig moeten lopen, houdt de standaard Real beter stand.

Is alleen de User-Agent aanpassen genoeg?

Nee. De User-Agent is één post van ruim twintig, alle andere parameters blijven zoals ze waren, en het apparaatbeeld is dus niet veranderd. Hij staat ook in een vaste verhouding tot gemeten posten als de videokaart en de lettertypen, dus één ingreep zet de parameters juist tegen elkaar op. Verzet de hele set samen. De losse aanpassing is de slechtste keuze.

Betekent een echte fingerprint dat ik nooit het risicobeheer van een platform raak?

Zo moet je het niet lezen. Een echte fingerprint dekt één laag: of het apparaat echt wordt gelezen. Het risicobeheer van een platform kijkt ook naar gedrag, IP-kwaliteit en het tempo van handelingen, allemaal buiten de fingerprint. Een echte fingerprint maakt de apparaatlaag solide, hij verzekert geen account. Staat de apparaatlaag stevig, dan moet het account nog steeds op gebruiksgewoonten meedragen.

Staat de consistentiecheck van MostMate voor het risicobeheer van een platform?

Nee, dat zijn twee verschillende dingen. De consistentiecheck van MostMate helpt je bij het aanmaken een omgeving samen te stellen waarvan de parameters bij elkaar passen en op het IP zijn afgestemd. Hij raakt geen enkele detectieregel van een platform. Hoe een platform oordeelt, is aan het platform. Wat jij kunt doen, is je eigen omgeving in de vorm van een echt apparaat brengen.

Zijn accounts die met een randomisatie-extensie zijn opgewarmd nog te redden?

Ja, maar niet overhaast. Zet de randomisatie eerst uit, leg één set echte parameters vast, lijn de regiogebonden posten af op de nieuwe lijn en laat het daarna een tijd met rust. Blijven bijstellen is riskanter dan de huidige staat aanhouden.

Slot

Randomisatie wil elke keer een nieuwe waarde. Platforms herkennen wat gelijk blijft. De juiste aanpak: grenzen horen bij de isolatie van omgevingen, continuïteit bij de stabiliteit van parameters. Elk werk op zijn plek.

Twijfel je nog tussen de twee wegen, download dan MostMate en maak twee omgevingen die je langs dit artikel configureert: één blijft op de standaard Real, de andere zet je op Random, en dan test je beide na een paar dagen twee keer met een testtool. Welke set meetwaarden de controle doorstaat, is duidelijk.