Third-party cookies: co naprawdę zmienił zwrot Chrome i które API Privacy Sandbox znikają

W 2026 roku ten opis jest już nieaktualny.

Chrome nie wdrożył powszechnego, obowiązkowego wyłączenia third-party cookies zgodnie z dawnym harmonogramem. Google zdecydował się utrzymać obecny model, w którym użytkownicy mogą zarządzać dostępem do takich cookies w ustawieniach Chrome. Firma zrezygnowała również z planu wdrożenia nowego, osobnego promptu dotyczącego third-party cookies.

Nie oznacza to jednak powrotu do stanu sprzed Privacy Sandbox.

Third-party cookies nadal mogą być niedostępne z powodu:

• decyzji użytkownika,
• trybu Incognito,
• zasad organizacyjnych Chrome Enterprise,
• ograniczeń konkretnej przeglądarki,
• ustawień witryny,
• eksperymentalnej grupy Chrome,
• mechanizmów partycjonowania i ochrony przed śledzeniem.

Równocześnie Google zdecydował się wycofać dużą część API Privacy Sandbox, w tym Topics, Protected Audience, Attribution Reporting, Shared Storage i Related Website Sets. Pozostają natomiast rozwiązania przydatne dla funkcjonalnych przypadków użycia, takie jak CHIPS, Storage Access API, FedCM, partycjonowanie storage i Private State Tokens.

Najważniejszy wniosek: zwrot Chrome nie oznacza, że można ponownie projektować logowanie, osadzone widgety, analitykę i płatności przy założeniu, że niepartycjonowane third-party cookies zawsze będą dostępne. W 2026 roku poprawna architektura musi obsługiwać oba stany: cookie dostępne oraz cookie zablokowane.

Status i dokumentację zweryfikowano 23 lipca 2026 roku.

TL;DR

Pytanie	Odpowiedź na 2026 rok
Czy Chrome wyłączył third-party cookies wszystkim użytkownikom?	Nie
Czy Chrome nadal planuje nowy osobny prompt?	Nie
Czy użytkownik może je zablokować?	Tak
Czy są domyślnie blokowane w Incognito?	Tak
Czy aplikacja powinna zakładać ich dostępność?	Nie
Czy całe Privacy Sandbox znika?	Nie
Czy reklamowe API takie jak Topics i Protected Audience są wycofywane?	Tak
Czy CHIPS pozostaje wspierane?	Tak
Czy Storage Access API pozostaje?	Tak
Czy FedCM pozostaje?	Tak
Czy SameSite=None; Secure gwarantuje działanie cookie?	Nie
Czy jedna data usunięcia dotyczy wszystkich API?	Nie

1. Czym jest third-party cookie?

Cookie jest wartością zapisywaną przez przeglądarkę i przesyłaną zgodnie z regułami domeny, ścieżki, protokołu, czasu życia oraz atrybutu SameSite.

Cookie jest traktowane jako third-party w sytuacji, gdy jest używane w kontekście witryny innym niż witryna znajdująca się na górze karty przeglądarki.

Przykład:

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

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

Jeżeli osadzony widget próbuje użyć niepartycjonowanego cookie domeny chat.vendor.example, robi to w kontekście strony trzeciej.

Typowa konfiguracja pozwalająca wysyłać cookie w kontekście cross-site wygląda tak:

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

SameSite=None pozwala na wysyłanie cookie w żądaniach cross-site, a Secure jest wymagane dla cookies z SameSite=None we współczesnych przeglądarkach.

To jednak tylko warunek techniczny. Nie jest gwarancją, że przeglądarka dopuści third-party cookie. Ustawienie użytkownika lub polityka przeglądarki może nadal je zablokować.

2. Jak zmieniał się plan Chrome?

Etap 1: zapowiedź świata bez third-party cookies

Privacy Sandbox powstało jako zestaw propozycji mających ograniczyć śledzenie między witrynami, a jednocześnie zapewnić rozwiązania dla reklam, pomiaru, zapobiegania nadużyciom i tożsamości.

W styczniu 2024 roku Chrome rozpoczął ograniczanie third-party cookies dla 1% użytkowników w ramach testu Tracking Protection.

Etap 2: odejście od powszechnego phase-out

W lipcu 2024 roku Google ogłosił zmianę kierunku: zamiast powszechnego wyłączenia cookies zaproponowano podejście oparte na wyborze użytkownika.

22 kwietnia 2025 roku Google doprecyzował decyzję:

• Chrome zachowuje aktualne podejście do wyboru użytkownika,
• nowy osobny prompt nie zostanie wdrożony,
• użytkownicy nadal zarządzają cookies w ustawieniach Privacy and Security,
• Incognito nadal blokuje third-party cookies domyślnie.

To właśnie jest najważniejszy „zwrot Chrome”.

Etap 3: redukcja Privacy Sandbox

17 października 2025 roku Google ogłosił, że po analizie adopcji i opinii ekosystemu wycofa znaczną część technologii Privacy Sandbox.

W styczniu 2026 roku release notes Chrome 144 wymieniły deprecjację i planowane usunięcie Private Aggregation, Shared Storage i Protected Audience.

Nie należy jednak sprowadzać całej zmiany do Chrome 144. Oficjalny status obejmuje więcej technologii, a proces ich wycofywania jest rozłożony i prowadzony zgodnie z procedurami Chrome oraz Androida.

3. Co znaczy „Chrome zachowuje obecne podejście”?

Nie oznacza to:

• gwarancji dostępności cookies w każdej instalacji,
• powrotu do nieograniczonego śledzenia cross-site,
• anulowania partycjonowania storage,
• identycznego zachowania Chrome, Safari i Firefox,
• gwarancji, że istniejąca integracja SSO lub iframe będzie działać.

Oznacza to, że Chrome nie zastąpił obecnego modelu jednym globalnym wyłączeniem i nowym promptem obejmującym całą bazę użytkowników.

Oficjalna dokumentacja Chrome nadal opisuje kilka przyczyn blokowania cookies:

• ustawienia użytkownika,
• ograniczenia przeglądarki,
• flagi testowe,
• zasady Chrome Enterprise.

Ta sama dokumentacja, zaktualizowana 18 grudnia 2025 roku, nadal informuje o grupie 1% użytkowników, dla której third-party cookies są ograniczone domyślnie w celu testowania.

Dla programisty praktyczny wniosek jest prosty:

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

4. Które technologie Privacy Sandbox są wycofywane?

Oficjalny status używa kilku różnych kategorii:

• Deprecate and remove - API jest przeznaczone do deprecjacji i usunięcia.
• Discontinue - projekt jest zakończony lub wycofywany.
• Do not launch - technologia nie zostanie uruchomiona.
• Scheduled for phaseout - planowane jest stopniowe wycofanie.

Nie należy przedstawiać ich jako jednego jednoczesnego „wyłączenia Privacy Sandbox”.

Główne technologie webowe przeznaczone do deprecjacji i usunięcia

Technologia	Pierwotne zastosowanie	Status
Attribution Reporting API	pomiar atrybucji bez identyfikatora cross-site	deprecate and remove
Aggregation Service	agregacja raportów dla Attribution Reporting	scheduled for phaseout
Topics API	zainteresowania użytkownika dla reklam	deprecate and remove
Protected Audience API	remarketing i aukcje interest-group w przeglądarce	deprecate and remove
Private Aggregation API	zagregowane pomiary cross-site	deprecate and remove
Shared Storage API	cross-site storage z kontrolowanymi operacjami	deprecate and remove
SelectURL	wybór wariantu URL na podstawie Shared Storage	wycofywane razem z Shared Storage
Related Website Sets	deklarowanie powiązanych domen	deprecate and remove
requestStorageAccessFor()	żądanie dostępu w imieniu zasobu powiązanej witryny	deprecate and remove
Related Website Partition	współdzielona partycja dla powiązanych witryn	discontinue

Technologie zakończone lub niewprowadzane

Technologia	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 wycofuje także:

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

5. Co dokładnie znikało w Chrome 144?

Chrome 144, wydany jako stable w styczniu 2026 roku, zawierał formalne pozycje deprecacyjne dla:

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

Release notes mówią o planie deprecjacji i usunięcia, nie o gwarancji, że wszystkie elementy natychmiast przestały działać w każdej instalacji.

To ważne przy migracji. Sygnały mogą pojawiać się etapami:

1. komunikat Intent to Deprecate,
2. ostrzeżenia w konsoli lub dokumentacji,
3. zmiana domyślnego stanu,
4. usunięcie kodu,
5. ewentualny deprecation trial lub okres przejściowy.

Zespół powinien śledzić Chrome Platform Status i release notes, zamiast opierać się na jednej dacie z artykułu.

6. Co pozostaje wspierane?

Privacy Sandbox nie znika jako jeden pakiet. Oficjalny status wskazuje technologie pozostające we wsparciu.

CHIPS

CHIPS pozwala oznaczyć cookie atrybutem Partitioned. Przeglądarka tworzy osobny „słoik” cookie dla każdej witryny najwyższego poziomu.

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

Jeżeli chat.vendor.example jest osadzony na:

shop-a.example
shop-b.example

to otrzymuje dwie oddzielne partycje. Cookie ustawione w kontekście shop-a.example nie jest dostępne w osadzeniu na shop-b.example.

CHIPS nadaje się między innymi do:

• widgetów czatu,
• map,
• osadzonych płatności,
• stanu komponentu per witryna,
• zasobów wymagających sesji ograniczonej do jednego embeddera.

CHIPS nie jest zamiennikiem, gdy ten sam identyfikator ma być współdzielony pomiędzy niezależnymi witrynami. Właśnie brak takiej możliwości stanowi mechanizm ochrony prywatności.

Storage Access API

Storage Access API pozwala osadzonemu dokumentowi sprawdzić, czy ma dostęp do niepartycjonowanych cookies, oraz poprosić przeglądarkę o taki dostęp.

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

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

Dostęp:

• może wymagać aktywności użytkownika,
• może wywołać prompt,
• podlega politykom przeglądarki,
• może zostać odmówiony,
• wymaga bezpiecznego kontekstu,
• może być zablokowany przez Permissions Policy.

Nie wolno traktować requestStorageAccess() jako automatycznego obejścia prywatności.

FedCM

Federated Credential Management API jest przeznaczone do federacyjnych przepływów tożsamości bez zależności od third-party cookies i klasycznych przekierowań nawigacyjnych.

FedCM ma sens dla:

• „Zaloguj przez dostawcę tożsamości”,
• One Tap,
• federacyjnego tworzenia kont,
• przepływów, w których przeglądarka pośredniczy pomiędzy RP i IdP.

Nie jest uniwersalnym zamiennikiem wszystkich cookies. Nie rozwiązuje stanu widgetu, analityki ani każdej funkcji OpenID Connect.

Storage i Network State Partitioning

Chrome nadal wspiera partycjonowanie storage i stanu sieciowego. Celem jest ograniczenie możliwości łączenia aktywności użytkownika pomiędzy różnymi witrynami najwyższego poziomu.

Private State Tokens

Private State Tokens pozostają utrzymywane jako mechanizm pomagający przekazywać ograniczone sygnały zaufania bez klasycznego śledzenia użytkownika pomiędzy witrynami.

Pozostałe wspierane elementy

Status wymienia również:

• bounce tracking mitigations,
• Fenced Frames,
• frame-ancestors,
• User-Agent Client Hints i redukcję User-Agent.

Nie wszystkie z nich są zamiennikami third-party cookies. Są to odrębne mechanizmy platformy prywatności i bezpieczeństwa.

7. Czy wystarczy SameSite=None; Secure?

Nie.

To jeden z najważniejszych mitów.

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

oznacza, że cookie może być wysyłane w kontekście cross-site, jeżeli przeglądarka zezwala na niepartycjonowane cookies stron trzecich.

Nie oznacza, że:

• użytkownik ich nie zablokował,
• Incognito je dopuści,
• Safari lub Firefox zachowają się tak samo jak Chrome,
• Chrome Enterprise nie zastosuje polityki,
• iframe ma Storage Access,
• mechanizm ochrony przed trackingiem nie ograniczy dostępu.

Kod powinien wykrywać realną dostępność.

8. Jak wykrywać dostępność cookies w embedzie?

Chrome opisuje dwie podstawowe metody.

document.hasStorageAccess()

const hasAccess = await document.hasStorageAccess();

Metoda pozwala osadzonemu dokumentowi sprawdzić, czy ma dostęp do niepartycjonowanych cookies.

Sec-Fetch-Storage-Access

Od Chrome 133 credentialed requests mogą zawierać nagłówek:

Sec-Fetch-Storage-Access: active

Możliwe wartości:

• none,
• inactive,
• active.

Przykład po stronie serwera:

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

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

Czego nie używać jako jedynego testu?

navigator.cookieEnabled

Ta właściwość nie mówi wiarygodnie, czy konkretne iframe ma dostęp do konkretnego third-party cookie. Może jedynie wskazywać ogólną obsługę cookies.

9. Co z requestStorageAccessFor()?

To nie jest to samo co:

document.requestStorageAccess()

requestStorageAccessFor() było rozszerzeniem związanym z Related Website Sets, pozwalającym witrynie najwyższego poziomu prosić o dostęp w imieniu zasobu z powiązanej witryny.

Ponieważ Related Website Sets jest wycofywane, requestStorageAccessFor() również ma status deprecate and remove.

MDN oznacza tę metodę jako deprecated i non-standard.

Zwykłe requestStorageAccess() pozostaje wspieranym, międzyprzeglądarkowym kierunkiem dla osadzonych dokumentów wymagających niepartycjonowanego stanu.

10. Konsekwencje dla logowania

Najbardziej narażone są przepływy, które zakładają, że IdP osadzony w iframe zawsze odczyta własne cookie.

Możliwe kierunki:

Przypadek	Lepsze rozwiązanie
federacyjne logowanie	FedCM lub dobrze zaprojektowany top-level OAuth/OIDC flow
sesja własnej aplikacji	first-party cookie na domenie aplikacji
embed wymagający dostępu do istniejącego konta	Storage Access API z czytelnym UX
niezależny stan widgetu	CHIPS
komunikacja parent ↔ iframe	postMessage() z walidacją origin
backend pomiędzy własnymi usługami	tokeny i sesje po stronie serwera, nie śledzące cookies cross-site

Nie należy automatycznie przenosić tokenów do localStorage. Taka zmiana nie rozwiązuje wszystkich problemów i może zwiększyć skutki XSS.

11. Konsekwencje dla analityki

Zwrot Chrome oznacza, że third-party cookies nie zostały globalnie usunięte, ale nadal są niestabilnym fundamentem pomiaru.

Dane mogą różnić się pomiędzy:

• użytkownikami blokującymi cookies,
• zwykłym i prywatnym trybem,
• Chrome, Safari i Firefox,
• urządzeniami zarządzanymi przez organizację,
• użytkownikami z rozszerzeniami blokującymi,
• wdrożeniami z consentem i bez niego.

Attribution Reporting API, które miało być jednym z mechanizmów pomiarowych Privacy Sandbox, jest wycofywane. Google deklaruje jednak dalszą pracę nad interoperacyjnym standardem atrybucji w ramach procesu standardów webowych.

To nie jest gwarancja gotowego zamiennika.

Praktyczne podejście obejmuje:

• first-party measurement,
• jawny consent tam, gdzie jest wymagany,
• modelowanie brakujących danych,
• agregację,
• server-side collection z kontrolą prywatności,
• mierzenie ograniczeń i pokrycia danych,
• unikanie obietnic pełnego śledzenia użytkownika pomiędzy witrynami.

12. Konsekwencje dla reklam

Wycofywane są trzy centralne filary reklamowego Privacy Sandbox:

• Topics,
• Protected Audience,
• Attribution Reporting.

Do tego dochodzą Shared Storage, SelectURL, Private Aggregation i Aggregation Service.

Oznacza to, że nie należy rozpoczynać nowej strategicznej implementacji opartej wyłącznie na tych API bez sprawdzenia bieżącego statusu i planu migracji.

Nie oznacza to automatycznie, że branża wraca do jednego stabilnego modelu third-party-cookie-based advertising. Dostępność cookies pozostaje fragmentaryczna, a pozostałe przeglądarki stosują własne mechanizmy ochrony.

13. Konsekwencje dla widgetów i osadzonych usług

Typowy widget:

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

może wymagać:

• rozpoznania sesji,
• zapamiętania ustawień,
• dostępu do konta użytkownika,
• komunikacji ze stroną nadrzędną.

Wybór rozwiązania powinien zależeć od celu:

Stan tylko dla jednego embeddera

Użyj CHIPS.

Dostęp do istniejącej, niepartycjonowanej sesji

Użyj Storage Access API, z fallbackiem i jasnym komunikatem.

Logowanie federacyjne

Rozważ FedCM.

Stan możliwy do przekazania jawnie

Przekaż minimalne dane z parent do iframe przez postMessage() po ścisłej walidacji origin.

14. Audyt third-party cookies

Chrome rekomenduje audyt DevTools i Privacy Sandbox Analysis Tool.

Krok 1: zinwentaryzuj cookies

Dla każdego cookie zapisz:

Pole	Przykład
nazwa	widget_session
setter	chat.vendor.example
kontekst	iframe
cel	stan rozmowy
wymagane cross-site?	tak
wymagane współdzielenie między witrynami?	nie
alternatywa	CHIPS

Krok 2: znajdź SameSite=None

grep -R "SameSite=None" .

To nie wykryje cookies tworzonych przez zewnętrzne skrypty, dlatego trzeba również użyć DevTools i logów sieciowych.

Krok 3: testuj z blokadą

Chrome dokumentuje flagę:

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

oraz uruchomienie:

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

Dokumentacja nadal rekomenduje ten tryb do testowania awarii przy ograniczonych cookies.

Krok 4: testuj realne ścieżki

• logowanie,
• wylogowanie,
• odświeżenie tokenu,
• płatność,
• czat,
• mapa,
• embedded media,
• consent,
• analityka,
• cross-domain checkout,
• odzyskiwanie konta.

Krok 5: testuj różne przeglądarki

Nie ograniczaj testu do Chrome. Zwrot Chrome nie zmienił polityk Safari i Firefox.

15. Przykładowa progresywna strategia widgetu

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

Po świadomej akcji użytkownika można zaoferować dostęp:

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

Logika musi uwzględniać odmowę. Prompt nie jest obowiązkiem użytkownika.

16. Czego nie robić?

Nie zakładaj, że zwrot Chrome rozwiązał problem

Third-party cookies nadal nie są przewidywalnym dependency.

Nie migruj wszystkiego do fingerprintingu

Zastąpienie cookies agresywnym zbieraniem sygnałów urządzenia nie jest rozwiązaniem privacy-first.

Nie przenoś automatycznie sesji do localStorage

Może to zwiększyć ryzyko przy XSS i nie daje automatycznej możliwości współdzielenia danych cross-site.

Nie używaj CHIPS do cross-site identity

CHIPS celowo izoluje cookie według top-level site.

Nie używaj Storage Access API bez fallbacku

Dostęp może zostać odrzucony.

Nie zaczynaj nowego projektu na wycofywanym API

Sprawdź status Topics, Protected Audience, Attribution Reporting, Shared Storage i RWS przed inwestycją.

Nie utożsamiaj „deprecated” z „już nie działa”

Deprecjacja i usunięcie są procesem. Sprawdź wersję Chrome i Chrome Platform Status.

17. Rekomendowana architektura w 2026 roku

Dla zwykłej aplikacji

• first-party session cookie,
• Secure,
• HttpOnly,
• rozsądne SameSite,
• CSRF protection,
• brak zależności od cross-site iframe.

Dla widgetu

• CHIPS dla stanu izolowanego per witryna,
• anonymous fallback,
• Storage Access tylko dla funkcji wymagającej istniejącej sesji,
• postMessage() z walidacją origin.

Dla federacyjnego logowania

• FedCM, jeżeli pasuje do wspieranego przepływu,
• standardowy redirect OAuth/OIDC jako kompatybilny fallback,
• first-party session po powrocie do aplikacji.

Dla analityki

• first-party collection,
• zgoda i minimalizacja danych,
• jawne raportowanie brakującego pokrycia,
• agregacja zamiast obietnicy pełnej identyfikacji cross-site.

18. Checklista migracyjna

Inwentaryzacja

• Lista wszystkich cookies.
• Określony setter i domain.
• Określony kontekst first-party lub third-party.
• Znany cel biznesowy.
• Znany właściciel integracji.
• Znane konsekwencje blokady.
• Usunięte nieużywane cookies.

Bezpieczeństwo cookies

• Secure na cookies sesyjnych.
• HttpOnly tam, gdzie JavaScript nie potrzebuje dostępu.
• Minimalny Domain.
• Minimalny Path.
• Odpowiedni SameSite.
• Krótki czas życia.
• Prefiks __Host- tam, gdzie pasuje.

Cross-site

• Brak założenia, że SameSite=None gwarantuje dostęp.
• Wykrywanie hasStorageAccess().
• Obsługa odmowy requestStorageAccess().
• CHIPS dla izolowanego stanu.
• FedCM dla wspieranego federacyjnego logowania.
• Fallback bez cookies stron trzecich.
• Test w Incognito.
• Test z blokadą third-party cookies.

Privacy Sandbox

• Brak nowej zależności od Topics.
• Brak nowej zależności od Protected Audience.
• Plan odejścia od Attribution Reporting API.
• Plan odejścia od Shared Storage i SelectURL.
• Plan odejścia od Private Aggregation.
• Plan odejścia od Related Website Sets.
• Usunięte użycie requestStorageAccessFor().
• Monitorowane Chrome release notes.

Testy

• Chrome zwykły.
• Chrome Incognito.
• Chrome z ręczną blokadą.
• Safari.
• Firefox.
• Konto zalogowane i niezalogowane.
• Nowy i istniejący użytkownik.
• Embed na co najmniej dwóch top-level sites.
• Tryb offline i błędy API.
• Zasady Chrome Enterprise, jeżeli dotyczą produktu.

19. Narzędzia POLPROG

Przy audycie warto połączyć analizę cookies z innymi warstwami:

• Kondycja witryny pomaga znaleźć problemy techniczne i wydajnościowe.
• Inspektor nagłówków bezpieczeństwa pozwala sprawdzić CSP, HSTS i inne zabezpieczenia.
• Inspektor DNS i SSL weryfikuje warstwę domeny oraz TLS.
• FlowTrace pomaga prześledzić przepływ żądania, sesji i danych pomiędzy przeglądarką, CDN i backendem.
• W bazie wiedzy POLPROG znajdują się materiały o prywatności, bezpieczeństwie i architekturze webowej.

Werdykt

Chrome nie wykonał dawnego planu globalnego wyłączenia third-party cookies. Użytkownicy nadal mają wybór, a nowy osobny prompt nie został wdrożony.

Nie oznacza to jednak, że third-party cookies odzyskały status stabilnego standardu, na którym można bezpiecznie oprzeć produkt.

W 2026 roku:

• część użytkowników ma cookies zablokowane,
• Incognito blokuje je domyślnie,
• polityki organizacyjne mogą je ograniczać,
• inne przeglądarki stosują własne reguły,
• storage jest coraz częściej partycjonowane,
• wiele reklamowych API Privacy Sandbox jest wycofywanych,
• rozwiązania funkcjonalne takie jak CHIPS, Storage Access API i FedCM pozostają.

Najlepsza architektura nie próbuje zgadywać przyszłej decyzji Chrome. Działa poprawnie niezależnie od tego, czy niepartycjonowane third-party cookies są dostępne.