API Storage Access

Il blocco dei cookie di terze parti da parte dei browser, delle impostazioni utente e del partizionamento dell'archiviazione rappresenta una sfida per i siti e i servizi che si basano su cookie e altre forme di archiviazione in contesti incorporati, per i percorsi utente come l'autenticazione. L'API Storage Access (SAA) consente a questi casi d'uso di continuare a funzionare, limitando il più possibile il monitoraggio cross-site.

Stato dell'implementazione

L'API Storage Access è disponibile in tutti i principali browser, ma esistono lievi differenze di implementazione tra i browser. Queste differenze sono state evidenziate nelle sezioni pertinenti di questo post.

Stiamo continuando 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. I contenuti incorporati con casi d'uso che dipendono dal caricamento di risorse cross-site possono utilizzare l'API per richiedere l'autorizzazione di accesso all'utente, in base alle necessità.

Se la richiesta di spazio di archiviazione viene concessa, l'iframe avrà accesso ai suoi cookie e al suo spazio di archiviazione non partizionati, che sono disponibili anche quando gli utenti lo visitano come sito di primo livello.

L'API Storage Access consente di fornire l'accesso a cookie e spazio di archiviazione non partizionati specifici con un carico minimo per l'utente finale, impedendo al contempo l'accesso generico a cookie e spazio di archiviazione non partizionati, come spesso utilizzato per il monitoraggio degli utenti.

Casi d'uso

Alcuni incorporamenti di terze parti richiedono l'accesso a cookie o spazio di archiviazione non partizionati per offrire un'esperienza migliore all'utente, cosa che non sarà disponibile quando i cookie di terze parti sono limitati e il partizionamento dello spazio di archiviazione è attivato.

I casi d'uso includono:

• Widget di commento incorporati che richiedono i dettagli della sessione di accesso.
• Pulsanti "Mi piace" dei 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 annunci agli utenti che hanno eseguito l'accesso o per conoscere le preferenze dell'utente per i sottotitoli codificati o limitare determinati tipi di video).
• Sistemi di pagamento integrati.

Molti di questi casi d'uso prevedono il mantenimento dell'accesso con le credenziali negli 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, pertanto è importante capire quando utilizzare questa API rispetto alle altre. È destinato a casi d'uso in cui sono vere entrambe le seguenti condizioni:

• L'utente interagirà con i contenuti incorporati, ovvero non si tratta di un iframe passivo o 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 una serie di casi d'uso:

• Cookies Having Independent Partitioned State (CHIPS) consente agli sviluppatori di attivare un cookie per lo spazio di archiviazione "partizionato", con un cookie jar separato per ogni 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 sulla sessione. Le informazioni sulla sessione vengono salvate per 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 su origini diverse (ad esempio per i dettagli o le preferenze della sessione di accesso).
• Il partizionamento dello spazio di archiviazione è un modo per consentire agli iframe cross-site di utilizzare i meccanismi di archiviazione JavaScript esistenti dividendo lo spazio di archiviazione sottostante per sito. In questo modo, l'accesso allo spazio di archiviazione incorporato in un sito web viene impedito allo stesso incorporamento su altri siti web.
• I set di siti web correlati (RWS) consentono a un'organizzazione di dichiarare le relazioni tra i siti, in modo che i browser consentano l'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 del set, l'accesso può essere concesso senza prompt utente.
• Federated Credential Management (FedCM) è un approccio che tutela la privacy per i servizi di identità federata. L'API Storage Access si occupa dell'accesso ai cookie e allo spazio di archiviazione non partizionati dopo l'accesso. Per alcuni casi d'uso, FedCM fornisce una soluzione alternativa all'API Storage Access e potrebbe essere preferibile in quanto presenta un prompt del browser più orientato all'accesso. Tuttavia, l'adozione di FedCM richiede in genere modifiche aggiuntive al codice, ad esempio per supportare i relativi endpoint HTTP.
• Esistono anche API antifrode, correlate agli annunci e di misurazione e l'API Storage Access non è pensata per risolvere questi problemi.

Utilizzare l'API Storage Access

L'API Storage Access ha due metodi basati su promesse:

• Document.hasStorageAccess() (disponibile anche con il nuovo nome Document.hasUnpartitionedCookieAccess() a partire da Chrome 125)
• Document.requestStorageAccess()

Si integra anche 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() verrebbe concessa automaticamente:

• navigator.permissions.query({name: "storage-access"});

Utilizzare 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 using the Storage Access API.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

L'API Storage Access concede l'accesso allo spazio di archiviazione a un documento iframe solo dopo aver chiamato requestStorageAccess(),, quindi hasStorageAccess() potrebbe inizialmente restituire false, ad esempio se l'utente blocca i cookie di terze parti per impostazione predefinita. Tuttavia, le impostazioni utente specifiche del sito possono anche consentire l'accesso ai cookie su un determinato sito, anche se l'utente blocca i cookie di terze parti per impostazione predefinita. L'accesso allo spazio di archiviazione tramite questa API viene mantenuto durante le navigazioni con stessa origine all'interno dell'iframe, in particolare per consentire i ricaricamenti dopo la concessione dell'accesso per le pagine che richiedono la presenza di cookie nella richiesta iniziale del documento HTML.

Utilizza 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 richiesto, l'utente potrebbe dover approvare questo accesso con una richiesta del browser, dopodiché la promessa verrà risolta o rifiutata, con conseguente eccezione se viene utilizzato await.

Per evitare abusi, questo prompt del browser verrà mostrato solo dopo un'interazione dell'utente. Ecco perché requestStorageAccess() deve essere chiamato inizialmente da un gestore di eventi attivato dall'utente, anziché immediatamente al 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 requestStorageAccess() did not reject.
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  if (hasAccess) {
    // Use the cookies
  }
}

document.querySelector('#my-button').addEventListener('click', doClick);

Prompt delle autorizzazioni

Quando l'utente fa clic sul pulsante per la prima volta, nella maggior parte dei casi il prompt del browser viene visualizzato automaticamente, in genere nella barra degli indirizzi. Lo screenshot seguente mostra un esempio del prompt di Chrome, ma altri browser hanno un'interfaccia utente simile:

In determinate circostanze, il browser potrebbe ignorare la richiesta e fornire automaticamente l'autorizzazione:

• Se la pagina e l'iframe sono stati utilizzati negli ultimi 30 giorni dopo aver accettato il prompt.
• Se l'iframe incorporato fa parte di un insieme di siti web correlati.
• Se FedCM viene utilizzato come indicatore di attendibilità per l'accesso allo spazio di archiviazione.
• In Firefox, la richiesta viene ignorata anche per i siti web noti (quelli con cui hai interagito a livello principale) per i primi cinque tentativi.

In alternativa, il metodo potrebbe essere rifiutato automaticamente senza mostrare il prompt in determinate circostanze:

• Se l'utente non ha 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 chiamato al di fuori di un evento di interazione utente senza previa approvazione della richiesta dopo un'interazione.

Anche se all'utente verrà chiesto di risolvere requestStorageAccess() al primo utilizzo, le visite successive potranno essere risolte senza prompt e senza richiedere l'interazione dell'utente in Chrome e Firefox. Tieni presente che Safari richiede sempre un'interazione dell'utente.

Poiché l'accesso ai cookie e allo spazio di archiviazione può essere concesso senza prompt o interazione dell'utente, spesso è possibile ottenere l'accesso ai cookie o allo spazio di archiviazione non partizionati prima di un'interazione dell'utente sui browser che lo supportano (Chrome e Firefox) chiamando requestStorageAccess() al caricamento della pagina. In questo modo, potresti 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, questa può essere un'esperienza utente migliore rispetto all'attesa dell'interazione dell'utente.

FedCM come indicatore di affidabilità per gli annunci di Shopping

Federated Credential Management (FedCM) è un approccio che tutela la privacy dei servizi di identità federati (ad esempio "Accedi con…") e che non si basa su cookie di terze parti o reindirizzamenti di navigazione.

Quando un utente accede a una parte autorizzata che ha alcuni contenuti incorporati di un provider di identità (IdP) di terze parti con FedCM, i contenuti IdP incorporati possono ottenere automaticamente l'accesso allo spazio di archiviazione dei propri cookie non partizionati di primo livello. Per attivare l'accesso automatico allo spazio di archiviazione con FedCM, devono essere soddisfatte le seguenti condizioni:

• L'autenticazione FedCM (lo stato di accesso dell'utente) deve essere attiva.
• La RP ha attivato l'autorizzazione identity-credentials-get, ad esempio:

<iframe src="https://idp.example" allow="identity-credentials-get"></iframe>

Ad esempio, un iframe idp.example è incorporato in rp.example. Quando l'utente accede con FedCM, l'iframe idp.example può richiedere l'accesso allo spazio di archiviazione per i propri cookie di primo livello.

rp.example effettua una chiamata FedCM per consentire all'utente di accedere con il provider di identità idp.example:

// The user will be asked to grant FedCM permission.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
});

Dopo l'accesso dell'utente, l'IdP può chiamare requestStorageAccess() dall'iframe idp.example, a condizione che il RP lo abbia consentito esplicitamente con i criteri delle autorizzazioni. L'incorporamento riceverà automaticamente l'accesso allo spazio di archiviazione del proprio cookie di primo livello, senza attivazione dell'utente o la necessità di un altro prompt di autorizzazione:

// Make this call within the embedded IdP iframe:

// No user gesture is needed, and the storage access will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

L'autorizzazione verrà concessa automaticamente solo finché l'utente è connesso con FedCM. Una volta che l'autenticazione è inattiva, si applicano i requisiti SAA standard per concedere l'accesso allo spazio di archiviazione.

API Storage Access per l'archiviazione non basata su cookie

Puoi richiedere l'accesso allo spazio di archiviazione locale non partizionato passando il parametro types alla chiamata requestStorageAccess. Ad esempio, per richiedere l'accesso allo spazio di archiviazione locale non partizionato, puoi chiamare requestStorageAccess({localStorage: true}).

Se i cookie di terze parti sono attivati, questo metodo concede l'accesso senza richiedere l'attivazione dell'utente o alcuna richiesta di autorizzazione. Se l'utente ha disattivato i cookie di terze parti, dovrà ricevere una richiesta prima che venga concesso l'accesso allo spazio di archiviazione.

Innanzitutto, verifica se il browser ha già accesso allo spazio di archiviazione:

async function hasCookieAccess(){
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported, so we assume it's an older browser that doesn't partition storage.
    throw new Error("requestStorageAccess is not supported")
  }

  // Check if access has already been granted or if the user has 3-party cookies enabled
  return document.hasStorageAccess();
}

Se i cookie di terze parti sono attivi, richiedi l'accesso allo spazio di archiviazione:

// Request storage access and return the storage handle
async function requestStorageHandle(){
// You can request for multiple types of non-cookie storage
// at once, or request for all of them with all:true
return document.requestStorageAccess({all:true});
}

Se i cookie di terze parti sono bloccati (ad esempio, in modalità di navigazione in incognito), controlla le autorizzazioni di query per decidere se è necessario un prompt per l'utente. Lo stato dell'autorizzazione navigator.permissions.query({name: 'storage-access'}) può avere i seguenti valori:

• granted. L'utente ha già concesso l'accesso. Chiama requestStorageAccess per ottenere l'accesso allo spazio di archiviazione non partizionato senza la necessità di un ulteriore prompt per l'utente.
• prompt. L'utente non ha ancora concesso l'accesso. Imposta un listener di clic e chiama di nuovo requestStorageAccess dopo un'interazione dell'utente.
• error. L'autorizzazione non è supportata. Quando l'API Storage Access è supportata, è probabile che sia supportata anche questa autorizzazione.

// Returns `granted`, or `prompt`; or throws an error if storage-access
// permission is not supported
async function getStorageAccessPermission(){
  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
    return navigator.permissions.query({name: 'storage-access'});
}

Il flusso completo per la gestione dell'archiviazione partizionata non basata su cookie può essere implementato nel seguente modo:

async function getStorageHandle() {
    // Check if the user has 3-party cookie access
    if (await hasCookieAccess()) {
    // If the user has access, requestStorageAccess() will resolve automatically
        return requestStorageHandle();
    }

    // If the browser blocks third party cookies, check if the user has
    // accepted the prompt and granted access. If they have,
    // requestStorageAccess() will resolve automatically
    const permission = await getStorageAccessPermission();
    if (permission == 'granted') { // User has seen prompt and granted access
        return requestStorageHandle();
    }

    // Wait for user activation to prompt the user again
    // (or put your silent failure logic here instead)
    return new Promise((resolve, reject) => {
        document.querySelector('#myButton').addEventListener(e => {
            requestStorageHandle().then(resolve, reject);
        })
    })
}

// Use your storage
getStorageHandle().then(handle=>{
    handle.indexedDB.open(...);
}).catch(() => {
    // If the promise is rejected, you can use regular partitioned storage
    indexedDB.open(...);
})

Caricamento successivo con le intestazioni di accesso allo spazio di archiviazione

Le intestazioni Storage Access sono un modo consigliato e più efficiente per attivare il caricamento dei contenuti incorporati, incluse le risorse non iframe. La funzionalità è disponibile a partire da Chrome 133. Con le intestazioni di accesso allo spazio di archiviazione, il browser può riconoscere quando l'utente ha già concesso a storage-access l'autorizzazione all'origine di terze parti nel contesto attuale e può caricare le risorse con accesso ai cookie non partizionati durante le visite successive.

Flusso delle intestazioni di accesso all'archiviazione

Con le intestazioni Storage Access, le visite alle pagine successive attiveranno il seguente flusso:

1. L'utente ha visitato in precedenza website.example che incorpora una risorsa calendar.example e ha concesso storage-access con la chiamata document.requestStorageAccess().
2. L'utente visita di nuovo website.example che ha la risorsa calendar.example incorporata . Questa richiesta non ha ancora accesso al cookie, come in precedenza. Tuttavia, l'utente ha precedentemente concesso l'autorizzazione storage-access e il recupero include un'intestazione Sec-Fetch-Storage-Access: inactive per indicare che l'accesso ai cookie non partizionati è disponibile ma non attivato.
3. Il server calendar.example risponde con un'intestazione Activate-Storage-Access: retry; allowed-origin='<origin>' (in questo caso, <origin> sarebbe https://website.example) per indicare che il recupero della risorsa richiede l'utilizzo di cookie non partizionati con l'autorizzazione storage-access.
4. Il browser riprova a inviare la richiesta, questa volta includendo i cookie non partizionati (attivando l'autorizzazione storage-access per questo recupero e per i recuperi successivi).
5. Il server calendar.example risponde con i contenuti dell'iframe personalizzati. La risposta include un'intestazione Activate-Storage-Access: load per indicare che il browser deve caricare i contenuti con l'autorizzazione storage-access attivata (in altre parole, caricare con accesso ai cookie non partizionati, come se fosse stato chiamato document.requestStorageAccess()).
6. Lo user agent carica i contenuti dell'iframe con accesso ai cookie non partizionati utilizzando l'autorizzazione storage-access. Dopo questo passaggio, il widget può funzionare come previsto.

Utilizzare le intestazioni di accesso allo spazio di archiviazione

La tabella seguente elenca le intestazioni di accesso allo spazio di archiviazione.

Ad esempio, le intestazioni di accesso allo spazio di archiviazione possono essere utilizzate per caricare un'immagine da una terza parte:

  // On the client side
  <img src="https://server.example/image">

In questo caso, server.example deve implementare la seguente logica sul lato server:

  app.get('/image', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // The user needs to grant permission, trigger a prompt

    // Check if the requesting origin is allowed
    // to send credentialed requests to this server.
    // Assuming the `validate_origin(origin)` method is previously defined:
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(req.headers.origin +
        ' is not allowed to send credentialed requests to this server.');
      return;
    }
    // 'retry' header value indicates that the content load request should be re-sent after the user has granted permissions
    res.set('Activate-Storage-Access', `retry; allowed-origin='${req.headers.origin}'`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

La demo dell'API Storage Access incorpora contenuti di terze parti (inclusa un'immagine non iframe) utilizzando le intestazioni Storage Access.

Utilizzare la query per l'autorizzazione storage-access

Per verificare se l'accesso può essere concesso senza un'interazione 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é chiamarla e farla non riuscire quando è richiesta un'interazione.

In questo modo, puoi anche gestire in anticipo la necessità di un prompt visualizzando contenuti diversi, ad esempio un pulsante di accesso.

Il seguente codice aggiunge il controllo dell'autorizzazione 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 earlier 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') {
            // Not used: see https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by earlier tests.
  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 è tenuto a 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 dei cookie

Per essere accessibili con l'API Storage Access in Chrome, i cookie cross-site devono essere impostati con i seguenti due attributi:

• SameSite=None, necessario 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 impostati per impostazione predefinita su SameSite=None e non limitano SAA ai cookie Secure, pertanto questi attributi non sono obbligatori. Ti consigliamo di specificare l'attributo SameSite e di utilizzare sempre i cookie Secure.

Accesso alla pagina di primo livello

L'API Storage Access è pensata per consentire l'accesso ai 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 ai 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 risolvere questo caso d'uso, Chrome ha proposto un'estensione dell'API Storage Access che aggiunge un metodorequestStorageAccessFor().

Il metodo requestStorageAccessFor()

Il metodo requestStorageAccessFor() funziona in modo simile a requestStorageAccess(), ma per le risorse di primo livello. Può essere utilizzato solo per i siti all'interno di un set di siti web correlati per impedire la concessione dell'accesso generale ai cookie di terze parti.

Per ulteriori dettagli su come utilizzare requestStorageAccessFor(), leggi la Guida per gli sviluppatori: insiemi di siti web correlati.

Query per l'autorizzazione top-level-storage-access

Analogamente all'autorizzazione storage-access, esiste un'autorizzazione top-level-storage-access per verificare se è possibile concedere l'accesso per requestStorageAccessFor().

In che modo l'API Storage Access è diversa quando viene utilizzata con gli insiemi di siti web correlati?

Quando gli insiemi di siti web correlati vengono utilizzati con l'API Storage Access, sono disponibili alcune funzionalità aggiuntive, come descritto nella seguente tabella:

Demo: impostazione e accesso ai cookie

La seguente demo mostra come è possibile accedere a un cookie impostato 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-phaseout impostato e il browser riavviato.
• Firefox
• Safari

Demo: impostazione dell'archiviazione locale

La seguente demo mostra come accedere ai 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 attivato.

Risorse

• Leggi le specifiche che forniscono l'accesso ai cookie di terze parti o segui e segnala i problemi.
• Leggi la specifica che fornisce l'accesso allo spazio di archiviazione non partizionato o 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