Restreindre le partage de modules Wasm à la même origine

Le partage d'un module WebAssembly entre des environnements de même site sera limité à la même origine.

Eiji Kitamura

Le partage d'un module WebAssembly (Wasm) entre des environnements sur un même site, mais multi-origines sera abandonné pour permettre aux clusters d'agents d'être limités aux origines à long terme. Les développeurs qui utilisent des modules Wasm de cette manière doivent s'assurer d'instancier ces modules à la même origine pour continuer à les utiliser après Chrome 95.

Qu'est-ce qu'un module Wasm et comment fonctionne-t-il ?

Les programmes WebAssembly sont organisés en modules, qui constituent l'unité de déploiement, de chargement et de compilation.

Dans l'exemple de code suivant, un module Wasm importé depuis https://iframe.site.example est partagé avec https://main.site.example via postMessage(). Notez que ces domaines sont du même site, mais d'origine différente.

Module Wasm sur https://iframe.site.example:

(async () => {
  const instance = await WebAssembly.instantiateStreaming(fetch('./add.wasm'), {});
  iframe.contentWindow.postMessage(instance.module, `https://main.site.example`);
})();

À partir de Chrome 95, l'émetteur et le destinataire doivent être de la même origine. Dans le cas ci-dessus, https://iframe.site.example doit être https://main.site.example ou inversement.

Pourquoi est-ce nécessaire ?

Chrome gérait en interne différents documents, onglets et cadres sur des clusters d'agents basés sur des clés de site. Cela signifie que les documents du même site sont gérés dans le même processus (le fonctionnement exact varie selon le navigateur). Récemment, Chrome a commencé à les gérer dans des unités plus précises: les origines. Nous les appelons clusters d'agents selon l'origine. Toutefois, comme cette opération est coûteuse en ressources, les clusters d'agents basés sur l'origine n'étaient appliqués que de manière heuristique à un nombre limité de sites Web.

L'objectif est de faire en sorte que tous les clusters d'agents soient configurés par défaut avec un clé d'origine. Pour ce faire, nous devons limiter les fonctionnalités qui nécessitent des clusters d'origine avec clé de site:

  • (Chrome uniquement) Vous ne pouvez plus envoyer d'objets SharedArrayBuffer ou WebAssembly.Memory à d'autres pages multi-origines sur le même site. Cette fonctionnalité est déjà en place depuis Chrome 92.
  • Vous ne pouvez plus envoyer d'objets WebAssembly.Module à d'autres pages multi-origines sur le même site via postMessage(). Ce changement est expliqué plus en détail ci-dessous.
  • Vous ne pouvez plus définir document.domain. Il s'agit d'une ancienne fonctionnalité qui permet normalement aux pages multi-origines sur le même site d'accéder de manière synchrone au DOM de l'autre, mais dans les clusters d'agents basés sur l'origine, elle est désactivée.

En prenant en compte toutes les modifications ci-dessus, Chrome passera à l'utilisation de clusters d'agents avec clé d'origine par défaut.

Pour en savoir plus sur les clusters d'agents basés sur l'origine, consultez Demander l'isolation des performances avec l'en-tête Origin-Agent-Cluster.

Étapes suivantes et ressources

Pour que Chrome fonctionne avec des clusters d'agents basés sur l'origine par défaut, nous allons rendre document.domain en lecture seule. L'équipe Chrome prévoit de déployer cette modification dans le courant de l'année 2022.

Photo de Markus Winkler sur Unsplash