Chrome 130 apporte des modifications à l'API Shared Storage pour permettre l'utilisation de scripts de worklet inter-origines avec createWorklet() et addModule(). Nous apportons également des modifications à l'API Select URL avec Shared Storage dans Chrome 132, avec la prise en charge des requêtes enregistrées.
Worklets inter-origines avec l'API Shared Storage dans Chrome 130
Nous avons apporté des modifications à l'API Shared Storage dans Chrome 130 pour vous offrir plus de flexibilité lorsque vous travaillez avec des scripts de worklet inter-origines.
Modifications apportées
Nous avons supprimé la restriction de même origine pour addModule() afin que vous puissiez désormais charger des scripts de worklet à partir de n'importe quelle origine. Les scripts de worklet inter-origines permettent d'utiliser des cas d'utilisation clés, tels que l'hébergement de scripts de worklet sur des CDN. Lorsque le script de worklet est multi-origine par rapport au contexte de navigation qui l'appelle, l'origine du contexte d'appel est utilisée comme origine de la partition de données pour accéder au stockage partagé.
Pour correspondre au nouveau comportement de addModule() et réduire les confusions potentielles, la propriété dataOrigin a été ajoutée à l'appel createWorklet() pour permettre la lecture et l'écriture dans une partition de données de stockage partagée différente du contexte de navigation d'appel. Vous pouvez ainsi contrôler plus précisément à quel espace de stockage partagé chaque worklet accède, même lorsque vous utilisez des scripts de worklet inter-origines.
En quoi cela a-t-il changé
Depuis Chrome 125, un script multi-origine tiers sur une page peut créer des worklets multi-origines sans avoir besoin d'iFrame multi-origines en appelant createWorklet(url). Auparavant, createWorklet(url) utilisait l'origine de l'URL du script (url) comme origine de la partition de données, quel que soit le contexte d'appel.
Dans Chrome 130, pour s'aligner sur le nouveau comportement de addModule(), createWorklet() utilise également le contexte d'appel comme origine de partition de données par défaut. Pour continuer à utiliser l'origine de l'URL du script comme origine de la partition de données, une nouvelle propriété dataOrigin est introduite pour vous permettre de définir explicitement l'origine de la partition de données.
La nouvelle propriété dataOrigin accepte "script-origin", qui définit l'origine de la partition de données comme l'origine du script, et "context-origin", qui définit l'origine de la partition de données comme l'origine du contexte de navigation qui appelle. Dans une prochaine version, nous prévoyons également de prendre en charge les origines de partitionnement de données personnalisées, où un script de worklet peut accéder aux données de stockage partagé à partir d'une origine arbitraire sur une base d'activation.
Lorsque vous chargez un script inter-origine dont l'origine des données est définie sur "script-origin", la requête du script envoyée depuis le navigateur inclut un en-tête "Sec-Shared-Storage-Data-Origin: <origin>". Pour ce faire, le script doit également inclure l'en-tête de réponse d'activation "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1".
Fonctionnement
Si vous utilisez déjà createWorklet() avec l'origine du script comme origine de la partition de données du worklet, vous pouvez définir dataOrigin comme suit:
sharedStorage.createWorklet(scriptUrl, {dataOrigin: "script-origin"});
Étant donné que createWorklet() permet de créer une partition de données multi-origine et plusieurs worklets, nous vous encourageons à passer à createWorklet() plutôt qu'à utiliser addModule().
Nous avons mis à jour la documentation destinée aux développeurs pour refléter ces modifications et fournir des conseils supplémentaires.
Requêtes enregistrées avec l'API Select URL dans Chrome 132
Nous apportons des modifications à l'API Select URL avec Shared Storage dans Chrome 132, avec la prise en charge des requêtes enregistrées.
Ce qui change
L'API Select URL dispose actuellement de deux budgets par chargement de page qui limitent le nombre d'appels effectués à l'API à chaque chargement de page. Nous lançons la possibilité d'enregistrer et de réutiliser des requêtes par page. Lorsque vous utilisez une requête enregistrée, les budgets par chargement de page sont facturés la première fois qu'une requête enregistrée est exécutée, mais pas pour les exécutions ultérieures de la requête enregistrée lors du même chargement de page.
Implémenter des requêtes enregistrées
À partir de la version 132 de Chrome, vous pouvez utiliser le paramètre savedQuery dans les options de selectURL() avec le nom de la requête:
await sharedStorage.selectURL('experiment', urls, {
savedQuery: 'control_or_experiment',
keepAlive: true
});
Utilisez le même nom savedQuery pour chaque appel à selectURL() afin de vous assurer que les requêtes de suivi sont facturées au même budget.
Nous avons mis à jour la documentation pour refléter ces modifications et fournir des informations supplémentaires sur la budgétisation pour selectURL().
Interagir et envoyer des commentaires
Notez que la proposition d'API Shared Storage est en cours de discussion et de développement, et est donc susceptible d'être modifiée.
Nous sommes impatients de connaître votre avis sur l'API Shared Storage.
- Proposition: consultez la proposition détaillée.
- Discussion: rejoignez la discussion en cours pour poser des questions et partager vos insights.
Se tenir informé
- Liste de diffusion: abonnez-vous à notre liste de diffusion pour recevoir les dernières informations et annonces concernant l'API Shared Storage.
Besoin d'aide ?
- Assistance pour les développeurs: échangez avec d'autres développeurs et obtenez des réponses à vos questions dans le dépôt d'assistance pour les développeurs de la Privacy Sandbox.