Consentire agli sviluppatori di attivare un cookie per lo spazio di archiviazione "partizionato", con un cookie jar separato per ogni sito di primo livello.
Stato dell'implementazione
- Opzione supportata per impostazione predefinita in Chrome 114 e versioni successive.
- Una prova dell'origine, ora completata, era disponibile da Chrome 100 a 116.
- Leggi le sezioni Intent to esperimento e Intent to Ship.
Che cos'è CHIPS?
I cookie con stato partizionato indipendente (CHIPS) consentono agli sviluppatori di attivare lo spazio di archiviazione partizionato per un cookie, con jar separati di cookie per sito di primo livello, migliorando la privacy e la sicurezza degli utenti.
Senza il partizionamento, i cookie di terze parti possono consentire ai servizi di monitorare gli utenti e unire le loro informazioni da molti siti di primo livello non correlati. Questo è chiamato monitoraggio tra siti.
I browser stanno eliminando gradualmente i cookie di terze parti non partizionati, quindi i CHIPS, l'API Storage Access e i set di siti web correlati saranno gli unici modi per leggere e scrivere cookie da contesti tra siti, come gli iframe, quando i cookie di terze parti sono bloccati.
CHIPS introduce un nuovo attributo dei cookie, Partitioned
, per supportare i cookie tra siti che sono partizionati in base al contesto di primo livello.
Intestazione Set-Cookie:
Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned;
JavaScript:
document.cookie="__Host-name=value; Secure; Path=/; SameSite=None; Partitioned;"
Un cookie di terze parti partizionato è collegato al sito di primo livello dove viene inizialmente impostato e non è accessibile da nessun'altra parte. In questo modo i cookie impostati da un servizio di terze parti possono essere letti solo nello stesso contesto incorporato del sito di primo livello in cui sono stati inizialmente impostati.
Con i cookie suddivisi, quando un utente visita il sito A e i contenuti incorporati del sito C impostano un cookie con l'attributo Partitioned, il cookie viene salvato in un jar suddiviso destinato solo ai cookie impostati dal sito C quando è incorporato nel sito A. Il browser invierà quel cookie solo se il sito di primo livello A.
Quando l'utente visita un nuovo sito, ad esempio il sito B, un frame C incorporato non riceverà il cookie impostato quando il sito C era incorporato nel sito A.
Se un utente visita il sito C come sito web di primo livello, il cookie partizionato che C ha impostato quando è stato incorporato in A non verrà inviato nella richiesta nemmeno.
Casi d'uso
Ad esempio, il sito retail.example
potrebbe voler collaborare con un servizio di terze parti support.chat.example
per incorporare una casella di chat di assistenza sul suo sito. Oggi molti servizi di chat incorporabili si basano sui cookie per salvare lo stato.
Senza la possibilità di impostare un cookie cross-site, support.chat.example
dovrebbe trovare metodi alternativi, spesso più complessi, per memorizzare lo stato. In alternativa, deve essere incorporato nella pagina di primo livello, il che comporta rischi perché consente allo script support.chat.example
di avere privilegi elevati su retail.example, ad esempio la possibilità di accedere ai cookie di autenticazione.
I CHIPS offrono un'opzione più semplice per continuare a utilizzare i cookie cross-site, senza i rischi associati ai cookie non partizionati.
Esempi di casi d'uso per i CHIPS includono qualsiasi scenario in cui sottorisorse tra siti richiedano una nozione di sessione o stato permanente che abbia come ambito l'attività di un utente su un singolo sito di primo livello, ad esempio:
- Chat incorporate di terze parti
- Incorporamenti di mappe di terze parti
- Incorporamenti nei pagamenti di terze parti
- Bilanciamento del carico CDN delle sottorisorse
- Fornitori di CMS headless
- Domini sandbox per la pubblicazione di contenuti utente non attendibili (ad esempio googleusercontent.com e githubusercontent.com)
- CDN di terze parti che utilizzano cookie per pubblicare contenuti il cui accesso è controllato dallo stato dell'autenticazione sul sito proprietario (ad esempio, immagini del profilo su siti di social media ospitati su CDN di terze parti)
- Framework di front-end che si basano su API remote che utilizzano cookie per le loro richieste
- Annunci incorporati che richiedono un ambito per lo stato in base al publisher (ad esempio, l'acquisizione delle preferenze degli utenti relative agli annunci per il sito web in questione).
Perché CHIPS utilizza un modello di partizionamento con attivazione
Poiché i browser stanno eliminando gradualmente i cookie di terze parti non partizionati, sono stati tentati un paio di altri approcci al partizionamento.
Firefox ha annunciato che partiziona tutti i cookie di terze parti per impostazione predefinita in modalità ETP Strict e in modalità di navigazione privata, in modo che tutti i cookie tra siti siano partizionati in base al sito di primo livello. Tuttavia, il partizionamento dei cookie senza un'attivazione di terze parti può portare a bug imprevisti, poiché alcuni servizi di terze parti hanno creato server che prevedono un cookie di terze parti non partizionato.
In precedenza Safari ha provato a eseguire il partizionamento dei cookie in base all'euristica, ma alla fine ha scelto di bloccarli del tutto, citando una delle cause della confusione per gli sviluppatori. Recentemente, Safari ha espresso interesse per un modello basato su attivazione.
Ciò che distingue CHIPS dalle implementazioni esistenti di cookie partizionati è l'attivazione di terze parti. I cookie devono essere impostati con un nuovo attributo per poter essere inviati nelle richieste tra parti una volta che i cookie di terze parti (non partizionati) saranno obsoleti.
Sebbene i cookie di terze parti esistano ancora, l'attributo Partitioned
consente di attivare un tipo di comportamento dei cookie più restrittivo e più sicuro. CHIPS è un passaggio importante per aiutare i servizi a effettuare una transizione senza problemi verso un futuro senza cookie di terze parti.
Progettazione tecnica del partizionamento dei cookie
Oggi, i cookie sono associati al nome host o al dominio del sito che li imposta, ossia la chiave host.
Ad esempio, per i cookie provenienti da https://support.chat.example
, la chiave host è ("support.chat.example")
.
In CHIPS, i cookie che attivano il partizionamento avranno una chiave doppia sulla chiave host e sulla chiave di partizione.
Una chiave di partizione dei cookie è il sito (schema e dominio registrabile) dell'URL di primo livello visitato dal browser all'inizio della richiesta all'endpoint che ha impostato il cookie.
Nell'esempio precedente, in cui https://support.chat.example
è incorporato in https://retail.example
, l'URL di primo livello è https://retail.example
.
La chiave di partizione in questo caso è ("https", "retail.example")
.
Analogamente, una chiave di partizione della richiesta è il sito dell'URL di primo livello che il browser visita all'inizio di una richiesta. I browser devono inviare un cookie con l'attributo Partitioned
solo nelle richieste con la stessa chiave di partizione del cookie.
Ecco come appare la chiave cookie nell'esempio precedente prima e dopo i CHIPS.
Prima dei CHIPS
key=("support.chat.example")
Dopo i CHIPS
key={("support.chat.example"),("https", "retail.example")}
Progettazione della sicurezza
Per favorire le buone pratiche di sicurezza, con i CHIPS, i cookie vengono impostati e inviati solo tramite protocolli sicuri.
- I cookie partizionati devono essere impostati con
Secure
. - Ti consigliamo di utilizzare il prefisso
__Host-
quando imposti i cookie partizionati per associarli al nome host (e non al dominio registrabile).
Esempio:
Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
Alternative ai CHIPS
L'API Storage Access e i set di siti web correlati (RWS) associati sono meccanismi della piattaforma web che consentono un accesso limitato ai cookie tra siti per scopi specifici rivolti agli utenti.
Queste sono alternative al partizionamento CHIPS in cui è necessario l'accesso a cucine non partizionate tra siti.
Prendi in considerazione l'API Storage Access e gli insiemi di siti web correlati nelle situazioni in cui è necessario che lo stesso cookie sia disponibile per un servizio incorporato in più siti correlati.
I CHIPS consentono a un servizio di agire come componente isolato su più siti, dove non è necessario che lo stesso cookie sia disponibile su più siti. Se il servizio imposta un cookie partizionato, la sua chiave di partizione sarà il sito di primo livello e quel cookie non sarà disponibile anche per altri siti che utilizzano il servizio.
Il design degli insiemi di siti web correlati si basa sull'API Storage Access e non si integra con il partizionamento CHIPS. Se hai un caso d'uso che si basa su una partizione dei cookie condivisa tra i siti all'interno di una rete RWS, puoi fornire esempi e feedback sul problema di GitHub.
Demo
Questa demo illustra il funzionamento dei cookie partizionati e il modo in cui puoi controllarli in DevTools.
Il sito A incorpora un iframe del sito B che utilizza JavaScript per impostare due cookie: uno suddiviso e uno non suddiviso. Il sito B mostra tutti i cookie accessibili da quella località utilizzando document.cookie
.
Quando i cookie di terze parti sono bloccati, il sito B potrà impostare il cookie e accedervi con l'attributo Partitioned
solo nel contesto tra siti.
Quando i cookie di terze parti sono consentiti, il sito B può anche impostare e accedere al cookie non partizionato.
Prerequisiti
- Chrome 118 o versioni successive.
- Visita
chrome://flags/#test-third-party-cookie-phaseout
e attiva questa impostazione
Utilizza DevTools per esaminare i cookie partizionati
- Visita https://chips-site-a.glitch.me.
- Premi
Control+Shift+J
(oCommand+Option+J
su Mac) per aprire DevTools. - Fai clic sulla scheda Richiesta.
- Vai ad Applicazione > Spazio di archiviazione > Cookie.
- Fai clic su
https://chips-site-b.glitch.me
.
DevTools mostrerà tutti i cookie dell'origine selezionata.
Il sito B può impostare il cookie partizionato solo in un contesto tra siti. Il cookie non partizionato verrà bloccato:
- Dovresti vedere
__Host-partitioned-cookie
con la chiave di partizione del sito di primo livellohttps://chips-site-a.glitch.me
.
- Fai clic su Vai al sito B.
- In DevTools, vai a Applicazione > Spazio di archiviazione > Cookie.
- Fai clic su
https://chips-site-b.glitch.me
.
In questo scenario, poiché ti trovi nel sito B nel contesto di primo livello, può impostare e accedere a entrambi i cookie:
unpartitioned-cookie
ha una chiave di partizione vuota.- Il cookie
__Host-partitioned-cookie
ha la chiave di partizionehttps://chips-site-b.glitch.me
.
Se torni al sito A, unpartitioned-cookie
viene memorizzato nel browser, ma non sarà accessibile dal sito A.
- Fai clic su Vai al sito A.
- Fai clic sulla scheda Rete.
- Fai clic su
https://chips-site-b.glitch.me
. - Fai clic sulla scheda Cookie.
Nel sito A dovresti vedere __Host-partitioned-cookie
con la chiave di partizione del sito di primo livello https://chips-site-a.glitch.me
.
Se selezioni l'opzione Mostra richieste di cookie filtrate, DevTools mostrerà che il cookie non partizionato è bloccato, evidenziato in giallo con una descrizione comando: "Questo cookie è stato bloccato a causa delle preferenze dell'utente".
In Applicazione > Spazio di archiviazione > Cookie che fanno clic su https://chips-site-b.glitch.me
mostrerà:
unpartitioned-cookie
con la chiave di partizione vuota.- Cookie
__Host-partitioned-cookie
con la chiave di partizionehttps://chips-site-a.glitch.me
.
Cancella cookie
Per reimpostare la demo, cancella tutti i cookie del sito:
- Premi
Control+Shift+J
(oCommand+Option+J
su Mac) per aprire DevTools. - Fai clic sulla scheda Richiesta.
- Vai ad Applicazione > Spazio di archiviazione > Cookie.
- Fai clic con il tasto destro del mouse su
https://chips-site-b.glitch.me
. - Fai clic su Cancella.
Risorse
- GitHub: leggi l'spiegatore, solleva le domande e segui la discussione.
- Assistenza per gli sviluppatori: poni domande e partecipa alle discussioni nel repository dell'assistenza per gli sviluppatori di Privacy Sandbox.