Participer à la phase d'évaluation pour accéder au stockage sans cookie via l'API Storage Access

Helen Cho
Helen Cho
Ari Chivukula
Ari Chivukula
GitHub

Chrome 115 a apporté des modifications aux API de stockage, de service workers et de communication en les partitionnant dans des contextes tiers. En plus d'être isolées par la règle SOP (Same-Origin Policy), les API concernées utilisées dans des contextes tiers sont également isolées par le site du contexte de premier niveau.

Les sites qui n'ont pas eu le temps d'implémenter la prise en charge du partitionnement du stockage tiers peuvent participer à une phase d'évaluation d'abandon pour annuler temporairement le partitionnement (continuer l'isolation par règle SOP, mais supprimer l'isolation par site de premier niveau) et restaurer le comportement antérieur des API de stockage, de service workers et de communication dans le contenu intégré à leur site. Cette expérimentation d'abandon est prévue pour expirer avec la sortie de Chrome 127 le 3 septembre 2024. Notez que cette évaluation avant arrêt est distincte de celle concernant l'accès aux cookies tiers. Elle concerne uniquement l'accès au stockage.

Pour résoudre à long terme certains cas d'utilisation perturbés par le partitionnement du stockage tiers non basé sur les cookies, Chrome propose aux tiers de demander l'accès au stockage/à la communication (cookies et non cookies) via l'API Storage Access (livraison à partir de Chrome 117), qui permet déjà aux tiers de demander l'accès aux cookies.

À partir de Chrome 120, cette proposition sera disponible pour les tests via une phase d'évaluation de l'origine. Les développeurs doivent participer à ce test d'origine pour évaluer comment la solution proposée répond à leurs cas d'utilisation et s'assurer qu'ils sont prêts avant la fin du test d'abandon.

Détails de l'essai Origin

À partir de Chrome 120, Chrome prendra en charge une phase d'évaluation d'origine, StorageAccessAPIBeyondCookies, pour permettre l'extension proposée de l'API Storage Access (rétrocompatible) afin d'autoriser l'accès au stockage non partitionné (cookie et non basé sur les cookies) dans un contexte tiers.

Mécanique

Vous pouvez utiliser l'API comme suit (JavaScript exécuté dans un iFrame intégré):

// Request a new storage handle via rSA (this should prompt the user)
const handle = await document.requestStorageAccess({all: true});
// Write some 1P context sessionStorage
handle.sessionStorage.setItem('userid', '1234');
// Write some 1P context localStorage
handle.localStorage.setItem('preference', 'A');
// Open or create an indexedDB that is shared with the 1P context
const messageDB = handle.indexedDB.open('messages');
// Use locks shared with the 1P context
await handle.locks.request('example', ...);

Si vous ne souhaitez accéder qu'à une API spécifique plutôt qu'à all, vous pouvez transmettre uniquement les noms des poignées d'API dont vous avez besoin. Par exemple, vous pouvez transmettre {sessionStorage: true} pour accéder uniquement à Session Storage, ou {indexedDB: true, locks:true} pour accéder à IndexedDB et aux verrous Web.

En plus d'appeler cette extension supplémentaire, l'accès au stockage non basé sur les cookies correspondrait aux exigences actuelles concernant l'accès aux cookies via l'API Storage Access. Par exemple, dans Chrome, aucune invite ne s'affiche lorsque les origines se trouvent dans le même ensemble de sites Web associés (RWS, nouveau nom des ensembles propriétaires). Les origines qui ne font pas partie de la même RWS sont soumises aux exigences d'invite de l'API Storage Access dans Chrome.

Durée

L'évaluation de l'origine sera disponible de Chrome 120 à Chrome 125 (ou après le 6 août 2024, à n'importe quel stade).

Portée

Seuls le stockage DOM (stockage par session et local), la base de données indexée et les verrous Web sont disponibles dans Chrome 120.

Cache Storage, Origin Private File System, Quota, Blob Storage et Broadcast Channel ont été ajoutés dans Chrome 121.

Les workers partagés et le contrôle de l'inclusion des cookies ont été ajoutés dans Chrome 123.

Les nœuds de calcul dédiés héritent de l'accès aux cookies non partitionnés si requestStorageAccess a été appelé avant la création du nœud de calcul à partir de Chrome 120 (cela ne nécessite pas d'utiliser le gestionnaire de l'API Storage Access).

Participer

  1. Évaluez la façon dont vous utilisez le stockage de cookies et non basé sur les cookies dans un contexte tiers. Les exemples de cas d'utilisation peuvent vous aider à déterminer si cette proposition peut répondre à vos besoins.
  2. Lancez Chrome 120 (ou version ultérieure) et assurez-vous que l'option test-third-party-cookie-phaseout est activée.
  3. Si vous souhaitez tester la fonctionnalité localement sans avoir à configurer d'abord un jeton d'essai d'origine, vous pouvez activer #enable-experimental-web-platform-features dans votre navigateur.
    1. Une fois que vous avez terminé les tests en local, vous pouvez vous inscrire à l'essai de l'origine StorageAccessAPIBeyondCookies et obtenir un jeton pour vos domaines. Pour obtenir des instructions plus détaillées, consultez Premiers pas avec les tests d'origine. Le guide de dépannage des phases d'évaluation des origines Chrome fournit une checklist complète pour vous assurer que votre jeton est correctement configuré.
    2. Intégrez ce jeton d'essai d'origine dans l'iFrame dans laquelle vous devez utiliser le gestionnaire de l'API Storage Access, à l'aide d'un en-tête HTTP, d'une balise méta HTML ou de manière programmatique. Notez que le jeton doit être intégré par tous les frames qui souhaitent utiliser cette API. L'intégrer dans le frame parent n'activera pas l'API dans les frames enfants.
  4. Appelez document.requestStorageAccess(...) pour obtenir le gestionnaire de l'API Storage Access dans l'iframe intersites. Consultez la documentation de l'API Storage Access pour connaître les conditions requises pour que cet appel aboutisse.
  5. Migrez le stockage associé dans votre iframe pour utiliser le gestionnaire de l'API Storage Access, le cas échéant. Par exemple, les appels à window.sessionStorage.setItem(...) deviennent handle.sessionStorage.setItem(...).
  6. Ouvrez votre site Web et vérifiez que le gestionnaire d'accès au stockage fonctionne comme prévu.
  7. Pour ne plus participer au test d'origine, supprimez le jeton que vous avez ajouté à l'étape 3.
  8. Envoyez vos commentaires ou signalez les problèmes que vous rencontrez dans le dépôt GitHub de l'API Storage Access pour le stockage non basé sur les cookies.

Démo: utiliser l'API Storage Access pour accéder au stockage local non partitionné

La démonstration suivante montre comment accéder à des canaux de diffusion non partitionnés à partir d'un iframe tiers à l'aide de l'API Storage Access:

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

La démonstration nécessite Chrome 121 ou version ultérieure avec l'option test-third-party-cookie-phaseout activée.

Ressources supplémentaires