Participer à l'essai d'abandon pour le stockage tiers non partitionné, les service workers et les API de communication

À partir de Chrome 115, les API de stockage, de service workers et de communication sont partitionnées 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.

En plus d'une phase d'évaluation d'abandon générale du partitionnement, vous pouvez participer à une phase d'évaluation d'abandon ciblée uniquement pour window.sessionStorage. Cette phase d'évaluation est disponible, car certains sites doivent migrer leur flux Firebase signInWithRedirect. Pour en savoir plus sur cette migration, consultez les bonnes pratiques pour utiliser signInWithRedirect sur les navigateurs qui bloquent l'accès au stockage tiers.

Pour laisser aux développeurs plus de temps pour s'adapter à la nouvelle implémentation du partitionnement de l'espace de stockage, les évaluations avant arrêt seront disponibles jusqu'à la sortie de Chrome 127, prévue pour le 23 juillet 2024. L'évaluation avant arrêt expirera pour les utilisateurs de Chrome 111 à Chrome 126 le 3 septembre 2024.

Évaluations avant arrêt disponibles

Depuis Chrome 115, deux évaluations avant arrêt sont disponibles:

1. DisableThirdPartyStoragePartitioning : permet à un site de premier niveau de désintégrer (de supprimer temporairement l'isolation par site de premier niveau) les API de stockage, de service workers et de communication dans le contenu tiers intégré à ses pages.
2. DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning : permet à un site de désorganiser sessionStorage lors des navigations.

Vous trouverez ci-dessous une présentation de l'essai de l'abandon et de ce à quoi vous devez vous attendre. Si vous avez des commentaires à partager ou si vous rencontrez des problèmes au cours de ce test, veuillez nous en informer dans le dépôt GitHub de l'essai de l'abandon du stockage partitionné.

DisableThirdPartyStoragePartitioning

Les API suivantes resteront non partitionnées dans les contextes tiers si vous inscrivez le site de niveau supérieur à la phase d'évaluation de l'abandon de DisableThirdPartyStoragePartitioning : les API Storage (telles que localStorage, sessionStorage, IndexedDB, Quota, etc.), les API Communication (telles que BroadcastChannel, SharedWorkers et WebLocks) et l'API ServiceWorker.

Exemple :

Pour en savoir plus, consultez la présentation du projet.

DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning

Si vous vous inscrivez au test de l'abandon de DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning, la navigation dans un onglet vers une origine enregistrée entraînera le maintien de toutes les iFrames intersites de cette même origine non partitionnées uniquement pour Window.sessionStorage et uniquement pendant la durée de vie de cet onglet particulier. Alors que l'évaluation avant abandon de DisableThirdPartyStoragePartitioning affecte tous les contextes tiers intégrés à l'origine enregistrée, l'évaluation avant abandon de DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning enregistre plutôt une origine donnée pour recevoir un accès non partitionné lorsqu'elle est intégrée à des contextes tiers.

Exemple :

Qu'est-ce que cela signifie pour les développeurs Web ?

Les sites doivent auditer leur utilisation des API de stockage, de service worker et de communication non partitionnées dans des contextes tiers, et, si nécessaire, se préparer au partitionnement tiers avant que ces phases d'évaluation d'abandon n'expirent. L'objectif est de faire expirer ces essais d'abandon avec la sortie de Chrome 127 le 3 septembre 2024.

Pour demander au navigateur de déspartitionner le stockage dans le contenu tiers intégré à ses pages, les sites de niveau supérieur doivent s'inscrire à l'un ou aux deux essais de suppression et ajouter le ou les jetons d'essai correspondants à leurs en-têtes de réponse HTTP (voir l'exemple détaillé ci-dessous).

Chaque évaluation avant arrêt est disponible sur Windows, Mac, Linux, ChromeOS et Android.

Participer aux tests de l'abandon

Vous trouverez ci-dessous un bref aperçu de la procédure à suivre pour participer à l'un ou aux deux essais de suppression. Pour obtenir des instructions plus détaillées, consultez Premiers pas avec les tests d'origine.

1. Lancez Chrome version 115 (ou ultérieure) et assurez-vous que l'indicateur ThirdPartyStoragePartitioning est activé.
2. Vérifiez que le comportement du contenu tiers intégré à votre site de premier niveau est interrompu par le partitionnement de l'espace de stockage (sinon, il n'est pas nécessaire de participer aux tests de dépréciation).
3. Inscrivez-vous au test de l'abandon et obtenez un jeton pour vos domaines en accédant à la page suivante :
   1. Pour qu'un site de premier niveau annule le partitionnement des API de stockage, de service workers et de communication dans son contenu intégré tiers : DisableThirdPartyStoragePartitioning
   2. Pour qu'un site de premier niveau désimente sessionStorage lors des navigations : DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning
4. Ajoutez un jeton de test d'origine à votre page :
   1. Pour le test DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning, vous pouvez ajouter un Origin-Trial: <DEPRECATION TRIAL TOKEN> à l'en-tête de réponse HTTP de votre site racine, où <DEPRECATION TRIAL TOKEN> contient le jeton que vous avez reçu lorsque vous vous êtes inscrit au test de l'abandon. Vous pouvez également le faire via le code HTML : .
   2. Pour le test DisableThirdPartyStoragePartitioning, le jeton doit être fourni via une balise HTML <meta> injectée via JavaScript. La méthode d'en-tête HTTP n'est pas compatible.
5. Chargez votre site Web dans Chrome 115 (ou version ultérieure) avec ThirdPartyStoragePartitioning toujours activé et vérifiez que les problèmes liés au partitionnement ont été correctement atténués.
6. Pour ne plus participer au test de l'abandon, supprimez simplement le jeton que vous avez ajouté à l'étape 2.

Le test de l'abandon de DisableThirdPartyStoragePartitioning est compatible avec la fonctionnalité de tests d'origine tiers, mais le script tiers qui injecte le jeton doit être évalué dans le frame de niveau supérieur avant le chargement de l'iFrame tiers auquel le partitionnement ne sera pas appliqué. La phase d'évaluation de l'abandon de DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning n'est pas compatible avec les phases d'évaluation d'origine tierce, car l'enrôlé doit avoir été le site de niveau supérieur à un moment donné de la durée de vie de l'onglet donné. Le guide de dépannage des tests d'origine de Chrome fournit une checklist complète pour vous assurer que votre jeton est correctement configuré.

Envoyer des commentaires

Veuillez envoyer vos commentaires ou les problèmes que vous rencontrez au dépôt GitHub de l'essai de l'abandon du stockage partitionné.