Das Cookie-Gesetz Handelt Nicht Mehr von Cookies: Was Artikel 5(3) Jetzt Abdeckt

Der Begriff „Cookie-Gesetz" war schon immer eine Fehlbezeichnung. Artikel 5(3) der ePrivacy-Richtlinie hat das Wort Cookie nie verwendet — er spricht vom „Speichern von Informationen oder dem Zugriff auf bereits gespeicherte Informationen im Endgerät eines Teilnehmers oder Nutzers". Zwei Jahrzehnte lang wendeten Regulierungsbehörden diesen Text vor allem auf Cookies an, weil Cookies der dominierende Speichermechanismus waren. Diese Zeit ist vorbei.

Im Oktober 2024 hat der Europäische Datenschutzausschuss die Leitlinien 2/2023 zum technischen Geltungsbereich von Artikel 5(3) finalisiert. Die Leitlinien sind technologieneutral und erfassen ausdrücklich Tracking-Pixel, URL-basiertes Tracking, reines IP-Tracking und eindeutige Kennungen. Im April 2026 übersetzten die französische CNIL und der italienische Garante diesen Rahmen in verbindliche nationale Vorgaben zum Pixel-Tracking in E-Mails. Die Richtung ist eindeutig: Wenn eine Technik einem Server erlaubt, identifizierende Signale vom Gerät eines Besuchers zu lesen, ist eine Einwilligung erforderlich — unabhängig davon, ob etwas zurückgeschrieben wird.

Was „Zugriff erlangen" jetzt bedeutet

Artikel 5(3) stützt sich auf zwei operative Konzepte: Speicherung und Zugriff erlangen. Der Großteil der bisherigen Compliance-Arbeit behandelt nur die Speicherung als Auslöser — wenn man kein Cookie setzt, geht man davon aus, dass keine Einwilligung erforderlich ist. Die Leitlinien lehnen diese Lesart ab.

Zugriff erlangen ist erfüllt, wenn ein Server das Gerät aktiv anweist, Werte zurückzusenden. Ein Tracking-Pixel löst eine Anfrage aus, deren Query-String Kennungen trägt. Eine eindeutige URL, die in einen Newsletter eingebettet ist, löst den Empfänger auf. Eine IP-Adresse, wenn sie verwendet wird, um dasselbe Gerät über Sitzungen hinweg zu verfolgen, ist ebenfalls Zugriff — der Wert entstammt dem Netzwerk-Stack des Geräts und wird in jeder Anfrage gesendet.

Was zählt, ist der Mechanismus, nicht das Persistenzformat. Ein in einer serverseitigen Datenbank gespeicherter Fingerabdruck wird genauso behandelt wie ein im Browser gespeichertes Cookie.

Warum dies die Analytics-Tool-Landschaft neu schreibt

Viele auf Datenschutz fokussierte Analytics-Tools vermarkten sich als cookie-frei, verlassen sich aber weiterhin auf Muster, die von den Leitlinien jetzt erfasst werden:

• Serverseitige Cookies und CHIPS-artige partitionierte Kennungen. Das Verschieben des Cookies in einen partitionierten Kontext oder in einen First-Party-Server-Speicher ändert nichts an der Zugriffsfrage. Wenn dieselbe Kennung den Analytics-Server über mehrere Besuche hinweg erreicht, ist es weiterhin Zugriff.
• IP-abgeleitete Besucher-IDs. Tools, die die IP hashen und den Hash als stabile Kennung über mehrere Tage hinweg verwenden, greifen auf Informationen zu, die vom Gerät stammen. Der Rat des EDPB ist explizit: Dies erfordert eine Einwilligung, es sei denn, der Verantwortliche kann nachweisen, dass die IP nicht aus dem Endgerät des Nutzers stammte.
• Pixelbasiertes Open- und View-Tracking. Die Entscheidung Nr. 2026-042 der CNIL (14. April 2026) und die Garante-Leitlinien vom 17. April 2026 verlangen eine ausdrückliche, separate Einwilligung für individuelles Open-Tracking in E-Mails — bevor die E-Mail gesendet wird.

Das gemeinsame Muster ist eine stabile Kennung, die über Besuche, Sitzungen oder Nachrichten hinweg fortbesteht. Unabhängig von der Speicherebene erzeugt sie dieselbe regulatorische Exposition wie ein Cookie.

Der technische Test für konforme Erfassung

Die Leitlinien lassen einen schmalen Korridor: aggregierte Signale, bei denen kein vom Server gespeicherter Wert über die Zeit hinweg zu einem bestimmten Gerät zurückaufgelöst werden kann. Eine Anfrage an einen Erfassungsendpunkt trägt Werte, die in drei Kategorien fallen:

1. Transport-layer values (IP, User-Agent) the server cannot avoid receiving
2. Contextual values (path, referrer domain, country derived from IP)
3. Derived values the server chooses to produce and store

Kategorie 1 ist in TCP/HTTP unvermeidbar. Die Frage ist, wie Kategorie 3 aussieht. Wenn ein abgeleiteter Wert eine persistente Kennung ist — auch gehasht, auch mit Salt — ist es Zugriff. Wenn ein abgeleiteter Wert sich innerhalb eines begrenzten Fensters zurücksetzt und nicht über Fenster hinweg korreliert werden kann, behandelt die EDPB-Analyse ihn als aggregiert.

Der tägliche Besucher-Hash von Monoid ist gegen diesen Test konstruiert:

visitor_hash = SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

IP und User-Agent werden nur im Speicher zur Berechnung des Hashes verwendet und anschließend verworfen. Die Datumseingabe bedeutet, dass derselbe Besucher morgen einen anderen Hash erzeugt — es gibt konstruktionsbedingt keine tagübergreifende Kennung, auf die zugegriffen werden könnte. Innerhalb eines einzelnen Tages dedupliziert der Hash einen Besucher für aggregierte Zählungen; über Tage hinweg gibt es nichts, was ein Angreifer oder eine Behörde rekonstruieren könnte.

Die Header, die am Erfassungsendpunkt zählen

Zwei HTTP-Header tragen den größten Teil der Privacy-Oberfläche an einem First-Party-Edge-Collector und sollten bewusst gesetzt werden.

Referrer-Policy: strict-origin-when-cross-origin ist die moderne Chrome-Standardeinstellung und sendet bei Cross-Origin-Anfragen nur den Origin. Vermeiden Sie unsafe-url und no-referrer-when-downgrade — beide leaken unnötig Pfadinformationen.

Permissions-Policy sollte Funktionen, die der Analytics-Tracker nicht benötigt, ausdrücklich verweigern:

Permissions-Policy: geolocation=(), microphone=(), camera=(),
  payment=(), usb=(), interest-cohort=()

Ein Tracker, der weder Standort noch Audio noch Gerätesensoren anfordern kann, kann auch nicht durch ein kompromittiertes Drittanbieter-Skript auf derselben Seite dazu gezwungen werden.

Was Entwickler in diesem Quartal auditieren sollten

Drei Fragen bringen das Audit voran:

1. Erlaubt irgendein Wert, den der Analytics-Server speichert, denselben Besucher über ein 25-Stunden-Fenster zu identifizieren? Falls ja, erfordert die Installation wahrscheinlich nun eine Einwilligung nach Artikel 5(3).
2. Werden Pixel- und URL-Kennungen in Transaktions- oder Marketing-E-Mails verwendet? Nach den CNIL- und Garante-Vorgaben erfordert individuelles Open-Tracking eine separate, ausdrückliche Einwilligung, bevor die E-Mail gesendet wird.
3. Setzt der Erfassungsendpunkt eine strikte Referrer-Policy und eine standardmäßig verweigernde Permissions-Policy?

Die Frage nach dem „Cookie-Banner" ist einer grundlegenderen nachgelagert: Erzeugt das Datenmodell überhaupt eine sitzungsübergreifende Kennung? Wenn die Antwort Nein lautet, greift die gesamte Maschinerie von Artikel 5(3) — Einwilligung, Widerruf, Verarbeitungsverzeichnis — nicht, weil der technische Auslöser der Regulierung nie betätigt wurde.