Chrome sta eliminando gradualmente il supporto per i cookie di terze parti e il partizionamento dello spazio di archiviazione per ridurre il monitoraggio tra siti. Ciò rappresenta una sfida per i siti e i servizi che si basano su cookie e altro spazio di archiviazione in contesti incorporati per i percorsi degli utenti come l'autenticazione. L'API Storage Access (SAA) consente a questi casi d'uso di continuare a funzionare, limitando il più possibile il monitoraggio tra siti.
Stato implementazione
L'API Storage Access è disponibile in tutti i principali browser, ma esistono leggere differenze di implementazione tra i browser. Queste differenze sono state evidenziate nelle sezioni pertinenti di questo post.
Il lavoro continua per risolvere tutti i problemi di blocco rimanenti prima di standardizzare l'API.
Che cos'è l'API Storage Access?
L'API Storage Access è un'API JavaScript che consente agli iframe di richiedere le autorizzazioni di accesso allo spazio di archiviazione quando altrimenti l'accesso sarebbe negato dalle impostazioni del browser. Gli incorporamenti con casi d'uso che dipendono dal caricamento di risorse tra siti possono utilizzare l'API per richiedere l'autorizzazione di accesso all'utente, in base alle necessità.
Se la richiesta di spazio di archiviazione viene accolta, l'iframe avrà accesso ai propri cookie e allo spazio di archiviazione non partizionati, disponibili anche quando gli utenti lo visitano come sito di primo livello.
L'API Storage Access consente di fornire accesso specifico a cookie non partizionati e allo spazio di archiviazione con un carico minimo per l'utente finale, impedendo comunque l'accesso allo spazio di archiviazione e ai cookie non partizionati generici, come viene spesso utilizzato per il monitoraggio degli utenti.
Casi d'uso
Alcuni incorporamenti di terze parti richiedono l'accesso a spazio di archiviazione o cookie non partizionati per offrire un'esperienza migliore all'utente, cosa che non sarà disponibile dopo che i cookie di terze parti saranno stati deprecati e sarà stato attivato il partizionamento dello spazio di archiviazione.
I casi d'uso includono:
- Widget di commento incorporati che richiedono dettagli della sessione di accesso.
- Pulsanti "Mi piace" per i social media che richiedono i dettagli della sessione di accesso.
- Documenti incorporati che richiedono dettagli della sessione di accesso.
- Un'esperienza premium offerta a un video incorporato (ad esempio, per non mostrare annunci agli utenti che hanno eseguito l'accesso, conoscere le preferenze dell'utente in merito ai sottotitoli codificati o limitare determinati tipi di video).
- Sistemi di pagamento integrati.
Molti di questi casi di utilizzo prevedono la persistenza dell'accesso all'accesso in iframe incorporati.
Quando utilizzare l'API Storage Access rispetto ad altre API
L'API Storage Access è una delle alternative all'utilizzo di cookie e spazio di archiviazione non partizionati, quindi è importante capire quando utilizzare questa API rispetto alle altre. È pensata per i casi d'uso in cui si verificano entrambe le seguenti condizioni:
- L'utente interagirà con i contenuti incorporati, ovvero non si tratta di un iframe passivo o di un iframe nascosto.
- L'utente ha visitato l'origine incorporata in un contesto di primo livello, ovvero quando l'origine non è incorporata in un altro sito.
Esistono API alternative per diversi casi d'uso:
- I cookie con stato partizionato indipendente (CHIPS) consentono agli sviluppatori di attivare un cookie per l'archiviazione "partizionata", con un barattolo di cookie separato per ciascun sito di primo livello. Ad esempio, un widget di chat web di terze parti potrebbe basarsi sull'impostazione di un cookie per salvare le informazioni della sessione. Le informazioni sulla sessione vengono salvate in base al sito, quindi non è necessario accedere al cookie impostato dal widget su altri siti web in cui è incorporato. L'API Storage Access è utile quando un widget di terze parti incorporato dipende dalla condivisione delle stesse informazioni tra origini diverse (ad esempio, per dettagli o preferenze della sessione con accesso).
- Il partizionamento dello spazio di archiviazione è un modo per consentire agli iframe tra siti di utilizzare i meccanismi di archiviazione JavaScript esistenti e di dividere lo spazio di archiviazione sottostante per sito. In questo modo, lo spazio di archiviazione incorporato in un sito web non è accessibile da parte dello stesso incorporamento su altri siti web.
- Insiemi di siti web correlati (RWS) è un modo per un'organizzazione di dichiarare le relazioni tra i siti, in modo che i browser consentano accesso limitato ai cookie e allo spazio di archiviazione non partizionati per scopi specifici. I siti devono comunque richiedere l'accesso con l'API Storage Access, ma per i siti all'interno dell'insieme, l'accesso può essere concesso senza richieste dell'utente.
- La gestione delle credenziali federate (FedCM) è un approccio ai servizi di identità federati che tutela la privacy. L'API Storage Access gestisce l'accesso a cookie non partizionati e allo spazio di archiviazione dopo l'accesso. Per alcuni casi d'uso FedCM offre una soluzione alternativa all'API Storage Access e potrebbe essere preferibile in quanto presenta una richiesta del browser più orientata all'accesso. Tuttavia, l'adozione di FedCM di solito richiede ulteriori modifiche al codice, ad esempio per supportare i suoi endpoint HTTP.
- Esistono anche API antifrode, relative agli annunci e misurazione, e l'API Storage Access non è pensata per risolvere questi problemi.
Utilizzo dell'API Storage Access
L'API Storage Access ha due metodi basati sulla promessa:
Document.hasStorageAccess()(disponibile anche con il nuovo nomeDocument.hasUnpartitionedCookieAccess()a partire da Chrome 125)Document.requestStorageAccess()
Inoltre, si integra con l'API Permissions. Ciò consente di controllare lo stato dell'autorizzazione di accesso allo spazio di archiviazione in un contesto di terze parti, che indica se una chiamata a document.requestStorageAccess() verrà concessa automaticamente:
Se utilizzi il metodo hasStorageAccess()
Quando un sito viene caricato per la prima volta, può utilizzare il metodo hasStorageAccess() per verificare se l'accesso ai cookie di terze parti è già stato concesso.
// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;
async function handleCookieAccessInit() {
if (!document.hasStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
hasAccess = true;
} else {
// Check whether access has been granted via the Storage Access API.
// Note on page load this will always be false initially so we could be
// skipped in this example, but including for completeness for when this
// is not so obvious.
hasAccess = await document.hasStorageAccess();
if (!hasAccess) {
// Handle the lack of access (covered later)
}
}
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
L'accesso allo spazio di archiviazione viene concesso a un documento iframe solo dopo che ha chiamato requestStorageAccess(),, quindi hasStorageAccess() inizialmente restituirà sempre false, tranne quando è già stato concesso l'accesso a un altro documento della stessa origine nello stesso iframe. La concessione viene conservata nelle navigazioni della stessa origine all'interno dell'iframe, in modo specifico per consentire il ricaricamento dopo aver concesso l'accesso alle pagine che richiedono la presenza di cookie nella richiesta iniziale per il documento HTML.
Se utilizzi il metodo requestStorageAccess()
Se l'iframe non ha accesso, potrebbe essere necessario richiedere l'accesso utilizzando il metodo requestStorageAccess():
if (!hasAccess) {
try {
await document.requestStorageAccess();
} catch (err) {
// Access was not granted and it may be gated behind an interaction
return;
}
}
La prima volta che viene richiesta questa richiesta, l'utente potrebbe dover approvare l'accesso con una richiesta del browser, dopodiché la promessa verrà risolta oppure verrà rifiutata, generando un'eccezione se viene usato await.
Per prevenire comportamenti illeciti, questa richiesta del browser verrà visualizzata soltanto dopo l'interazione di un utente. Ecco perché inizialmente requestStorageAccess() deve essere chiamato da un gestore di eventi attivato dall'utente, anziché subito quando viene caricato l'iframe:
async function doClick() {
// Only do this extra check if access hasn't already been given
// based on the hasAccess variable.
if (!hasAccess) {
try {
await document.requestStorageAccess();
hasAccess = true; // Can assume this was true if above did not reject.
} catch (err) {
// Access was not granted.
return;
}
}
if (hasAccess) {
// Use the cookies
}
}
document.querySelector('#my-button').addEventListener('click', doClick);
Se devi utilizzare lo spazio di archiviazione locale anziché i cookie, puoi procedere come segue:
let handle = null;
async function doClick() {
if (!handle) {
try {
handle = await document.requestStorageAccess({localStorage: true});
} catch (err) {
// Access was not granted.
return;
}
}
// Use handle to access unpartitioned local storage.
handle.localStorage.setItem('foo', 'bar');
}
document.querySelector('#my-button').addEventListener('click', doClick);
Richieste di autorizzazione
Quando l'utente fa clic sul pulsante per la prima volta, viene visualizzata automaticamente la richiesta del browser, in genere nella barra degli indirizzi. Di seguito è riportato un esempio del prompt di Chrome, ma altri browser hanno un'interfaccia utente simile:
In determinate circostanze, la richiesta potrebbe essere ignorata dal browser e l'autorizzazione potrebbe essere fornita automaticamente:
- Se la pagina e l'iframe sono stati utilizzati negli ultimi 30 giorni dall'accettazione della richiesta.
- Se l'iframe incorporato fa parte di un insieme di siti web correlati.
- In Firefox, il prompt viene ignorato anche per i siti web noti (quelli con cui hai interagito al livello più alto) per i primi cinque tentativi.
In alternativa, il metodo potrebbe essere rifiutato automaticamente senza mostrare la richiesta in determinate circostanze:
- Se l'utente non ha mai visitato o interagito in precedenza con il sito proprietario dell'iframe come documento di primo livello, non in iframe. Ciò significa che l'API Storage Access è utile solo per i siti incorporati che gli utenti hanno già visitato in un contesto proprietario.
- Se il metodo
requestStorageAccess()viene chiamato al di fuori di un evento di interazione dell'utente senza la previa approvazione della richiesta dopo un'interazione.
Anche se all'utente verrà richiesto durante l'utilizzo iniziale, le visite successive possono risolvere requestStorageAccess() senza chiedere conferma e senza richiedere l'interazione dell'utente in Chrome e Firefox. Tieni presente che Safari richiede sempre un'interazione da parte dell'utente.
Poiché l'accesso ai cookie e allo spazio di archiviazione può essere concesso senza un prompt o senza interazione dell'utente, spesso è possibile ottenere l'accesso non partizionato ai cookie o allo spazio di archiviazione prima che un'interazione dell'utente sui browser che lo supportano (Chrome e Firefox) richiamando requestStorageAccess() al caricamento pagina. Ciò potrebbe consentirti di accedere immediatamente ai cookie e allo spazio di archiviazione non partizionati e offrire un'esperienza più completa, anche prima che l'utente interagisca con l'iframe. In alcune situazioni, l'esperienza utente potrebbe risultare migliore rispetto all'attesa per un'interazione dell'utente.
Utilizzo della query sulle autorizzazioni storage-access
Per verificare se l'accesso può essere concesso senza interazione da parte dell'utente, puoi controllare lo stato dell'autorizzazione storage-access ed effettuare la chiamata requestStoreAccess() in anticipo solo se non è richiesta alcuna azione dell'utente. In alternativa, puoi chiamarla e fare in modo che non vada a buon fine quando è richiesta un'interazione.
In questo modo, puoi anche gestire in anticipo la necessità di una richiesta visualizzando contenuti diversi, ad esempio un pulsante di accesso.
Il codice seguente aggiunge il controllo delle autorizzazioni storage-access all'esempio precedente:
// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;
async function hasCookieAccess() {
// Check if Storage Access API is supported
if (!document.requestStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
return true;
}
// Check if access has already been granted
if (await document.hasStorageAccess()) {
return true;
}
// Check the storage-access permission
// Wrap this in a try/catch for browsers that support the
// Storage Access API but not this permission check
// (e.g. Safari and older versions of Firefox).
let permission;
try {
permission = await navigator.permissions.query(
{name: 'storage-access'}
);
} catch (error) {
// storage-access permission not supported. Assume no cookie access.
return false;
}
if (permission) {
if (permission.state === 'granted') {
// Permission has previously been granted so can just call
// requestStorageAccess() without a user interaction and
// it will resolve automatically.
try {
await document.requestStorageAccess();
return true;
} catch (error) {
// This shouldn't really fail if access is granted, but return false
// if it does.
return false;
}
} else if (permission.state === 'prompt') {
// Need to call requestStorageAccess() after a user interaction
// (potentially with a prompt). Can't do anything further here,
// so handle this in the click handler.
return false;
} else if (permission.state === 'denied') {
// Currently not used. See:
// https://github.com/privacycg/storage-access/issues/149
return false;
}
}
// By default return false, though should really be caught by one of above.
return false;
}
async function handleCookieAccessInit() {
hasAccess = await hasCookieAccess();
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
iframe con sandbox
Quando utilizzi l'API Storage Access negli iframe con sandbox, sono necessarie le seguenti autorizzazioni sandbox:
allow-storage-access-by-user-activationè necessario per consentire l'accesso all'API Storage Access.allow-scriptsè necessario per consentire l'utilizzo di JavaScript per chiamare l'API.allow-same-originè necessario per consentire l'accesso ai cookie della stessa origine e ad altri tipi di archiviazione.
Ad esempio:
<iframe sandbox="allow-storage-access-by-user-activation
allow-scripts
allow-same-origin"
src="..."></iframe>
Requisiti dei cookie
Per essere accessibili con l'API Storage Access in Chrome, i cookie tra siti devono essere impostati con i due attributi seguenti:
SameSite=None: necessaria per contrassegnare il cookie come cross-siteSecure, che garantisce l'accesso solo ai cookie impostati dai siti HTTPS.
In Firefox e Safari, l'impostazione predefinita dei cookie è SameSite=None e non limitano SSA ai cookie Secure, quindi questi attributi non sono obbligatori. Ti consigliamo di indicare esplicitamente l'attributo SameSite e di usare sempre i cookie Secure.
Accesso alla pagina di primo livello
L'API Storage Access è concepita per consentire l'accesso a cookie di terze parti all'interno di iframe incorporati.
Esistono anche altri casi d'uso in cui la pagina di primo livello richiede l'accesso a cookie di terze parti. Ad esempio, immagini o script limitati dai cookie, che i proprietari dei siti potrebbero voler includere direttamente nel documento di primo livello anziché in un iframe. Per affrontare questo caso d'uso, Chrome ha proposto un'estensione all'API Storage Access che aggiunge un metodo requestStorageAccessFor().
Il metodo requestStorageAccessFor()
Il metodo requestStorageAccessFor() funziona in modo simile a requestStorageAccess(), ma per risorse di primo livello. Può essere utilizzata solo per i siti all'interno di un insieme di siti web correlati per impedire l'accesso generale ai cookie di terze parti.
Per maggiori dettagli su come utilizzare requestStorageAccessFor(), leggi la sezione Set di siti web correlati: guida per gli sviluppatori.
Query sull'autorizzazione top-level-storage-access
Supporto dei browser
- x
- x
- x
- x
Analogamente all'autorizzazione storage-access, esiste un'autorizzazione top-level-storage-access per verificare se è possibile concedere l'accesso a requestStorageAccessFor().
Qual è la differenza tra l'API Storage Access e l'API RWS?
Quando vengono utilizzati gli insiemi di siti web correlati con l'API Storage Access, sono disponibili alcune funzionalità aggiuntive, come descritto nella tabella seguente:
| Senza RWS | Con RWS | |
|---|---|---|
| Richiede un gesto dell'utente per avviare la richiesta di accesso allo spazio di archiviazione | ||
| Richiede all'utente di visitare l'origine di archiviazione richiesta in un contesto di primo livello prima di concedere l'accesso | ||
| Il prompt iniziale dell'utente può essere ignorato | ||
Non è necessario chiamare requestStorageAccess se l'accesso è stato precedentemente concesso |
||
| Concede automaticamente l'accesso ad altri domini in un sito web correlato | ||
Supporta requestStorageAccessFor l'accesso alle pagine di primo livello |
Demo: impostazione e accesso ai cookie
La demo seguente mostra come accedere a un cookie impostato da te nella prima schermata della demo in un frame incorporato nel secondo sito della demo:
storage-access-api-demo.glitch.me
La demo richiede un browser con i cookie di terze parti disabilitati:
- Chrome 118 o versioni successive con il flag
chrome://flags/#test-third-party-cookie-phaseoutimpostato e il browser riavviato. - Firefox
- Safari
Demo: impostazione dello spazio di archiviazione locale
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 125 o versioni successive con il flag test-third-party-cookie-phaseout abilitato.
Risorse
- Leggi la specifica che fornisce l'accesso ai cookie di terze parti oppure segui e segnala i problemi.
- Leggi la specifica relativa all'accesso non partizionato allo spazio di archiviazione oppure segui e segnala i problemi.
- documentazione dell'API e guida.
- Documentazione di Chrome sull'utilizzo dell'API Storage Access negli insiemi di siti web correlati