Third-party cookies: co skutečně změnil obrat Chrome a které API Privacy Sandbox zmizí

V roce 2026 je tento popis již neaktuální.

Chrome nezavedl plošné, povinné vypnutí third-party cookies podle dřívějšího harmonogramu. Google se rozhodl zachovat současný model, ve kterém uživatelé mohou spravovat přístup k takovým cookies v nastavení Chrome. Společnost rovněž upustila od plánu zavést nový, samostatný prompt týkající se third-party cookies.

Neznamená to však návrat do stavu před Privacy Sandbox.

Third-party cookies mohou být i nadále nedostupná z důvodu:

• rozhodnutí uživatele,
• režimu Incognito,
• organizačních zásad Chrome Enterprise,
• omezení konkrétního prohlížeče,
• nastavení webu,
• experimentální skupiny Chrome,
• mechanismů partitioningu a ochrany před sledováním.

Zároveň se Google rozhodl vyřadit velkou část API Privacy Sandbox, včetně Topics, Protected Audience, Attribution Reporting, Shared Storage a Related Website Sets. Zůstávají naopak řešení užitečná pro funkční případy použití, jako jsou CHIPS, Storage Access API, FedCM, partitioning storage a Private State Tokens.

Nejdůležitější závěr: obrat Chrome neznamená, že lze znovu navrhovat přihlašování, vložené widgety, analytiku a platby s předpokladem, že nepartitionovaná third-party cookies budou vždy dostupná. V roce 2026 musí správná architektura obsluhovat oba stavy: cookie dostupné i cookie zablokované.

Status a dokumentace ověřeny 23. července 2026.

TL;DR

Otázka	Odpověď pro rok 2026
Vypnul Chrome third-party cookies všem uživatelům?	Ne
Plánuje Chrome stále nový samostatný prompt?	Ne
Může je uživatel zablokovat?	Ano
Jsou ve výchozím nastavení blokovány v Incognito?	Ano
Měla by aplikace předpokládat jejich dostupnost?	Ne
Mizí celý Privacy Sandbox?	Ne
Jsou reklamní API jako Topics a Protected Audience vyřazována?	Ano
Zůstává CHIPS podporováno?	Ano
Zůstává Storage Access API?	Ano
Zůstává FedCM?	Ano
Zaručuje SameSite=None; Secure funkčnost cookie?	Ne
Platí jedno datum odstranění pro všechna API?	Ne

1. Co je to third-party cookie?

Cookie je hodnota ukládaná prohlížečem a odesílaná podle pravidel domény, cesty, protokolu, doby platnosti a atributu SameSite.

Cookie je považováno za third-party v situaci, kdy je používáno v kontextu jiného webu, než je web nacházející se v horní části karty prohlížeče.

Příklad:

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

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

Pokud se vložený widget pokusí použít nepartitionované cookie domény chat.vendor.example, dělá to v kontextu třetí strany.

Typická konfigurace umožňující odesílat cookie v kontextu cross-site vypadá takto:

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

SameSite=None umožňuje odesílání cookie v požadavcích cross-site a Secure je vyžadováno pro cookies s SameSite=None v moderních prohlížečích.

To je však jen technická podmínka. Není zárukou, že prohlížeč third-party cookie povolí. Nastavení uživatele nebo zásady prohlížeče je mohou i nadále zablokovat.

2. Jak se měnil plán Chrome?

Fáze 1: ohlášení světa bez third-party cookies

Privacy Sandbox vzniklo jako soubor návrhů, které měly omezit sledování mezi weby a zároveň zajistit řešení pro reklamy, měření, prevenci zneužití a identitu.

V lednu 2024 začal Chrome omezovat third-party cookies pro 1 % uživatelů v rámci testu Tracking Protection.

Fáze 2: odklon od plošného phase-out

V červenci 2024 Google oznámil změnu směru: místo plošného vypnutí cookies bylo navrženo řešení založené na volbě uživatele.

22. dubna 2025 Google upřesnil rozhodnutí:

• Chrome zachovává aktuální přístup k volbě uživatele,
• nový samostatný prompt nebude zaveden,
• uživatelé i nadále spravují cookies v nastavení Privacy and Security,
• Incognito i nadále blokuje third-party cookies ve výchozím nastavení.

Právě to je nejdůležitější „obrat Chrome".

Fáze 3: redukce Privacy Sandbox

17. října 2025 Google oznámil, že po analýze adopce a názorů ekosystému vyřadí značnou část technologií Privacy Sandbox.

V lednu 2026 release notes Chrome 144 uvedly deprecaci a plánované odstranění Private Aggregation, Shared Storage a Protected Audience.

Celou změnu však nelze redukovat na Chrome 144. Oficiální status zahrnuje více technologií a proces jejich vyřazování je rozložen a veden v souladu s postupy Chrome a Androidu.

3. Co znamená „Chrome zachovává současný přístup"?

Neznamená to:

• záruku dostupnosti cookies v každé instalaci,
• návrat k neomezenému sledování cross-site,
• zrušení partitioningu storage,
• identické chování Chrome, Safari a Firefox,
• záruku, že stávající integrace SSO nebo iframe bude fungovat.

Znamená to, že Chrome nenahradil současný model jedním globálním vypnutím a novým promptem zahrnujícím celou uživatelskou základnu.

Oficiální dokumentace Chrome i nadále popisuje několik důvodů blokování cookies:

• nastavení uživatele,
• omezení prohlížeče,
• testovací příznaky,
• zásady Chrome Enterprise.

Tatáž dokumentace, aktualizovaná 18. prosince 2025, i nadále informuje o skupině 1 % uživatelů, pro kterou jsou third-party cookies ve výchozím nastavení omezeny za účelem testování.

Pro vývojáře je praktický závěr jednoduchý:

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

4. Které technologie Privacy Sandbox jsou vyřazovány?

Oficiální status používá několik různých kategorií:

• Deprecate and remove - API je určeno k deprecaci a odstranění.
• Discontinue - projekt je ukončen nebo vyřazován.
• Do not launch - technologie nebude spuštěna.
• Scheduled for phaseout - plánováno je postupné vyřazení.

Nelze je prezentovat jako jedno souběžné „vypnutí Privacy Sandbox".

Hlavní webové technologie určené k deprecaci a odstranění

Technologie	Původní použití	Status
Attribution Reporting API	měření atribuce bez identifikátoru cross-site	deprecate and remove
Aggregation Service	agregace reportů pro Attribution Reporting	scheduled for phaseout
Topics API	zájmy uživatele pro reklamy	deprecate and remove
Protected Audience API	remarketing a aukce interest-group v prohlížeči	deprecate and remove
Private Aggregation API	agregovaná měření cross-site	deprecate and remove
Shared Storage API	cross-site storage s řízenými operacemi	deprecate and remove
SelectURL	výběr varianty URL na základě Shared Storage	vyřazováno spolu se Shared Storage
Related Website Sets	deklarování souvisejících domén	deprecate and remove
requestStorageAccessFor()	žádost o přístup jménem zdroje související webové stránky	deprecate and remove
Related Website Partition	sdílená partition pro související weby	discontinue

Technologie ukončené nebo nezavádě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 vyřazuje také:

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

5. Co přesně mizelo v Chrome 144?

Chrome 144, vydaný jako stable v lednu 2026, obsahoval formální deprecační položky pro:

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

Release notes hovoří o plánu deprecace a odstranění, nikoli o záruce, že všechny prvky okamžitě přestaly fungovat v každé instalaci.

To je důležité při migraci. Signály se mohou objevovat po etapách:

1. zpráva Intent to Deprecate,
2. varování v konzoli nebo dokumentaci,
3. změna výchozího stavu,
4. odstranění kódu,
5. případný deprecation trial nebo přechodné období.

Tým by měl sledovat Chrome Platform Status a release notes, místo aby se opíral o jedno datum z článku.

6. Co zůstává podporováno?

Privacy Sandbox nemizí jako jeden balík. Oficiální status uvádí technologie, které zůstávají v podpoře.

CHIPS

CHIPS umožňuje označit cookie atributem Partitioned. Prohlížeč vytváří samostatnou „nádobu" na cookie pro každý web nejvyšší úrovně.

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

Pokud je chat.vendor.example vložen na:

shop-a.example
shop-b.example

obdrží dvě samostatné partition. Cookie nastavené v kontextu shop-a.example není dostupné ve vložení na shop-b.example.

CHIPS se hodí mimo jiné pro:

• widgety chatu,
• mapy,
• vložené platby,
• stav komponenty per web,
• zdroje vyžadující relaci omezenou na jednoho embeddera.

CHIPS není náhradou, pokud má být tentýž identifikátor sdílen mezi nezávislými weby. Právě absence takové možnosti představuje mechanismus ochrany soukromí.

Storage Access API

Storage Access API umožňuje vloženému dokumentu ověřit, zda má přístup k nepartitionovaným cookies, a požádat prohlížeč o takový přístup.

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

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

Přístup:

• může vyžadovat aktivitu uživatele,
• může vyvolat prompt,
• podléhá zásadám prohlížeče,
• může být zamítnut,
• vyžaduje bezpečný kontext,
• může být zablokován prostřednictvím Permissions Policy.

requestStorageAccess() nelze považovat za automatické obejití soukromí.

FedCM

Federated Credential Management API je určeno pro federativní toky identity bez závislosti na third-party cookies a klasických navigačních přesměrováních.

FedCM má smysl pro:

• „Přihlásit přes poskytovatele identity",
• One Tap,
• federativní vytváření účtů,
• toky, ve kterých prohlížeč zprostředkovává mezi RP a IdP.

Není univerzální náhradou všech cookies. Neřeší stav widgetu, analytiku ani každou funkci OpenID Connect.

Storage a Network State Partitioning

Chrome i nadále podporuje partitioning storage a síťového stavu. Cílem je omezit možnost propojování aktivity uživatele mezi různými weby nejvyšší úrovně.

Private State Tokens

Private State Tokens zůstávají udržovány jako mechanismus pomáhající předávat omezené signály důvěry bez klasického sledování uživatele mezi weby.

Ostatní podporované prvky

Status uvádí rovněž:

• bounce tracking mitigations,
• Fenced Frames,
• frame-ancestors,
• User-Agent Client Hints a redukci User-Agent.

Ne všechny z nich jsou náhradou third-party cookies. Jsou to samostatné mechanismy platformy soukromí a bezpečnosti.

7. Stačí SameSite=None; Secure?

Ne.

To je jeden z nejdůležitějších mýtů.

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

znamená, že cookie může být odesíláno v kontextu cross-site, pokud prohlížeč povoluje nepartitionovaná cookies třetích stran.

Neznamená, že:

• uživatel je nezablokoval,
• Incognito je povolí,
• Safari nebo Firefox se budou chovat stejně jako Chrome,
• Chrome Enterprise neuplatní zásadu,
• iframe má Storage Access,
• mechanismus ochrany před trackingem neomezí přístup.

Kód by měl detekovat reálnou dostupnost.

8. Jak detekovat dostupnost cookies v embedu?

Chrome popisuje dvě základní metody.

document.hasStorageAccess()

const hasAccess = await document.hasStorageAccess();

Metoda umožňuje vloženému dokumentu ověřit, zda má přístup k nepartitionovaným cookies.

Sec-Fetch-Storage-Access

Od Chrome 133 mohou credentialed requests obsahovat hlavičku:

Sec-Fetch-Storage-Access: active

Možné hodnoty:

• none,
• inactive,
• active.

Příklad na straně serveru:

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

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

Co nepoužívat jako jediný test?

navigator.cookieEnabled

Tato vlastnost spolehlivě neříká, zda konkrétní iframe má přístup ke konkrétnímu third-party cookie. Může pouze naznačovat obecnou podporu cookies.

9. Co s requestStorageAccessFor()?

To není totéž co:

document.requestStorageAccess()

requestStorageAccessFor() bylo rozšířením souvisejícím s Related Website Sets, které umožňovalo webu nejvyšší úrovně žádat o přístup jménem zdroje ze souvisejícího webu.

Protože Related Website Sets je vyřazováno, requestStorageAccessFor() má rovněž status deprecate and remove.

MDN označuje tuto metodu jako deprecated a non-standard.

Běžné requestStorageAccess() zůstává podporovaným, mezi-prohlížečovým směrem pro vložené dokumenty vyžadující nepartitionovaný stav.

10. Důsledky pro přihlašování

Nejohroženější jsou toky, které předpokládají, že IdP vložený v iframe vždy načte vlastní cookie.

Možné směry:

Případ	Lepší řešení
federativní přihlašování	FedCM nebo dobře navržený top-level OAuth/OIDC flow
relace vlastní aplikace	first-party cookie na doméně aplikace
embed vyžadující přístup ke stávajícímu účtu	Storage Access API s přehledným UX
nezávislý stav widgetu	CHIPS
komunikace parent ↔ iframe	postMessage() s validací origin
backend mezi vlastními službami	tokeny a relace na straně serveru, nikoli sledující cookies cross-site

Tokeny by se neměly automaticky přesouvat do localStorage. Taková změna neřeší všechny problémy a může zvýšit dopady XSS.

11. Důsledky pro analytiku

Obrat Chrome znamená, že third-party cookies nebyly globálně odstraněny, ale i nadále jsou nestabilním základem měření.

Data se mohou lišit mezi:

• uživateli blokujícími cookies,
• běžným a soukromým režimem,
• Chrome, Safari a Firefox,
• zařízeními spravovanými organizací,
• uživateli s blokujícími rozšířeními,
• nasazeními s consentem i bez něj.

Attribution Reporting API, které mělo být jedním z měřicích mechanismů Privacy Sandbox, je vyřazováno. Google však deklaruje další práci na interoperabilním standardu atribuce v rámci procesu webových standardů.

To není záruka hotové náhrady.

Praktické řešení zahrnuje:

• first-party measurement,
• explicitní consent tam, kde je vyžadován,
• modelování chybějících dat,
• agregaci,
• server-side collection s kontrolou soukromí,
• měření omezení a pokrytí dat,
• vyhýbání se slibům úplného sledování uživatele mezi weby.

12. Důsledky pro reklamy

Vyřazovány jsou tři centrální pilíře reklamního Privacy Sandbox:

• Topics,
• Protected Audience,
• Attribution Reporting.

K tomu se přidávají Shared Storage, SelectURL, Private Aggregation a Aggregation Service.

Znamená to, že by se neměla zahajovat nová strategická implementace založená výhradně na těchto API bez ověření aktuálního statusu a plánu migrace.

Neznamená to automaticky, že se odvětví vrací k jednomu stabilnímu modelu third-party-cookie-based advertising. Dostupnost cookies zůstává roztříštěná a ostatní prohlížeče používají vlastní mechanismy ochrany.

13. Důsledky pro widgety a vložené služby

Typický widget:

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

může vyžadovat:

• rozpoznání relace,
• zapamatování nastavení,
• přístupu k účtu uživatele,
• komunikace s nadřazenou stránkou.

Výběr řešení by měl záviset na cíli:

Stav pouze pro jednoho embeddera

Použijte CHIPS.

Přístup ke stávající, nepartitionované relaci

Použijte Storage Access API, s fallbackem a jasnou zprávou.

Federativní přihlašování

Zvažte FedCM.

Stav, který lze předat explicitně

Předejte minimální data z parent do iframe pomocí postMessage() po přísné validaci origin.

14. Audit third-party cookies

Chrome doporučuje audit DevTools a Privacy Sandbox Analysis Tool.

Krok 1: inventarizujte cookies

Pro každé cookie zaznamenejte:

Pole	Příklad
název	widget_session
setter	chat.vendor.example
kontext	iframe
účel	stav konverzace
vyžadováno cross-site?	ano
vyžadováno sdílení mezi weby?	ne
alternativa	CHIPS

Krok 2: najděte SameSite=None

grep -R "SameSite=None" .

To neodhalí cookies vytvořené externími skripty, proto je třeba rovněž použít DevTools a síťové logy.

Krok 3: testujte s blokádou

Chrome dokumentuje příznak:

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

a spuštění:

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

Dokumentace i nadále doporučuje tento režim pro testování výpadků při omezených cookies.

Krok 4: testujte reálné cesty

• přihlašování,
• odhlašování,
• obnovení tokenu,
• platba,
• chat,
• mapa,
• embedded media,
• consent,
• analytika,
• cross-domain checkout,
• obnova účtu.

Krok 5: testujte různé prohlížeče

Neomezujte test na Chrome. Obrat Chrome nezměnil zásady Safari a Firefox.

15. Příklad progresivní strategie 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 vědomé akci uživatele lze nabídnout přístup:

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

Logika musí počítat se zamítnutím. Prompt není povinností uživatele.

16. Co nedělat?

Nepředpokládejte, že obrat Chrome vyřešil problém

Third-party cookies i nadále nejsou předvídatelná dependency.

Nemigrujte vše na fingerprinting

Nahrazení cookies agresivním sběrem signálů zařízení není řešením privacy-first.

Nepřesouvejte automaticky relace do localStorage

Může to zvýšit riziko při XSS a nedává automatickou možnost sdílet data cross-site.

Nepoužívejte CHIPS pro cross-site identity

CHIPS záměrně izoluje cookie podle top-level site.

Nepoužívejte Storage Access API bez fallbacku

Přístup může být odmítnut.

Nezačínejte nový projekt na vyřazovaném API

Před investicí ověřte status Topics, Protected Audience, Attribution Reporting, Shared Storage a RWS.

Neztotožňujte „deprecated" s „už nefunguje"

Deprecace a odstranění jsou proces. Ověřte verzi Chrome a Chrome Platform Status.

17. Doporučená architektura v roce 2026

Pro běžnou aplikaci

• first-party session cookie,
• Secure,
• HttpOnly,
• rozumné SameSite,
• CSRF protection,
• žádná závislost na cross-site iframe.

Pro widget

• CHIPS pro stav izolovaný per web,
• anonymous fallback,
• Storage Access pouze pro funkci vyžadující stávající relaci,
• postMessage() s validací origin.

Pro federativní přihlašování

• FedCM, pokud odpovídá podporovanému toku,
• standardní redirect OAuth/OIDC jako kompatibilní fallback,
• first-party session po návratu do aplikace.

Pro analytiku

• first-party collection,
• souhlas a minimalizace dat,
• explicitní reportování chybějícího pokrytí,
• agregace místo slibu úplné identifikace cross-site.

18. Migrační checklist

Inventarizace

• Seznam všech cookies.
• Určený setter a domain.
• Určený kontext first-party nebo third-party.
• Známý obchodní účel.
• Známý vlastník integrace.
• Známé důsledky blokády.
• Odstraněná nepoužívaná cookies.

Bezpečnost cookies

• Secure na relačních cookies.
• HttpOnly tam, kde JavaScript nepotřebuje přístup.
• Minimální Domain.
• Minimální Path.
• Vhodný SameSite.
• Krátká doba platnosti.
• Prefix __Host- tam, kde se hodí.

Cross-site

• Žádný předpoklad, že SameSite=None zaručuje přístup.
• Detekce hasStorageAccess().
• Obsluha zamítnutí requestStorageAccess().
• CHIPS pro izolovaný stav.
• FedCM pro podporované federativní přihlašování.
• Fallback bez cookies třetích stran.
• Test v Incognito.
• Test s blokádou third-party cookies.

Privacy Sandbox

• Žádná nová závislost na Topics.
• Žádná nová závislost na Protected Audience.
• Plán odklonu od Attribution Reporting API.
• Plán odklonu od Shared Storage a SelectURL.
• Plán odklonu od Private Aggregation.
• Plán odklonu od Related Website Sets.
• Odstraněné použití requestStorageAccessFor().
• Monitorované Chrome release notes.

Testy

• Chrome běžný.
• Chrome Incognito.
• Chrome s ruční blokádou.
• Safari.
• Firefox.
• Účet přihlášený a nepřihlášený.
• Nový a stávající uživatel.
• Embed na alespoň dvou top-level sites.
• Offline režim a chyby API.
• Zásady Chrome Enterprise, pokud se týkají produktu.

19. Nástroje POLPROG

Při auditu se vyplatí propojit analýzu cookies s dalšími vrstvami:

• Kondice webu pomáhá najít technické a výkonnostní problémy.
• Inspektor bezpečnostních hlaviček umožňuje ověřit CSP, HSTS a další zabezpečení.
• Inspektor DNS a SSL ověřuje vrstvu domény a TLS.
• FlowTrace pomáhá sledovat tok požadavku, relace a dat mezi prohlížečem, CDN a backendem.
• V bázi znalostí POLPROG najdete materiály o soukromí, bezpečnosti a webové architektuře.

Verdikt

Chrome nerealizoval dřívější plán globálního vypnutí third-party cookies. Uživatelé mají i nadále volbu a nový samostatný prompt nebyl zaveden.

Neznamená to však, že third-party cookies získala zpět status stabilního standardu, na kterém lze bezpečně postavit produkt.

V roce 2026:

• část uživatelů má cookies zablokovaná,
• Incognito je blokuje ve výchozím nastavení,
• organizační zásady je mohou omezovat,
• jiné prohlížeče používají vlastní pravidla,
• storage je stále častěji rozdělován do oddílů,
• mnoho reklamních API Privacy Sandbox je vyřazováno,
• funkční řešení jako CHIPS, Storage Access API a FedCM zůstávají.

Nejlepší architektura se nesnaží uhodnout budoucí rozhodnutí Chrome. Funguje správně bez ohledu na to, zda jsou nepartitionovaná third-party cookies dostupná.