Browsers die door Selenium worden gestart kunnen verschillen in debugpoorten, eigenschappen die een pagina kan uitlezen en de manier van opstarten. Sommige verschillen zijn redelijk te configureren; pogingen om automatisering zelf te verbergen zijn kwetsbaar, onnodig en vaak weinig effectief.
Bij automatisering met Selenium kan de scriptlogica correct zijn terwijl het gewenste resultaat toch uitblijft. Veel mensen proberen dan eerst één of twee parameters aan te passen, maar wat een omgeving werkelijk opvallend maakt is meestal geen enkele schakelaar. Het gaat vaak om een combinatie van verschillen op meerdere niveaus. Door die niveaus apart te bekijken wordt duidelijker wat zinvol is om te configureren en wat waarschijnlijk weinig oplevert.
Debugpoorten en runtime-artefacten
De manier waarop Selenium een browser bestuurt laat twee soorten sporen achter. Ten eerste kan de browser bij het opstarten een debugpoort openen waarmee externe software de pagina kan overnemen. Ten tweede kunnen er extra elementen in de runtime-omgeving verschijnen, zoals globale variabelen met het voorvoegsel cdc_ die door de driver zijn geïnjecteerd, extra driverobjecten op window en gewijzigde delen van bepaalde objectprototypes.
Deze elementen komen niet van de webpagina, maar van de driver zelf. Als de browser op de standaardmanier wordt gestart, zijn ze aanwezig ongeacht hoe goed het script is geschreven.
Eigenschappen die de pagina kan uitlezen
Een andere categorie sporen zit niet in de driver, maar in de JavaScript-omgeving die door de pagina kan worden uitgelezen. Het meest genoemde voorbeeld is navigator.webdriver.
Deze eigenschap kan drie waarden hebben. true betekent dat de browser door een automatiseringstool wordt bestuurd, false betekent dat dit niet zo is en undefined betekent dat de betreffende informatie niet beschikbaar is, meestal omdat de browser de eigenschap niet blootstelt of omdat deze is bewerkt. Bij normaal menselijk gebruik is de waarde false of undefined, terwijl Selenium bij een standaardstart true gebruikt.
Daaromheen bestaat een bredere set parameters: User-Agent, besturingssysteem en browserversie, schermresolutie, tijdzone, taal, Canvas, WebGL, AudioContext, lettertypenlijst, GPU-model en aantal CPU-kernen. Samen vormen ze wat doorgaans een browserfingerprint wordt genoemd. Echte gebruikers hebben van nature uiteenlopende fingerprints omdat hun systemen, software en gewoonten verschillen. Browsers met standaard automatiseringsinstellingen leveren daarentegen makkelijker sterk vergelijkbare combinaties op, waardoor ze eenvoudiger in bekende patronen kunnen worden gegroepeerd.
Verschillen door opstartmodus en renderingstiming
De derde categorie hangt niet aan één afzonderlijke eigenschap, maar aan de totale manier waarop de browser wordt gestart en gerenderd.
Opstarten met automatiseringsflags, draaien in headless-modus, niet overeenkomende venster- en schermparameters, onlogische combinaties van lettertyperendering en grafische drivers of een te gelijkmatige tijdsverdeling van laden tot interactie zijn op zichzelf geen bewijs. Samen kunnen ze echter een omgeving vormen die weinig lijkt op een omgeving die door een echte gebruiker wordt gebruikt.
Headless is hiervan een typisch voorbeeld. De headless-modus van recente Chrome-versies lijkt veel meer op een normale browser dan enkele jaren geleden, maar kan nog steeds gemakkelijker automatiseringskenmerken tonen dan de gewone modus, vooral op sites met strenge risicocontroles.
Wat redelijkerwijs kan worden geconfigureerd
Tijdzone, taal, schermresolutie en lettertypenlijst zijn niet uniek voor automatisering. Echte apparaten verschillen hier van nature ook in. Waar het om gaat is interne consistentie: de tijdzone moet passen bij de regio van de netwerkuitgang, de taal bij de gebruikelijke regio en de resolutie mag niet botsen met het hardwareprofiel.
Met andere woorden: het doel is niet om de omgeving bijzonder te laten lijken, maar om haar intern logisch te maken. Als een apparaat eruitziet alsof het vanuit Duitsland verbinding maakt, terwijl de browser een tijdzone van de Amerikaanse westkust meldt, alleen Engels als systeemtaal heeft en een schermresolutie gebruikt die typisch is voor een virtueel display, dan is die combinatie al opvallend genoeg.
Daarom kunnen omgevingsinstellingen het best persistent worden opgeslagen. Vandaag de tijdzone aanpassen en morgen de taal vergeten kan meer inconsistentie veroorzaken dan helemaal niets wijzigen.
Wat automatisering zelf probeert te verbergen en waarom dat niet de moeite waard is
Een andere groep technieken richt zich rechtstreeks op de sporen: navigator.webdriver verwijderen, door de driver geïnjecteerde variabelen wissen, driverobjecten verbergen of op een andere manier voorkomen dat een detector de automatiseringsstatus kan lezen.
Het probleem is dat zulke technieken alleen de buitenkant veranderen. Detectie kijkt al lang niet meer naar slechts één eigenschap; het uitlezen van attributen is slechts de meest oppervlakkige laag. Een driverupdate, een andere uitvoeringsvolgorde van het detectiescript of een detector die JavaScript omzeilt en direct lage-niveau renderingresultaten en combinaties van apparaateigenschappen bekijkt, kan eerdere aanpassingen onbruikbaar maken. De onderhoudskosten blijven hoog terwijl het voordeel verder afneemt.
Praktisch gezien vallen zulke handelingen bovendien vaak precies in het gebied dat platformvoorwaarden omschrijven als het omzeilen van technische beschermingsmaatregelen. Netjes geschreven code verandert de aard van de handeling niet doordat een paar eigenschappen zijn aangepast.
De netwerklaag valt buiten de controle van het script
Zelfs als de browseromgeving consistent lijkt, kan de netwerklaag de sessie nog steeds herkennen. Daarbij kan worden gekeken of een IP bij een datacenter, cloudserver of proxynetwerk hoort, naar de historische reputatie en ASN van het IP-bereik, geolocatie, de verzoekdichtheid vanaf hetzelfde IP en of dat IP in korte tijd meerdere accounts of pagina's bezoekt. Ook Cookies, Sessions en de aanmeldstatus in verzoeken kunnen met elkaar worden gecorreleerd.
Dit kan niet in het script worden opgelost en moet op omgevingsniveau worden geregeld: een aparte uitgang per taak, overeenstemming tussen de regio van de uitgang en de regio van de omgeving, en beheersbare request pacing. Bij het isoleren van meerdere taken werken mogelijkheden zoals PurpleMark doorgaans op dit niveau door elke taak een onafhankelijke browseromgeving en netwerkuitgang te geven en geografische parameters consistent te houden.
Praktische volgorde voor probleemonderzoek bij blokkering
Een redelijke volgorde is: controleer eerst de netwerklaag op IP-type, stabiliteit en geografische consistentie; kijk daarna of tijdzone, taal, resolutie en lettertypen binnen de omgeving met elkaar kloppen; onderzoek vervolgens het gedragstempo, bijvoorbeeld of wachttijden altijd vast zijn of invoer onmiddellijk wordt voltooid; en bekijk pas daarna de automatiseringseigenschappen op driverniveau.
De reden is eenvoudig: driverartefacten zijn al lang niet meer het belangrijkste aandachtspunt van detectie. Ze als eerste onderzoeken kost meestal vooral tijd.
Grenzen
Technische maatregelen kunnen de kans op herkenning verkleinen, maar sommige grenzen mogen niet worden overschreden: volg de robots-regels en gebruiksvoorwaarden van de doelsite, verzamel geen persoonsgegevens, omzeil geen technische beschermingsmaatregelen, beperk de verzoekfrequentie en verstoor de normale werking van de dienst niet.
