TL;DR: Das Drittanbieter-Cookie war ein Behälter, nie der Tracker. Regulierer und Browser haben den Behälter angegriffen — die Identifikation wanderte in den Fingerprint, die Verbindung, den Cache und die Subdomains der Website selbst. Ein sauberes Profil hinterließ null Cookies und war trotzdem einzigartig — und nur einer der Mechanismen in diesem Artikel braucht überhaupt JavaScript. „Wir nutzen keine Cookies" beantwortet eine Frage, die niemand Ernsthaftes gestellt hat.
Die Ausgangslage
Ich auditiere beruflich Websites und öffne sie deshalb so, wie ein skeptischer Besucher es tun würde: frisches Profil, kein Verlauf, keine Einwilligung, ein Seitenaufruf. Nur dieser Aufbau ist der ehrliche Test dafür, was eine Website jemandem antut, der nichts zugestimmt hat.
An einem guten Tag kommt das Cookie-Glas leer zurück, und die Website gratuliert sich selbst im Datenschutzhinweis. Im selben Seitenaufruf hat mich ein Fingerprint aus Bildschirm, Schriften und GPU längst zu einem von einer Million gemacht; der TLS-ClientHello meines Clients wurde bereits von einem Fingerprinting-Dienst stromaufwärts gehasht; und eine Subdomain der Website hat still von der Adresse eines Werbenetzwerks geantwortet. Nichts davon brauchte ein Cookie, einen Klick oder einen Dialog.
Dieser Artikel handelt von dieser Lücke. Ich habe bereits darüber geschrieben, was ein Browser preisgibt — das Live-Banner unter der Navigation dieser Website zeigt es jedem Besucher. Das hier ist die andere Hälfte: was die Gegenseite damit macht, in der Post-Cookie-Welt, in der wir tatsächlich leben.
Ich halte die technischen Aussagen reproduzierbar und das Labor lokal. Kein echter Besucher, kein Drittanbieter-Dienst wird so abgefragt, dass jemand identifiziert wird.
Das Muster
Das Denkmodell, das die meisten tragen — Tracking = Cookies — war schon immer eine Vereinfachung, und 2026 ist es schlicht falsch. Hier sind die Orte, an denen Identität heute stattdessen lebt.
Der Fingerprint, bei jedem Besuch neu berechnet
Ein Fingerprint ist keine Datei. Er ist eine Neuberechnung: Ein Skript liest Werte, die die Plattform ohnehin preisgibt — Bildschirm und Pixel-Verhältnis, Zeitzone und Sprache, CPU-Kerne und geschätzter Speicher, der WebGL-Renderer-String, die installierten Schriftarten, die exakten Pixel, die ein Canvas erzeugt — und hasht die Kombination.
Die Arithmetik ist gnadenlos. Rund 33 Bit Entropie reichen, um eine Person auf der Welt zu isolieren; eine einzelne moderne Maschine bietet aus einer Handvoll Werten routinemäßig 20 bis 30 Bit nutzbarer Eindeutigkeit. Nichts wird gespeichert, weil nichts gespeichert werden muss: Der Wert entsteht bei jedem Mal neu aus derselben Hardware. Es gibt kein Cookie abzulehnen, und „Cookies löschen" entfernt nichts davon.
Die Verbindung ist ein Identifikator, bevor JavaScript existiert
Lange bevor die Seite läuft, hat der Server bereits den TLS-Handshake des Clients gesehen — die geordnete Liste aus Ciphers, Elliptic Curves und Extensions — und dessen HTTP/2-Settings-Frame. Dieses Muster ist pro Client-Implementierung stabil und wird als JA3/JA4 (TLS) und Akamai-Fingerprint (HTTP/2) erfasst. Header-Reihenfolge und -Schreibweise fügen ein wenig mehr hinzu.
Das ist wichtig, weil es serverseitig und passiv ist. Kein Skript, kein Speicher, kein Einwilligungsdialog. Sogar ein nackter curl ist eine Signatur. Ein Tracker, der am Handshake fingerprintet, hat die Verbindung identifiziert, bevor er entscheidet, ob die Seite überhaupt relevant ist.
Client Hints öffnen wieder, was höflich geschlossen wurde
User-Agent-Strings wurden reduziert, weil sie zu viel preisgaben. Der Ersatz, Client Hints, lässt eine Website das Detail per Accept-CH-Header zurückfordern: vollständige Versionsliste, Plattformversion, Gerätemodell und mehr. Der Browser sendet diese dann bei folgenden Anfragen — ohne Dialog, ohne Einwilligung, die ein Besucher erkennen würde.
Die Entropie ist also nicht verschwunden; sie wurde zum Opt-in für die Website, nicht für den Nutzer. Eine Seite, die die alte Präzision will, fordert sie einfach an, und ein Chromium-Browser liefert. (Die Unterstützung unterscheidet sich nach Engine — was bequemerweise selbst ein Fingerprinting-Signal ist.)
Zustand versteckt sich in Caches, nicht in Cookies
„Wir nutzen keine Cookies" ist eine Aussage über eine einzige Speicher-API. Identität lebt auch in localStorage, sessionStorage, IndexedDB und der Cache API — alles Same-Origin, alles persistent, nichts davon ein Cookie, nichts davon mit Cookie-Banner. Der HTTP-Cache kann denselben Trick: Ein ETag oder eine Cache-Timing-Sonde macht aus „Habe ich diese Ressource noch?" ein stabiles Bit Zustand.
Der Behälter hat gewechselt. Der Speicher ist nirgendwohin verschwunden.
Der Tracker, der deine eigene Domain trägt
Adblocker sperren Drittanbieter-Hosts über den Namen. Die Antwort war elegant: Gib dem Tracker einen CNAME auf einer Subdomain der Website (metrics.example.com → vendor.tracker.net). Der Browser sieht jetzt einen First-Party-Host, Blocker lassen ihn in Ruhe, und die Einwilligung des Besuchers — gegeben an die Website — deckt still einen Anbieter mit ab. Zu analysieren, wo die Subressourcen einer Website tatsächlich enden, ist heute ein Schritt im Security-Review, keine Adblocker-Funktion.
Warum der Cookie-Rahmen überlebte
Weil er für alle bequem war. Für Websites sieht ein Cookie-Hinweis wie Einwilligung aus. Für Regulierer ist das Cookie ein sichtbares, lesbares Objekt. Für Anbieter war Cookie-Tracking leicht zu erklären und leicht abzurechnen. Fingerprint, Handshake und Cache haben keine dieser Eigenschaften — genau deshalb ist das Tracking dorthin gewandert.
Befunde
| Schwere | Mechanismus | Warum er zählt |
|---|---|---|
| HOCH | Serverseitiges TLS-/HTTP2-Fingerprinting (JA3/JA4) | Identifiziert auf Verbindungsebene, vor jedem Skript oder Consent — unsichtbar für Cookie-Controls |
| HOCH | First-Party-Subdomain auf Dritte (CNAME-Cloaking) | Unterläuft Hostname-Blocking; schmuggelt einen Anbieter in die Einwilligung der Website |
| MITTEL | JavaScript-Geräte-Fingerprinting (Canvas, WebGL, Schriften, Hardware) | Erkennt ohne Speicher und ohne Cookie wieder; pro Besuch neu berechnet |
| MITTEL | Client Hints (Accept-CH) | Gibt absichtlich reduziertes User-Agent-Detail wieder preis |
| MITTEL | Nicht-Cookie-Speicher (localStorage, IndexedDB, Cache API, ETag) | Persistente Identifikatoren außerhalb der Cookie-Einwilligung |
| NIEDRIG | Reduzierter User-Agent-String als Datenschutz verkauft | Versionsreduktion ohne Deaktivierung der Hints ist Kosmetik |
| INFO | „Wir nutzen keine Cookies"-Aussagen | Technisch wahr, inhaltlich irreführend |
Der Angriffspfad
- Passiv fingerprinten. Den Handshake hashen, bevor die Seite lädt. Günstig, serverseitig und außerhalb jeder Cookie-Regel, die einem Besucher je gezeigt wurde.
- In der Seite anreichern. Den JavaScript-Zensus — Canvas, Schriften, GPU — hinzufügen, um die Sicherheit von „ein Client" zu „diese Maschine" zu heben.
- Ohne Erlaubnis persistieren. Einen Cache-Eintrag oder ein
ETagnutzen, damit ein Wiedersehen auch nach dem Cookie-Löschen erkannt wird. - Den Anbieter absorbieren. Eine First-Party-Subdomain auf das Werbenetzwerk zeigen lassen, damit Blocker und die Einwilligung der Seite beide erfüllt aussehen.
- Profilieren und monetarisieren. Das Ganze zu einem Publikum kombinieren, verkaufen, und den Besucher weiter auf „Alle ablehnen" klicken lassen — was bei keinem dieser Mechanismen etwas ändert.
Reproduktion im Labor
Ich habe ein sauberes Browserprofil gegen einen kontrollierten Stack laufen lassen und in dieser Reihenfolge erfasst: das Cookie-Glas, die Drittanbieter-Anfragen, den Zensus in der Seite und die Handshake-Signatur.
| Szenario | Gemessenes Ergebnis |
|---|---|
| Frisches Profil, keine Interaktion | 0 Cookies, 0 Drittanbieter-Hosts — und ein einzigartiger Fingerprint |
| Dasselbe Profil, Cookies gelöscht, neu geladen | Fingerprint unverändert (die Hardware hat sich nicht geändert) |
| Skripte deaktiviert | Fingerprint weg; Handshake-Signatur weiterhin vorhanden |
| Nur Cookies löschen | Für die serverseitigen und Fingerprint-Schichten ändert sich nichts |
| Gehärteter Browser (Canvas-/WebGL-Widerstand) | Gerätesignal kollabiert in einen generischen Eimer |
Die letzte Zeile ist die einzige, die etwas bewegt, und sie ist eine Browser-Änderung, kein Klick. Das ist die unbequeme Zusammenfassung: Einwilligungs-Schalter sind das falsche Werkzeug für das meiste, was dich identifiziert.
Wie du es im eigenen Bestand erkennst
- Geh davon aus, dass die Verbindung beobachtet wird. Behandle JA3/JA4 und HTTP/2-Settings als Identifikator, den du weder kontrollierst noch per Richtlinie versteckst — prüfe, was dein Edge loggt und mit wem er es teilt.
- Inventarisiere Subressourcen nach ihrem Endpunkt. Verfolge jeden CNAME. Ein First-Party-Host
metrics., der bei einem Anbieter endet, ist der Befund, nicht die Fußnote. - Lies das eigene
Accept-CH. Wenn du volle Versionen und Plattformversionen anforderst, sei dir bewusst, dass du Entropie bewusst wieder geöffnet hast. - Frisches-Profil-Test pro Release. Beobachte Cookies und Speicher und Drittanbieter-Hosts beim ersten Paint — nicht nur das Cookie-Banner.
- Frag, was du wirklich brauchst. Die meisten Analysen beantworten ihre Frage mit weit weniger Entropie als ein voller Geräte-Zensus.
Wie du es behebst (in dieser Reihenfolge)
- P0 — Hör auf, Entropie anzufordern. Streiche
Accept-CH-Anfragen, die du nicht brauchst; fingerprinte nicht am Edge. - P0 — Repariere die Anbietergrenze. Keine Drittanbieter-Subressourcen, keine CNAME-auf-Anbieter-Subdomains; muss ein Dienst laufen, lass ihn First-Party unter deinem Vertrag laufen und leg ihn offen.
- P1 — Wähle datenschutzfreundliche Messung. First-Party, cookielose Analytik, die nicht wiedererkennen kann, dokumentiert im Datenschutzhinweis.
- P1 — Sende eine strikte
Referrer-Policyund kappe Metadaten-Leakage für alle stromabwärts. - P2 — Mach es sichtbar. Zeig dem Besucher, was die Seite über ihn lesen kann, und sei konkret, was den Browser verlässt. Transparenz stoppt keinen entschlossenen Tracker — sie stoppt die leisen, die annahmen, niemand prüft.
Sobald ein Angreifer Zugriff hat, kann er folgende Aktionen durchführen:
Das Fazit
Das Cookie war nie das Tracking; es war der Kassenbon. Das Tracking ist die Neuberechnung dessen, wer du bist, aus einer Maschine, die jedes Mal gleich antwortet — plus eine Verbindung, die sich identifiziert, bevor man dich fragen kann, und ein Anbieter, der sich hinter deiner eigenen Domain versteckt. Cookies zu löschen ist Hygiene. Zu verstehen, was abgeleitet wird, und es zu verweigern, ist die eigentliche Verteidigung.
Wenn dich interessiert, was dein eigener Browser auf dieser Website preisgibt: Das Banner unter der Navigation ist die Live-Version genau dieses Artikels.