Auf dieser Seite
Ralf Gundelach, Michael Mühlhauser, Dominik Herrmann · Full Paper, ARES 2026, 24.–27. August 2026, Linköping (Schweden)
Kurzfassung
Viele Websites setzen Bot-Erkennung ein, die automatisierte Browser blockiert – genau die Werkzeuge, mit denen die Forschung Datenschutz- und Sicherheitspraktiken im Web misst. Unser Literatursurvey zeigt, dass 83 % von 81 Measurement-Papern an Top-Venues (2020–2025) dieses Problem nicht berichten. In einer Messstudie über die Tranco Top 10.000 (vier Browser-Konfigurationen, 40.000 Seitenaufrufe) quantifizieren wir den Effekt: Chromium headless wird auf 15,2 % der Sites geblockt, die übrigen Konfigurationen auf 6,8–7,2 %; 82 % der Blocks sind auf Bot-Erkennung zurückführbar. Der resultierende Stichprobenverlust ist nicht zufällig, sondern korreliert mit dem Infrastruktur-Anbieter – und lässt sich daher nicht durch stratifiziertes Sampling korrigieren.
Kernzahlen
- 83 % der 81 untersuchten Measurement-Paper (USENIX Security, IEEE S&P, CCS, NDSS, WWW, IMC, PETS; 2020–2025) berichten Block-Raten nicht; nur 5 % quantifizieren sie.
- 772 vs. 14: Von 6.936 paarweise vergleichbaren Sites blocken 772 ausschließlich Chromium headless, nur 14 ausschließlich Chromium headed. Bei Firefox ist der Unterschied vernachlässigbar (15 vs. 12).
- 82 % der 1.554 beobachteten Blocks sind auf Bot-Erkennung zurückführbar: 59 % über Vendor-Signaturen bestätigt (Cloudflare-Challenges, DataDome, PerimeterX/HUMAN, CAPTCHA, Imperva), 23 % aus konfigurationsabhängigem Blocking abgeleitet. Nur 18 % sind uniforme Infrastruktur-Blocks.
- 75 % der ausschließlich in Chromium headless geblockten Sites lassen sich allein durch angepasste HTTP-Header entblocken (User-Agent und
sec-ch-ua-Client-Hints verraten „HeadlessChrome“); 25 % blocken auch danach – dort greifen tiefere Detection-Ebenen. - Detection-Infrastruktur ist breiter als aktives Blocking: 34 % der erfolgreich gescannten Sites prüfen
navigator.webdriver, 46 % proben mindestens ein eindeutiges Automations-Signal.
Taxonomie der Detection-Techniken
Das Paper klassifiziert client-seitige Bot-Detection auf zwei Achsen: nach der Aussagekraft der abgefragten Signale und nach der Messmethode, mit der sich diese Zugriffe beobachten lassen.
| Signal-Tier | Bedeutung | Beispiele |
|---|---|---|
| Tier 1 | Kein legitimer Zweck außer Automations-Erkennung | navigator.webdriver, window._selenium |
| Tier 2 | Starke Automations-Indikatoren, auch für Fingerprinting nutzbar | chrome.runtime, navigator.plugins |
| Tier 3 | Allgemeines Browser-Fingerprinting, nur im Kontext interpretierbar | navigator.userAgent, localStorage |
| Messmethode | Funktionsweise |
|---|---|
| Property Interception | Rekursiver JavaScript-Proxy auf window protokolliert jeden Property-Zugriff samt Zugriffspfad |
| Prototype Patching | Nicht-konfigurierbare Getter auf Built-in-Prototypen werden durch instrumentierte Versionen ersetzt |
| Honeypot Properties | Gepflanzte Schein-Properties (z. B. window._selenium), deren Abfrage Detection-Absicht belegt |
Die 28 identifizierten Tier-1-Signale verteilen sich auf acht Framework-Familien (WebDriver API, PhantomJS, NightmareJS, WebDriver Protocol, Selenium, Chrome DevTools, Awesomium, ChromeDriver). Kommerzielle Anbieter kombinieren sie mit Fingerprinting in bis zu acht Kategorien (Canvas, Audio, WebGL, Speech, Fonts, Dimensions, Permissions, Plugins).
Selbsttest: Sieht Ihr Browser wie ein Bot aus?
Der Test prüft direkt in Ihrem Browser einen Ausschnitt der client-seitig sichtbaren Signale aus der Taxonomie oben. Er läuft vollständig lokal – es werden keine Daten übertragen oder gespeichert.
Empfehlungen für Measurement-Studien
Browser-Setup berichten
Engine, Version und Display-Modus (headless/headed) dokumentieren – der Unterschied macht bis zu Faktor 2 in der Block-Rate aus.
Block-Raten quantifizieren
Die beobachtete Block- und Fehlerrate während des Crawls messen und berichten, statt sie als Rauschen zu behandeln.
CDN-Zusammensetzung dokumentieren
Der Infrastruktur-Anbieter ist ein Confounder: Cloudflare-gehostete Sites fallen systematisch häufiger aus der Stichprobe als andere.
Stealth-Maßnahmen offenlegen
Eingesetzte Gegenmaßnahmen – oder deren bewusste Weglassung – gehören in die Methodenbeschreibung.
Methodik und Limitationen
Methodik. Literatursurvey: 132 Paper gescreent, 81 eingeschlossen, 12 Kriterien, doppelt kodierte Teilstichprobe (Cohen’s κ = 0,90). Messstudie: Tranco Top 10.000 (Liste vom 25.02.2026), vier Konfigurationen im 2×2-Design (Chromium/Firefox × headless/headed, Playwright ohne Stealth-Maßnahmen), 40.000 Seitenaufrufe von Datacenter-IPs mit IP-Rotation, 27.02.–02.03.2026. Block = HTTP 403/429/503; Zuordnung zu Bot-Erkennung über manuell verifizierte Vendor-Signaturen und Cross-Condition-Analyse.
Limitationen. Einzelner europäischer Vantage-Point und einmaliger Messzeitpunkt; nur Homepages der Top 10K; erfasst werden explizite HTTP-Blocks, nicht degradierte Inhalte in 200er-Antworten; die headed-Konfigurationen approximieren menschliches Browsen nur. Die client-seitig gemessene Detection-Prevalence ist eine Untergrenze, da serverseitige Verfahren (TLS-Fingerprinting, IP-Reputation, Verhaltensanalyse) unsichtbar bleiben.
Zitieren
Camera-Ready-Version und DOI erscheinen zur Konferenz; bis dahin bitte den Preprint zitieren:
@misc{gundelach2026botdetection,
title = {Detecting Bot Detection: Prevalence, Techniques, and
Implications for Web Measurement Research},
author = {Gundelach, Ralf and M{\"u}hlhauser, Michael and Herrmann, Dominik},
year = {2026},
eprint = {2606.14525},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
note = {Angenommen bei ARES 2026}
}Crawler, Datensatz, Analyse-Notebooks und die Kodierungen des Literatursurveys sind offen verfügbar: doi.org/10.5281/zenodo.20334022 (Screenshots aus Urheberrechtsgründen ausgenommen).
