API Storage Access

Le blocage des cookies tiers par les navigateurs, les paramètres utilisateur et le partitionnement du stockage posent un problème pour les sites et services qui s'appuient sur les cookies et autres types de stockage dans des contextes intégrés, pour les parcours utilisateur tels que l'authentification. L'API Storage Access (SAA) permet à ces cas d'utilisation de continuer à fonctionner, tout en limitant autant que possible le suivi multisite.

État de l'implémentation

L'API Storage Access est disponible dans tous les principaux navigateurs, mais il existe de légères différences d'implémentation entre les navigateurs. Ces différences sont mises en évidence dans les sections concernées de cet article.

Nous continuons de travailler à la résolution de tous les problèmes bloquants restants avant de standardiser l'API.

Qu'est-ce que l'API Storage Access ?

L'API Storage Access est une API JavaScript qui permet aux iFrames de demander des autorisations d'accès au stockage lorsque l'accès serait refusé par les paramètres du navigateur. Les intégrations avec des cas d'utilisation qui dépendent du chargement de ressources multisites peuvent utiliser l'API pour demander l'autorisation d'accès à l'utilisateur, selon les besoins.

Si la demande de stockage est accordée, l'iframe aura accès à ses cookies et à son stockage non partitionnés, qui sont également disponibles lorsque les utilisateurs y accèdent en tant que site de premier niveau.

L'API Storage Access permet d'accorder un accès spécifique aux cookies et au stockage non partitionnés avec un minimum de contraintes pour l'utilisateur final, tout en empêchant l'accès générique aux cookies et au stockage non partitionnés, qui est souvent utilisé pour le suivi des utilisateurs.

Cas d'utilisation

Certains composants intégrés tiers nécessitent d'accéder à des cookies ou à un stockage non partitionnés pour offrir une meilleure expérience à l'utilisateur. Cela ne sera pas possible lorsque les cookies tiers seront soumis à des restrictions et que le partitionnement du stockage sera activé.

Voici quelques cas d'utilisation :

• Widgets de commentaires intégrés nécessitant des informations de session de connexion.
• Boutons "J'aime" des réseaux sociaux qui nécessitent des informations sur la session de connexion.
• Documents intégrés nécessitant des informations de session de connexion.
• Expérience premium fournie à une vidéo intégrée (par exemple, pour ne pas afficher d'annonces pour les utilisateurs connectés, ou pour connaître les préférences de l'utilisateur concernant les sous-titres ou restreindre certains types de vidéos).
• Systèmes de paiement intégrés.

Dans de nombreux cas d'utilisation, l'accès à la connexion est conservé dans des iFrames intégrés.

Quand utiliser l'API Storage Access plutôt que d'autres API ?

L'API Storage Access est l'une des alternatives à l'utilisation de cookies et de stockage non partitionnés. Il est donc important de comprendre quand l'utiliser par rapport aux autres. Elle est destinée aux cas d'utilisation où les deux conditions suivantes sont remplies :

• L'utilisateur interagit avec le contenu intégré (il ne s'agit pas d'un iFrame passif ni caché).
• L'utilisateur a consulté l'origine intégrée dans un contexte de premier niveau, c'est-à-dire lorsque cette origine n'est pas intégrée à un autre site.

Il existe d'autres API pour différents cas d'utilisation :

• Cookies Having Independent Partitioned State (CHIPS) permet aux développeurs d'activer le stockage "partitionné" pour un cookie, avec une boîte à cookies distincte pour chaque site de premier niveau. Par exemple, un widget de chat Web tiers peut s'appuyer sur la définition d'un cookie pour enregistrer les informations de session. Les informations de session sont enregistrées par site. Il n'est donc pas nécessaire d'accéder au cookie défini par le widget sur d'autres sites Web où il est également intégré. L'API Storage Access est utile lorsqu'un widget tiers intégré dépend du partage des mêmes informations sur différentes origines (par exemple, pour les détails de la session connectée ou les préférences).
• Le partitionnement du stockage permet aux iFrames multisites d'utiliser les mécanismes de stockage JavaScript existants tout en divisant le stockage sous-jacent par site. Cela empêche l'accès au stockage intégré d'un site Web par la même intégration sur d'autres sites Web.
• Les ensembles de sites Web associés (RWS, Related Website Sets) permettent à une organisation de déclarer des relations entre des sites, afin que les navigateurs autorisent un accès limité aux cookies et au stockage non partitionnés à des fins spécifiques. Les sites doivent toujours demander l'accès avec l'API Storage Access, mais pour les sites de l'ensemble, l'accès peut être accordé sans invite à l'utilisateur.
• Federated Credential Management (FedCM) est une approche respectueuse de la confidentialité pour les services d'identité fédérée. L'API Storage Access permet d'accéder aux cookies et au stockage non partitionnés après la connexion. Pour certains cas d'utilisation, FedCM constitue une solution alternative à l'API Storage Access. Il peut être préférable, car il comporte une invite de navigateur plus axée sur la connexion. Toutefois, l'adoption de FedCM nécessite généralement des modifications supplémentaires de votre code, par exemple pour prendre en charge ses points de terminaison HTTP.
• Il existe également des API antifraude, associées aux annonces et de mesure. L'API Storage Access n'est pas destinée à répondre à ces préoccupations.

Utiliser l'API Storage Access

L'API Storage Access comporte deux méthodes basées sur des promesses :

• Document.hasStorageAccess() (également disponible sous le nouveau nom Document.hasUnpartitionedCookieAccess() à partir de Chrome 125)
• Document.requestStorageAccess()

Il s'intègre également à l'API Permissions. Cela vous permet de vérifier l'état de l'autorisation d'accès au stockage dans un contexte tiers, ce qui indique si un appel à document.requestStorageAccess() serait automatiquement accordé :

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

Utiliser la méthode hasStorageAccess()

Lorsqu'un site se charge pour la première fois, il peut utiliser la méthode hasStorageAccess() pour vérifier si l'accès aux cookies tiers a déjà été accordé.

// 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 n'accorde l'accès au stockage à un document iframe qu'après l'appel de requestStorageAccess(),. Par conséquent, hasStorageAccess() peut renvoyer la valeur "false" au départ, par exemple si l'utilisateur bloque les cookies tiers par défaut. (Toutefois, les paramètres utilisateur spécifiques à un site peuvent également autoriser l'accès aux cookies sur un site particulier, même si l'utilisateur bloque les cookies tiers par défaut.) L'accès au stockage à l'aide de cette API est conservé lors des navigations de même origine à l'intérieur de l'iFrame, en particulier pour permettre les rechargements après l'octroi de l'accès pour les pages qui nécessitent la présence de cookies dans la requête initiale du document HTML.

Utiliser requestStorageAccess()

Si l'iFrame n'y a pas accès, il devra peut-être le demander à l'aide de la méthode requestStorageAccess() :

if (!hasAccess) {
  try {
    await document.requestStorageAccess();
  } catch (err) {
    // Access was not granted and it may be gated behind an interaction
    return;
  }
}

La première fois que cela est demandé, l'utilisateur peut avoir besoin d'approuver cet accès avec une invite du navigateur, après quoi la promesse sera résolue ou rejetée, ce qui entraînera une exception si await est utilisé.

Pour éviter toute utilisation abusive, cette invite du navigateur ne s'affiche qu'après une interaction de l'utilisateur. C'est pourquoi requestStorageAccess() doit initialement être appelé à partir d'un gestionnaire d'événements activé par l'utilisateur, plutôt qu'immédiatement au chargement de 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 requestStorageAccess() did not reject.
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

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

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

Invites d'autorisation

Lorsque l'utilisateur clique sur le bouton pour la première fois, l'invite du navigateur s'affiche automatiquement dans la plupart des cas, généralement dans la barre d'adresse. La capture d'écran ci-dessous montre un exemple d'invite Chrome, mais d'autres navigateurs ont une interface utilisateur similaire :

Dans certains cas, l'invite peut être ignorée par le navigateur et l'autorisation accordée automatiquement :

• Si la page et l'iframe ont été utilisés au cours des 30 derniers jours après avoir accepté l'invite.
• Si l'iFrame intégré fait partie d'un ensemble de sites Web associés.
• Si FedCM est utilisé comme signal de confiance pour l'accès au stockage.
• Dans Firefox, l'invite est également ignorée pour les sites Web connus (ceux avec lesquels vous avez interagi au premier niveau) lors des cinq premières tentatives.

Dans certains cas, la méthode peut être automatiquement refusée sans afficher l'invite :

• Si l'utilisateur n'a jamais visité le site propriétaire de l'iFrame ni interagi avec lui en tant que document de premier niveau, et non dans un iFrame. Cela signifie que l'API Storage Access n'est utile que pour les sites intégrés que les utilisateurs ont déjà consultés dans un contexte propriétaire.
• Si la méthode requestStorageAccess() est appelée en dehors d'un événement d'interaction utilisateur sans approbation préalable de l'invite après une interaction.

Bien que l'utilisateur soit invité à le faire lors de la première utilisation, les visites ultérieures peuvent résoudre requestStorageAccess() sans invite et sans nécessiter d'interaction de l'utilisateur dans Chrome et Firefox. Notez que Safari nécessite toujours une interaction utilisateur.

Étant donné que l'accès aux cookies et au stockage peut être accordé sans invite ni interaction de l'utilisateur, il est souvent possible d'obtenir un accès aux cookies ou au stockage non partitionnés avant une interaction de l'utilisateur sur les navigateurs qui le prennent en charge (Chrome et Firefox) en appelant requestStorageAccess() lors du chargement de la page. Cela peut vous permettre d'accéder immédiatement aux cookies et au stockage non partitionnés, et d'offrir une expérience plus complète, même avant que l'utilisateur n'interagisse avec l'iFrame. Dans certaines situations, cela peut améliorer l'expérience utilisateur par rapport à l'attente d'une interaction de l'utilisateur.

FedCM comme signal de confiance pour SAA

FedCM (Federated Credential Management) est une approche respectueuse de la confidentialité pour les services d'identité fédérée (tels que "Se connecter avec…") qui ne repose pas sur les cookies tiers ni sur les redirections de navigation.

Lorsqu'un utilisateur se connecte à une partie de confiance (RP) qui contient du contenu intégré provenant d'un fournisseur d'identité (IdP) tiers avec FedCM, le contenu IdP intégré peut automatiquement obtenir l'accès au stockage de ses propres cookies non partitionnés de premier niveau. Pour activer l'accès automatique au stockage avec FedCM, les conditions suivantes doivent être remplies :

• L'authentification FedCM (état de connexion de l'utilisateur) doit être active.
• Le RP a activé l'autorisation identity-credentials-get en définissant, par exemple :

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

Par exemple, un iframe idp.example est intégré à rp.example. Lorsque l'utilisateur se connecte avec FedCM, l'iframe idp.example peut demander l'accès au stockage pour ses propres cookies de premier niveau.

rp.example effectue un appel FedCM pour connecter l'utilisateur avec le fournisseur d'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',
    }],
  },
});

Une fois l'utilisateur connecté, l'IdP peut appeler requestStorageAccess() depuis l'iFrame idp.example, à condition que le RP l'ait explicitement autorisé avec la stratégie d'autorisation. L'élément intégré se verra automatiquement accorder l'accès au stockage de son propre cookie de premier niveau, sans activation de l'utilisateur ni besoin d'une autre invite d'autorisation :

// 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'autorisation ne sera accordée automatiquement que tant que l'utilisateur sera connecté avec FedCM. Une fois l'authentification inactive, les exigences standards concernant les SAA s'appliquent pour accorder l'accès au stockage.

API Storage Access pour le stockage non basé sur les cookies

Vous pouvez demander l'accès au stockage local non partitionné en transmettant le paramètre types à votre appel requestStorageAccess. Par exemple, pour demander l'accès au stockage local non partitionné, vous pouvez appeler requestStorageAccess({localStorage: true}).

Si les cookies tiers sont activés, cette méthode accorde l'accès sans nécessiter l'activation par l'utilisateur ni aucune invite d'autorisation. Si l'utilisateur a désactivé les cookies tiers, il devra être invité à autoriser l'accès au stockage avant que celui-ci ne lui soit accordé.

Commencez par vérifier si le navigateur a déjà accès au stockage :

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();
}

Si les cookies tiers sont activés, demandez l'accès au stockage :

// 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});
}

Si les cookies tiers sont bloqués (par exemple, en mode navigation privée), vérifiez les autorisations de requête pour déterminer si une invite utilisateur est requise. L'état d'autorisation navigator.permissions.query({name: 'storage-access'}) peut avoir les valeurs suivantes :

• granted : l'utilisateur a déjà accordé l'accès. Appelez requestStorageAccess pour obtenir un accès au stockage non partitionné sans avoir besoin d'une invite utilisateur supplémentaire.
• prompt : l'utilisateur n'a pas encore accordé l'accès. Définissez un écouteur de clics et appelez requestStorageAccess à nouveau après une interaction de l'utilisateur.
• error. L'autorisation n'est pas disponible. Lorsque l'API Storage Access est compatible, cette autorisation l'est probablement aussi.

// 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'});
}

Le flux complet pour gérer le stockage partitionné sans cookie peut être implémenté comme suit :

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(...);
})

Chargement ultérieur avec les en-têtes d'accès au stockage

Les en-têtes d'accès au stockage sont une méthode recommandée et plus performante pour permettre le chargement de contenu intégré, y compris les ressources non-iframe. Cette fonctionnalité est disponible à partir de Chrome 133. Grâce aux en-têtes d'accès au stockage, le navigateur peut reconnaître quand l'utilisateur a déjà accordé à storage-access l'autorisation d'accéder à l'origine tierce dans le contexte actuel. Il peut ainsi charger des ressources ayant accès aux cookies non partitionnés lors des visites ultérieures.

Flux des en-têtes d'accès au stockage

Avec les en-têtes Storage Access, les visites de pages ultérieures déclenchent le flux suivant :

1. L'utilisateur a déjà consulté website.example qui intègre une ressource calendar.example et a accordé storage-access avec l'appel document.requestStorageAccess().
2. L'utilisateur consulte de nouveau la page website.example qui contient la ressource calendar.example intégrée. Comme avant, cette requête n'a pas encore accès au cookie. Toutefois, l'utilisateur a déjà accordé l'autorisation storage-access, et la récupération inclut un en-tête Sec-Fetch-Storage-Access: inactive pour indiquer que l'accès aux cookies non partitionnés est disponible, mais pas activé.
3. Le serveur calendar.example répond avec un en-tête Activate-Storage-Access: retry; allowed-origin='<origin>' (dans ce cas, <origin> serait https://website.example) pour indiquer que la récupération de la ressource nécessite l'utilisation de cookies non partitionnés avec l'autorisation storage-access.
4. Le navigateur relance la requête, cette fois en incluant les cookies non partitionnés (en activant l'autorisation storage-access pour cette récupération et les récupérations suivantes).
5. Le serveur calendar.example répond avec le contenu personnalisé de l'iFrame. La réponse inclut un en-tête Activate-Storage-Access: load pour indiquer que le navigateur doit charger le contenu avec l'autorisation storage-access activée (en d'autres termes, charger avec un accès aux cookies non partitionné, comme si document.requestStorageAccess() avait été appelé).
6. L'agent utilisateur charge le contenu de l'iFrame avec un accès aux cookies non partitionné à l'aide de l'autorisation storage-access. Une fois cette étape effectuée, le widget peut fonctionner comme prévu.

Utiliser des en-têtes d'accès au stockage

Le tableau suivant répertorie les en-têtes d'accès au stockage.

Par exemple, les en-têtes d'accès au stockage peuvent être utilisés pour charger une image à partir d'un tiers :

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

Dans ce cas, server.example doit implémenter la logique suivante côté serveur :

  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 démonstration de l'API Storage Access intègre du contenu tiers (y compris une image non-iframe) à l'aide d'en-têtes Storage Access.

Utiliser la requête d'autorisation storage-access

Pour vérifier si l'accès peut être accordé sans interaction de l'utilisateur, vous pouvez vérifier l'état de l'autorisation storage-access et n'effectuer l'appel requestStoreAccess() de manière anticipée que si aucune action de l'utilisateur n'est requise. Vous éviterez ainsi de l'appeler et de le voir échouer lorsqu'une interaction est requise.

Cela vous permet également de gérer potentiellement la nécessité d'une invite à l'avance en affichant un contenu différent, par exemple un bouton de connexion.

Le code suivant ajoute la vérification de l'autorisation storage-access à l'exemple précédent :

// 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();

iFrames en bac à sable

Lorsque vous utilisez l'API Storage Access dans des iFrames en bac à sable, les autorisations de bac à sable suivantes sont requises :

• allow-storage-access-by-user-activation est nécessaire pour autoriser l'accès à l'API Storage Access.
• allow-scripts est nécessaire pour autoriser l'utilisation de JavaScript afin d'appeler l'API.
• allow-same-origin est nécessaire pour autoriser l'accès aux cookies et autres espaces de stockage de même origine.

Exemple :

<iframe sandbox="allow-storage-access-by-user-activation
                 allow-scripts
                 allow-same-origin"
        src="..."></iframe>

Exigences concernant les cookies

Pour être accessibles avec l'API Storage Access dans Chrome, les cookies multisites doivent être définis avec les deux attributs suivants :

• SameSite=None, qui est obligatoire pour marquer le cookie comme intersite
• Secure, qui garantit que seuls les cookies définis par les sites HTTPS sont accessibles.

Dans Firefox et Safari, les cookies sont définis par défaut sur SameSite=None et ne limitent pas SAA aux cookies Secure. Ces attributs ne sont donc pas obligatoires. Nous vous recommandons d'être explicite concernant l'attribut SameSite et d'utiliser systématiquement les cookies Secure.

Accès aux pages de premier niveau

L'API Storage Access est destinée à permettre l'accès aux cookies tiers dans les iFrames intégrés.

Il existe également d'autres cas d'utilisation où la page de premier niveau nécessite d'accéder aux cookies tiers. Par exemple, les images ou les scripts qui sont limités par les cookies, que les propriétaires de sites peuvent souhaiter inclure directement dans le document de premier niveau plutôt que dans un iFrame. Pour répondre à ce cas d'utilisation, Chrome a proposé une extension de l'API Storage Access qui ajoute une méthoderequestStorageAccessFor().

La méthode requestStorageAccessFor()

La méthode requestStorageAccessFor() fonctionne de la même manière que requestStorageAccess(), mais pour les ressources de premier niveau. Elle ne peut être utilisée que pour les sites d'un ensemble de sites Web associés afin d'empêcher l'octroi d'un accès général aux cookies tiers.

Pour en savoir plus sur l'utilisation de requestStorageAccessFor(), consultez le guide du développeur sur les ensembles de sites Web associés.

Requête d'autorisation top-level-storage-access

Comme pour l'autorisation storage-access, il existe une autorisation top-level-storage-access permettant de vérifier si l'accès peut être accordé pour requestStorageAccessFor().

En quoi l'API Storage Access est-elle différente lorsqu'elle est utilisée avec RWS ?

Lorsque les ensembles de sites Web associés sont utilisés avec l'API Storage Access, certaines fonctionnalités supplémentaires sont disponibles, comme indiqué dans le tableau suivant :

Démonstration : définir des cookies et y accéder

La démonstration suivante montre comment un cookie que vous avez défini sur le premier écran de la démonstration peut être consulté dans un frame intégré sur le deuxième site de la démonstration :

storage-access-api-demo.glitch.me

La démo nécessite un navigateur dont les cookies tiers sont désactivés :

• Chrome 118 ou version ultérieure avec l'option chrome://flags/#test-third-party-cookie-phaseout définie et le navigateur redémarré.
• Firefox
• Safari

Démonstration : Définir le stockage local

La démonstration suivante montre comment accéder aux chaînes de diffusion non partitionnées à partir d'un iFrame tiers à l'aide de l'API Storage Access :

https://saa-beyond-cookies.glitch.me/

La démo nécessite Chrome 125 ou version ultérieure avec l'indicateur test-third-party-cookie-phaseout activé.

Ressources

• Lisez les spécifications qui fournissent un accès aux cookies tiers, ou suivez et signalez les problèmes.
• Lisez les spécifications qui fournissent un accès au stockage non partitionné, ou suivez et signalez les problèmes.
• Documentation de l'API et guide
• Documentation Chrome sur l'utilisation de l'API Storage Access dans les ensembles de sites Web associés