Restricting Wasm module sharing to same-origin

Sharing a WebAssembly module between same-site environments will be restricted to just same-origin.

Sharing a WebAssembly (Wasm) module between same-site but cross-origin environments will be deprecated to allow agent clusters to be scoped to origins long term. Developers who are using Wasm modules in such a way must make sure to instantiate those modules at the same-origin to continue using them after Chrome 95.

What are Wasm modules and how they work

WebAssembly programs are organized into modules, which are the unit of deployment, loading, and compilation.

In the following example code, a Wasm module imported from is shared with via postMessage(). Notice these domains are same-site but cross-origin.

Wasm module on

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

Starting from Chrome 95, the sender and the receiver must be the same-origin. In the above case, needs to be or the other way around.

Why this is needed

Chrome has been internally handling different documents, tabs, and frames on site-keyed agent clusters. This means the same-site documents are handled within the same process (how exactly this works varies per browser). Recently, Chrome started to handle them in more fine grained units: origins. We call it origin-keyed agent clusters. However, because doing so is resource expensive, origin-keyed agent clusters were applied only to limited websites heuristically.

The plan is to make all agent clusters origin-keyed by default. In order to achieve this, we need to restrict the capabilities that require site-keyed origin clusters:

  • (Chrome-only) You can no longer send SharedArrayBuffer or WebAssembly.Memory objects to other same-site cross-origin pages. This is already in place since Chrome 92.
  • You can no longer send WebAssembly.Module objects to other same-site cross-origin pages via postMessage(). This change is explained in more detail below..
  • You can no longer set document.domain. This is a legacy feature that normally allows same-site cross-origin pages to synchronously access each other's DOM, but in origin-keyed agent clusters, it is disabled.

By addressing all above changes, Chrome will move to use origin-keyed agent clusters by default.

To learn more about origin-keyed agent clusters, see Requesting performance isolation with the Origin-Agent-Cluster header.

Next steps and resources

In order to make Chrome work with origin-keyed agent clusters by default, we'll make document.domain read only. The Chrome team is aiming to land this change sometime in 2022.

Photo by Markus Winkler on Unsplash