Cookie-Lebensdauer: Die drei Browsergrenzen und wie die Art des Setzens sie verändert

Max-Age=63072000 fordert 730 Tage Speicherung an. Daraus folgen keine garantierten 730 Tage Wiedererkennung. Der Browser kann die Ablaufzeit begrenzen, das Cookie ablehnen oder früher entfernen. Setzverfahren, Trackingschutz, Browsermodus und Cookie-Attribute wirken zusammen.

Drei Gruppen von Grenzen

Skriptgesetzter Speicher in WebKit: ITP 2.1 führte für dauerhafte Cookies aus document.cookie eine Ablaufgrenze von sieben Tagen ein. Kürzere angeforderte Laufzeiten bleiben kürzer; Sitzungscookies sind gesondert zu betrachten. Zusätzlich besteht eine Inaktivitätslöschung für skriptgesetzte Cookies und weiteren skriptbeschreibbaren Speicher. WebKit beschreibt dafür sieben Tage Safari-Nutzung ohne Interaktion mit der Website. Ablaufdatum und Speicherlöschung sind unterschiedliche Mechanismen. Das erneute Schreiben eines Cookies entspricht keinem Klick, Tippen oder Tastatureingriff.

Verschleierte Drittanbieter-Antworten: Bei erkanntem Drittanbieter-CNAME- oder IP-Cloaking begrenzt WebKit die Ablaufzeit von Antwort-Cookies auf sieben Tage. Ein CNAME ist ein DNS-Alias; nicht jeder Alias löst diese Regel aus. Maßgeblich sind auch die Beziehung zur Erstanbieter-Domain und zum CNAME des Hauptdokuments. Ein A-Eintrag allein belegt keine Ausnahme.

Allgemeine Ablaufgrenzen: Chrome und Firefox begrenzen die Laufzeit beim Setzen auf höchstens 400 Tage. Das ist weder eine Aufbewahrungszusage noch eine Empfehlung für die Messdauer. Chrome dokumentiert die Grenze ab Version 104; aktuelle Mozilla-Implementierungsnachweise bestätigen ebenfalls die Begrenzung.

Eine Serverantwort verändert die Architektur

Der Wechsel von JavaScript zu einer Set-Cookie-Antwort kann andere Regeln zur Anwendung bringen. Ein Jahr Wiedererkennung ist dadurch nicht garantiert; Trackingschutz und Ausfallrisiken eines Endpunkts bleiben relevant. Servereigentum entspricht nicht automatisch der vom Browser bewerteten Netzbeziehung. WebKits IP-Heuristik vergleicht Adressfamilien und gemeinsame Adresspräfixe; die dokumentierten Kriterien können sich ändern.

Eine Serverantwort kann HttpOnly setzen. Seitenskripte können dieses Cookie anschließend weder lesen noch verändern. Bei passenden HTTP-Anfragen sendet der Browser das Cookie weiterhin, auch bei durch JavaScript ausgelösten Anfragen. Ein Tag mit direktem Zugriff auf die Kennung benötigt daher eine andere Architektur. HttpOnly erschwert den direkten Cookie-Diebstahl über Skriptzugriff, verhindert aber nicht jede Aktion eines eingeschleusten Skripts.

Attribute: Ablehnung und Übertragung unterscheiden

• SameSite=None verlangt in aktuellen verbreiteten Implementierungen Secure. Browserregeln können den Zugriff über Website-Grenzen trotzdem blockieren.
• SameSite=Lax verhindert nicht jede Anfrage über Website-Grenzen: Bei einer Navigation des Hauptfensters mit einer sicheren Methode wie GET kann das Cookie mitgesendet werden. Ohne Attribut kann eine Standard-Lax-Regel gelten, teilweise mit begrenzter POST-Ausnahme für gerade gesetzte Cookies.
• __Host- verlangt in unterstützenden Browsern Secure, Path=/, keinen Domain-Eintrag und eine sichere Herkunft.
• Größengrenzen unterscheiden sich im Detail. RFC 6265 empfiehlt Unterstützung für mindestens 4096 Byte einschließlich Name, Wert und Attributen. Daraus folgt keine universelle Grenze ausschließlich für Name plus Wert. Zu große Cookies können abgelehnt werden; Grenzen des gesamten Anfrage-Headers sind ein anderes Problem.
• Bei zwei gültigen Angaben hat Max-Age Vorrang vor Expires. Expires bleibt ein unterstütztes Ablaufverfahren. Die Kombination bedeutet keine Ablehnung.

Wiedererkennung ist keine Datenaufbewahrung

Nach Ablauf einer anonymen Kennung kann ein wiederkehrender Browser eine neue Kennung erhalten, sofern kein anderer zulässiger Identitätsmechanismus spätere Aktivitäten verbindet. Bereits gespeicherte Ereignisse verschwinden dadurch nicht aus der Analysedatenbank. Die Einordnung als neuer Nutzer und die Verbindung zu einer Conversion hängen von Identitätseinstellungen, verfügbaren Daten und Attributionsverfahren ab.

Kürzere Cookie-Laufzeiten können Pfade unterbrechen. Längere Berichtszeiträume werden dadurch nicht generell sinnlos. Ein verkürztes Attributionsfenster stellt fehlende Verbindungen ebenfalls nicht wieder her. Die Auswertung sollte die beobachtete Abdeckung benennen und direkt verbundene Aktivitäten von modellierten oder anderweitig verbundenen Ergebnissen unterscheiden.

Fragen und Antworten

Verlängert erneutes Schreiben die Laufzeit?

Eine erfolgreiche Aktualisierung kann innerhalb der geltenden Grenze ein neues Ablaufdatum anfordern. Durchgehende Wiedererkennung folgt daraus nicht: Frühere Löschung, eine kürzere angeforderte Laufzeit oder strengere Schutzregeln können eingreifen. Für erkanntes Tracking über verzierte Links dokumentiert WebKit außerdem eine Ablaufgrenze von 24 Stunden für JavaScript-Cookies. Eine Aktualisierung schafft keine allgemeine Ausnahme.

Entfällt bei serverseitigem Setzen die Einwilligung?

Nein. § 25 TDDDG regelt in Deutschland Speicherung auf und Zugriff auf Endeinrichtungen samt bestimmten Ausnahmen. Eine HTTP-Antwort schafft allein keine Ausnahme. Zweck und anwendbares Recht bleiben maßgeblich. Einwilligungsabhängiges Setzen und Verarbeiten müssen nach Widerruf enden. Zum Entfernen eines HttpOnly-Cookies ist eine passende Serverantwort mit übereinstimmendem Namen, Domain und Pfad sowie abgelaufener Laufzeit erforderlich. Auf die Löschung darf keine automatische Neuanlage folgen.

Was gehört in eine praktische Prüfung?

Browserstand, Datenschutzmodus, Setzweg und Einwilligungsstand dokumentieren. Angeforderte Attribute mit dem gespeicherten Cookie vergleichen und anschließend bei einer passenden Anfrage das tatsächliche Mitsenden prüfen. Bei skriptgesetzten Cookies kann ein Set-Cookie-Header fehlen. Ein angezeigtes Ablaufdatum schützt nicht nachweislich vor späterer Inaktivitätslöschung. Fehlende Cookies können durch Browserregeln, Ablehnung, Löschung oder einen falschen Speicherkontext entstehen. Auch ein leeres document.cookie beweist nicht die Abwesenheit eines HttpOnly-Cookies.

Safari-spezifisches Verhalten benötigt eine passende Safari-/WebKit-Umgebung. Desktop-Chrome validiert kein ITP. Unterschiede im Anteil wiederkehrender Nutzer belegen allein keine Ursache.

Quellen

• WebKit: Intelligent Tracking Prevention 2.1
• WebKit: Full Third-Party Cookie Blocking and More
• WebKit: Tracking Prevention
• WebKit: Private Browsing 2.0
• Chrome: Cookie expiry upper limit
• Mozilla: Cookie expiry cap implementation
• MDN: Set-Cookie
• RFC 6265: HTTP State Management Mechanism
• TDDDG § 25: Schutz der Privatsphäre bei Endeinrichtungen