Terug naar blog

Mobiele fingerprint-simulatie: parameter­verschillen met desktop

Bij mobiele fingerprint-simulatie presenteert een desktopbrowser zich als mobiel apparaat. Scherm, apparaatmodel, sensoren en touch, netwerk en provider, plus UA- en App-identificatie moeten onderling kloppen om controles te doorstaan.

Bij advertenties en accountbeheer op platforms zoals Facebook, Instagram en TikTok gedragen veel handelingen zich anders op mobiel dan op desktop: de paginalay-out verschilt, functies zijn via andere ingangen bereikbaar en platforms kunnen mobiel verkeer anders behandelen. Om zulke scenario's te testen zonder een groot aantal echte telefoons te onderhouden, moet een desktopbrowser zich als mobiel apparaat kunnen voordoen.

Dat klinkt als één aanpassing, maar in de praktijk moet een hele set parameters op elkaar worden afgestemd. De geloofwaardigheid van een mobiele omgeving hangt ervan af of die parameters samen logisch zijn.

Waar mobiel en desktop verschillen

Het scherm is het meest voor de hand liggende verschil. De logische resolutie en viewportbreedte van mobiele apparaten liggen ver van desktopwaarden, en zelfs bij hetzelfde model kan de bruikbare viewport per OS-versie verschillen. Als de scherminstellingen niet kloppen, blijven latere aanpassingen onnatuurlijk aanvoelen.

De tweede laag bestaat uit apparaatmodel en hardwareklasse. Platforms kunnen het model gebruiken om in te schatten in welke klasse een apparaat valt en op basis daarvan een bepaalde pagina- of contentversie tonen. Model, pixel ratio, geheugen en grafische parameters moeten bij elkaar passen. Een naam van een high-end model combineren met hardwarekenmerken van een instapmodel is op zichzelf tegenstrijdig.

Sensor- en touchkenmerken worden gemakkelijk over het hoofd gezien. Echte telefoons hebben een gyroscoop en versnellingsmeter, en touch events kunnen druk, contactoppervlak en multi-touch bevatten; desktopbrowsers bieden dit standaard niet. Als alleen de UA naar een mobiele UA wordt gewijzigd, kan een controle van touch events de afwijking al zichtbaar maken. Voor deze laag zijn geloofwaardige sensorwaarden en touch-eventpatronen nodig, niet alleen een paar ingeschakelde opties.

Netwerktype en provider zijn eveneens onderdeel van de fingerprint. Mobiele apparaten gebruiken vaak een mobiel netwerk en een pagina kan soms providernaam, verbindingstype of zelfs signaalgerelateerde gegevens lezen. Als een omgeving beweert bij een bepaalde provider in een land te horen, terwijl de uitgaande verbinding via een datacenter-IP loopt, is die combinatie op echte apparaten ongebruikelijk en verdient zij een aparte controle.

De laatste laag is de user agent en apparaatidentificatie, en voor veel gebruikers is dit de enige laag die ze veranderen. De UA moet passen bij apparaatmodel, OS-versie en browserversie. Een WebView-identificatie binnen een App en een normale browseridentificatie zijn bovendien twee verschillende dingen; platforms kunnen hiermee afleiden of een bezoek vanuit een App of rechtstreeks vanuit een browser is geopend. Door beide te mengen, worden sporen van een samengesteld profiel zichtbaar.

Zo controleer je de consistentie

Controleer de parameters na het instellen in een vaste volgorde. De volgorde is belangrijk, omdat een probleem vroeg in de keten zich vaak voordoet als een probleem later in de keten.

Begin met de apparaatidentiteit: controleer of besturingssysteem, apparaatmodel, resolutie en pixel ratio die de testpagina leest overeenkomen met de configuratie, en of model en OS-versie in de UA daarmee kloppen. Controleer daarna tijdzone en taal. Beide moeten bij de doelmarkt van het account passen, terwijl geolocatie en uitgaande regio eveneens in hetzelfde gebied horen te liggen; tegenstrijdigheden tussen deze gegevens zijn veelvoorkomende signalen. Bekijk vervolgens de netwerkgroep: is de uitgaande IP residentieel of een datacenter-IP, past providerinformatie bij de IP-toewijzing en lekt WebRTC een adres dat duidelijk niet bij de omgeving hoort? Controleer ten slotte of touch events, sensorwaarden en de lettertypeset eruitzien zoals bij een mobiel apparaat.

Als enkele onderdelen niet kloppen, zoek dan eerst welke parameter botst met het totale profiel in plaats van de omgeving telkens opnieuw op te bouwen. Opnieuw opbouwen lost interne tegenstrijdigheden tussen parameters niet op.

Nog een belangrijk punt: een afwijking op een externe fingerprint-testpagina betekent niet automatisch dat de omgeving zelf fout is. Testsites verzamelen gegevens op verschillende manieren; sommige lezen browserkenmerken met scripts, andere bekijken request headers. Daardoor kan dezelfde omgeving op verschillende sites verschillende resultaten krijgen. Browserextensies kunnen veranderen wat een pagina uitleest, en een verouderde IP-database kan een residentieel IP verkeerd lokaliseren. Eén regelmatig bijgewerkte, betrouwbare testsite als referentie gebruiken is nuttiger dan voortdurend resultaten van meerdere sites vergelijken.

Mobiele simulatie vervangt geen echt apparaat

Sommige scenario's vereisen nog steeds fysieke apparaten: tests met echte sensordata, camera of volledige gyroscoopfuncties; risicocontroles waarbij een platform zeer hoge eisen stelt aan apparaatauthenticiteit en in de App controleert; en validatie met echte betalingen of een echt providernetwerk. Daarnaast bestaan sommige platformfuncties alleen in de native client en niet op het web, zodat een gesimuleerde omgeving ze niet kan afdekken.

Een praktische taakverdeling is: mobiele scenario's die via het web getest kunnen worden gaan naar de simulatieomgeving, terwijl hardware- en App-laagvalidatie op echte apparaten gebeurt. De twee vullen elkaar aan en vervangen elkaar niet.

Veelgestelde vragen

Is alleen de UA wijzigen genoeg om detectie te doorstaan Meestal niet. De UA is een van de eenvoudigste parameters om los te wijzigen en ook een van de eenvoudigste om kruislings te controleren. Als resolutie, lettertypen, taal, tijdzone en touchmogelijkheden niet overeenkomen, valt de afwijking snel op.

Moet één account vast op mobiel of desktop blijven Consistentie heeft de voorkeur. Als hetzelfde account steeds tussen twee apparaatklassen wisselt, kan dat op zichzelf een ongebruikelijk signaal zijn. Laat het apparaattype van de omgeving aansluiten bij het normale gebruik van het account.

Waar moet je voor compliance op letten Gebruik dit alleen voor het testen van accounts die je zelf beheert en voor je eigen bedrijfsprocessen. Gebruik het niet om een apparaatidentiteit te vervalsen om platformcontroles te omzeilen en niet voor frauduleuze activiteiten.

Tot slot

Bij mobiele fingerprint-simulatie draait het niet om één parameter, maar om de consistentie van de volledige set met de apparaatidentiteit en doelmarkt. Scherm, model, sensoren, netwerk en UA moeten elk logisch zijn en elkaar niet tegenspreken. Beheer mobiele en desktopomgevingen apart, houd één account op lange termijn aan een stabiel apparaatprofiel en gebruik een afzonderlijke uitgaande verbinding die bij de regio past. Omgevingsbeheertools zoals PurpleMark kunnen apparaat- en systeemparameters, proxy en startpagina bij het maken van een omgeving aan elkaar koppelen en bij elke start dezelfde instellingen herstellen, zodat herhaald configureren niet nodig is.