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 partitionnant dans des contextes tiers. En plus d'être isolées par la règle d'origine commune, 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 compatibilité avec le partitionnement du stockage tiers peuvent participer à un essai avant arrêt pour annuler temporairement la partition (poursuivre l'isolation par une règle de même origine, mais supprimer l'isolation par le 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. Cet essai avant arrêt arrivera à expiration avec la sortie de Chrome 127 le 3 septembre 2024. Notez que cette étape est différente de l'évaluation avant arrêt pour l'accès aux cookies tiers: elle concerne uniquement l'accès au stockage.

En tant que solution à long terme pour faire face à certains cas d'utilisation interrompus par le partitionnement du stockage tiers sans cookies, Chrome propose aux tiers de demander l'accès aux espaces de stockage et de communication (cookies ou non) via l'API Storage Access (shipping à partir de Chrome 117), qui permet déjà à des tiers de demander l'accès aux cookies.

À partir de Chrome 120, cette proposition sera disponible pour les tests via une phase d'évaluation. Les développeurs doivent participer à cette phase d'évaluation pour évaluer la façon dont la solution proposée répond à leurs cas d'utilisation et s'assurer qu'ils sont préparés avant la fin de l'évaluation avant arrêt.

Détails de l'essai Origin Trial

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

Mécanique

L'API peut être utilisée comme suit (JavaScript s'exécutant 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 souhaitez uniquement accéder à une API spécifique plutôt qu'à all, vous pouvez transmettre uniquement les noms des identifiants d'API dont vous avez besoin. Par exemple, vous pouvez transmettre {sessionStorage: true} pour n'accéder qu'au stockage de session, ou {indexedDB: true, locks:true} pour accéder à IndexedDB et aux verrous Web.

Au-delà de l'appel de cette extension supplémentaire, l'accès au stockage autre que les cookies correspondrait aux exigences actuelles en matière d'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 pour les ensembles internes). Les origines qui ne font pas partie du même RWS seront soumises aux exigences de requête de l'API Storage Access dans Chrome.

Durée

La phase d'évaluation sera disponible de Chrome 120 à Chrome 125 (ou après le 6 août 2024).

Champ d'application

Seuls le stockage DOM (stockage de session et local), les bases de données indexées et les verrouillages Web sont disponibles dans Chrome 120.

Le stockage du cache, le système de fichiers privé d'origine, les quotas, le stockage Blob et la chaîne de diffusion ont été ajoutés dans Chrome 121.

Les travailleurs 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 (il n'est pas nécessaire d'utiliser le handle de l'API Storage Access).

Participer

  1. Évaluez la façon dont vous utilisez le stockage de cookies et d'autres types de 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'indicateur test-third-party-cookie-phaseout est activé.
  3. Si vous souhaitez tester la fonctionnalité localement sans configurer d'abord un jeton d'évaluation d'origine, vous pouvez activer #enable-experimental-web-platform-features dans votre navigateur.
    1. Une fois les tests en local terminés, vous pouvez vous inscrire à la phase d'évaluation StorageAccessAPIBeyondCookies et obtenir un jeton pour vos domaines. Pour en savoir plus, consultez Premiers pas avec les phases d'évaluation. Le guide de dépannage des problèmes liés aux phases d'évaluation de Chrome fournit une checklist complète pour vous assurer que votre jeton est correctement configuré.
    2. Intégrez ce jeton d'essai dans l'iFrame dont vous avez besoin pour utiliser le handle de l'API Storage Access, à l'aide d'un en-tête HTTP, d'une balise Meta HTML ou de façon programmatique. Notez que le jeton doit être intégré par tout frame qui souhaite utiliser cette API. Son intégration dans le frame parent ne permet pas d'activer l'API dans les frames enfants.
  4. Appelez document.requestStorageAccess(...) pour obtenir le handle de l'API Storage Access dans l'iFrame intersite. Consultez la documentation de l'API Storage Access pour connaître les conditions requises pour que cet appel aboutisse.
  5. Migrez l'espace de stockage associé dans votre iFrame pour utiliser le handle de l'API Storage Access, s'il est disponible. Par exemple, les appels à window.sessionStorage.setItem(...) deviennent handle.sessionStorage.setItem(...).
  6. Ouvrez votre site Web et vérifiez que le handle d'accès au stockage fonctionne comme prévu.
  7. Pour ne plus participer à la phase d'évaluation, supprimez le jeton que vous avez ajouté à l'étape 3.
  8. Envoyez vos commentaires ou signalez des problèmes que vous rencontrez sur le dépôt GitHub de l'API Storage Access sans stockage de cookies.

Démonstration: Utiliser l'API Storage Access pour accéder à un 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 une version ultérieure avec l'indicateur test-third-party-cookie-phaseout activé.

Ressources supplémentaires