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, damit sie auch nach Chrome 95 weiterhin verwendet werden 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. Seit Kurzem verarbeitet Chrome diese Probleme in detaillierteren Einheiten: Ursprüngen. Wir nennen es an Ursprünge gebundenes Agent-Clustering. Da dies jedoch ressourcenintensiv ist, wurden an Ursprünge gebundene Agent-Cluster heuristisch nur auf begrenzte 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 über postMessage() keine WebAssembly.Module-Objekte mehr an andere ursprungsü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üssel.

Weitere Informationen zu an Ursprünge gebundenen Agent-Clustern finden Sie unter Leistungsisolation mit dem Header „Origin-Agent-Cluster“ anfordern.

Weitere Informationen und Ressourcen

Damit Chrome standardmäßig mit Clustern von Kundenservicemitarbeitern mit Herkunftsschlüssel funktioniert, wird document.domain schreibgeschützt. Das Chrome-Team möchte diese Änderung im Laufe des Jahres 2022 umsetzen.

Foto von Markus Winkler auf Unsplash