Partecipare alla prova dell'origine per accedere allo spazio di archiviazione senza cookie tramite l'API Storage Access

Helen Cho
Helen Cho
Ari Chivukula
Ari Chivukula
GitHub

Chrome 115 ha introdotto modifiche alle API di archiviazione, service worker e comunicazione partizionando 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 in base al sito del contesto di primo livello.

I siti che non hanno avuto il tempo di implementare il supporto per il partizionamento dello spazio di archiviazione di terze parti possono partecipare a una prova di ritiro per annullare temporaneamente la partizione (continua l'isolamento in base al criterio della stessa origine, ma rimuovere l'isolamento per sito di primo livello) e ripristinare il comportamento precedente delle API di archiviazione, dei service worker e delle API di comunicazione nei contenuti incorporati sul loro sito. Questa prova relativa al ritiro scadrà con il rilascio di Chrome 127 il 3 settembre 2024. Tieni presente che questa procedura è separata dalla prova relativa al ritiro per l'accesso a cookie di terze parti e solo per l'accesso allo spazio di archiviazione.

Come soluzione a lungo termine per risolvere determinati casi d'uso interrotti dal partizionamento dello spazio di archiviazione non basato sui cookie di terze parti, Chrome propone a terze parti di richiedere l'accesso allo spazio di archiviazione/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 che siano 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) per 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 nel seguente modo (JavaScript in esecuzione 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 specifico all'API anziché l'accesso a all, puoi trasmettere solo i nomi degli handle delle API che ti servono. Ad esempio, puoi passare {sessionStorage: true} per ottenere solo l'accesso allo spazio di archiviazione delle sessioni oppure {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 corrisponde 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 richiesta dell'API Storage Access in Chrome.

Durata

La prova dell'origine sarà disponibile da Chrome 120 a Chrome 125 (o dopo il 6 agosto 2024 in qualsiasi traguardo).

Ambito

In Chrome 120 sono disponibili solo archiviazione DOM (archiviazione di sessione e locale), DB indicizzato e blocchi web.

Archiviazione cache, file system privato di origine, Quota, Archiviazione BLOB e Broadcast Channel sono stati aggiunti in Chrome 121.

In Chrome 123 sono stati aggiunti i lavoratori condivisi e il controllo sull'inclusione dei cookie.

I worker dedicati ereditano l'accesso ai cookie non partizionati se requestStorageAccess è stato chiamato prima della creazione del worker a partire da Chrome 120 (questo non richiede l'utilizzo dell'handle API Storage Access).

Partecipa

  1. Valutare come utilizzare l'archiviazione di cookie e non in un contesto di terze parti. I casi d'uso di esempio possono aiutarti a capire se questa proposta può soddisfare le tue esigenze.
  2. Avvia Chrome versione 120 (o successiva) e assicurati che il flag test-third-party-cookie-phaseout sia attivo.
  3. Se vuoi testare la funzionalità localmente senza prima configurare un token di prova dell'origine, puoi attivare #enable-experimental-web-platform-features nel tuo browser.
    1. Una volta completati i test a livello locale, puoi register alla prova dell'origine di StorageAccessAPIBeyondCookies e ricevere un token per i tuoi domini. Per istruzioni più dettagliate, consulta la pagina Iniziare a utilizzare le prove dell'origine. La guida per la risoluzione dei problemi relativi alle prove dell'origine di Chrome fornisce un elenco di controllo completo per garantire che il token sia configurato correttamente.
    2. Incorpora il token della prova dell'origine nell'iframe in cui devi utilizzare l'handle dell'API Storage Access, utilizzando un'intestazione HTTP, un meta tag HTML o in modo programmatico. Tieni presente che il token deve essere incorporato da qualsiasi frame che voglia utilizzare l'API; l'incorporamento nel frame principale non attiverà l'API nei frame secondari.
  4. Chiama document.requestStorageAccess(...) per ottenere l'handle dell'API Storage Access nell'iframe cross-site. Consulta la documentazione dell'API Storage Access per i requisiti necessari per la riuscita di questa chiamata.
  5. Esegui la migrazione dello spazio di archiviazione correlato nell'iframe per utilizzare l'handle dell'API Storage Access, se disponibile. Ad esempio, le chiamate a window.sessionStorage.setItem(...) diventano handle.sessionStorage.setItem(...).
  6. Apri il tuo sito web e verifica che l'handle di accesso allo spazio di archiviazione funzioni come previsto.
  7. Per interrompere la partecipazione alla prova dell'origine, rimuovi il token aggiunto nel passaggio 3.
  8. Invia il tuo feedback o segnala eventuali problemi al repository GitHub di archiviazione non cookie dell'API Storage Access.

Demo: utilizzare l'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 attivo.

Altre risorse