Een studie op IMC 2024 maakte van detectie een reproduceerbaar online experiment: in plaats van te vertrouwen op wat een browser zegt te zijn, telde men eigenschappen van onderliggende objecten en vergeleek die met de opgegeven versie. De methode is leerzamer dan de conclusie.
Er bestaan veel claims over de vraag of browserfingerprints detecteerbaar zijn, en de meeste blijven steken bij een conclusie. In plaats van te discussiëren over wie wint of verliest, is het nuttiger om te bekijken hoe onderzoekers de vraag omzetten in een reproduceerbaar experiment en welke maatstaven zij voor hun oordeel gebruiken.
Een studie die werd gepubliceerd op de ACM Internet Measurement Conference (IMC) 2024, met de titel Browser Polygraph, werd uitgevoerd door onderzoekers van Arizona State University, Boston University en Amazon; de DOI is 10.1145/3646547.3688455. In plaats van gesimuleerde data in een laboratorium te gebruiken, werd het systeem 4,5 maanden ingezet in de echte productieomgeving van een grote financiële onderneming en omvatte het 205.000 echte gebruikerssessies. Tien gangbare oplossingen voor het maskeren van browseromgevingen werden getest, met normaal gebruikersverkeer als controlegroep.
Hoe het experiment werd opgezet
Drie ontwerpkeuzes maakten het mogelijk om de detectie op al het verkeer toe te passen zonder de bedrijfsvoering te verstoren.
De kenmerken moesten goedkoop te meten zijn. De detector leest slechts een vaste set eigenschappen uit en de overhead per uitvoering ligt in de orde van milliseconden en KB. Daardoor kan de controle op al het verkeer worden uitgevoerd zonder steekproeven en zonder merkbaar effect voor de gebruiker.
De kenmerken moesten stabiel zijn. Er werd niet gekozen voor parameters die gebruikers kunnen aanpassen, maar voor onderliggende structuren die door de browser zelf worden vastgelegd. Elke browserversie gebruikt een andere JavaScript-engine, en tussen versies bestaan kleine verschillen in het aantal API's en het aantal eigenschappen dat aan elk object hangt. De studie gebruikte het bereik van Chrome 110 tot Chrome 114 als vergelijking: het systeem telde de eigenschappen van 28 belangrijke objecten en vergeleek het resultaat met de versie die de browser beweerde te gebruiken. Als die niet overeenkomen, komen de verklaring en het werkelijke gedrag niet uit dezelfde technische basis.
De labels moesten betrouwbaar zijn. Elke geteste omgeving werd op hetzelfde productieverkeer aangesloten en met dezelfde regels beoordeeld, terwijl de controlegroep bestond uit normaal gedrag van echte gebruikers. Het resultaat gaat dus niet om een subjectief oordeel of iets “echt lijkt”, maar om de vraag of dit verkeer met dezelfde regels te onderscheiden is.
Maatstaven om te beoordelen of de simulatie echt is
De metingen in de studie zijn in vier categorieën onder te brengen.
- Consistentie: komt de opgegeven browserversie overeen met de structuur van de onderliggende objecten? Dit is de belangrijkste maatstaf en tegelijk de moeilijkste om te vervalsen, omdat het wijzigen van een tekenreeks niet automatisch het aantal objecten en eigenschappen in de engine verandert.
- Detectiepercentage: voor vier oplossingen voerde de studie gedetailleerde experimenten uit; de detectiepercentages lagen tussen 67% en 84%.
- Afwijking van echte apparaten: onder dezelfde beslisregels kregen normale browsers een risicoscore van 0, terwijl de geteste oplossingen gemiddeld tussen 8,85 en 11,66 uitkwamen. De score geeft de afstand tot de echte verdeling weer, niet een subjectieve indruk van gelijkenis.
- Onderscheidbaarheid: kan het geteste verkeer van normaal verkeer worden gescheiden? Als een categorie niet te scheiden is, laat die onder deze methode geen gedragskloof met echte browsers zien.
Van de vier maatstaven is de eerste de oorzaak; de andere drie zijn gevolgen daarvan.
Waar de vier resultaatcategorieën van elkaar verschillen
De studie deelde de geteste oplossingen in vier categorieën in op basis van de onderliggende implementatie.
In de eerste categorie komen de low-level kenmerken met geen enkele bekende echte browserversie overeen. Er bestaat dus geen bijpassende engine; een eenvoudige scan maakt de afwijking zichtbaar.
In de tweede categorie bevat de omgeving echte fingerprintkenmerken, maar bij een identiteitswissel verandert alleen de oppervlakkige verklaring terwijl de onderliggende engine gelijk blijft. Dit was het meest voorkomende patroon in de studie. Als vergelijking: op het visitekaartje staat een nieuwe versie, maar het accent klinkt nog oud. Het probleem is niet hoe goed afzonderlijke parameters zijn afgesteld, maar de kloof tussen verklaring en gedrag; daar komt een groot deel van de detecties vandaan.
In de derde categorie wisselt de onderliggende engine mee met de identiteit. Als de omgeving een bepaalde versie claimt, draait ook de engine die bij die versie hoort. De consistentie blijft daardoor intact en deze detector kon het verkeer niet onderscheiden. Het artikel merkt daarnaast op dat voor deze categorie complexere detectiemethoden nodig zijn.
De vierde categorie verandert de browser zelf niet. Een echte browser draait in een virtuele machine en laadt daarna de doelconfiguratie. Omdat de browser werkelijk echt is, kan de detector hem niet onderscheiden, maar de operationele kosten zijn hoog en moeilijk op te schalen.
Het verschil tussen de vier categorieën zit niet in het aantal parameters, maar in de vraag of de verklaring en het gedrag uit dezelfde technische basis komen.
Praktische aanwijzingen voor het kiezen van een omgevingsoplossing
De focus van detectie is verschoven van het lezen van verklaringen naar het valideren van gedrag. Aanpasbare oppervlakkige parameters leveren daardoor steeds minder voordeel op. Voor een praktische beoordeling:
- Vraag naar de onderliggende laag, niet naar de parameterlijst. Verandert de onderliggende laag mee wanneer de opgegeven versie verandert? Worden fingerprints automatisch als echte combinaties gegenereerd of handmatig uit losse waarden samengesteld?
- Vergelijk omgevingen onderling. Als meerdere omgevingen sterk overeenkomstige low-level kenmerken teruggeven, is de isolatie niet volledig.
- Eerst consistentie, daarna differentiatie. Hoe meer intern tegenstrijdige kenmerken worden aangepast, hoe groter het blootstellingsoppervlak.
- Slagen voor een algemene detectiepagina betekent niet dat een platform de omgeving accepteert. De uiteindelijke controle moet nog steeds met een kleine hoeveelheid echt verkeer worden uitgevoerd.
Het kernprobleem van omgevingsisolatie is dat elke omgeving zelfstandig en intern consistent moet zijn. Dat is wat PurpleMark probeert te realiseren. Detectie en anti-detectie horen beide binnen toepasselijke compliancegrenzen te worden gebruikt; de echte waarde van deze studie is dat zij een onderbouwde basis voor evaluatie biedt, niet een ranglijst van goede en slechte producten.
