Chrome sta ritirando gradualmente il supporto per i cookie di terze parti per ridurre il monitoraggio tra siti. Ciò rappresenta una sfida per i siti e i servizi che si basano sui cookie 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 con leggermente differenze di implementazione tra i browser. Queste differenze sono state evidenziate nelle sezioni pertinenti di questo post.
Si continuerà a 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 l'accesso verrebbe altrimenti negato dalle impostazioni del browser. Gli incorporamenti con casi d'uso che dipendono dal caricamento delle risorse tra siti possono utilizzare l'API per richiedere l'autorizzazione di accesso all'utente, in base alle esigenze.
Se la richiesta di spazio di archiviazione viene accolta, l'iframe avrà accesso ai propri cookie cross-site, che saranno disponibili anche quando gli utenti lo visitano come sito di primo livello.
L'API Storage Access consente di fornire un accesso specifico ai cookie tra siti con un carico minimo per l'utente finale, impedendo allo stesso tempo l'accesso generico ai cookie tra siti, come spesso viene utilizzato per il monitoraggio degli utenti.
casi d'uso
Alcuni incorporamenti di terze parti richiedono l'accesso ai cookie cross-site per offrire un'esperienza migliore all'utente, qualcosa che non sarà più disponibile dopo il ritiro dei cookie di terze parti.
I casi d'uso includono:
- Widget di commento incorporati che richiedono i dettagli della sessione di accesso.
- Pulsanti "Mi piace" sui social media che richiedono i dettagli della sessione di accesso.
- Documenti incorporati che richiedono i dettagli della sessione di accesso.
- Un'esperienza premium fornita a un video incorporato (ad esempio per non mostrare gli annunci agli utenti che hanno eseguito l'accesso, per conoscere le preferenze dell'utente in merito ai sottotitoli codificati o per limitare determinati tipi di video).
- Sistemi di pagamento incorporati.
Molti di questi casi d’uso comportano il persistere dell’accesso all’accesso negli iframe incorporati.
Quando utilizzare l'API Storage Access rispetto ad altre API
L'API Storage Access è una delle alternative all'utilizzo dei cookie di terze parti, quindi è importante capire quando utilizzare questa API rispetto alle altre. È destinato ai 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.
Sono disponibili API alternative per vari casi d'uso:
- La soluzione CHIPS (Cookie con stato partizionato indipendente) consente agli sviluppatori di attivare un cookie per lo spazio di archiviazione "partizionato", con un contenitore dei cookie separato per ogni sito di primo livello. Ad esempio, un widget della chat web di terze parti potrebbe basarsi sull'impostazione di un cookie per salvare le informazioni sulle sessioni. Le informazioni sulla sessione vengono salvate per sito, quindi non è necessario accedere al cookie impostato dal widget da 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 le preferenze o i dettagli della sessione con accesso eseguito).
- Il set di siti web correlati (RWS) consente a un'organizzazione di dichiarare relazioni tra siti, in modo che i browser consentano un accesso limitato ai cookie di terze parti per scopi specifici. I siti devono comunque richiedere l'accesso con l'API Storage Access, ma per i siti inclusi nel set, l'accesso può essere concesso senza richieste dell'utente.
- Federated Credential Management (FedCM) è un approccio ai servizi di identità federate incentrati sulla tutela della privacy. L'API Storage Access si occupa dell'accesso ai cookie dopo l'accesso. Per alcuni casi d'uso FedCM fornisce 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 gli endpoint HTTP.
- Esistono anche API antifrode, correlate agli annunci e di misurazione e l'API Storage Access non è destinata a risolvere questi problemi.
Utilizzo dell'API Storage Access
L'API Storage Access ha due metodi promessi:
Inoltre, si integra con l'API Permissions. In questo modo puoi 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:
Utilizzo del 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 la chiamata a requestStorageAccess(),, per cui hasStorageAccess() inizialmente restituirà sempre false, tranne quando a un altro documento della stessa origine nello stesso iframe è già stato concesso l'accesso. La concessione viene mantenuta nelle navigazioni dalla stessa origine all'interno dell'iframe, in modo specifico per consentire i ricaricamenti dopo aver concesso l'accesso alle pagine che richiedono la presenza di cookie nella richiesta iniziale del documento HTML.
Utilizzo del metodo requestStorageAccess()
Se l'iframe non ha accesso, potrebbe essere necessario richiederlo 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, l'utente potrebbe dover approvare questo accesso tramite una richiesta del browser. Trascorso questo periodo, la promessa verrà risolta o verrà rifiutata, creando un'eccezione se viene utilizzato await.
Per impedire utilizzi 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, invece che immediatamente durante il caricamento dell'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);
Prompt di autorizzazione
Quando l'utente fa clic sul pulsante per la prima volta, la richiesta del browser viene visualizzata automaticamente, solitamente nella barra degli indirizzi. Di seguito è riportato un esempio della richiesta di Chrome, ma altri browser hanno un'interfaccia utente simile:
La richiesta potrebbe essere ignorata dal browser e l'autorizzazione fornita automaticamente in determinate circostanze:
- Se la pagina e l'iframe sono stati utilizzati negli ultimi 30 giorni dopo l'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 superiore) per i primi cinque tentativi.
In alternativa, il metodo può essere rifiutato automaticamente senza mostrare la richiesta in determinate circostanze:
- Se l'utente non ha mai visitato e interagito in precedenza con il sito proprietario dell'iframe come documento di primo livello, non in un iframe. Ciò significa che l'API Storage Access è utile solo per i siti incorporati che gli utenti hanno visitato in precedenza in un contesto proprietario.
- Se il metodo
requestStorageAccess()viene richiamato al di fuori di un evento di interazione dell'utente senza previa approvazione della richiesta dopo un'interazione.
Anche se all'utente verrà chiesto l'utilizzo iniziale, le visite successive possono risolvere requestStorageAccess() senza richiesta e senza richiedere l'interazione dell'utente in Chrome e Firefox. Tieni presente che Safari richiede sempre l'interazione dell'utente.
Poiché l'accesso ai cookie può essere concesso senza un prompt o un'interazione da parte dell'utente, spesso è possibile ottenere l'accesso ai cookie di terze parti prima che un utente interagisca con i browser che supportano questa funzionalità (Chrome e Firefox) chiamando requestStorageAccess() al caricamento della pagina. Questo potrebbe consentirti di accedere immediatamente ai cookie cross-site di terze parti e di offrire un'esperienza più completa, anche prima che l'utente interagisca con l'iframe. In alcuni casi, l'esperienza utente potrebbe migliorare rispetto all'attesa dell'interazione dell'utente.
Utilizzo della query sulle autorizzazioni storage-access
Per verificare se l'accesso può essere concesso senza l'interazione di un utente, puoi controllare lo stato dell'autorizzazione storage-access ed effettuare la chiamata requestStoreAccess() in anticipo solo se non è richiesta alcuna azione da parte dell'utente, anziché chiamare la chiamata e fare in modo che non vada a buon fine quando è richiesta un'interazione.
Questo ti consente anche di gestire potenzialmente in anticipo la necessità di una richiesta mostrando contenuti diversi, ad esempio un pulsante di accesso.
Il seguente codice 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 in iframe con sandbox, sono necessarie le seguenti autorizzazioni della 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.- L'app
allow-same-originè necessaria per consentire l'accesso ai cookie della stessa origine e ad altro spazio di archiviazione.
Ad esempio:
<iframe sandbox="allow-storage-access-by-user-activation
allow-scripts
allow-same-origin"
src="..."></iframe>
Requisiti per i cookie
Per accedere con l'API Storage Access in Chrome, i cookie cross-site devono essere impostati con i seguenti due attributi:
SameSite=None: necessaria per contrassegnare il cookie come cross-site.Secure, che garantisce che sia possibile accedere solo ai cookie impostati dai siti HTTPS.
In Firefox e Safari, i cookie sono per impostazione predefinita SameSite=None e non limitano l'SSA ai cookie Secure, per cui questi attributi non sono obbligatori. Ti consigliamo di essere esplicito in merito all'attributo SameSite e di utilizzare sempre i cookie Secure.
Accesso alla pagina di primo livello
L'API Storage Access è progettata 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 di siti potrebbero voler includere direttamente nel documento di primo livello anziché in un iframe. Per risolvere 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 le risorse di primo livello. Può essere usata soltanto per i siti che fanno parte di un insieme di siti web correlati per impedire la concessione dell'accesso generale a cookie di terze parti.
Per ulteriori dettagli sull'utilizzo di requestStorageAccessFor(), leggi la guida per gli sviluppatori relativa a insiemi di siti web correlati.
La query sulle autorizzazioni top-level-storage-access
Supporto dei browser
- 119
- 119
- x
- x
Analogamente all'autorizzazione storage-access, esiste un'autorizzazione top-level-storage-access per controllare se è possibile concedere l'accesso per requestStorageAccessFor().
Quali sono le differenze tra l'API Storage Access e RWS?
Quando si utilizzano insiemi di siti web correlati con l'API Storage Access, sono disponibili alcune funzionalità aggiuntive, come descritto nella tabella seguente:
| Senza RWS | Con tecnologia RWS | |
|---|---|---|
| Richiede un gesto dell'utente per avviare la richiesta di accesso allo spazio di archiviazione | ||
| Richiede che l'utente visiti l'origine dello spazio di archiviazione richiesta in un contesto di primo livello prima di concedere l'accesso | ||
| Il primo prompt dell'utente può essere ignorato | ||
Non è necessario chiamare requestStorageAccess se l'accesso è stato concesso in precedenza |
||
| Concedi automaticamente l'accesso ad altri domini in un sito di sito web correlato | ||
Supporta l'requestStorageAccessFor accesso alla pagina di primo livello |
Demo: impostazione e accesso ai cookie
La demo seguente mostra come è possibile 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 disattivati:
- Chrome 118 o versioni successive con il flag
chrome://flags/#test-third-party-cookie-phaseoutimpostato e il browser riavviato. - Firefox
- Safari
Risorse
- Leggi la specifica o segui e segnala i problemi.
- Documentazione e guida dell'API.
- Documentazione di Chrome sull'utilizzo dell'API Storage Access in insiemi di siti web correlati