Third-party cookie: cosa ha cambiato davvero l’inversione di Chrome e quali API Privacy Sandbox spariscono

Nel 2026 questa descrizione è ormai superata.

Chrome non ha implementato una disattivazione generalizzata e obbligatoria dei third-party cookies secondo il vecchio calendario. Google ha deciso di mantenere il modello attuale, in cui gli utenti possono gestire l'accesso a questi cookie nelle impostazioni di Chrome. L'azienda ha inoltre rinunciato al piano di introdurre un nuovo prompt dedicato ai third-party cookies.

Questo non significa però un ritorno alla situazione precedente a Privacy Sandbox.

I third-party cookies possono comunque non essere disponibili a causa di:

• una decisione dell'utente,
• la modalità Incognito,
• le policy organizzative di Chrome Enterprise,
• le limitazioni di un browser specifico,
• le impostazioni del sito,
• un gruppo sperimentale di Chrome,
• i meccanismi di partizionamento e di protezione dal tracciamento.

Allo stesso tempo Google ha deciso di ritirare gran parte delle API Privacy Sandbox, tra cui Topics, Protected Audience, Attribution Reporting, Shared Storage e Related Website Sets. Restano invece le soluzioni utili per i casi d'uso funzionali, come CHIPS, Storage Access API, FedCM, il partizionamento dello storage e Private State Tokens.

Conclusione più importante: il cambio di rotta di Chrome non significa che si possano di nuovo progettare login, widget incorporati, analytics e pagamenti presumendo che i third-party cookies non partizionati saranno sempre disponibili. Nel 2026 un'architettura corretta deve gestire entrambi gli stati: cookie disponibili e cookie bloccati.

Stato e documentazione verificati il 23 luglio 2026.

TL;DR

Domanda	Risposta per il 2026
Chrome ha disattivato i third-party cookies per tutti gli utenti?	No
Chrome prevede ancora un nuovo prompt dedicato?	No
L'utente può bloccarli?	Sì
Vengono bloccati per impostazione predefinita in Incognito?	Sì
L'applicazione dovrebbe presumere la loro disponibilità?	No
L'intero Privacy Sandbox scompare?	No
Le API pubblicitarie come Topics e Protected Audience vengono ritirate?	Sì
CHIPS resta supportato?	Sì
Storage Access API resta?	Sì
FedCM resta?	Sì
SameSite=None; Secure garantisce il funzionamento del cookie?	No
Una sola data di rimozione vale per tutte le API?	No

1. Che cos'è un third-party cookie?

Un cookie è un valore memorizzato dal browser e inviato secondo le regole di dominio, percorso, protocollo, durata e attributo SameSite.

Un cookie è considerato third-party quando viene utilizzato in un contesto di sito diverso da quello che si trova in cima alla scheda del browser.

Esempio:

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

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

Se un widget incorporato prova a usare un cookie non partizionato del dominio chat.vendor.example, lo fa in un contesto di terza parte.

Una configurazione tipica che consente di inviare un cookie in contesto cross-site è la seguente:

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

SameSite=None consente di inviare il cookie nelle richieste cross-site, mentre Secure è obbligatorio per i cookie con SameSite=None nei browser moderni.

Si tratta però solo di una condizione tecnica. Non è una garanzia che il browser consenta il third-party cookie. Un'impostazione dell'utente o una policy del browser possono comunque bloccarlo.

2. Come è cambiato il piano di Chrome?

Fase 1: l'annuncio di un mondo senza third-party cookies

Privacy Sandbox è nato come un insieme di proposte volte a limitare il tracciamento tra siti e, allo stesso tempo, a fornire soluzioni per pubblicità, misurazione, prevenzione degli abusi e identità.

Nel gennaio 2024 Chrome ha iniziato a limitare i third-party cookies per l'1% degli utenti nell'ambito del test Tracking Protection.

Fase 2: l'abbandono del phase-out generalizzato

Nel luglio 2024 Google ha annunciato un cambio di direzione: al posto di una disattivazione generalizzata dei cookie è stato proposto un approccio basato sulla scelta dell'utente.

Il 22 aprile 2025 Google ha precisato la decisione:

• Chrome mantiene l'attuale approccio basato sulla scelta dell'utente,
• il nuovo prompt dedicato non verrà implementato,
• gli utenti continuano a gestire i cookie nelle impostazioni Privacy and Security,
• Incognito continua a bloccare i third-party cookies per impostazione predefinita.

È proprio questo il «cambio di rotta di Chrome» più importante.

Fase 3: la riduzione di Privacy Sandbox

Il 17 ottobre 2025 Google ha annunciato che, dopo aver analizzato l'adozione e i pareri dell'ecosistema, avrebbe ritirato una parte significativa delle tecnologie Privacy Sandbox.

Nel gennaio 2026 le release notes di Chrome 144 hanno indicato la deprecazione e la rimozione pianificata di Private Aggregation, Shared Storage e Protected Audience.

Non bisogna però ridurre l'intero cambiamento a Chrome 144. Lo stato ufficiale comprende più tecnologie e il processo del loro ritiro è distribuito nel tempo e condotto secondo le procedure di Chrome e di Android.

3. Cosa significa «Chrome mantiene l'approccio attuale»?

Non significa:

• la garanzia della disponibilità dei cookie in ogni installazione,
• un ritorno al tracciamento cross-site illimitato,
• l'annullamento del partizionamento dello storage,
• un comportamento identico di Chrome, Safari e Firefox,
• la garanzia che un'integrazione SSO o iframe esistente funzionerà.

Significa che Chrome non ha sostituito il modello attuale con un'unica disattivazione globale e un nuovo prompt esteso all'intera base di utenti.

La documentazione ufficiale di Chrome descrive ancora diverse cause di blocco dei cookie:

• le impostazioni dell'utente,
• le limitazioni del browser,
• i flag sperimentali,
• le policy di Chrome Enterprise.

La stessa documentazione, aggiornata il 18 dicembre 2025, informa ancora del gruppo dell'1% di utenti per cui i third-party cookies sono limitati per impostazione predefinita a scopo di test.

Per lo sviluppatore la conclusione pratica è semplice:

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

4. Quali tecnologie Privacy Sandbox vengono ritirate?

Lo stato ufficiale usa diverse categorie:

• Deprecate and remove - l'API è destinata alla deprecazione e alla rimozione.
• Discontinue - il progetto è concluso o in fase di ritiro.
• Do not launch - la tecnologia non verrà lanciata.
• Scheduled for phaseout - è previsto un ritiro graduale.

Non bisogna presentarle come un'unica «disattivazione di Privacy Sandbox» simultanea.

Principali tecnologie web destinate a deprecazione e rimozione

Tecnologia	Utilizzo originario	Stato
Attribution Reporting API	misurazione dell'attribuzione senza identificatore cross-site	deprecate and remove
Aggregation Service	aggregazione dei report per Attribution Reporting	scheduled for phaseout
Topics API	interessi dell'utente per la pubblicità	deprecate and remove
Protected Audience API	remarketing e aste interest-group nel browser	deprecate and remove
Private Aggregation API	misurazioni aggregate cross-site	deprecate and remove
Shared Storage API	storage cross-site con operazioni controllate	deprecate and remove
SelectURL	scelta della variante di URL in base a Shared Storage	ritirato insieme a Shared Storage
Related Website Sets	dichiarazione di domini correlati	deprecate and remove
requestStorageAccessFor()	richiesta di accesso per conto di una risorsa di un sito correlato	deprecate and remove
Related Website Partition	partizione condivisa per i siti correlati	discontinue

Tecnologie concluse o non introdotte

Tecnologia	Stato
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 ritira anche:

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

5. Cosa scompariva esattamente in Chrome 144?

Chrome 144, rilasciato come versione stable nel gennaio 2026, conteneva voci formali di deprecazione per:

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

Le release notes parlano di un piano di deprecazione e rimozione, non di una garanzia che tutti gli elementi abbiano immediatamente smesso di funzionare in ogni installazione.

Questo è importante durante la migrazione. I segnali possono comparire per fasi:

1. l'annuncio Intent to Deprecate,
2. avvisi nella console o nella documentazione,
3. il cambiamento dello stato predefinito,
4. la rimozione del codice,
5. un eventuale deprecation trial o periodo di transizione.

Il team dovrebbe seguire Chrome Platform Status e le release notes, invece di basarsi su un'unica data presa da un articolo.

6. Cosa resta supportato?

Privacy Sandbox non scompare come un unico pacchetto. Lo stato ufficiale indica le tecnologie che restano supportate.

CHIPS

CHIPS consente di contrassegnare un cookie con l'attributo Partitioned. Il browser crea un «barattolo» di cookie separato per ogni sito di primo livello.

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

Se chat.vendor.example è incorporato su:

shop-a.example
shop-b.example

ottiene due partizioni separate. Un cookie impostato nel contesto di shop-a.example non è disponibile nell'incorporamento su shop-b.example.

CHIPS è adatto, tra l'altro, a:

• widget di chat,
• mappe,
• pagamenti incorporati,
• stato di un componente per singolo sito,
• risorse che richiedono una sessione limitata a un singolo embedder.

CHIPS non è un sostituto quando lo stesso identificatore deve essere condiviso tra siti indipendenti. È proprio l'assenza di questa possibilità a costituire il meccanismo di protezione della privacy.

Storage Access API

Storage Access API consente a un documento incorporato di verificare se ha accesso ai cookie non partizionati e di richiedere tale accesso al browser.

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

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

L'accesso:

• può richiedere un'interazione dell'utente,
• può attivare un prompt,
• è soggetto alle policy del browser,
• può essere negato,
• richiede un contesto sicuro,
• può essere bloccato dalla Permissions Policy.

Non bisogna considerare requestStorageAccess() come un aggiramento automatico della privacy.

FedCM

La Federated Credential Management API è pensata per i flussi di identità federata senza dipendere dai third-party cookies e dai classici reindirizzamenti di navigazione.

FedCM ha senso per:

• «Accedi tramite un provider di identità»,
• One Tap,
• la creazione federata di account,
• flussi in cui il browser fa da intermediario tra RP e IdP.

Non è un sostituto universale di tutti i cookie. Non risolve lo stato del widget, l'analytics né ogni funzionalità di OpenID Connect.

Partizionamento di storage e stato di rete

Chrome continua a supportare il partizionamento dello storage e dello stato di rete. L'obiettivo è limitare la possibilità di collegare l'attività dell'utente tra diversi siti di primo livello.

Private State Tokens

Private State Tokens restano mantenuti come meccanismo che aiuta a trasmettere segnali di fiducia limitati senza il classico tracciamento dell'utente tra siti.

Altri elementi supportati

Lo stato elenca anche:

• bounce tracking mitigations,
• Fenced Frames,
• frame-ancestors,
• User-Agent Client Hints e la riduzione dello User-Agent.

Non tutti sono sostituti dei third-party cookies. Sono meccanismi distinti della piattaforma di privacy e sicurezza.

7. Basta SameSite=None; Secure?

No.

È uno dei miti più diffusi.

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

significa che il cookie può essere inviato in contesto cross-site, se il browser consente i cookie di terze parti non partizionati.

Non significa che:

• l'utente non li abbia bloccati,
• Incognito li consenta,
• Safari o Firefox si comportino allo stesso modo di Chrome,
• Chrome Enterprise non applichi una policy,
• l'iframe abbia Storage Access,
• un meccanismo di protezione dal tracciamento non limiti l'accesso.

Il codice dovrebbe rilevare la disponibilità reale.

8. Come rilevare la disponibilità dei cookie in un embed?

Chrome descrive due metodi principali.

document.hasStorageAccess()

const hasAccess = await document.hasStorageAccess();

Il metodo consente a un documento incorporato di verificare se ha accesso ai cookie non partizionati.

Sec-Fetch-Storage-Access

A partire da Chrome 133 le credentialed request possono includere l'header:

Sec-Fetch-Storage-Access: active

Valori possibili:

• none,
• inactive,
• active.

Esempio lato server:

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

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

Cosa non usare come unico test?

navigator.cookieEnabled

Questa proprietà non indica in modo affidabile se un determinato iframe ha accesso a un determinato third-party cookie. Può soltanto segnalare il supporto generale dei cookie.

9. E per quanto riguarda requestStorageAccessFor()?

Non è la stessa cosa di:

document.requestStorageAccess()

requestStorageAccessFor() era un'estensione legata a Related Website Sets, che consentiva a un sito di primo livello di richiedere l'accesso per conto di una risorsa di un sito correlato.

Poiché Related Website Sets viene ritirato, anche requestStorageAccessFor() ha lo stato deprecate and remove.

MDN contrassegna questo metodo come deprecated e non-standard.

Il normale requestStorageAccess() resta la direzione supportata e cross-browser per i documenti incorporati che richiedono uno stato non partizionato.

10. Conseguenze per il login

I più esposti sono i flussi che presumono che un IdP incorporato in un iframe legga sempre il proprio cookie.

Direzioni possibili:

Caso	Soluzione migliore
login federato	FedCM o un flusso OAuth/OIDC top-level ben progettato
sessione della propria applicazione	first-party cookie sul dominio dell'applicazione
embed che richiede l'accesso a un account esistente	Storage Access API con una UX chiara
stato indipendente del widget	CHIPS
comunicazione parent ↔ iframe	postMessage() con validazione dell'origin
backend tra i propri servizi	token e sessioni lato server, non cookie di tracciamento cross-site

Non bisogna spostare automaticamente i token in localStorage. Un cambiamento del genere non risolve tutti i problemi e può aggravare le conseguenze di un XSS.

11. Conseguenze per l'analytics

Il cambio di rotta di Chrome significa che i third-party cookies non sono stati rimossi a livello globale, ma restano una base instabile per la misurazione.

I dati possono differire tra:

• utenti che bloccano i cookie,
• modalità normale e modalità privata,
• Chrome, Safari e Firefox,
• dispositivi gestiti da un'organizzazione,
• utenti con estensioni di blocco,
• implementazioni con e senza consenso.

Attribution Reporting API, che avrebbe dovuto essere uno dei meccanismi di misurazione di Privacy Sandbox, viene ritirata. Google dichiara però di continuare a lavorare su uno standard di attribuzione interoperabile nell'ambito del processo degli standard web.

Questo non è una garanzia di un sostituto già pronto.

Un approccio pratico comprende:

• first-party measurement,
• consenso esplicito dove è richiesto,
• la modellazione dei dati mancanti,
• l'aggregazione,
• server-side collection con controllo della privacy,
• la misurazione dei limiti e della copertura dei dati,
• evitare promesse di un tracciamento completo dell'utente tra siti.

12. Conseguenze per la pubblicità

Vengono ritirati i tre pilastri centrali del Privacy Sandbox pubblicitario:

• Topics,
• Protected Audience,
• Attribution Reporting.

A questi si aggiungono Shared Storage, SelectURL, Private Aggregation e Aggregation Service.

Ciò significa che non bisogna avviare una nuova implementazione strategica basata esclusivamente su queste API senza verificare lo stato attuale e il piano di migrazione.

Questo non significa automaticamente che il settore torni a un unico modello stabile di third-party-cookie-based advertising. La disponibilità dei cookie resta frammentaria e gli altri browser applicano i propri meccanismi di protezione.

13. Conseguenze per i widget e i servizi incorporati

Un widget tipico:

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

può richiedere:

• il riconoscimento della sessione,
• la memorizzazione delle impostazioni,
• l'accesso all'account dell'utente,
• la comunicazione con la pagina principale.

La scelta della soluzione dovrebbe dipendere dall'obiettivo:

Stato solo per un singolo embedder

Usa CHIPS.

Accesso a una sessione esistente, non partizionata

Usa Storage Access API, con un fallback e un messaggio chiaro.

Login federato

Valuta FedCM.

Stato trasmissibile in modo esplicito

Trasmetti dati minimi dal parent all'iframe tramite postMessage() dopo una rigorosa validazione dell'origin.

14. Audit dei third-party cookies

Chrome consiglia un audit con DevTools e il Privacy Sandbox Analysis Tool.

Passo 1: inventaria i cookie

Per ogni cookie annota:

Campo	Esempio
nome	widget_session
setter	chat.vendor.example
contesto	iframe
scopo	stato della conversazione
cross-site richiesto?	sì
condivisione tra siti richiesta?	no
alternativa	CHIPS

Passo 2: individua SameSite=None

grep -R "SameSite=None" .

Questo non rileverà i cookie creati da script esterni, perciò occorre usare anche DevTools e i log di rete.

Passo 3: testa con il blocco

Chrome documenta il flag:

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

e l'avvio:

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

La documentazione consiglia ancora questa modalità per testare i malfunzionamenti in caso di cookie limitati.

Passo 4: testa i percorsi reali

• login,
• logout,
• refresh del token,
• pagamento,
• chat,
• mappa,
• embedded media,
• consenso,
• analytics,
• cross-domain checkout,
• recupero dell'account.

Passo 5: testa browser diversi

Non limitare il test a Chrome. Il cambio di rotta di Chrome non ha modificato le policy di Safari e Firefox.

15. Esempio di strategia progressiva per un widget

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

Dopo un'azione consapevole dell'utente si può offrire l'accesso:

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

La logica deve tenere conto del rifiuto. Il prompt non è un obbligo per l'utente.

16. Cosa non fare?

Non dare per scontato che il cambio di rotta di Chrome abbia risolto il problema

I third-party cookies non sono ancora una dependency prevedibile.

Non migrare tutto verso il fingerprinting

Sostituire i cookie con una raccolta aggressiva di segnali del dispositivo non è una soluzione privacy-first.

Non spostare automaticamente le sessioni in localStorage

Può aumentare il rischio in caso di XSS e non offre automaticamente la possibilità di condividere dati cross-site.

Non usare CHIPS per la cross-site identity

CHIPS isola deliberatamente il cookie in base al top-level site.

Non usare Storage Access API senza fallback

L'accesso può essere respinto.

Non avviare un nuovo progetto su un'API in fase di ritiro

Verifica lo stato di Topics, Protected Audience, Attribution Reporting, Shared Storage e RWS prima di investire.

Non identificare «deprecated» con «non funziona più»

La deprecazione e la rimozione sono un processo. Verifica la versione di Chrome e Chrome Platform Status.

17. Architettura consigliata nel 2026

Per un'applicazione ordinaria

• first-party session cookie,
• Secure,
• HttpOnly,
• un SameSite ragionevole,
• CSRF protection,
• nessuna dipendenza da iframe cross-site.

Per un widget

• CHIPS per lo stato isolato per singolo sito,
• anonymous fallback,
• Storage Access solo per una funzionalità che richiede una sessione esistente,
• postMessage() con validazione dell'origin.

Per il login federato

• FedCM, se si adatta a un flusso supportato,
• il redirect standard OAuth/OIDC come fallback compatibile,
• first-party session al ritorno nell'applicazione.

Per l'analytics

• first-party collection,
• consenso e minimizzazione dei dati,
• reporting esplicito della copertura mancante,
• aggregazione invece della promessa di un'identificazione cross-site completa.

18. Checklist di migrazione

Inventario

• Elenco di tutti i cookie.
• Setter e domain identificati.
• Contesto first-party o third-party identificato.
• Obiettivo di business noto.
• Proprietario dell'integrazione noto.
• Conseguenze del blocco note.
• Cookie inutilizzati rimossi.

Sicurezza dei cookie

• Secure sui cookie di sessione.
• HttpOnly dove JavaScript non ha bisogno di accedere.
• Domain minimo.
• Path minimo.
• SameSite appropriato.
• Durata breve.
• Prefisso __Host- dove appropriato.

Cross-site

• Nessuna assunzione che SameSite=None garantisca l'accesso.
• Rilevamento di hasStorageAccess().
• Gestione del rifiuto di requestStorageAccess().
• CHIPS per lo stato isolato.
• FedCM per il login federato supportato.
• Fallback senza cookie di terze parti.
• Test in Incognito.
• Test con il blocco dei third-party cookies.

Privacy Sandbox

• Nessuna nuova dipendenza da Topics.
• Nessuna nuova dipendenza da Protected Audience.
• Piano di abbandono di Attribution Reporting API.
• Piano di abbandono di Shared Storage e SelectURL.
• Piano di abbandono di Private Aggregation.
• Piano di abbandono di Related Website Sets.
• Uso di requestStorageAccessFor() rimosso.
• Chrome release notes monitorate.

Test

• Chrome normale.
• Chrome Incognito.
• Chrome con blocco manuale.
• Safari.
• Firefox.
• Account con e senza login.
• Utente nuovo ed esistente.
• Embed su almeno due top-level sites.
• Modalità offline ed errori API.
• Policy di Chrome Enterprise, se riguardano il prodotto.

19. Strumenti POLPROG

Durante l'audit conviene combinare l'analisi dei cookie con altri livelli:

• Stato di salute del sito aiuta a individuare problemi tecnici e di prestazioni.
• Ispettore degli header di sicurezza consente di verificare CSP, HSTS e altre protezioni.
• Ispettore DNS e SSL verifica il livello del dominio e TLS.
• FlowTrace aiuta a seguire il flusso della richiesta, della sessione e dei dati tra browser, CDN e backend.
• Nella base di conoscenza POLPROG sono disponibili materiali su privacy, sicurezza e architettura web.

Verdetto

Chrome non ha realizzato il vecchio piano di disattivazione globale dei third-party cookies. Gli utenti hanno ancora la possibilità di scegliere e il nuovo prompt dedicato non è stato implementato.

Questo non significa però che i third-party cookies abbiano riacquistato lo status di standard stabile su cui poter basare un prodotto in sicurezza.

Nel 2026:

• una parte degli utenti ha i cookie bloccati,
• Incognito li blocca per impostazione predefinita,
• le policy organizzative possono limitarli,
• gli altri browser applicano le proprie regole,
• lo storage è sempre più spesso partizionato,
• molte API pubblicitarie di Privacy Sandbox vengono ritirate,
• le soluzioni funzionali come CHIPS, Storage Access API e FedCM restano.

La migliore architettura non cerca di indovinare la futura decisione di Chrome. Funziona correttamente indipendentemente dal fatto che i third-party cookies non partizionati siano disponibili.