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

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

Eiji Kitamura

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

Présentation des modules Wasm et de leur fonctionnement

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é à partir de https://iframe.site.example est partagé avec https://main.site.example via postMessage(). Notez que ces domaines sont identiques, mais multi-origines.

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'expéditeur et le destinataire doivent avoir la même origine. Dans le cas ci-dessus, https://iframe.site.example doit être https://main.site.example, ou inversement.

Pourquoi cette étape est-elle nécessaire ?

Chrome gère en interne différents documents, onglets et cadres sur des clusters d'agents selon le site. Cela signifie que les documents du même site sont traités dans le même processus (la façon dont cela fonctionne varie selon le navigateur). Récemment, Chrome a commencé à les gérer dans des unités plus précises: les origines. Nous les appelons des clusters d'agents selon l'origine. Toutefois, étant donné que cela coûte cher en ressources, les clusters d'agents selon l'origine n'ont été appliqués qu'à des sites Web limités de manière heuristique.

L'objectif est que tous les clusters d'agents soient basés sur l'origine par défaut. Pour ce faire, nous devons limiter les capacités nécessitant des clusters d'origine selon le site:

  • (Chrome uniquement) Vous ne pouvez plus envoyer d'objets SharedArrayBuffer ni WebAssembly.Memory à d'autres pages multi-origines du même site. Cette fonctionnalité est déjà en vigueur depuis Chrome 92.
  • Vous ne pouvez plus envoyer d'objets WebAssembly.Module à d'autres pages multi-origines du 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 du même site d'accéder de manière synchrone au DOM des autres. Toutefois, elle est désactivée dans les clusters d'agents selon l'origine.

Si vous prenez en compte tous les changements ci-dessus, Chrome utilisera par défaut les clusters d'agents selon l'origine.

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

Étapes suivantes et ressources

Pour que Chrome fonctionne par défaut avec des clusters d'agents selon l'origine, document.domain est en lecture seule. L'équipe Chrome prévoit de mettre en place ce changement en 2022.

Photo de Markus Winkler sur Unsplash