Freigabe von Wasm-Modulen auf denselben Ursprung beschränken

Die Freigabe eines WebAssembly-Moduls zwischen Umgebungen auf derselben Website ist nur noch auf denselben Ursprung beschränkt.

Eiji Kitamura

Die Freigabe eines WebAssembly-Moduls (Wasm) zwischen Umgebungen derselben Website, aber mit unterschiedlichen Ursprüngen wird eingestellt, damit Kundenservicemitarbeiter-Cluster langfristig auf Ursprünge beschränkt werden können. Entwickler, die Wasm-Module auf diese Weise verwenden, müssen diese Module am selben Ursprung instanziieren, um sie auch nach Chrome 95 weiterverwenden zu können.

Was sind Wasm-Module und wie funktionieren sie?

WebAssembly-Programme sind in Modulen organisiert, die die Einheit für Bereitstellung, Laden und Kompilieren sind.

Im folgenden Beispielcode wird ein aus https://iframe.site.example importiertes Wasm-Modul über postMessage() für https://main.site.example freigegeben. Beachten Sie, dass diese Domains auf derselben Website, aber verschiedener Herkunft sind.

Wasm-Modul auf https://iframe.site.example:

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

Ab Chrome 95 müssen Absender und Empfänger aus derselben Quelle stammen. Im obigen Fall muss https://iframe.site.example zu https://main.site.example oder umgekehrt werden.

Warum ist das erforderlich?

Chrome hat intern verschiedene Dokumente, Tabs und Frames in Clustern mit Standortschlüsseln verarbeitet. Das bedeutet, dass Dokumente auf derselben Website im selben Prozess verarbeitet werden. Wie genau das funktioniert, hängt vom jeweiligen Browser ab. Vor Kurzem hat Chrome damit begonnen, sie in detaillierteren Einheiten zu verarbeiten: Ursprüngen. Wir nennen es an Ursprünge gebundenes Agent-Clustering. Da dies jedoch ressourcenintensiv ist, wurden Agentencluster mit Quellschlüsseln nur heuristisch auf eine begrenzte Anzahl von Websites angewendet.

Künftig sollen alle Kundenservicemitarbeiter-Cluster standardmäßig an Ursprünge gebunden sein. Dazu müssen wir die Funktionen einschränken, für die Ursprungscluster mit Websiteschlüssel erforderlich sind:

  • (Nur Chrome) Sie können keine SharedArrayBuffer- oder WebAssembly.Memory-Objekte mehr an andere seiteninterne, plattformübergreifende Seiten senden. Diese Funktion ist bereits seit Chrome 92 verfügbar.
  • Sie können WebAssembly.Module-Objekte nicht mehr über postMessage() an andere seitenübergreifende Seiten derselben Website senden. Diese Änderung wird unten genauer erläutert.
  • Sie können document.domain nicht mehr festlegen. Dies ist eine ältere Funktion, die normalerweise ursprungsübergreifenden Seiten auf derselben Website ermöglicht, synchron auf das DOM der jeweils anderen zuzugreifen. In an Ursprünge gebundenen Agent-Clustern ist sie jedoch deaktiviert.

Wenn alle oben genannten Änderungen vorgenommen wurden, verwendet Chrome standardmäßig Cluster von User-Agents mit Ursprungsschlüsseln.

Weitere Informationen zu Clustern mit Ursprungsschlüsseln finden Sie unter Leistungsisolation mit dem Origin-Agent-Cluster-Header anfordern.

Weitere Informationen und Ressourcen

Damit Chrome standardmäßig mit Clustern von Kundenservicemitarbeitern mit Ursprungsschlüssel funktioniert, wird document.domain schreibgeschützt. Das Chrome-Team plant, diese Änderung irgendwann im Jahr 2022 einzuführen.

Foto von Markus Winkler bei Unsplash