How We Built a System That Scans 100,000 Websites for Cookie Consent Violations

Automatisierte Prüfung der Einwilligungskonformität klingt unkompliziert, bis man versucht, sie zu bauen. Der naive Ansatz – eine Seite abrufen, nach Cookies suchen, nach einem Banner schauen – verfehlt das meiste, worauf es ankommt. Einwilligungsverstöße sind verhaltensbasiert, nicht strukturell. Sie manifestieren sich im Timing der Skriptausführung, in der Reihenfolge der Netzwerkanfragen, in der Reaktion von UI-Elementen auf Nutzerinteraktion und in der Persistenz des Zustands über Seitenladevorgänge hinweg. Man kann nichts davon beurteilen, ohne einen echten Browser auszuführen, mit der Seite so zu interagieren, wie es ein Mensch tun würde, und aufzuzeichnen, was tatsächlich auf Netzwerkebene passiert.

Dieser Beitrag beschreibt, wie wir die Scan-Engine hinter GDPR Monitor gebaut haben, die Engineering-Herausforderungen, die den Großteil unserer Zeit in Anspruch nahmen, die architektonischen Entscheidungen, die wir getroffen haben und warum, sowie die Einschränkungen, über die wir ehrlich sind. Wenn Sie an Web-Compliance, Browser-Automatisierung oder großangelegter Web-Messung arbeiten, sollte hier etwas Nützliches für Sie dabei sein.

Die Pipeline-Übersicht

Jeder Scan durchläuft sechs Stufen. Das Verständnis der Pipeline ist notwendiger Kontext für die spezifischen Herausforderungen, die folgen.

Stufe 1: Browser-Start und Isolation. Eine frische Chromium-Instanz startet mit null Zustand – keine Cookies, kein localStorage, kein Cache, keine Service Worker. Dies ist die Reinraum-Garantie, die Pre-Consent-Messung aussagekräftig macht. Wir konfigurieren ein Standard-Viewport, realistische User-Agent- und Accept-Language-Header passend zum Zielland sowie Standard-Browser-Flags. Jeder Scan erhält seinen eigenen Browser-Prozess; es gibt keine Zustandslecks zwischen Scans. Stufe 2: Navigation und Pre-Consent-Snapshot. Der Scanner navigiert zur Ziel-URL, wartet, bis die Seite einen stabilen Zustand erreicht hat (Netzwerk-Leerlauf, DOM beruhigt) und erfasst alles, was passiert ist: gesetzte Cookies, getätigte Netzwerkanfragen (mit vollständiger URL, Timing und Antwort-Metadaten), kontaktierte Drittanbieter-Domains und ein ganzseitiger Screenshot. Dieser Snapshot beantwortet die grundlegende Frage: Was hat diese Website getan, bevor der Nutzer überhaupt die Möglichkeit hatte einzuwilligen? Stufe 3: CMP-Erkennung und Banner-Identifizierung. Der Scanner versucht, die Consent-Management-Plattform zu identifizieren und das Einwilligungsbanner, die Akzeptieren-Schaltfläche und die Ablehnen-Schaltfläche zu lokalisieren. Dies verwendet ein mehrschichtiges Erkennungssystem, das unten im Detail beschrieben wird. Stufe 4: Einwilligungsinteraktion. Der Scanner interagiert mit dem Banner – klickt auf Akzeptieren für den Standardfluss, klickt auf Ablehnen für den Ablehnungsfluss-Test. Er wartet, bis sich die Seite nach der Interaktion beruhigt hat, unter Berücksichtigung von Animationen, Skript-Neubewertung und verzögertem Tag-Auslösen. Stufe 5: Post-Consent-Snapshot und Differenzanalyse. Ein zweiter vollständiger Snapshot erfasst den Zustand nach der Einwilligungsinteraktion. Der Vergleich von Pre-Consent- und Post-Consent-Snapshots zeigt, was sich geändert hat: neue Cookies, neue Tracking-Anfragen, Einwilligungsstatus in CMP-APIs. Stufe 6: Analyse, Klassifizierung und Berichterstellung. Rohdaten fließen in Analysemodule: Cookie-Klassifizierung gegen unsere Datenbank, Tracker-Abgleich gegen bekannte Muster, Cookie-Lebensdauer-Bewertung, Barrierefreiheitsaudit des Banners, Google Consent Mode-Validierung, Fingerprint-Signal-Erkennung und Risikobewertung. Die Ausgabe ist ein strukturierter Bericht mit Befunden, Beweisartefakten und einer zusammengesetzten Risikobewertung.

Jede Stufe erzeugt zeitgestempelte Nachweise, die dauerhaft gespeichert werden. Jeder Befund kann auf spezifische Netzwerkanfragen, Cookie-Einträge oder Screenshots zurückverfolgt werden.

Herausforderung 1: CMP-Erkennung – 45 Plattformen, unendliche Variationen

Consent-Management ist nicht standardisiert. Es gibt kein universelles HTML-Attribut, keine vorgeschriebene JavaScript-API, keine einheitliche DOM-Struktur, die sagt: „Dies ist ein Einwilligungsbanner." Es gibt 45 verschiedene CMPs in unserer Erkennungsbibliothek, jedes mit eigener DOM-Struktur, Skript-Signaturen, JavaScript-Globals und Interaktionsmustern. Darüber hinaus waren 34,7 % der Banner, die wir in unserer Studie mit 97.304 Websites erkannt haben, generisch oder nicht identifiziert – benutzerdefinierte Implementierungen, regionale Anbieter oder minimale Lösungen, die keiner bekannten CMP-Signatur entsprechen.

Unsere Erkennung verwendet einen konfidenzbasierten, mehrschichtigen Ansatz:

Schicht 1: Skript-Signatur-Erkennung

Der Scanner prüft auf das Vorhandensein bekannter CMP-Skripte anhand von URL-Mustern und JavaScript-globalen Variablen. Cookiebot beispielsweise lädt von `consent.cookiebot.com` und stellt `window.Cookiebot` bereit. OneTrust lädt von `cdn.cookielaw.org` und stellt `window.OneTrust` bereit. Jedes CMP hat charakteristische Lademuster, die erkannt werden können, bevor das DOM untersucht wird.

Diese Schicht ist schnell und hochkonfident, wenn sie passt. Aber sie hat eine kritische Einschränkung: Sie sagt Ihnen, welches CMP auf der Seite vorhanden ist, nicht unbedingt, welches CMP für das Einwilligungsbanner verantwortlich ist. Eine Website könnte PiwikPRO für Analytics laden (das eine CMP-Komponente enthält), während sie tarteaucitron für das eigentliche Consent-Management verwendet. Beide Skripte zu erkennen ist einfach; zu wissen, welches das Banner kontrolliert, ist schwieriger.

Schicht 2: Verifizierter Selektor-Abgleich

Für jedes bekannte CMP pflegen wir einen kuratierten Satz von CSS-Selektoren, die den Banner-Container, die Akzeptieren-Schaltfläche und die Ablehnen-Schaltfläche zuverlässig identifizieren. Dies sind Selektoren, die wir über mehrere Versionen und Konfigurationen jedes CMP hinweg validiert haben. Wenn ein CMP in Schicht 1 erkannt wird und seine verifizierten Selektoren mit Elementen im DOM übereinstimmen, haben wir hohe Konfidenz sowohl bei der CMP-Identifizierung als auch bei den Banner-Interaktionszielen.

Schicht 3: Kompatibler Selektor-Abgleich

Ein breiterer Satz von Selektoren, die über viele Versionen eines CMP funktionieren, aber weniger präzise sind. Diese behandeln Fälle, in denen ein CMP angepasst, gestaltet wurde oder eine Version ausführt, die von unseren verifizierten Selektoren nicht abgedeckt wird. Sie tauschen Präzision gegen Abdeckung.

Schicht 4: Generische Heuristiken

Für die 34,7 % der Banner, die keinem bekannten CMP zugeordnet sind, fallen wir auf heuristische Erkennung zurück. Der Scanner sucht nach:

• Fest oder klebrig positionierten Elementen am unteren oder oberen Rand des Viewports
• Elementen mit einwilligungsbezogenen Schlüsselwörtern in mehreren Sprachen („Cookies", „Einwilligung", „Datenschutz", „akzeptieren", „accepter", „aceptar" usw.)
• Schaltflächen mit gängigen Einwilligungsaktions-Labels („Alle akzeptieren", „Alle ablehnen", „Einstellungen verwalten" und Äquivalente)
• Strukturmustern, die typisch für Einwilligungsdialoge sind: Overlay-Hintergründe, modale Container, Schließen-Schaltflächen

Diese Schicht fängt viele benutzerdefinierte Implementierungen ab, ist aber von Natur aus weniger zuverlässig. Ein fest positioniertes Werbebanner oder eine Newsletter-Anmeldung kann strukturell einem Einwilligungsdialog ähnlich sehen.

Schicht 5: CMP-API-Sondierung

Einige CMPs stellen JavaScript-APIs bereit – am bekanntesten die IAB Transparency and Consent Framework (TCF) API über `__tcfapi`. Wir sondieren diese APIs, um sowohl die CMP-Erkennung zu verifizieren als auch den programmatischen Einwilligungsstatus zu lesen, den wir später mit dem beobachteten Browserverhalten vergleichen.

Das Konfidenzmodell

Anstatt die Erkennung als binär (gefunden/nicht gefunden) zu behandeln, vergeben wir Konfidenzwerte basierend darauf, welche Schichten übereinstimmten und wie stark. Eine Website, bei der wir ein CMP-Skript erkennen, verifizierte Selektoren abgleichen und eine TCF-API finden, erhält hohe Konfidenz. Eine Website, bei der nur generische Heuristiken ausgelöst haben, erhält niedrigere Konfidenz. Dieser Konfidenzwert fließt in unsere Risiko-Klassifizierung ein – niedrigere Erkennungskonfidenz bedeutet, dass Befunde eher als nicht eindeutig statt als definitiv klassifiziert werden.

Das Konfidenzmodell ist der Grund, warum CMP-Fehlidentifikation, obwohl sie vorkommt, unsere Ergebnisse nicht systematisch verzerrt. Wenn die Erkennung mehrdeutig ist, sagen wir das, anstatt eine Klassifizierung zu erzwingen.

Herausforderung 2: Der Ablehnungsfluss – Warum „Klicken und Prüfen" überraschend schwer ist

Das Testen einer Ablehnungsschaltfläche klingt einfach: finden, klicken, prüfen ob Cookies weg sind. In der Praxis ist jeder Schritt mit Timing-Problemen, asynchronem Verhalten und plattformspezifischen Eigenheiten behaftet.

Die Ablehnungsschaltfläche finden. Nicht alle Ablehnungsschaltflächen sind als „Ablehnen" beschriftet. Sie können „Alle ablehnen", „Verweigern", „Nur notwendige Cookies", „Einstellungen verwalten" (was zu einer zweiten Ebene führt, wo Ablehnung möglich ist) oder Äquivalente in Dutzenden von Sprachen sagen. Einige CMPs platzieren die Ablehnungsoption an einer anderen visuellen Position, in einer anderen Größe oder in einer anderen Farbe als die Akzeptierungsoption. Einige verstecken sie hinter einem „Weitere Optionen"- oder „Anpassen"-Link. Unser Scanner pflegt einen mehrsprachigen Satz von Ablehnungsaktionsmustern und erkennt auch Ablehnungsoptionen in der zweiten Ebene, wenn die erste Ebene nur Akzeptieren und Anpassen anbietet. Auf den richtigen Moment warten. Nach dem Klick auf Ablehnen kann sich die Seite erheblich verändern: Das Banner wird geschlossen (oft mit Animation), das CMP löst Einwilligungsstatus-Callbacks aus, Tag Manager bewerten ihre Regeln neu und Skripte können geladen oder entladen werden. Zu frühes Prüfen der Cookies erfasst den Übergangszustand. Zu spätes Prüfen verpasst vorübergehendes Tracking, das schnell ausgeführt und abgeschlossen wird. Wir verwenden eine Multi-Signal-Wartebedingung: Netzwerk-Leerlauf, DOM-Stabilität und eine Mindestverzögerung, empirisch abgestimmt über Hunderte von CMP-Konfigurationen. Der Neulade-Test und Consent-Respawn. Der Neulade-Schritt hat Consent-Respawn als Phänomen offenbart. Wir haben nicht danach gesucht – unser ursprünglicher Ablehnungsfluss-Test prüfte nur den unmittelbaren Post-Reject-Zustand. Aber während der Entwicklung bemerkten wir Websites, die nach der Ablehnung sauber aussahen, aber nach einem Neuladen der Seite Tracking-Cookies hatten. Erstes Debugging vermutete ein Scanner-Timing-Problem. Weitere Untersuchungen bestätigten, dass es real war: Drittanbieter-Skripte, die bei jedem Seitenladen Cookies neu setzen, ungeachtet des Einwilligungsstatus.

Wir haben die explizite Respawn-Erkennung in die Pipeline aufgenommen: Nach dem Ablehnungsfluss lädt der Scanner die Seite neu, wartet auf Stabilität und vergleicht das Cookie-Inventar mit dem Post-Reject-Snapshot. Jedes Cookie, das durch die Ablehnung entfernt wurde und nach dem Neuladen wieder auftaucht, wird als Respawn markiert. Dies erfasste 1.642 Websites mit 4.932 respawnenden Cookies – ein Befund, der ohne den Neulade-Schritt unsichtbar geblieben wäre.

Die `waitForScriptIdentifiedCMP`-Abfrage. Einige CMPs laden asynchron und rendern ihr Banner erst mehrere Sekunden nach dem ersten Seitenladen. Wenn der Scanner zum Ablehnungsschritt übergeht, bevor das CMP initialisiert ist, verpasst er entweder das Banner vollständig oder interagiert mit einer teilweise geladenen Benutzeroberfläche. Wir haben einen Abfragemechanismus implementiert, der wartet, bis die JavaScript-API des CMP verfügbar ist (z. B. `__tcfapi` für TCF-basierte CMPs, `Cookiebot`-Global für Cookiebot), bevor er fortfährt. Dies fügt Latenz pro Scan hinzu, reduziert aber falsch-negative Ergebnisse durch asynchrones CMP-Laden erheblich.

Herausforderung 3: Pipeline-Sättigung im großen Maßstab

Das Scannen von 97.304 Websites ist keine Einzelmaschinen-Aufgabe. Jeder Scan startet einen Chromium-Prozess, navigiert zu einer Website, fängt Hunderte von Netzwerkanfragen ab und klassifiziert sie, erstellt mehrere Screenshots und führt Analysemodule aus. Ein einzelner Scan dauert 30-90 Sekunden je nach Komplexität der Website. Bei 15 gleichzeitigen Scans pro Worker wird das Ressourcenmanagement zum primären Engineering-Anliegen.

Die Semaphor-Architektur

Wir verwenden ein semaphorbasiertes Nebenläufigkeitsmodell, um die Anzahl gleichzeitiger Chromium-Prozesse pro Worker zu begrenzen. Jeder Worker hat ein festes Semaphor (15 Slots in unserer Produktionskonfiguration). Ein Scan belegt einen Slot vor dem Start seines Browsers und gibt ihn nach Abschluss frei. Dies verhindert Speichererschöpfung – 15 Chromium-Instanzen mit vollständiger Anfrage-Interception verbrauchen bereits erheblichen RAM – und bietet Gegendruck gegen die Redis-Warteschlange.

Die Dokumentenanfrage-Ausnahme

Früh in der Entwicklung stießen wir auf ein Durchsatzproblem: Unsere Anfrage-Interception-Logik (die jede Anfrage auf SSRF-Sicherheit prüft – Anfragen an private IP-Bereiche, interne Netzwerke und andere potenziell gefährliche Ziele blockiert) fügte jeder Ressourcenladung Latenz hinzu, einschließlich der Hauptdokumentanfrage. Da die Dokument-URL bereits vor Beginn des Scans validiert wurde, fügten wir einen Fast-Path-Bypass hinzu: Dokumenttypanfragen an die vorvalidierte Ziel-URL überspringen die vollständige Interception-Pipeline. Diese scheinbar kleine Optimierung hatte erhebliche Auswirkungen auf den Gesamtdurchsatz, da die Dokumentanfrage alles andere blockiert.

DNS-Vorwärmen

Die erste Anfrage an eine neue Domain verursacht eine DNS-Abfrage, die auf unserer Infrastruktur 50-200ms pro Domain hinzufügen konnte. Bei durchschnittlich 10,4 Drittanbieter-Domains pro Website (und einigen mit bis zu 171) akkumulierte sich die DNS-Auflösungszeit erheblich. Wir implementierten DNS-Vorwärmen mit einem lokalen Unbound-DNS-Resolver-Cache: Vor jedem Scan lösen wir die Zieldomain auf und wärmen den Cache. Die Unbound-Instanz liefert zwischengespeicherte Antworten für nachfolgende Abfragen innerhalb des Scans, wodurch der DNS-Overhead pro Domain auf unter eine Millisekunde reduziert wird.

SSRF-Sicherheit im großen Maßstab

Jede vom Scanner abgefangene Anfrage wird gegen eine Reihe von Sicherheitsregeln geprüft, bevor sie fortgesetzt werden darf. Anfragen an private IP-Bereiche (RFC 1918, RFC 4193, Link-local, Loopback) werden blockiert. Dies verhindert, dass eine bösartige Zielwebsite den Scanner als SSRF-Vektor zum Sondieren interner Netzwerke nutzt.

Die Herausforderung im großen Maßstab bestand darin, echte SSRF-Blockierungen von Semaphor-Sättigung zu unterscheiden. Wenn alle 15 Semaphor-Slots belegt sind und ein Scan keinen Slot erwerben kann, sieht das resultierende Timeout oberflächlich ähnlich aus wie eine aus Sicherheitsgründen blockierte Anfrage. Wir haben eine explizite Fehlerkategorisierung hinzugefügt, um „blockiert, weil das Ziel in eine private IP aufgelöst wurde" von „blockiert, weil der Scanner an der Kapazitätsgrenze ist" zu unterscheiden. Dies war wesentlich für das Betriebsmonitoring und für eine genaue Klassifizierung von Scan-Fehlern.

Herausforderung 4: Bot-Umgehungs-Erkennung

Während der Studie identifizierten wir 137 Websites, die ihr Einwilligungsbanner absichtlich vor automatisierten Scannern zu verbergen scheinen. Das Banner wird menschlichen Besuchern angezeigt, aber unterdrückt, wenn die Website Merkmale automatisierten Browsens erkennt.

Der häufigste Mechanismus, den wir identifizierten, betrifft die `isAcceptAllForBots`-Konfigurationsoption des RCB (Real Cookie Banner) WordPress-Plugins. Wenn aktiviert, erkennt diese Einstellung automatisierte Browser (über `navigator.webdriver`, User-Agent-Heuristiken oder Verhaltenssignale) und akzeptiert entweder automatisch die Einwilligung in ihrem Namen oder blendet das Banner vollständig aus. Die Absicht, wie vom Plugin dokumentiert, ist es, zu verhindern, dass automatisierten Besuchern ein Einwilligungsdialog angezeigt wird, mit dem sie nicht sinnvoll interagieren können. Die Wirkung ist, dass Compliance-Scanner – und Regulierungsauditoren, die automatisierte Tools verwenden – eine Website sehen, die keinen Einwilligungsmechanismus zu haben scheint, während menschliche Besucher ein vollständiges Einwilligungsbanner sehen.

Dies ist ein Transparenzproblem. Wenn der Einwilligungsmechanismus einer Website nur für menschliche Besucher sichtbar ist, kann er nicht in großem Maßstab geprüft werden. Wir kennzeichnen diese Websites in unseren Ergebnissen separat, weil der Befund qualitativ anders ist als „kein Banner erkannt". Die Website hat ein Banner; sie entscheidet sich, es uns nicht zu zeigen.

Wir erkennen Bot-Umgehung durch eine Kombination von Signalen: das Vorhandensein bekannter Bot-Erkennungskonfigurationen in CMP-Einstellungen (zugänglich über JavaScript-Inspektion), Diskrepanzen zwischen dem, was das DOM zeigt, und dem, was die API des CMP meldet, und in einigen Fällen durch den Vergleich automatisierter Scan-Ergebnisse mit manueller Verifizierung.

Die Zahl 137 ist sicherlich eine Unterschätzung. Wir können Bot-Umgehung nur erkennen, wenn wir den Mechanismus identifizieren können. Websites, die ausgefeiltere oder benutzerdefinierte Bot-Erkennung verwenden, können sowohl unseren Scanner als auch unsere Umgehungserkennung erfolgreich umgehen.

Herausforderung 5: CMP-Fehlidentifikation

Eine Website kann mehrere Skripte laden, die wie Consent-Management-Plattformen aussehen. PiwikPRO enthält eine CMP-Komponente, ist aber primär eine Analytics-Suite. Einige WordPress-Websites laden Complianz zusammen mit einem separaten Analytics-Plugin, das CMP-ähnliche Funktionen hat. Enterprise-Websites können Überreste eines früheren CMP haben, die noch neben dem aktuellen geladen werden.

Naive Erkennung – „wenn wir das Skript sehen, ist es das CMP" – erzeugt falsche Identifikationen, die sich zu falscher Banner-Interaktion kaskadieren. Wenn der Scanner PiwikPRO als das CMP identifiziert und versucht, PiwikPROs Banner-Selektoren zu verwenden, kann er das eigentliche tarteaucitron-Banner übersehen, das die Einwilligung auf der Website kontrolliert.

Unser konfidenzbasierter Ansatz adressiert dies durch Ranking der CMP-Kandidaten. Wenn mehrere potenzielle CMPs erkannt werden:

1. Wir prüfen, welches ein sichtbares Banner im DOM hat (Skript vorhanden, aber kein Banner bedeutet wahrscheinlich inaktiv oder Nicht-CMP-Nutzung).

2. Wir prüfen, welches eine aktive CMP-API bereitstellt (z. B. eine funktionierende `__tcfapi` oder Äquivalent).

3. Wir bevorzugen das CMP, dessen verifizierte Selektoren mit sichtbaren DOM-Elementen übereinstimmen, gegenüber dem, das nur durch Skript-URL erkannt wurde.

Diese Heuristik ist nicht perfekt, löste aber die häufigsten Fehlidentifizierungsfälle, auf die wir während der Entwicklung und beim Testen stießen.

Einschränkungen

Kein automatisierter Scanner repliziert perfekt jede menschliche Browsing-Erfahrung. Dies sind die bekannten Einschränkungen:

GeoIP-abhängige Banner. Einige CMPs, namentlich CookieYes, liefern unterschiedliche Einwilligungserfahrungen basierend auf der IP-Geolokation des Besuchers. Unsere Scans stammen von bestimmten Netzwerkstandorten in Europa. Eine Website, die Besuchern aus Frankreich ein Einwilligungsbanner zeigt, aber nicht Besuchern von außerhalb der EU, zeigt je nach Scan-Ursprung unterschiedliche Ergebnisse. Wir scannen derzeit nicht jede Website von jedem EU-Land aus. Geschlossenes Shadow DOM. Einige CMPs rendern ihr Banner innerhalb eines geschlossenen Shadow DOM, das für Standard-DOM-Abfragen über `document.querySelector` nicht zugänglich ist. Transcends CMP verwendet diesen Ansatz. Unser Scanner kann das Shadow-Host-Element erkennen, aber seinen Inhalt nicht inspizieren, um Akzeptieren-/Ablehnen-Schaltflächen zu finden. Diese Websites landen in unseren Ergebnissen typischerweise als nicht eindeutig. Dynamische Klassennamen und Obfuskation. Einige CMPs, namentlich Admiral, verwenden dynamisch generierte Klassennamen, die sich bei jedem Seitenladen ändern. Selektorbasierte Erkennung scheitert bei diesen, weil die Selektoren über Besuche hinweg nicht stabil sind. Wir fallen auf generische Heuristiken zurück, aber die Konfidenz ist niedriger. Single-Page-Applications. SPAs, die den Einwilligungsstatus vollständig in clientseitigem JavaScript verwalten und den Einwilligungsmechanismus nach anfänglichen Routenwechseln laden (statt beim ersten Seitenladen), sind schwieriger zu bewerten. Unser Scanner navigiert zur URL und wartet auf die Stabilisierung der Seite, simuliert aber keine In-App-Navigation. Ein Einwilligungsbanner, das erst erscheint, nachdem der Nutzer innerhalb der SPA navigiert hat, kann übersehen werden. Sprachabdeckung. Unsere Ablehnungsschaltflächen-Erkennung verwendet Textabgleich über einen Satz unterstützter Sprachen, aber wir decken nicht jede EU-Sprache gleichermaßen ab. Ein Banner auf Maltesisch oder Estnisch kann Ablehnungsschaltflächen-Beschriftungen haben, die unser Textabgleich nicht erkennt, was zu einem Versäumnis beim Ablehnungsfluss-Test führt (obwohl das Banner selbst möglicherweise noch durch strukturelle Heuristiken erkannt wird). Timing-Grenzfälle. Ein Skript, das 30 Sekunden nach dem Seitenladen ausgeführt wird, wird von einem Scan übersehen, der 15 Sekunden auf Netzwerk-Leerlauf wartet. Wir verwenden großzügige Timeouts, aber der Long Tail asynchronen Verhaltens ist von Natur aus schwer vollständig zu erfassen.

Diese Einschränkungen tragen zu unserer 14,9 % Rate nicht eindeutiger Ergebnisse bei.

Die Infrastruktur

Die Produktions-Scanning-Infrastruktur besteht aus:

• Scanner-Engine: Eine Go-Anwendung, die chromedp als CDP-Client für die Chromium-Automatisierung verwendet. Go wurde wegen seines Nebenläufigkeitsmodells gewählt (Goroutinen und Channels passen natürlich auf parallele Scan-Orchestrierung), seiner Leistungsmerkmale und seiner Einfachheit beim Deployment (einzelne statische Binary).
• Browser-Runtime: Headless Chromium, pro Scan über CDP gestartet. Jeder Scan erhält einen frischen Browser-Prozess ohne gemeinsamen Zustand.
• Warteschlange: Redis-gestützte Arbeitswarteschlange, die URLs an Scanner-Worker verteilt. Redis übernimmt Auftragsverteilung, Fortschrittsverfolgung und Ratenbegrenzung.
• Datenbank: PostgreSQL für dauerhafte Scan-Ergebnisse, Befunde, Beweis-Metadaten und alle strukturierten Daten. Scans, Befunde, Cookies, Anfragen und Analyseausgaben werden alle relational gespeichert.
• DNS-Cache: Lokaler Unbound-Resolver, der zwischengespeicherte DNS-Abfragen und SSRF-sichere Auflösung bereitstellt.
• Beweis-Speicher: Screenshots, HAR-Dateien und PDF-Berichte werden als dauerhafte Artefakte gespeichert, die mit Scan-Datensätzen verknüpft sind.

Für die Studie mit 97.304 Websites verarbeiteten wir 114.748 Kandidaten-URLs (97.304 erfolgreich abgeschlossen) über etwa 2,5 Tage mit 3 Server-Instanzen, die Scanner-Worker parallel ausführten. Jeder Server führte mehrere Worker-Prozesse mit jeweils 15 gleichzeitigen Scan-Slots aus. Der Spitzendurchsatz betrug ungefähr 25-30 abgeschlossene Scans pro Minute pro Server.

Der primäre Engpass war nicht CPU oder Speicher, sondern das Netzwerk: Jeder Scan erzeugt Hunderte ausgehender Anfragen (an die Zielwebsite und ihre Drittanbieter-Ressourcen), und die aggregierte Bandbreite und Verbindungsanzahl über alle gleichzeitigen Scans hinweg sättigte die verfügbare Netzwerkkapazität, bevor andere Ressourcen erschöpft waren.

Offene Herausforderungen und zukünftige Arbeit

Mehrere Probleme bleiben ungelöst oder teilweise gelöst:

Lokalisierung von Einwilligungsbannern. Unser Textabgleich deckt die wichtigsten EU-Sprachen ab, ist aber für kleinere Sprachgemeinschaften unvollständig. Die Erweiterung der Abdeckung erfordert nicht nur das Hinzufügen von Übersetzungen, sondern auch die Validierung, dass die Selektoren und Interaktionsmuster mit lokalisierten CMP-Versionen korrekt funktionieren. Longitudinales Monitoring. Unsere aktuelle Architektur ist für Zeitpunkt-Scans optimiert. Die Erkennung von Änderungen im Einwilligungsverhalten über die Zeit – hat sich eine Website nach Durchsetzung verbessert? Hat ein CMP-Update eine Klasse von Ablehnungsfluss-Fehlern behoben? – erfordert wiederholte Scans mit Differenzanalyse, was architektonisch anders ist als eine einmalige Bewertung. CMP-Compliance-Benchmarking. Wir haben die Daten, um CMP-spezifische Compliance-Raten zu bewerten (ist Cookiebot mit besserer Compliance verbunden als OneTrust?), aber die Entflechtung von CMP-Qualität und Konfigurationsqualität des Website-Betreibers ist methodisch komplex. Ein CMP, das häufiger von großen Unternehmen mit dedizierten Datenschutzteams eingesetzt wird, sieht in der Gesamtbetrachtung besser aus, selbst wenn das Tool selbst nicht konformer ist. Echtzeit-Einwilligungsstatus-Verifizierung. Der aktuelle Scanner arbeitet im Batch-Modus. Die Integration der Einwilligungsüberprüfung in CI/CD-Pipelines oder Echtzeit-Monitoring erfordert einen schnelleren, leichtgewichtigeren Scan-Modus, der etwas Beweistiefe für Geschwindigkeit opfert. Wir untersuchen dies.

Die API

Dieselbe Scan-Engine, die in diesem Beitrag beschrieben wird, ist über die öffentliche API von GDPR Monitor verfügbar. Sie können programmatisch Scan-Anfragen einreichen, auf Ergebnisse abfragen und strukturierte Befunde sowie Beweisartefakte abrufen. Die API gibt dieselben Daten zurück, die unsere Benutzeroberfläche anzeigt: Pre-Consent-Snapshots, Cookie-Inventare, CMP-Erkennungsergebnisse, Ablehnungsfluss-Ergebnisse, Risikobewertungen und vollständige Beweisketten.

Wenn Sie Compliance-Tools bauen, Datenschutzprüfungen in CI/CD-Pipelines integrieren, eigene Forschung betreiben oder Monitoring in ein Datenschutzprogramm einbauen, bietet die API Zugang zu verhaltensbasierter Einwilligungsanalyse, ohne dass Sie Ihre eigene Chromium-Automatisierungsinfrastruktur aufbauen und pflegen müssen.

---

Probieren Sie es selbst aus. API-Dokumentation ist verfügbar unter gdprmonitor.eu/developers/api. Reichen Sie eine einzelne URL ein oder integrieren Sie automatisiertes Datenschutz-Monitoring in Ihren Workflow.