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 apporte 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 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 ne concerne que 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. 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

À 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

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 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

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 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 d'origine privé, 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 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 version 120 (ou 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 les tests en local terminés, vous pouvez register à la phase d'évaluation 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 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 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 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