Chrome 115 ha introdotto modifiche alle API di archiviazione, service worker e comunicazione con il partizionamento in contesti di terze parti. Oltre a essere isolate dal criterio della stessa origine, le API interessate utilizzate in contesti di terze parti vengono isolate anche dal sito del contesto di primo livello.
I siti che non hanno avuto il tempo di implementare il supporto del partizionamento dello spazio di archiviazione di terze parti possono partecipare a una prova relativa al ritiro per annullare temporaneamente la partizione (continuare l'isolamento in base al criterio della stessa origine ma rimuovere l'isolamento dal sito di primo livello) e ripristinare il comportamento precedente di archiviazione, service worker e API di comunicazione nei contenuti incorporati nel loro sito. Questa prova relativa al ritiro scadrà con la release di Chrome 127 il 3 settembre 2024. Tieni presente che questa prova è separata dalla prova relativa al ritiro per l'accesso ai cookie di terze parti, ma è solo per l'accesso allo spazio di archiviazione.
Come soluzione a lungo termine per far fronte a determinati casi d'uso interrotti dal partizionamento dello spazio di archiviazione non basato sui cookie di terze parti, Chrome propone a terze parti la possibilità di richiedere l'accesso allo spazio di archiviazione/alla comunicazione (sia cookie che non cookie) tramite l'API Storage Access (spedizione a partire da Chrome 117), che consente già a terze parti di richiedere l'accesso ai cookie.
A partire da Chrome 120, questa proposta sarà disponibile per la sperimentazione tramite una prova dell'origine. Gli sviluppatori dovrebbero partecipare a questa prova dell'origine per valutare in che modo la soluzione proposta affronta i loro casi d'uso e assicurarsi di essere preparati prima della fine della prova relativa al ritiro.
Dettagli della prova dell'origine
A partire da Chrome 120, Chrome supporterà una prova dell'origine, StorageAccessAPIBeyondCookies, per attivare l'estensione proposta dell'API Storage Access (compatibile con le versioni precedenti) in modo da consentire l'accesso allo spazio di archiviazione non partizionato (cookie e non cookie) in un contesto di terze parti.
Meccanica
L'API può essere utilizzata come segue (JavaScript eseguito in un iframe incorporato):
// Request a new storage handle via rSA (this should prompt the user)
const handle = await document.requestStorageAccess({all: true});
// Write some 1P context sessionStorage
handle.sessionStorage.setItem('userid', '1234');
// Write some 1P context localStorage
handle.localStorage.setItem('preference', 'A');
// Open or create an indexedDB that is shared with the 1P context
const messageDB = handle.indexedDB.open('messages');
// Use locks shared with the 1P context
await handle.locks.request('example', ...);
Se vuoi solo un accesso all'API specifico anziché l'accesso a all, puoi trasmettere i nomi solo degli handle dell'API che ti servono. Ad esempio, puoi passare {sessionStorage: true} per ottenere l'accesso allo spazio di archiviazione della sessione o {indexedDB: true, locks:true} per ottenere l'accesso a IndexedDB e Web Locks.
Oltre a chiamare questa estensione aggiuntiva, l'accesso allo spazio di archiviazione non basato sui cookie corrisponderebbe agli attuali requisiti per l'accesso ai cookie tramite l'API Storage Access. Ad esempio, in Chrome non viene mostrata alcuna richiesta quando le origini si trovano nello stesso insieme di siti web correlati (RWS, il nuovo nome per gli insiemi proprietari). Le origini che non fanno parte dello stesso RWS sono soggette ai requisiti di prompt dell'API Storage Access in Chrome.
Durata
La prova dell'origine sarà disponibile da Chrome 120 fino a Chrome 125 (o dopo il 6 agosto 2024 in qualsiasi traguardo).
Ambito
In Chrome 120 sono disponibili solo l'archiviazione DOM (archiviazione di sessione e locale), il database indicizzato e i blocchi web.
In Chrome 121 sono stati aggiunti spazio di archiviazione della cache, file system privato di origine, quota, archiviazione BLOB e canale di trasmissione.
In Chrome 123 sono stati aggiunti i lavoratori condivisi e il controllo sull'inclusione dei cookie.
I lavoratori dedicati ereditano l'accesso ai cookie non partizionati se requestStorageAccess è stato chiamato prima della creazione del worker a partire da Chrome 120 (questa operazione non è necessaria per l'utilizzo dell'handle dell'API Storage Access).
Partecipa
- Valuta come utilizzi l'archiviazione dei cookie e non di cookie in un contesto di terze parti. I casi d'uso di esempio possono aiutarti a capire se questa proposta può soddisfare le tue esigenze.
- Avvia Chrome 120 (o versioni successive) e assicurati che il flag test-third-party-cookie-phaseout sia attivato.
- Se vuoi testare la funzionalità localmente senza prima impostare un token di prova dell'origine, puoi abilitare #enable-experimental-web-platform-features nel tuo browser.
- Una volta completati i test in locale, puoi registrarti alla prova dell'origine StorageAccessAPIBeyondCookies e ottenere un token per i tuoi domini. Per istruzioni più dettagliate, visita la pagina Iniziare a utilizzare le prove dell'origine. La guida alla risoluzione dei problemi relativi alle prove dell'origine di Chrome fornisce un elenco di controllo completo per assicurarsi che il token sia configurato correttamente.
- Incorpora il token di prova dell'origine nell'iframe in cui devi utilizzare l'handle dell'API Storage Access al suo interno, utilizzando un'intestazione HTTP, un meta tag HTML o in modo programmatico. Tieni presente che il token deve essere incorporato in qualsiasi frame che voglia utilizzare questa API, incorporandolo nel frame padre non abiliti l'API nei frame figlio.
- Chiama
document.requestStorageAccess(...)per ottenere l'handle dell'API Storage Access nell'iframe cross-site. Per conoscere i requisiti necessari per completare questa chiamata, consulta la documentazione dell'API Storage Access. - Esegui la migrazione dello spazio di archiviazione correlato nel tuo iframe per utilizzare l'handle dell'API Storage Access, se disponibile. Ad esempio, le chiamate a
window.sessionStorage.setItem(...)diventanohandle.sessionStorage.setItem(...). - Apri il tuo sito web e verifica che l'handle di accesso allo spazio di archiviazione funzioni come previsto.
- Per interrompere la partecipazione alla prova dell'origine, rimuovi il token che hai aggiunto al passaggio 3.
- Invia un feedback o segnala eventuali problemi riscontrati nel repository GitHub di Non-Cookie Storage dell'API Storage Access.
Demo: utilizzo dell'API Storage Access per accedere all'archiviazione locale non partizionata
La seguente demo mostra come accedere a canali di trasmissione non partizionati da un iframe di terze parti utilizzando l'API Storage Access:
https://saa-beyond-cookies.glitch.me/
La demo richiede Chrome 121 o versioni successive con il flag test-third-party-cookie-phaseout abilitato.