Third-Party-Cookies: Was Chromes Kehrtwende wirklich änderte und welche Privacy-Sandbox-APIs verschwinden

Im Jahr 2026 ist diese Beschreibung bereits veraltet.

Chrome hat kein flächendeckendes, verpflichtendes Abschalten von third-party cookies gemäß dem früheren Zeitplan umgesetzt. Google hat sich entschieden, das aktuelle Modell beizubehalten, in dem Nutzer den Zugriff auf solche Cookies in den Chrome-Einstellungen verwalten können. Das Unternehmen hat außerdem den Plan aufgegeben, einen neuen, separaten Prompt zu third-party cookies einzuführen.

Das bedeutet jedoch keine Rückkehr zum Zustand vor Privacy Sandbox.

Third-party cookies können weiterhin nicht verfügbar sein aufgrund von:

• einer Nutzerentscheidung,
• dem Incognito-Modus,
• organisatorischen Richtlinien von Chrome Enterprise,
• Einschränkungen eines bestimmten Browsers,
• Website-Einstellungen,
• einer experimentellen Chrome-Gruppe,
• Mechanismen zur Partitionierung und zum Schutz vor Tracking.

Gleichzeitig hat Google beschlossen, einen großen Teil der Privacy-Sandbox-APIs zurückzuziehen, darunter Topics, Protected Audience, Attribution Reporting, Shared Storage und Related Website Sets. Erhalten bleiben hingegen Lösungen, die für funktionale Anwendungsfälle nützlich sind, wie CHIPS, Storage Access API, FedCM, Storage-Partitionierung und Private State Tokens.

Wichtigste Schlussfolgerung: Die Kehrtwende von Chrome bedeutet nicht, dass man Anmeldung, eingebettete Widgets, Analytics und Zahlungen wieder unter der Annahme entwerfen darf, dass unpartitionierte third-party cookies immer verfügbar sein werden. Im Jahr 2026 muss eine korrekte Architektur beide Zustände unterstützen: verfügbare Cookies und blockierte Cookies.

Status und Dokumentation wurden am 23. Juli 2026 überprüft.

TL;DR

1. Was ist ein third-party cookie?

Ein Cookie ist ein Wert, der vom Browser gespeichert und gemäß den Regeln für Domain, Pfad, Protokoll, Lebensdauer und dem Attribut SameSite übertragen wird.

Ein Cookie wird als third-party behandelt, wenn es in einem Website-Kontext verwendet wird, der sich von der Website an der Spitze des Browser-Tabs unterscheidet.

Beispiel:

Użytkownik otwiera:
https://shop.example

Strona osadza:
https://chat.vendor.example/widget

Wenn ein eingebettetes Widget versucht, ein unpartitioniertes Cookie der Domain chat.vendor.example zu verwenden, geschieht dies im Kontext einer dritten Partei.

Eine typische Konfiguration, die das Senden eines Cookies im cross-site-Kontext ermöglicht, sieht so aus:

Set-Cookie: widget_session=abc123;
  SameSite=None;
  Secure;
  HttpOnly;
  Path=/

SameSite=None erlaubt das Senden eines Cookies in cross-site-Anfragen, und Secure ist für Cookies mit SameSite=None in modernen Browsern erforderlich.

Das ist jedoch nur eine technische Voraussetzung. Es ist keine Garantie dafür, dass der Browser das third-party cookie zulässt. Eine Nutzereinstellung oder eine Browser-Richtlinie kann es weiterhin blockieren.

2. Wie hat sich der Plan von Chrome verändert?

Phase 1: die Ankündigung einer Welt ohne third-party cookies

Privacy Sandbox entstand als eine Reihe von Vorschlägen, die das websiteübergreifende Tracking einschränken und zugleich Lösungen für Werbung, Messung, Missbrauchsprävention und Identität bereitstellen sollten.

Im Januar 2024 begann Chrome, third-party cookies für 1% der Nutzer im Rahmen des Tests Tracking Protection einzuschränken.

Phase 2: Abkehr vom flächendeckenden Phase-out

Im Juli 2024 kündigte Google einen Kurswechsel an: Statt eines flächendeckenden Abschaltens von Cookies wurde ein auf der Nutzerwahl basierender Ansatz vorgeschlagen.

Am 22. April 2025 präzisierte Google die Entscheidung:

• Chrome behält den aktuellen Ansatz zur Nutzerwahl bei,
• ein neuer, separater Prompt wird nicht eingeführt,
• Nutzer verwalten Cookies weiterhin in den Einstellungen Privacy and Security,
• Incognito blockiert third-party cookies weiterhin standardmäßig.

Genau das ist die wichtigste „Kehrtwende von Chrome“.

Phase 3: die Reduzierung von Privacy Sandbox

Am 17. Oktober 2025 kündigte Google an, nach der Analyse der Akzeptanz und der Rückmeldungen des Ökosystems einen erheblichen Teil der Privacy-Sandbox-Technologien zurückzuziehen.

Im Januar 2026 nannten die Release Notes von Chrome 144 die Deprecation und geplante Entfernung von Private Aggregation, Shared Storage und Protected Audience.

Man sollte die gesamte Änderung jedoch nicht auf Chrome 144 reduzieren. Der offizielle Status umfasst mehr Technologien, und der Prozess ihrer Zurückziehung ist gestaffelt und wird gemäß den Verfahren von Chrome und Android durchgeführt.

3. Was bedeutet „Chrome behält den aktuellen Ansatz bei“?

Das bedeutet nicht:

• eine Garantie für die Verfügbarkeit von Cookies in jeder Installation,
• eine Rückkehr zum uneingeschränkten cross-site-Tracking,
• eine Aufhebung der Storage-Partitionierung,
• ein identisches Verhalten von Chrome, Safari und Firefox,
• eine Garantie, dass eine bestehende SSO- oder iframe-Integration funktionieren wird.

Es bedeutet, dass Chrome das aktuelle Modell nicht durch ein einziges globales Abschalten und einen neuen Prompt für die gesamte Nutzerbasis ersetzt hat.

Die offizielle Chrome-Dokumentation beschreibt weiterhin mehrere Gründe für das Blockieren von Cookies:

• Nutzereinstellungen,
• Browser-Einschränkungen,
• Test-Flags,
• Richtlinien von Chrome Enterprise.

Dieselbe Dokumentation, aktualisiert am 18. Dezember 2025, informiert weiterhin über eine Gruppe von 1% der Nutzer, für die third-party cookies zu Testzwecken standardmäßig eingeschränkt sind.

Für Entwickler ist die praktische Schlussfolgerung einfach:

third-party cookie availability = stan runtime,
a nie właściwość gwarantowana przez nazwę przeglądarki

4. Welche Privacy-Sandbox-Technologien werden zurückgezogen?

Der offizielle Status verwendet mehrere verschiedene Kategorien:

• Deprecate and remove - die API ist zur Deprecation und Entfernung vorgesehen.
• Discontinue - das Projekt ist beendet oder wird zurückgezogen.
• Do not launch - die Technologie wird nicht eingeführt.
• Scheduled for phaseout - ein schrittweises Auslaufen ist geplant.

Man sollte sie nicht als ein einziges gleichzeitiges „Abschalten von Privacy Sandbox“ darstellen.

Wichtigste Web-Technologien, die zur Deprecation und Entfernung vorgesehen sind

Beendete oder nicht eingeführte Technologien

Android Privacy Sandbox

Google zieht außerdem zurück:

• Attribution Reporting,
• On-Device Personalization,
• Protected App Signals,
• Protected Audience,
• SDK Runtime,
• Topics.

5. Was genau verschwand in Chrome 144?

Chrome 144, veröffentlicht als Stable im Januar 2026, enthielt formale Deprecation-Einträge für:

• Private Aggregation API,
• Shared Storage API,
• Protected Audience API.

Die Release Notes sprechen von einem Plan zur Deprecation und Entfernung, nicht von einer Garantie, dass alle Elemente in jeder Installation sofort aufgehört haben zu funktionieren.

Das ist bei der Migration wichtig. Signale können in Etappen auftreten:

1. die Meldung Intent to Deprecate,
2. Warnungen in der Konsole oder Dokumentation,
3. Änderung des Standardzustands,
4. Entfernung des Codes,
5. ein eventueller Deprecation Trial oder eine Übergangsphase.

Das Team sollte Chrome Platform Status und die Release Notes verfolgen, anstatt sich auf ein einziges Datum aus einem Artikel zu verlassen.

6. Was bleibt unterstützt?

Privacy Sandbox verschwindet nicht als ein einziges Paket. Der offizielle Status weist auf Technologien hin, die weiterhin unterstützt werden.

CHIPS

CHIPS ermöglicht es, ein Cookie mit dem Attribut Partitioned zu kennzeichnen. Der Browser erstellt für jede Top-Level-Website einen separaten Cookie-„Behälter“.

Set-Cookie: __Host-widget_session=abc123;
  Secure;
  HttpOnly;
  Path=/;
  SameSite=None;
  Partitioned

Wenn chat.vendor.example eingebettet ist auf:

shop-a.example
shop-b.example

dann erhält es zwei getrennte Partitionen. Ein im Kontext von shop-a.example gesetztes Cookie ist bei der Einbettung auf shop-b.example nicht verfügbar.

CHIPS eignet sich unter anderem für:

• Chat-Widgets,
• Karten,
• eingebettete Zahlungen,
• Komponentenzustand pro Website,
• Ressourcen, die eine auf einen einzigen Embedder beschränkte Sitzung erfordern.

CHIPS ist kein Ersatz, wenn derselbe Identifikator zwischen unabhängigen Websites geteilt werden soll. Gerade das Fehlen dieser Möglichkeit stellt den Mechanismus zum Schutz der Privatsphäre dar.

Storage Access API

Die Storage Access API ermöglicht es einem eingebetteten Dokument zu prüfen, ob es Zugriff auf unpartitionierte Cookies hat, und den Browser um diesen Zugriff zu bitten.

async function ensureStorageAccess() {
  if (await document.hasStorageAccess()) {
    return true;
  }

  try {
    await document.requestStorageAccess();
    return true;
  } catch {
    return false;
  }
}

Der Zugriff:

• kann eine Nutzeraktivität erfordern,
• kann einen Prompt auslösen,
• unterliegt den Browser-Richtlinien,
• kann verweigert werden,
• erfordert einen sicheren Kontext,
• kann durch Permissions Policy blockiert werden.

Man darf requestStorageAccess() nicht als automatische Umgehung des Datenschutzes betrachten.

FedCM

Die Federated Credential Management API ist für föderierte Identitätsflüsse ohne Abhängigkeit von third-party cookies und klassischen Navigationsweiterleitungen vorgesehen.

FedCM ist sinnvoll für:

• „Anmeldung über einen Identitätsanbieter“,
• One Tap,
• föderierte Kontoerstellung,
• Flüsse, in denen der Browser zwischen RP und IdP vermittelt.

Es ist kein universeller Ersatz für alle Cookies. Es löst weder den Widget-Zustand noch Analytics noch jede Funktion von OpenID Connect.

Storage- und Network-State-Partitioning

Chrome unterstützt weiterhin die Partitionierung von Storage und Netzwerkzustand. Ziel ist es, die Möglichkeit einzuschränken, die Aktivität eines Nutzers zwischen verschiedenen Top-Level-Websites zu verknüpfen.

Private State Tokens

Private State Tokens bleiben als Mechanismus erhalten, der dabei hilft, begrenzte Vertrauenssignale zu übermitteln, ohne den Nutzer klassisch zwischen Websites zu verfolgen.

Weitere unterstützte Elemente

Der Status nennt außerdem:

• bounce tracking mitigations,
• Fenced Frames,
• frame-ancestors,
• User-Agent Client Hints und die Reduzierung des User-Agent.

Nicht alle davon sind ein Ersatz für third-party cookies. Es handelt sich um eigenständige Mechanismen der Datenschutz- und Sicherheitsplattform.

7. Reicht SameSite=None; Secure aus?

Nein.

Das ist einer der wichtigsten Mythen.

Set-Cookie: session=abc;
  SameSite=None;
  Secure

bedeutet, dass ein Cookie im cross-site-Kontext gesendet werden kann, wenn der Browser unpartitionierte Cookies von Drittanbietern zulässt.

Es bedeutet nicht, dass:

• der Nutzer sie nicht blockiert hat,
• Incognito sie zulässt,
• Safari oder Firefox sich genauso verhalten wie Chrome,
• Chrome Enterprise keine Richtlinie anwendet,
• das iframe Storage Access hat,
• ein Mechanismus zum Schutz vor Tracking den Zugriff nicht einschränkt.

Der Code sollte die tatsächliche Verfügbarkeit erkennen.

8. Wie erkennt man die Verfügbarkeit von Cookies in einer Einbettung?

Chrome beschreibt zwei grundlegende Methoden.

document.hasStorageAccess()

const hasAccess = await document.hasStorageAccess();

Die Methode ermöglicht es einem eingebetteten Dokument zu prüfen, ob es Zugriff auf unpartitionierte Cookies hat.

Sec-Fetch-Storage-Access

Ab Chrome 133 können credentialed requests den folgenden Header enthalten:

Sec-Fetch-Storage-Access: active

Mögliche Werte:

• none,
• inactive,
• active.

Beispiel auf der Serverseite:

const storageAccess =
  request.headers.get("sec-fetch-storage-access");

if (storageAccess !== "active") {
  // Nie zakładaj dostępu do unpartitioned third-party cookies.
}

Was sollte man nicht als einzigen Test verwenden?

navigator.cookieEnabled

Diese Eigenschaft sagt nicht zuverlässig aus, ob ein bestimmtes iframe Zugriff auf ein bestimmtes third-party cookie hat. Sie kann lediglich auf die allgemeine Cookie-Unterstützung hinweisen.

9. Was ist mit requestStorageAccessFor()?

Das ist nicht dasselbe wie:

document.requestStorageAccess()

requestStorageAccessFor() war eine mit Related Website Sets verbundene Erweiterung, die es einer Top-Level-Website erlaubte, im Namen einer Ressource aus einer verbundenen Website um Zugriff zu bitten.

Da Related Website Sets zurückgezogen wird, hat auch requestStorageAccessFor() den Status deprecate and remove.

MDN kennzeichnet diese Methode als deprecated und non-standard.

Das gewöhnliche requestStorageAccess() bleibt der unterstützte, browserübergreifende Weg für eingebettete Dokumente, die einen unpartitionierten Zustand benötigen.

10. Konsequenzen für die Anmeldung

Am stärksten gefährdet sind Flüsse, die davon ausgehen, dass ein in einem iframe eingebetteter IdP immer sein eigenes Cookie liest.

Mögliche Richtungen:

Man sollte Tokens nicht automatisch in localStorage verschieben. Eine solche Änderung löst nicht alle Probleme und kann die Auswirkungen von XSS verstärken.

11. Konsequenzen für Analytics

Die Kehrtwende von Chrome bedeutet, dass third-party cookies nicht global entfernt wurden, aber weiterhin ein instabiles Fundament für die Messung sind.

Die Daten können sich unterscheiden zwischen:

• Nutzern, die Cookies blockieren,
• dem normalen und dem privaten Modus,
• Chrome, Safari und Firefox,
• von einer Organisation verwalteten Geräten,
• Nutzern mit blockierenden Erweiterungen,
• Implementierungen mit und ohne Consent.

Die Attribution Reporting API, die einer der Messmechanismen von Privacy Sandbox sein sollte, wird zurückgezogen. Google erklärt jedoch, weiter an einem interoperablen Attributionsstandard im Rahmen des Web-Standards-Prozesses zu arbeiten.

Das ist keine Garantie für einen fertigen Ersatz.

Ein praktischer Ansatz umfasst:

• first-party measurement,
• expliziten Consent, wo er erforderlich ist,
• Modellierung fehlender Daten,
• Aggregation,
• server-side collection mit Datenschutzkontrolle,
• Messung der Einschränkungen und der Datenabdeckung,
• Vermeidung von Versprechen einer vollständigen websiteübergreifenden Nutzerverfolgung.

12. Konsequenzen für Werbung

Zurückgezogen werden drei zentrale Säulen des werblichen Privacy Sandbox:

• Topics,
• Protected Audience,
• Attribution Reporting.

Hinzu kommen Shared Storage, SelectURL, Private Aggregation und Aggregation Service.

Das bedeutet, dass man keine neue strategische Implementierung beginnen sollte, die ausschließlich auf diesen APIs basiert, ohne den aktuellen Status und den Migrationsplan zu prüfen.

Das bedeutet nicht automatisch, dass die Branche zu einem einzigen stabilen Modell des third-party-cookie-based advertising zurückkehrt. Die Verfügbarkeit von Cookies bleibt fragmentarisch, und die übrigen Browser wenden ihre eigenen Schutzmechanismen an.

13. Konsequenzen für Widgets und eingebettete Dienste

Ein typisches Widget:

<iframe src="https://support.vendor.example/widget"></iframe>

kann Folgendes erfordern:

• das Erkennen einer Sitzung,
• das Speichern von Einstellungen,
• den Zugriff auf das Nutzerkonto,
• die Kommunikation mit der übergeordneten Seite.

Die Wahl der Lösung sollte vom Ziel abhängen:

Zustand nur für einen einzigen Embedder

Verwende CHIPS.

Zugriff auf eine bestehende, unpartitionierte Sitzung

Verwende die Storage Access API, mit einem Fallback und einer klaren Meldung.

Föderierte Anmeldung

Ziehe FedCM in Betracht.

Zustand, der explizit übergeben werden kann

Übergib minimale Daten vom parent an das iframe über postMessage() nach strenger Validierung von origin.

14. Audit der third-party cookies

Chrome empfiehlt einen Audit mit DevTools und dem Privacy Sandbox Analysis Tool.

Schritt 1: Inventarisiere die Cookies

Notiere für jedes Cookie:

Schritt 2: Finde SameSite=None

grep -R "SameSite=None" .

Dies erkennt keine Cookies, die von externen Skripten erstellt werden, daher muss man auch DevTools und Netzwerk-Logs verwenden.

Schritt 3: Teste mit Blockierung

Chrome dokumentiert das Flag:

chrome://flags/#test-third-party-cookie-phaseout

sowie den Start:

google-chrome --test-third-party-cookie-phaseout

Die Dokumentation empfiehlt diesen Modus weiterhin, um Ausfälle bei eingeschränkten Cookies zu testen.

Schritt 4: Teste reale Pfade

• Anmeldung,
• Abmeldung,
• Token-Aktualisierung,
• Zahlung,
• Chat,
• Karte,
• embedded media,
• Consent,
• Analytics,
• cross-domain checkout,
• Kontowiederherstellung.

Schritt 5: Teste verschiedene Browser

Beschränke den Test nicht auf Chrome. Die Kehrtwende von Chrome hat die Richtlinien von Safari und Firefox nicht verändert.

15. Beispielhafte progressive Widget-Strategie

async function initializeWidget() {
  if ("hasStorageAccess" in document) {
    const hasAccess = await document.hasStorageAccess();

    if (hasAccess) {
      return startWithUnpartitionedSession();
    }
  }

  const partitionedSession = await tryPartitionedSession();

  if (partitionedSession) {
    return startWithPartitionedSession();
  }

  return startAnonymousMode();
}

Nach einer bewussten Nutzeraktion kann Zugriff angeboten werden:

button.addEventListener("click", async () => {
  try {
    await document.requestStorageAccess();
    location.reload();
  } catch {
    showManualLoginFallback();
  }
});

Die Logik muss eine Ablehnung berücksichtigen. Der Prompt ist keine Pflicht des Nutzers.

16. Was sollte man nicht tun?

Gehe nicht davon aus, dass die Kehrtwende von Chrome das Problem gelöst hat

Third-party cookies sind weiterhin keine vorhersehbare Dependency.

Migriere nicht alles zu Fingerprinting

Cookies durch die aggressive Erfassung von Gerätesignalen zu ersetzen, ist keine privacy-first-Lösung.

Verschiebe Sitzungen nicht automatisch in localStorage

Das kann das Risiko bei XSS erhöhen und bietet keine automatische Möglichkeit, Daten cross-site zu teilen.

Verwende CHIPS nicht für cross-site identity

CHIPS isoliert Cookies bewusst nach der Top-Level-Site.

Verwende die Storage Access API nicht ohne Fallback

Der Zugriff kann abgelehnt werden.

Beginne kein neues Projekt mit einer zurückgezogenen API

Prüfe den Status von Topics, Protected Audience, Attribution Reporting, Shared Storage und RWS vor einer Investition.

Setze „deprecated“ nicht mit „funktioniert nicht mehr“ gleich

Deprecation und Entfernung sind ein Prozess. Prüfe die Chrome-Version und Chrome Platform Status.

17. Empfohlene Architektur im Jahr 2026

Für eine gewöhnliche Anwendung

• first-party session cookie,
• Secure,
• HttpOnly,
• ein sinnvolles SameSite,
• CSRF protection,
• keine Abhängigkeit von cross-site iframe.

Für ein Widget

• CHIPS für einen pro Website isolierten Zustand,
• anonymous fallback,
• Storage Access nur für Funktionen, die eine bestehende Sitzung erfordern,
• postMessage() mit Origin-Validierung.

Für die föderierte Anmeldung

• FedCM, wenn es zu einem unterstützten Flow passt,
• Standard-Redirect OAuth/OIDC als kompatibler Fallback,
• first-party session nach der Rückkehr zur Anwendung.

Für Analytics

• first-party collection,
• Einwilligung und Datenminimierung,
• explizites Reporting fehlender Abdeckung,
• Aggregation statt des Versprechens einer vollständigen cross-site-Identifikation.

18. Migrations-Checkliste

Inventarisierung

• Liste aller Cookies.
• Bestimmter Setter und Domain.
• Bestimmter Kontext first-party oder third-party.
• Bekannter geschäftlicher Zweck.
• Bekannter Eigentümer der Integration.
• Bekannte Konsequenzen einer Blockierung.
• Entfernte ungenutzte Cookies.

Cookie-Sicherheit

• Secure bei Sitzungscookies.
• HttpOnly dort, wo JavaScript keinen Zugriff benötigt.
• Minimaler Domain.
• Minimaler Path.
• Passendes SameSite.
• Kurze Lebensdauer.
• Präfix __Host- dort, wo es passt.

Cross-site

• Keine Annahme, dass SameSite=None den Zugriff garantiert.
• Erkennung von hasStorageAccess().
• Behandlung der Ablehnung von requestStorageAccess().
• CHIPS für einen isolierten Zustand.
• FedCM für eine unterstützte föderierte Anmeldung.
• Fallback ohne Cookies von Drittanbietern.
• Test im Incognito-Modus.
• Test mit Blockierung von third-party cookies.

Privacy Sandbox

• Keine neue Abhängigkeit von Topics.
• Keine neue Abhängigkeit von Protected Audience.
• Plan zur Abkehr von der Attribution Reporting API.
• Plan zur Abkehr von Shared Storage und SelectURL.
• Plan zur Abkehr von Private Aggregation.
• Plan zur Abkehr von Related Website Sets.
• Entfernte Verwendung von requestStorageAccessFor().
• Überwachte Chrome Release Notes.

Tests

• Chrome normal.
• Chrome Incognito.
• Chrome mit manueller Blockierung.
• Safari.
• Firefox.
• Angemeldetes und nicht angemeldetes Konto.
• Neuer und bestehender Nutzer.
• Einbettung auf mindestens zwei top-level sites.
• Offline-Modus und API-Fehler.
• Richtlinien von Chrome Enterprise, sofern sie das Produkt betreffen.

19. POLPROG-Werkzeuge

Bei einem Audit lohnt es sich, die Cookie-Analyse mit anderen Schichten zu verbinden:

• Website-Zustand hilft, technische und Performance-Probleme zu finden.
• Inspektor für Sicherheits-Header ermöglicht die Prüfung von CSP, HSTS und weiteren Schutzmaßnahmen.
• DNS- und SSL-Inspektor überprüft die Domain-Schicht und TLS.
• FlowTrace hilft, den Fluss von Anfrage, Sitzung und Daten zwischen Browser, CDN und Backend nachzuverfolgen.
• In der POLPROG-Wissensdatenbank finden sich Materialien zu Datenschutz, Sicherheit und Web-Architektur.

Fazit

Chrome hat den früheren Plan eines globalen Abschaltens von third-party cookies nicht umgesetzt. Nutzer haben weiterhin die Wahl, und ein neuer, separater Prompt wurde nicht eingeführt.

Das bedeutet jedoch nicht, dass third-party cookies den Status eines stabilen Standards zurückerlangt haben, auf den man ein Produkt sicher stützen kann.

Im Jahr 2026:

• haben manche Nutzer Cookies blockiert,
• blockiert Incognito sie standardmäßig,
• können organisatorische Richtlinien sie einschränken,
• wenden andere Browser ihre eigenen Regeln an,
• wird Storage immer häufiger partitioniert,
• werden viele werbliche Privacy-Sandbox-APIs zurückgezogen,
• bleiben funktionale Lösungen wie CHIPS, Storage Access API und FedCM erhalten.

Die beste Architektur versucht nicht, die künftige Entscheidung von Chrome zu erraten. Sie funktioniert korrekt, unabhängig davon, ob unpartitionierte third-party cookies verfügbar sind.