Wie partitionierte CHIPS-Cookies jeder Site ein eigenes Glas geben

Was sind partitionierte CHIPS-Cookies?

Browser bewahren partitionierte CHIPS-Cookies in einem eigenen Glas für jede Top-Level-Site auf, sodass das Cookie, das ein Support-Widget eingebettet auf retail.example setzt, für dasselbe Widget eingebettet auf news.example unlesbar ist. CHIPS steht für Cookies Having Independent Partitioned State und läuft über ein einziges Opt-in-Attribut: Fügen Sie Partitioned zum Set-Cookie-Header hinzu, und der Browser speichert das Cookie unter zwei Schlüsseln statt unter einem, dem Host, der es gesetzt hat, plus der Top-Level-Site, unter der es gesetzt wurde. Setzen Sie es bei jedem seitenübergreifenden Cookie ein, das auf eine einzige Top-Level-Site beschränkt ist, etwa eine Chat-Sitzung, ein Load-Balancer-Hinweis eines CDN oder ein gespeicherter Kartenstandort.

Das doppelte Schlüsseln trennt CHIPS vom einfachen Third-Party Cookie, das mit dem Embed überallhin reist und seitenübergreifendes Tracking antreibt. Ein partitioniertes Cookie kann die Site nicht verlassen, auf der es entstanden ist, ein Embed bekommt also pro Top-Level-Site eine frische Kennung und nichts, was sich darüber hinweg verknüpfen ließe. Wenn die beiden Kategorien ineinander verschwimmen, beginnen Sie bei First-Party und Third-Party Cookies.

Was verlangt das Attribut Partitioned?

Das Attribut Partitioned verlangt Secure, und Browser werfen jedes partitionierte Cookie weg, das ohne Secure ankommt. Der CHIPS-Explainer der W3C Privacy Community Group weist Implementierer an: "User agent must reject any cookie set with Partitioned that does not also include the Secure." Auf Deutsch: Der User Agent muss jedes Cookie ablehnen, das mit Partitioned gesetzt wird und nicht auch Secure enthält. Googles Privacy-Sandbox-Dokumentation wiederholt es für Entwickler: "Partitioned cookies must be set with Secure.", partitionierte Cookies müssen also mit Secure gesetzt werden. Der IETF-Entwurf draft-cutler-httpbis-partitioned-cookies-01 vom 10. November 2022 nennt den Grund in seinen Sicherheitsüberlegungen: "This proposal takes the opportunity of defining the semantics of a new cookie attribute in order to require the Secure attribute, restricting this feature to secure protocols." Auf Deutsch: Dieser Vorschlag nutzt die Gelegenheit, die Semantik eines neuen Cookie-Attributs zu definieren, um das Secure-Attribut zu verlangen und diese Funktion auf sichere Protokolle zu beschränken.

Das Path=/ in jedem offiziellen Beispiel stammt aus einer zweiten Regel, die das Namenspräfix __Host- trägt und nicht Partitioned selbst. RFC 6265bis, Entwurf 22 vom Dezember 2025, Abschnitt 4.1.3.2 definiert sie: "If a cookie's name begins with a case-sensitive match for the string __Host-, then the cookie will have been set with a Secure attribute, a Path attribute with a value of /, and no Domain attribute." Auf Deutsch: Beginnt der Name eines Cookies unter Beachtung der Groß- und Kleinschreibung mit der Zeichenkette __Host-, dann wurde das Cookie mit einem Secure-Attribut, einem Path-Attribut mit dem Wert / und ohne Domain-Attribut gesetzt. Nennen Sie das Cookie __Host-something, und der Browser erzwingt Path=/ für Sie und lehnt alles andere ab. Der CHIPS-Explainer empfiehlt das Präfix, ohne es zu verlangen: "Although it is not required, it is still recommended to still include the __Host- prefix." Browser, die Partitioned ignorieren, erzwingen __Host- trotzdem, das Präfix kauft also Host-Bindung auf Clients, die nie von CHIPS gehört haben.

SameSite ist das dritte Stück. Der Explainer sagt, User Agents dürfen Partitioned nur akzeptieren, wenn SameSite auf None steht, und ein Cookie, das in einem seitenübergreifenden Frame funktionieren soll, braucht ohnehin SameSite=None. Wie die Attribute zusammenwirken, steht im Einsteigerleitfaden zu Browser-Cookies.

Was genau ist der Partitionsschlüssel?

Der Partitionsschlüssel ist die Site der Seite in der Adressleiste, nicht die Site des Embeds. Der CHIPS-Explainer definiert ihn genau: "A cookie's partition key is the site (i.e. scheme and registrable domain) of the top-level URL the browser was visiting at the start of the request to the endpoint that set the cookie." Auf Deutsch: Der Partitionsschlüssel eines Cookies ist die Site, also Schema und registrierbare Domain, der Top-Level-URL, die der Browser zu Beginn der Anfrage an den Endpunkt besuchte, der das Cookie gesetzt hat. Zwei Wörter darin leisten echte Arbeit. "Site" meint die registrierbare Domain, also teilen sich support.shoppy.example und checkout.shoppy.example eine Partition. "Scheme" nimmt das Protokoll in den Schlüssel auf, also teilen http://shoppy.example und https://shoppy.example sie nicht.

Chrome fügt ein weiteres Feld hinzu. Chrome Platform Status hält die Änderung fest: "Chrome 128 adds a cross-site ancestor bit to the keying of the partitioned cookie's CookiePartitionKey." Auf Deutsch: Chrome 128 fügt der Schlüsselbildung des CookiePartitionKey eines partitionierten Cookies ein seitenübergreifendes Ancestor-Bit hinzu. Dieses Bit hält fest, ob ein seitenübergreifender Frame zwischen dem Top-Level-Dokument und dem anfragenden Frame sitzt, was ein Embed daran hindert, über ein verschachteltes iframe an die eigenen partitionierten Cookies der Top-Level-Site zu kommen. Ab Chrome 128 ist der Schlüssel ein Tripel: Schema, registrierbare Domain, Ancestor-Bit.

Wie sieht ein echter Set-Cookie-Header aus?

Ein partitioniertes Cookie ist ein gewöhnlicher Set-Cookie-Header mit vier Attributen. Dies ist das Beispiel, das Googles Privacy-Sandbox-Dokumentation und MDN beide veröffentlichen, Zeichen für Zeichen:

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

Diese Antwort muss über HTTPS ankommen, da Secure und __Host- beide einen sicheren Origin verlangen. Bei einer späteren Anfrage an dasselbe Embed unter derselben Top-Level-Site sendet der Browser das Cookie nackt zurück:

Cookie: __Host-example=34d8g

Navigieren Sie zu einer anderen Top-Level-Site, und dieser zweite Header verschwindet. Das Embed sieht kein Cookie und erzeugt einen neuen Wert, was genau der Sinn der Sache ist.

Welche Browser akzeptieren das Attribut Partitioned?

Drei Engines akzeptieren es. Diese Versionen stammen aus MDNs Browser-Kompatibilitätsdaten zu Partitioned.

MDN führt partitionierte Cookies seit Dezember 2025 als Baseline newly available. Clients, die das Attribut nicht kennen, ignorieren es und behandeln das Cookie als gewöhnliches SameSite=None Cookie, Ihr Fallback ist also das, was der jeweilige Browser mit Third-Party Cookies macht. In Safari ist der Fallback nichts, weil Intelligent Tracking Prevention sie rundweg blockiert und per Skript gesetzte Cookies über die 7-Tage-Grenze für Safari-Cookies kappt.

Wie viel kann ein Embed in einer einzelnen Partition speichern?

Chrome deckelt eine Partition bei 180 Cookies und 10 KB pro eingebetteter Site. Seine CHIPS-Dokumentation sagt es direkt: "Chrome has a limit of maximum 180 cookies per partition that cannot exceed 10 KB per-embedded-site." Auf Deutsch: Chrome hat ein Limit von maximal 180 Cookies pro Partition, die 10 KB pro eingebetteter Site nicht überschreiten dürfen. Das Byte-Limit greift bei den meisten Embeds zuerst, die Zahl zum Prüfen ist also:

genutzte Partitions-Bytes = Anzahl der Cookies x durchschnittliche Bytes pro Cookie

Ein Embed, das 20 Cookies mit durchschnittlich je 500 Bytes speichert, verbraucht 20 x 500 = 10.000 Bytes und erreicht die 10-KB-Decke mit 160 der 180 Plätze frei. Jenseits des Byte-Budgets räumt der Browser aus, kalkulieren Sie also nach Größe, nicht nach Anzahl.

Schafft Chrome Third-Party Cookies noch ab?

Nein. Googles jüngste Privacy-Sandbox-Ankündigung, "Update on Plans for Privacy Sandbox Technologies" von Anthony Chavez, VP of Privacy Sandbox, vom 17. Oktober 2025, verweist auf die frühere Entscheidung zurück, "that Chrome will maintain our current approach to offering users third-party cookie choice in Chrome.", dass Chrome also den bisherigen Ansatz beibehält und Nutzern in Chrome die Wahl über Third-Party Cookies lässt. Keine browserweite Abschaffung ist geplant und keine neue Abfrage kommt. Chrome erlaubt Third-Party Cookies im normalen Surfen und blockiert sie im Inkognitomodus.

Dieselbe Ankündigung ist der Grund, warum sich CHIPS als Fundament lohnt. Sie stellte die Attribution Reporting API, Protected Audience, Topics, Private Aggregation und Related Website Sets ein und hob CHIPS dann für die gegenteilige Behandlung hervor: "CHIPS and FedCM, which improve cookie privacy and security and streamline identity flows respectively, have seen broad adoption, including support from other browsers. We'll continue to support those APIs and evaluate opportunities for future enhancements." Auf Deutsch: CHIPS und FedCM, die den Cookie-Datenschutz und die Cookie-Sicherheit verbessern beziehungsweise Identitätsflüsse verschlanken, haben breite Verbreitung gefunden, auch mit Unterstützung anderer Browser. Wir werden diese APIs weiter unterstützen und Möglichkeiten für künftige Erweiterungen prüfen. Related Website Sets steht auf der Streichliste. CHIPS nicht.

Was bedeutet das für Ihre Analytics?

Analytics, das keine Cookies setzt, überspringt die Frage. Partitionierung löst ein Problem, das Sie nur haben, wenn ein Skript einen Besucher über Browserspeicher wiedererkennt, also entfernt cookieloses Tracking den Fehlerfall, statt ihn zu isolieren. Flowserys cookiefreie, in der EU gehostete Analytics zeichnet Sitzungen und Replays ohne Cookies auf, es gibt also keinen Partitionsschlüssel, den man falsch machen könnte.

Die Rechnung kippt, wenn Ihr Produkt ein Widget ausliefert, das andere Unternehmen einbetten. Dieses Widget braucht Zustand, die Top-Level-Site gehört nicht Ihnen, und CHIPS hält es am Laufen. Fügen Sie Partitioned hinzu, verwenden Sie das __Host- Präfix, behalten Sie SameSite=None; Secure bei und testen Sie die erste Anfrage in einer frischen Partition, denn dieser Pfad läuft jetzt auf jeder neuen Kundensite.

Häufig gestellte Fragen

Braucht das Attribut Partitioned ein Path=/?

Nicht durch Partitioned selbst. Der CHIPS-Explainer, der IETF-Entwurf und Googles CHIPS-Dokumentation lassen Path=/ allesamt aus den Anforderungen des Attributs weg. Es taucht in jedem offiziellen Beispiel auf, weil diese Beispiele das __Host- Präfix verwenden, und RFC 6265bis verlangt von __Host- Cookies einen Path von / und kein Domain-Attribut.

Ist das __Host- Präfix für partitionierte Cookies Pflicht?

Nein. Der CHIPS-Explainer sagt, das Präfix "is not required", sei aber "still recommended", also nicht verlangt, aber weiterhin empfohlen, ein partitioniertes Cookie ohne Präfix wird demnach akzeptiert. Verwenden Sie es trotzdem: Browser, die Partitioned ignorieren, erzwingen das Präfix weiterhin und binden Ihr Cookie an den exakten Host.

Brauchen partitionierte Cookies weiterhin eine Einwilligung nach GDPR?

Ja. Partitionierung ändert, wer ein Cookie lesen kann, nicht ob eines auf dem Gerät landet. Die Einwilligungspflicht der ePrivacy-Richtlinie knüpft an das Speichern von Informationen auf der Endeinrichtung eines Nutzers oder den Zugriff darauf an, und ein partitioniertes Cookie tut beides. Unbedingt erforderliche Cookies bleiben so oder so ausgenommen.

Kann eine Top-Level-Site die partitionierten Cookies eines Embeds löschen?

Nein. Der CHIPS-Explainer hält fest, dass Top-Level-Sites die Cookies Dritter in ihrer Partition nicht löschen können dürfen, da eine Host-Site sonst in Code innerhalb eingebetteter Frames eingreifen könnte. Ein Embed löscht seine eigene Partition, indem es Clear-Site-Data sendet, was nur die Partition der aktuellen Top-Level-Site berührt.

Wie unterscheidet sich CHIPS von Firefox State Partitioning?

Firefox partitioniert Third-Party-Cookie-Speicher standardmäßig, ohne Opt-in der Site. CHIPS ist ein Attribut, das ein Dienst bewusst hinzufügt, und es gilt in First-Party- und Third-Party-Kontexten gleichermaßen. MDN empfiehlt das CHIPS-Opt-in gegenüber State Partitioning, weil das explizite Attribut browserübergreifend am besten kompatibel ist.

Was ersetzt CHIPS, wenn ein Embed ein Cookie über mehrere Sites hinweg braucht?

Die Storage Access API. Related Website Sets deckte diesen Fall früher ab, indem es eine Gruppe verwandter Domains deklarierte, und Googles Ankündigung vom 17. Oktober 2025 führte es unter den eingestellten Technologien auf. Die Storage Access API bittet den Nutzer um Erlaubnis, unpartitionierten Speicher in einem seitenübergreifenden Frame zu nutzen, und ist der verbleibende unterstützte Weg für geteilten Zustand.

Funktioniert Partitioned mit SameSite=Lax oder SameSite=Strict?

Der CHIPS-Explainer erlaubt Browsern, Partitioned nur bei SameSite=None zu akzeptieren, sodass ein Cookie mit Lax oder Strict trotz des Attributs unpartitioniert bleiben kann. Das passt zum Anwendungsfall, denn ein partitioniertes Cookie zählt in einem Cross-Site-Embed, und ein Embed braucht SameSite=None, um überhaupt ein Cookie zu erhalten. Setzen Sie SameSite=None; Secure zusammen mit Partitioned, dann stellt sich die Frage nicht.

Was passiert, wenn eine Partition Chromes 10-KB-Cookie-Limit überschreitet?

Chrome erzwingt pro eingebetteter Site eine Grenze von 180 Cookies und 10 KB pro Partition, und sobald der Speicher eine der beiden Grenzen überschreitet, entfernt der Browser Cookies aus dieser Partition. Meist greift zuerst das Byte-Limit: Eine Handvoll Cookies mit je ein paar hundert Byte kann 10 KB füllen, während Dutzende der 180 Plätze noch frei sind. Planen Sie nach der Gesamtzahl der Bytes pro Top-Level-Site, nicht nach der Anzahl gesetzter Cookies.

Kann ein partitioniertes Cookie über einfaches HTTP gesetzt werden?

Secure verhindert das. Das Attribut Partitioned verlangt Secure, und der IETF-Entwurf nennt genau diese Kopplung als Grund, das neue Attribut überhaupt einzuführen und die Funktion auf sichere Protokolle zu beschränken. Ein Set-Cookie-Header über einfaches HTTP verliert sowohl Partitioned als auch das Cookie selbst.

Was ist das Cross-Site-Ancestor-Bit im Partitionsschlüssel von Chrome?

Ab Chrome 128 erhält der Partitionsschlüssel neben Schema und registrierbarer Domain ein drittes Feld, das festhält, ob zwischen dem Top-Level-Dokument und dem anfragenden Frame ein Cross-Site-Frame liegt. Dieses Ancestor-Bit verhindert, dass ein Embed über ein verschachteltes iFrame auf die eigenen partitionierten Cookies der Top-Level-Site zugreift. Ältere Chrome-Versionen und andere Browser schlüsseln Partitionen nur nach Schema und registrierbarer Domain.