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 du même site, mais interorigines 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 de les instancier sur la même origine pour continuer à les utiliser après Chrome 95.

Présentation et fonctionnement des modules Wasm

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

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 l'inverse.

Pourquoi est-ce nécessaire ?

Chrome gère en interne différents documents, onglets et cadres sur des clusters d'agents à clé de site. Cela signifie que les documents du même site sont traité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 appelons cela des clusters d'agents selon l'origine. Toutefois, comme cette opération consomme beaucoup de ressources, le clustering d'agents selon l'origine n'a été appliqué qu'à un nombre limité de sites Web de manière heuristique.

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

  • (Chrome uniquement) Vous ne pouvez plus envoyer d'objets SharedArrayBuffer ou WebAssembly.Memory à d'autres pages interorigines du 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 interorigines 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 interorigines d'un même site d'accéder de manière synchrone au DOM de l'autre, mais elle est désactivée dans les clusters d'agents selon l'origine.

En apportant toutes les modifications ci-dessus, Chrome utilisera par défaut des clusters d'agents basés sur l'origine.

Pour en savoir plus sur les clusters d'agents selon l'origine, consultez 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 les clusters d'agents selon l'origine, nous allons définir document.domain en lecture seule. L'équipe Chrome prévoit d'implémenter ce changement en 2022.

Photo de Markus Winkler sur Unsplash