Wer eine Webseite auf Datenschutz-Konformität prüfen will, greift typischerweise zu einem der vielen Online-Scanner. Man gibt eine URL ein, wartet ein paar Sekunden, bekommt eine Liste von Cookies. Das Problem: Diese Liste ist fast immer unvollständig.
Der Grund liegt in der Art, wie moderne Webseiten funktionieren. Ein statischer HTTP-Request — also das, was die meisten Scanner machen — sieht nur das, was der Server direkt ausliefert. Doch ein Großteil der Cookies und externen Verbindungen entsteht erst durch JavaScript-Ausführung im Browser. Google Analytics setzt seine Cookies nicht über HTTP-Header, sondern über ein JavaScript, das erst geladen, geparst und ausgeführt werden muss. Ein statischer Scanner sieht davon nichts.
Wir wollten herausfinden, was wirklich passiert, wenn jemand eine Webseite besucht. Nicht auf einer Webseite. Auf tausenden.
Das Problem mit der Startseite
Die meisten Analyse-Tools prüfen ausschließlich die Startseite. Das klingt vernünftig, übersieht aber einen wesentlichen Punkt: Viele Webseiten laden datenschutzrelevante Dienste erst auf Unterseiten. Ein Kontaktformular bindet Google reCaptcha ein. Eine Anfahrtsseite lädt Google Maps. Ein eingebettetes Video auf einer Unterseite aktiviert YouTube-Tracking.
In unserer Analyse der Webseiten von Bundestagsabgeordneten zeigte sich das besonders deutlich am Beispiel von Josef Rief: Erst nach über 200 analysierten Unterseiten fanden wir Facebook-Einbindungen, die personenbezogene Daten weiterleiteten. Ein Startseiten-Scan hätte seine Webseite als unauffällig eingestuft.
Unsere Engine navigiert deshalb über konfigurierbare Seitentiefen hinweg. Sie erkennt interne Links, folgt ihnen und protokolliert für jede einzelne Unterseite, welche Cookies neu gesetzt und welche externen Verbindungen aufgebaut werden. In manchen Analysen besucht die Engine über tausend Unterseiten einer einzigen Webseite.
Zwei Browser, unterschiedliche Ergebnisse
Beim Entwickeln der Engine stellten wir eine Hypothese auf: Verschiedene Browser-Engines setzen Cookies unterschiedlich. Um das zu überprüfen, ließen wir zwei Engines parallel auf dieselbe Webseite los — Puppeteer auf Chromium-Basis und Playwright als Multi-Engine-Lösung.
Die Hypothese bestätigte sich. Systematische Vergleichstests an mehreren hundert Webseiten zeigten, dass bestimmte Tracking-Mechanismen browser-spezifisch sind. Was in Chromium gesetzt wird, muss in einer anderen Engine nicht identisch sein. Bestehende Tools wie Cookiebot oder OneTrust verwenden nur eine einzige Browser-Engine und können diese Unterschiede nicht erkennen.
Cookie-Normalisierung
Ein Google-Analytics-Cookie heißt nicht einfach _ga. Er heißt _ga_A1B2C3D4E5, wobei der Suffix für jede Webseite individuell ist. Matomo generiert _pk_id.7.a4c3, Hotjar setzt _hjSessionUser_3218564. Derselbe Cookie-Typ erscheint auf jeder Webseite unter einem anderen Namen.
Für eine einzelne Webseite ist das irrelevant. Für eine systematische Analyse von tausenden Webseiten ist es ein fundamentales Problem. Ohne Normalisierung wäre jeder Cookie ein Unikat. Man könnte nicht sagen: „Dieser Cookie ist Google Analytics" — man hätte nur eine Liste individueller Zeichenketten.
Durch systematische Analyse tausender Cookie-Namen haben wir Muster identifiziert, die es ermöglichen, den dynamischen Tracking-ID-Anteil vom semantischen Cookie-Namen zu trennen. Für die gängigsten Analytics- und Marketing-Dienste haben wir Parsing-Regeln entwickelt und iterativ verfeinert:
_ga_XXXXXXXXXX→_ga_*(Google Analytics)_pk_id.X.XXXX→_pk_id.*(Matomo)_hjSessionUser_XXXXXX→_hjSessionUser_*(Hotjar)mp_XXXXXXXXXX_mixpanel→mp_*_mixpanel(Mixpanel)
Das Ergebnis: Aus über 10.000 individuellen Cookie-Instanzen konnten wir die tatsächlichen Cookie-Typen extrahieren. Wird eine neue Webseite gescannt und ein bekannter Cookie-Typ erkannt, kann sofort eine Einordnung erfolgen — unabhängig von der individuellen Konfiguration der jeweiligen Webseite.
Was HTTP-Header verraten
Neben Cookies und JavaScript-Verhalten erfasst die Engine systematisch HTTP-Response-Header. Diese verraten oft mehr über die technologische Infrastruktur einer Webseite, als deren Betreibern bewusst ist.
Der Server-Header gibt preis, ob Apache, nginx oder ein anderer Webserver läuft. X-Powered-By verrät die Backend-Technologie. CF-Cache-Status zeigt, dass Cloudflare im Einsatz ist. X-Akamai-Cache weist auf Akamai als CDN hin. Via-Header offenbaren Reverse Proxies.
Diese Technologie-Erkennung liefert den Kontext für die datenschutzrechtliche Bewertung. Wenn eine Webseite Cloudflare als CDN nutzt, werden sämtliche Anfragen über Cloudflare-Server geroutet — ein Umstand, der für die DSGVO-Bewertung relevant sein kann, aber von reinen Cookie-Scannern nicht erfasst wird.
Die Wissensdatenbank
Die Erkennung von Cookies und externen Verbindungen ist nur die halbe Arbeit. Die andere Hälfte: Verstehen, was sie bedeuten.
Wir haben eine Wissensdatenbank aufgebaut, in der über 8.000 Cookie-Typen und mehr als 10.000 externe URLs systematisch erfasst und klassifiziert sind. Jeder Eintrag enthält den Zweck (Session-Management, Analytics, Marketing, Personalisierung), den Anbieter und dessen Datenverarbeitungspraktiken, die Speicherdauer und die DSGVO-Einschätzung: Ist dieser Cookie ohne Einwilligung zulässig (Art. 6 Abs. 1 lit. f — berechtigtes Interesse) oder ist eine Einwilligung erforderlich (Art. 6 Abs. 1 lit. a)?
Die Klassifizierung ist nicht trivial. Viele Cookies sind schlecht oder gar nicht dokumentiert. Ihre Funktion musste durch Reverse Engineering, Traffic-Analyse und systematische Vergleiche ermittelt werden. Bestehende öffentliche Cookie-Datenbanken wie Cookiepedia enthalten zwar Beschreibungen, bieten aber keine systematische DSGVO-Klassifizierung mit der Unterscheidung „zulässig ohne Einwilligung" versus „einwilligungspflichtig".
Die Datenbank verknüpft drei Entitäten: Webseiten, Cookies und externe URLs. Ein Cookie wird mit den externen Diensten verknüpft, über die er gesetzt wird. Externe URLs werden den Technologien und Skripten zugeordnet, über die sie eingebunden sind. So entsteht ein dreidimensionales Bild: Welcher Cookie stammt von welchem Dienst, der über welches CDN eingebunden wird — und wie ist jede dieser Ebenen datenschutzrechtlich zu bewerten?
Skalierung
Ein einzelner Webseiten-Scan dauert je nach Umfang unterschiedlich lang. Kleine Webseiten sind in Minuten erfasst, komplexe Auftritte mit vielen Unterseiten beschäftigen die Engine über Stunden. Um tausende Webseiten in vertretbarer Zeit zu analysieren, war ein prioritätsbasiertes Queuing-System notwendig.
Bis zu sechs Webseiten werden parallel verarbeitet. Jobs werden persistent gespeichert und bei Ausfällen automatisch neu gestartet. Hängende Browser-Prozesse — ein unvermeidliches Problem bei automatisierter Browser-Steuerung — werden nach zwölf Stunden beendet und als fehlgeschlagen markiert. Dazu kommen Timeout-Handling für nicht reagierende Server, Erkennung von HTTPS-Fehlkonfigurationen, Auflösung von Redirect-Ketten und Erkennung von Cloudflare-Turnstile-CAPTCHAs, bei denen ein automatisierter Scan naturgemäß scheitern muss.
Die technische Herausforderung lag weniger in den einzelnen Komponenten als in deren Zusammenspiel: Race Conditions bei parallelen Schreibzugriffen vermeiden, hängende Browser-Prozesse sauber terminieren, Netzwerkfehler von tatsächlichen Webseiten-Problemen unterscheiden.
Insgesamt haben wir mit diesem System bisher über 12.000 Webseiten analysiert.
Was wir gefunden haben
Die Ergebnisse unserer bisherigen Analysen sind in separaten Artikeln dokumentiert.
In unserer Analyse von 1.536 Webseiten Wiener Ärztinnen und Ärzte setzten 49 % der Webseiten bereits beim ersten Seitenaufruf Cookies ohne Einwilligung. Der Google-Analytics-Cookie _ga wurde auf 187 Webseiten gefunden, ohne vorherigen Consent. 655 Webseiten luden Google Fonts von externen Servern. Bei Arzt-Webseiten ist das besonders brisant: Schon der Besuch einer Fachärzte-Webseite kann Rückschlüsse auf den Gesundheitszustand ermöglichen — und wenn dabei Google Analytics ohne Consent läuft, wandern diese Informationen direkt an Google.
Bei der Untersuchung der Webseiten aller Bundestagsabgeordneten verstießen 513 von 709 Abgeordneten (72 %) gegen die DSGVO — jenes Gesetz, bei dessen Erlassung sie selbst mitverantwortlich waren. Nur 196 gestalteten ihre Webseiten datenschutzkonform.
Das wiederkehrende Muster über alle Analysen hinweg: Google-Dienste dominieren. Google Fonts, Google Analytics, Google Maps, Google Tag Manager, Google reCaptcha. In der Wiener Ärzte-Analyse belegten Google-Dienste die ersten sieben Plätze der am häufigsten ohne Einwilligung geladenen externen Ressourcen.
Strukturelle Ursachen
Die Ursachen liegen selten in böser Absicht. Web-Agenturen implementieren Standardkonfigurationen, die Google Analytics einbinden, ohne die datenschutzrechtlichen Konsequenzen zu prüfen. Homepage-Baukästen wie Wix setzen eigene Cookies, ohne dass der Betreiber darauf Einfluss hat — wie etwa der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit in seinem Tätigkeitsbericht 2022 angemerkt hat: Neue Angebote sind oft deshalb zunächst datenschutzrechtlich problematisch, weil sie häufig mittels vorgefertigter Baukastensysteme erstellt werden, welche von Haus aus unnötige Cookies nutzen und externe Dienste einbinden.1
WordPress-Plugins laden externe Ressourcen nach, die der Betreiber nie bewusst eingebunden hat. Und Cookie-Banner werden zwar angezeigt, sind aber technisch oft wirkungslos — die Cookies werden unabhängig von der Nutzerentscheidung gesetzt. All das lässt sich mit einem einzelnen manuellen Scan nicht erfassen. Es zeigt sich erst in der systematischen, automatisierten Analyse im großen Maßstab.
Footnotes
-
«Grundsätzlich ist anzumerken, dass neue Angebote oft deshalb zunächst datenschutzrechtlich problematisch sind, weil sie häufig mittels vorgefertigten Baukastensystemen erstellt werden, welche nicht selten von Hause aus unnötige Cookies nutzen und externe Dienste einbinden.» — Prof. Ulrich Kelber: Tätigkeitsbericht für den Datenschutz und die Informationsfreiheit 2022 ↩