Third-party cookies: wat Chrome’s koerswijziging echt veranderde en welke Privacy Sandbox-API’s verdwijnen

In 2026 is deze beschrijving niet langer actueel.

Chrome heeft geen algemene, verplichte uitschakeling van third-party cookies volgens het oude tijdschema doorgevoerd. Google heeft besloten het huidige model te behouden, waarin gebruikers de toegang tot dergelijke cookies kunnen beheren in de instellingen van Chrome. Het bedrijf heeft ook afgezien van het plan om een nieuwe, aparte prompt over third-party cookies in te voeren.

Dit betekent echter geen terugkeer naar de situatie van voor Privacy Sandbox.

Third-party cookies kunnen nog steeds ontoegankelijk zijn vanwege:

• een beslissing van de gebruiker,
• de Incognito-modus,
• organisatiebeleid van Chrome Enterprise,
• beperkingen van een specifieke browser,
• site-instellingen,
• een experimentele Chrome-groep,
• mechanismen voor partitionering en bescherming tegen tracking.

Tegelijkertijd heeft Google besloten een groot deel van de Privacy Sandbox-API's in te trekken, waaronder Topics, Protected Audience, Attribution Reporting, Shared Storage en Related Website Sets. Wat blijft, zijn oplossingen die nuttig zijn voor functionele use-cases, zoals CHIPS, Storage Access API, FedCM, storage-partitionering en Private State Tokens.

De belangrijkste conclusie: de ommezwaai van Chrome betekent niet dat je aanmelding, ingesloten widgets, analytics en betalingen opnieuw kunt ontwerpen in de veronderstelling dat niet-gepartitioneerde third-party cookies altijd beschikbaar zullen zijn. In 2026 moet een correcte architectuur beide toestanden ondersteunen: cookie beschikbaar en cookie geblokkeerd.

Status en documentatie geverifieerd op 23 juli 2026.

TL;DR

Vraag	Antwoord voor 2026
Heeft Chrome third-party cookies voor alle gebruikers uitgeschakeld?	Nee
Plant Chrome nog steeds een nieuwe aparte prompt?	Nee
Kan de gebruiker ze blokkeren?	Ja
Worden ze standaard geblokkeerd in Incognito?	Ja
Moet een applicatie ervan uitgaan dat ze beschikbaar zijn?	Nee
Verdwijnt de hele Privacy Sandbox?	Nee
Worden advertentie-API's zoals Topics en Protected Audience uitgefaseerd?	Ja
Blijft CHIPS ondersteund?	Ja
Blijft Storage Access API bestaan?	Ja
Blijft FedCM bestaan?	Ja
Garandeert SameSite=None; Secure dat een cookie werkt?	Nee
Geldt één verwijderingsdatum voor alle API's?	Nee

1. Wat is een third-party cookie?

Een cookie is een waarde die door de browser wordt opgeslagen en verzonden volgens de regels voor domein, pad, protocol, levensduur en het attribuut SameSite.

Een cookie wordt als third-party beschouwd wanneer het wordt gebruikt in de context van een andere site dan de site bovenaan het browsertabblad.

Voorbeeld:

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

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

Als een ingesloten widget probeert een niet-gepartitioneerd cookie van het domein chat.vendor.example te gebruiken, doet het dat in de context van een derde partij.

Een typische configuratie waarmee een cookie in cross-site-context kan worden verzonden, ziet er zo uit:

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

SameSite=None staat toe dat een cookie wordt verzonden in cross-site-verzoeken, en Secure is vereist voor cookies met SameSite=None in moderne browsers.

Dit is echter slechts een technische voorwaarde. Het is geen garantie dat de browser het third-party cookie toestaat. Een gebruikersinstelling of browserbeleid kan het nog steeds blokkeren.

2. Hoe is het plan van Chrome veranderd?

Fase 1: de aankondiging van een wereld zonder third-party cookies

Privacy Sandbox ontstond als een reeks voorstellen om tracking tussen sites te beperken en tegelijkertijd oplossingen te bieden voor advertenties, meting, misbruikpreventie en identiteit.

In januari 2024 begon Chrome met het beperken van third-party cookies voor 1% van de gebruikers als onderdeel van de Tracking Protection-test.

Fase 2: het afstappen van een algemene phase-out

In juli 2024 kondigde Google een koerswijziging aan: in plaats van een algemene uitschakeling van cookies werd een aanpak op basis van gebruikerskeuze voorgesteld.

Op 22 april 2025 verduidelijkte Google de beslissing:

• Chrome behoudt de huidige aanpak van gebruikerskeuze,
• een nieuwe aparte prompt wordt niet ingevoerd,
• gebruikers beheren cookies nog steeds in de instellingen Privacy and Security,
• Incognito blokkeert third-party cookies nog steeds standaard.

Dit is precies de belangrijkste 'ommezwaai van Chrome'.

Fase 3: de reductie van Privacy Sandbox

Op 17 oktober 2025 kondigde Google aan dat het na analyse van de adoptie en feedback van het ecosysteem een aanzienlijk deel van de Privacy Sandbox-technologieën zou intrekken.

In januari 2026 vermeldden de release notes van Chrome 144 de deprecatie en geplande verwijdering van Private Aggregation, Shared Storage en Protected Audience.

De hele verandering mag echter niet worden teruggebracht tot Chrome 144. De officiële status omvat meer technologieën, en het proces om ze uit te faseren is gespreid en wordt uitgevoerd volgens de procedures van Chrome en Android.

3. Wat betekent 'Chrome behoudt de huidige aanpak'?

Dit betekent niet:

• een garantie dat cookies in elke installatie beschikbaar zijn,
• een terugkeer naar onbeperkte cross-site-tracking,
• het annuleren van storage-partitionering,
• identiek gedrag van Chrome, Safari en Firefox,
• een garantie dat een bestaande SSO- of iframe-integratie zal werken.

Het betekent dat Chrome het huidige model niet heeft vervangen door één globale uitschakeling en een nieuwe prompt voor de hele gebruikersbasis.

De officiële documentatie van Chrome beschrijft nog steeds verschillende redenen voor het blokkeren van cookies:

• gebruikersinstellingen,
• browserbeperkingen,
• testflags,
• Chrome Enterprise-beleid.

Dezelfde documentatie, bijgewerkt op 18 december 2025, vermeldt nog steeds een groep van 1% van de gebruikers voor wie third-party cookies standaard beperkt zijn voor testdoeleinden.

Voor een ontwikkelaar is de praktische conclusie eenvoudig:

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

4. Welke Privacy Sandbox-technologieën worden uitgefaseerd?

De officiële status hanteert enkele verschillende categorieën:

• Deprecate and remove - de API is bestemd voor deprecatie en verwijdering.
• Discontinue - het project is beëindigd of wordt ingetrokken.
• Do not launch - de technologie wordt niet gelanceerd.
• Scheduled for phaseout - een geleidelijke uitfasering is gepland.

Ze mogen niet worden voorgesteld als één gelijktijdige 'uitschakeling van Privacy Sandbox'.

Belangrijkste webtechnologieën bestemd voor deprecatie en verwijdering

Technologie	Oorspronkelijke toepassing	Status
Attribution Reporting API	attributiemeting zonder cross-site-identifier	deprecate and remove
Aggregation Service	aggregatie van rapporten voor Attribution Reporting	scheduled for phaseout
Topics API	interesses van de gebruiker voor advertenties	deprecate and remove
Protected Audience API	remarketing en interest-group-veilingen in de browser	deprecate and remove
Private Aggregation API	geaggregeerde cross-site-metingen	deprecate and remove
Shared Storage API	cross-site storage met gecontroleerde operaties	deprecate and remove
SelectURL	keuze van URL-variant op basis van Shared Storage	wordt ingetrokken samen met Shared Storage
Related Website Sets	declareren van gerelateerde domeinen	deprecate and remove
requestStorageAccessFor()	toegang aanvragen namens een resource van een gerelateerde site	deprecate and remove
Related Website Partition	gedeelde partitie voor gerelateerde sites	discontinue

Beëindigde of niet-ingevoerde technologieën

Technologie	Status
IP Protection	discontinue / scheduled for phaseout
Partitioned Popins	discontinue
Fenced Storage Read	do not launch
Private Proofs	do not launch
Probabilistic Reveal Tokens	do not launch
Script Blocking	do not launch

Android Privacy Sandbox

Google trekt ook in:

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

5. Wat verdween er precies in Chrome 144?

Chrome 144, uitgebracht als stable in januari 2026, bevatte formele deprecatie-items voor:

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

De release notes spreken van een plan voor deprecatie en verwijdering, niet van een garantie dat alle elementen onmiddellijk in elke installatie zijn gestopt met werken.

Dit is belangrijk bij een migratie. Signalen kunnen in fasen verschijnen:

1. de melding Intent to Deprecate,
2. waarschuwingen in de console of documentatie,
3. wijziging van de standaardtoestand,
4. verwijdering van de code,
5. een eventuele deprecation trial of overgangsperiode.

Het team moet Chrome Platform Status en de release notes volgen in plaats van te vertrouwen op één datum uit een artikel.

6. Wat blijft ondersteund?

Privacy Sandbox verdwijnt niet als één pakket. De officiële status geeft aan welke technologieën ondersteund blijven.

CHIPS

CHIPS maakt het mogelijk een cookie te markeren met het attribuut Partitioned. De browser maakt een aparte 'cookiepot' voor elke top-level site.

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

Als chat.vendor.example is ingesloten op:

shop-a.example
shop-b.example

dan krijgt het twee afzonderlijke partities. Een cookie dat is ingesteld in de context van shop-a.example is niet beschikbaar in de insluiting op shop-b.example.

CHIPS is onder meer geschikt voor:

• chatwidgets,
• kaarten,
• ingesloten betalingen,
• componenttoestand per site,
• resources die een sessie vereisen die beperkt is tot één embedder.

CHIPS is geen vervanging wanneer dezelfde identifier gedeeld moet worden tussen onafhankelijke sites. Juist het ontbreken van die mogelijkheid vormt het mechanisme voor privacybescherming.

Storage Access API

Met de Storage Access API kan een ingesloten document controleren of het toegang heeft tot niet-gepartitioneerde cookies, en de browser om die toegang vragen.

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

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

De toegang:

• kan gebruikersactiviteit vereisen,
• kan een prompt oproepen,
• valt onder het browserbeleid,
• kan worden geweigerd,
• vereist een veilige context,
• kan worden geblokkeerd door Permissions Policy.

Je mag requestStorageAccess() niet beschouwen als een automatische omzeiling van privacy.

FedCM

De Federated Credential Management API is bedoeld voor federatieve identiteitsflows zonder afhankelijkheid van third-party cookies en klassieke navigatie-redirects.

FedCM is zinvol voor:

• 'Inloggen via identiteitsprovider',
• One Tap,
• federatief aanmaken van accounts,
• flows waarin de browser bemiddelt tussen RP en IdP.

Het is geen universele vervanging voor alle cookies. Het lost niet de widgettoestand, analytics of elke functie van OpenID Connect op.

Storage- en Network State Partitioning

Chrome ondersteunt nog steeds de partitionering van storage en netwerktoestand. Het doel is de mogelijkheid te beperken om gebruikersactiviteit te koppelen tussen verschillende top-level sites.

Private State Tokens

Private State Tokens blijven behouden als een mechanisme dat helpt beperkte vertrouwenssignalen door te geven zonder klassieke tracking van de gebruiker tussen sites.

Overige ondersteunde elementen

De status vermeldt ook:

• bounce tracking mitigations,
• Fenced Frames,
• frame-ancestors,
• User-Agent Client Hints en User-Agent-reductie.

Niet al deze zijn vervangingen voor third-party cookies. Het zijn afzonderlijke mechanismen van het privacy- en beveiligingsplatform.

7. Is SameSite=None; Secure voldoende?

Nee.

Dit is een van de belangrijkste mythes.

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

betekent dat een cookie in cross-site-context kan worden verzonden, als de browser niet-gepartitioneerde third-party cookies toestaat.

Het betekent niet dat:

• de gebruiker ze niet heeft geblokkeerd,
• Incognito ze toestaat,
• Safari of Firefox zich hetzelfde gedragen als Chrome,
• Chrome Enterprise geen beleid toepast,
• het iframe Storage Access heeft,
• een mechanisme ter bescherming tegen tracking de toegang niet beperkt.

De code moet de werkelijke beschikbaarheid detecteren.

8. Hoe detecteer je de beschikbaarheid van cookies in een embed?

Chrome beschrijft twee basismethoden.

document.hasStorageAccess()

const hasAccess = await document.hasStorageAccess();

Met deze methode kan een ingesloten document controleren of het toegang heeft tot niet-gepartitioneerde cookies.

Sec-Fetch-Storage-Access

Vanaf Chrome 133 kunnen credentialed requests de volgende header bevatten:

Sec-Fetch-Storage-Access: active

Mogelijke waarden:

• none,
• inactive,
• active.

Voorbeeld aan de serverzijde:

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

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

Wat moet je niet als enige test gebruiken?

navigator.cookieEnabled

Deze eigenschap zegt niet betrouwbaar of een specifiek iframe toegang heeft tot een specifiek third-party cookie. Het kan hoogstens wijzen op algemene ondersteuning voor cookies.

9. Hoe zit het met requestStorageAccessFor()?

Dit is niet hetzelfde als:

document.requestStorageAccess()

requestStorageAccessFor() was een uitbreiding die verband hield met Related Website Sets en waarmee een top-level site toegang kon aanvragen namens een resource van een gerelateerde site.

Omdat Related Website Sets wordt ingetrokken, heeft requestStorageAccessFor() eveneens de status deprecate and remove.

MDN markeert deze methode als deprecated en non-standard.

Het gewone requestStorageAccess() blijft de ondersteunde, cross-browser richting voor ingesloten documenten die niet-gepartitioneerde toestand nodig hebben.

10. Gevolgen voor aanmelding

Het meest kwetsbaar zijn flows die ervan uitgaan dat een in een iframe ingesloten IdP altijd zijn eigen cookie kan lezen.

Mogelijke richtingen:

Geval	Betere oplossing
federatief inloggen	FedCM of een goed ontworpen top-level OAuth/OIDC-flow
sessie van de eigen applicatie	first-party cookie op het domein van de applicatie
embed die toegang tot een bestaand account vereist	Storage Access API met duidelijke UX
onafhankelijke widgettoestand	CHIPS
communicatie parent ↔ iframe	postMessage() met origin-validatie
backend tussen eigen services	tokens en sessies aan de serverzijde, geen cross-site tracking-cookies

Je moet tokens niet automatisch verplaatsen naar localStorage. Zo'n wijziging lost niet alle problemen op en kan de gevolgen van XSS vergroten.

11. Gevolgen voor analytics

De ommezwaai van Chrome betekent dat third-party cookies niet globaal zijn verwijderd, maar ze blijven een instabiel fundament voor meting.

De gegevens kunnen verschillen tussen:

• gebruikers die cookies blokkeren,
• de normale en de privémodus,
• Chrome, Safari en Firefox,
• apparaten die door een organisatie worden beheerd,
• gebruikers met blokkerende extensies,
• implementaties met en zonder consent.

De Attribution Reporting API, die een van de meetmechanismen van Privacy Sandbox moest zijn, wordt ingetrokken. Google verklaart echter verder te werken aan een interoperabele attributiestandaard binnen het proces van webstandaarden.

Dit is geen garantie voor een kant-en-klare vervanging.

Een praktische aanpak omvat:

• first-party measurement,
• expliciete consent waar dit vereist is,
• het modelleren van ontbrekende gegevens,
• aggregatie,
• server-side collection met privacycontrole,
• het meten van beperkingen en dekking van de gegevens,
• het vermijden van beloften over volledige tracking van de gebruiker tussen sites.

12. Gevolgen voor advertenties

Er worden drie centrale pijlers van het advertentiegedeelte van Privacy Sandbox ingetrokken:

• Topics,
• Protected Audience,
• Attribution Reporting.

Daar komen Shared Storage, SelectURL, Private Aggregation en Aggregation Service bij.

Dit betekent dat je geen nieuwe strategische implementatie mag starten die uitsluitend op deze API's is gebaseerd zonder de huidige status en het migratieplan te controleren.

Dit betekent niet automatisch dat de sector terugkeert naar één stabiel model van third-party-cookie-based advertising. De beschikbaarheid van cookies blijft fragmentarisch, en de overige browsers passen hun eigen beschermingsmechanismen toe.

13. Gevolgen voor widgets en ingesloten diensten

Een typische widget:

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

kan het volgende vereisen:

• herkenning van de sessie,
• onthouden van instellingen,
• toegang tot het account van de gebruiker,
• communicatie met de bovenliggende pagina.

De keuze van de oplossing moet afhangen van het doel:

Toestand alleen voor één embedder

Gebruik CHIPS.

Toegang tot een bestaande, niet-gepartitioneerde sessie

Gebruik de Storage Access API, met een fallback en een duidelijke melding.

Federatief inloggen

Overweeg FedCM.

Toestand die expliciet kan worden doorgegeven

Geef minimale gegevens door van de parent naar het iframe via postMessage() na strikte validatie van origin.

14. Audit van third-party cookies

Chrome beveelt een audit aan met DevTools en de Privacy Sandbox Analysis Tool.

Stap 1: inventariseer de cookies

Noteer voor elk cookie:

Veld	Voorbeeld
naam	widget_session
setter	chat.vendor.example
context	iframe
doel	gesprekstoestand
cross-site vereist?	ja
delen tussen sites vereist?	nee
alternatief	CHIPS

Stap 2: vind SameSite=None

grep -R "SameSite=None" .

Dit detecteert geen cookies die door externe scripts worden aangemaakt, daarom moet je ook DevTools en netwerklogs gebruiken.

Stap 3: test met blokkering

Chrome documenteert de flag:

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

en het starten met:

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

De documentatie beveelt deze modus nog steeds aan om storingen te testen bij beperkte cookies.

Stap 4: test reële paden

• inloggen,
• uitloggen,
• vernieuwing van het token,
• betaling,
• chat,
• kaart,
• embedded media,
• consent,
• analytics,
• cross-domain checkout,
• accountherstel.

Stap 5: test verschillende browsers

Beperk de test niet tot Chrome. De ommezwaai van Chrome heeft het beleid van Safari en Firefox niet veranderd.

15. Voorbeeld van een progressieve widgetstrategie

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();
}

Na een bewuste actie van de gebruiker kun je toegang aanbieden:

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

De logica moet rekening houden met weigering. De prompt is geen verplichting voor de gebruiker.

16. Wat moet je niet doen?

Ga er niet van uit dat de ommezwaai van Chrome het probleem heeft opgelost

Third-party cookies zijn nog steeds geen voorspelbare dependency.

Migreer niet alles naar fingerprinting

Het vervangen van cookies door het agressief verzamelen van apparaatsignalen is geen privacy-first-oplossing.

Verplaats de sessie niet automatisch naar localStorage

Dit kan het risico bij XSS vergroten en biedt niet automatisch de mogelijkheid om gegevens cross-site te delen.

Gebruik CHIPS niet voor cross-site identity

CHIPS isoleert het cookie doelbewust per top-level site.

Gebruik de Storage Access API niet zonder fallback

De toegang kan worden geweigerd.

Begin geen nieuw project op een API die wordt uitgefaseerd

Controleer de status van Topics, Protected Audience, Attribution Reporting, Shared Storage en RWS voordat je investeert.

Stel 'deprecated' niet gelijk aan 'werkt niet meer'

Deprecatie en verwijdering zijn een proces. Controleer de Chrome-versie en Chrome Platform Status.

17. Aanbevolen architectuur in 2026

Voor een gewone applicatie

• first-party session cookie,
• Secure,
• HttpOnly,
• verstandige SameSite,
• CSRF protection,
• geen afhankelijkheid van cross-site iframe.

Voor een widget

• CHIPS voor per site geïsoleerde toestand,
• anonymous fallback,
• Storage Access alleen voor een functie die een bestaande sessie vereist,
• postMessage() met origin-validatie.

Voor federatief inloggen

• FedCM, als het past bij een ondersteunde flow,
• standaard OAuth/OIDC-redirect als compatibele fallback,
• first-party sessie na terugkeer naar de applicatie.

Voor analytics

• first-party collection,
• toestemming en dataminimalisatie,
• expliciete rapportage van ontbrekende dekking,
• aggregatie in plaats van de belofte van volledige cross-site-identificatie.

18. Migratiechecklist

Inventarisatie

• Lijst van alle cookies.
• Bepaalde setter en domain.
• Bepaalde first-party- of third-party-context.
• Bekend zakelijk doel.
• Bekende eigenaar van de integratie.
• Bekende gevolgen van blokkering.
• Verwijderde ongebruikte cookies.

Cookiebeveiliging

• Secure op sessiecookies.
• HttpOnly waar JavaScript geen toegang nodig heeft.
• Minimale Domain.
• Minimale Path.
• Passende SameSite.
• Korte levensduur.
• Prefix __Host- waar dit past.

Cross-site

• Geen aanname dat SameSite=None toegang garandeert.
• Detectie van hasStorageAccess().
• Afhandeling van weigering van requestStorageAccess().
• CHIPS voor geïsoleerde toestand.
• FedCM voor ondersteund federatief inloggen.
• Fallback zonder third-party cookies.
• Test in Incognito.
• Test met blokkering van third-party cookies.

Privacy Sandbox

• Geen nieuwe afhankelijkheid van Topics.
• Geen nieuwe afhankelijkheid van Protected Audience.
• Plan om af te stappen van de Attribution Reporting API.
• Plan om af te stappen van Shared Storage en SelectURL.
• Plan om af te stappen van Private Aggregation.
• Plan om af te stappen van Related Website Sets.
• Verwijderd gebruik van requestStorageAccessFor().
• Gemonitorde Chrome release notes.

Tests

• Chrome normaal.
• Chrome Incognito.
• Chrome met handmatige blokkering.
• Safari.
• Firefox.
• Ingelogd en niet-ingelogd account.
• Nieuwe en bestaande gebruiker.
• Embed op ten minste twee top-level sites.
• Offline modus en API-fouten.
• Chrome Enterprise-beleid, indien van toepassing op het product.

19. POLPROG-tools

Bij een audit is het nuttig de cookieanalyse te combineren met andere lagen:

• Websitegezondheid helpt technische en prestatieproblemen te vinden.
• Inspecteur voor beveiligingsheaders laat je CSP, HSTS en andere beveiligingen controleren.
• DNS- en SSL-inspecteur verifieert de domeinlaag en TLS.
• FlowTrace helpt de stroom van verzoeken, sessies en gegevens tussen browser, CDN en backend te volgen.
• In de kennisbank van POLPROG vind je materiaal over privacy, beveiliging en webarchitectuur.

Conclusie

Chrome heeft het oude plan voor een globale uitschakeling van third-party cookies niet uitgevoerd. Gebruikers hebben nog steeds keuze, en een nieuwe aparte prompt is niet ingevoerd.

Dit betekent echter niet dat third-party cookies de status van een stabiele standaard hebben teruggekregen waarop je veilig een product kunt baseren.

In 2026:

• heeft een deel van de gebruikers cookies geblokkeerd,
• blokkeert Incognito ze standaard,
• kan organisatiebeleid ze beperken,
• passen andere browsers hun eigen regels toe,
• wordt storage steeds vaker gepartitioneerd,
• worden veel advertentie-API's van Privacy Sandbox uitgefaseerd,
• blijven functionele oplossingen zoals CHIPS, Storage Access API en FedCM bestaan.

De beste architectuur probeert niet de toekomstige beslissing van Chrome te raden. Ze werkt correct ongeacht of niet-gepartitioneerde third-party cookies beschikbaar zijn.