SharedArrayBuffer-Updates in Android Chrome 88 und Chrome 92 für Computer

Jake Archibald
Jake Archibald
X Startseite
Eiji Kitamura

Man kann gut sagen, dass es SharedArrayBuffer im Web noch nicht ganz sicher ist, aber die Lage hat sich gerade beruhigt. Dazu sollten Sie Folgendes wissen:

Kurz zusammengefasst

  • SharedArrayBuffer wird derzeit in Firefox 79 und höher unterstützt und wird in Chrome 88 verfügbar sein. Er ist jedoch nur für Seiten verfügbar, die ursprungsübergreifend isoliert sind.
  • SharedArrayBuffer ist derzeit in der Desktopversion von Chrome verfügbar, wird aber ab Chrome 92 auf ursprungsübergreifende Seiten beschränkt. Wenn Sie der Meinung sind, dass Sie diese Änderung nicht rechtzeitig vornehmen können, können Sie sich für einen Ursprungstest registrieren, um das aktuelle Verhalten bis mindestens Chrome 113 beizubehalten.
  • Wenn Sie die ursprungsübergreifende Isolierung weiterhin aktivieren möchten, um SharedArrayBuffer weiter zu verwenden, sollten Sie die Auswirkungen auf andere ursprungsübergreifende Elemente auf Ihrer Website prüfen, z. B. Anzeigen-Placements. Prüfe, ob SharedArrayBuffer von Ressourcen von Drittanbietern verwendet wird, um die Auswirkungen und Hinweise zu verstehen.

Cross-Origin Isolation – Übersicht

Sie können eine Seite ursprungsübergreifend isoliert machen, indem Sie sie mit den folgenden Headern bereitstellen:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Danach können auf Ihrer Seite keine ursprungsübergreifenden Inhalte geladen werden, es sei denn, die Ressource lässt dies ausdrücklich über einen Cross-Origin-Resource-Policy-Header oder CORS-Header (Access-Control-Allow-* usw.) zu.

Mit der Reporting API können Sie Daten zu Anfragen erfassen, die aufgrund von Cross-Origin-Embedder-Policy und Cross-Origin-Opener-Policy fehlgeschlagen sind.

Wenn Sie der Meinung sind, dass Sie diese Änderungen nicht rechtzeitig für Chrome 92 vornehmen können, können Sie sich für einen Ursprungstest registrieren, um das aktuelle Chrome-Verhalten bis mindestens Chrome 113 beizubehalten.

Im Abschnitt Weitere Informationen unten auf dieser Seite findest du weitere Anleitungen und Informationen zur ursprungsübergreifenden Isolierung.

Wie haben wir das erreicht?

SharedArrayBuffer ist jetzt in Chrome 60 verfügbar (also Juli 2017 – für alle, die nicht auf Chrome-Versionen, sondern auf Zeiträume denken) und alles hat gut geklappt. 6 Monate lang.

Im Januar 2018 wurde bei einigen beliebten CPUs eine Sicherheitslücke entdeckt. Ausführliche Informationen finden Sie in der Mitteilung. Grundsätzlich bedeutete sie aber, dass der Code hochauflösende Timer zum Lesen des Arbeitsspeichers verwenden konnte, auf die er keinen Zugriff haben sollte.

Dies war für uns Browser-Anbieter ein Problem, da wir Websites erlauben möchten, Code in Form von JavaScript und WASM auszuführen, aber den Speicher, auf den dieser Code zugreifen kann, streng zu kontrollieren. Wenn Sie auf meine Website gelangen, sollte ich nichts von der ebenfalls geöffneten Onlinebanking-Website lesen können. Eigentlich sollte ich gar nicht wissen, dass Sie Ihre Online-Banking-Website geöffnet haben. Dies sind die Grundlagen der Websicherheit.

Um dieses Problem zu umgehen, haben wir die Auflösung unserer hochauflösenden Timer wie performance.now() reduziert. Sie können jedoch mit SharedArrayBuffer einen Timer mit hoher Auflösung erstellen, indem Sie den Arbeitsspeicher in einer engen Schleife in einem Worker ändern und ihn in einem anderen Thread auslesen. Dies ließ sich nur wirksam vermeiden, ohne dass sich dies stark auf den gut beabsichtigten Code auswirkt. Daher wurde SharedArrayBuffer vollständig deaktiviert.

Im Allgemeinen sollten Sie darauf achten, dass der Systemprozess einer Webseite keine sensiblen Daten von anderen Quellen enthält. Chrome hatte von Anfang an in eine Multi-Prozess-Architektur investiert (erinnern Sie sich an den Comic?). Es gab jedoch auch Fälle, in denen Daten von mehreren Websites in denselben Prozess landeten:

<iframe src="https://your-bank.example/balance.json"></iframe>
<script src="https://your-bank.example/balance.json"></script>
<link rel="stylesheet" href="https://your-bank.example/balance.json" />
<img src="https://your-bank.example/balance.json" />
<video src="https://your-bank.example/balance.json"></video>
<!-- …and more… -->

Diese APIs haben ein „altes“ Verhalten, das ermöglicht, Inhalte aus anderen Ursprüngen zu verwenden, ohne die Zustimmung des anderen Ursprungs zu geben. Diese Anfragen werden mit den Cookies des anderen Ursprungs gestellt, sodass es sich um eine vollständige Anfrage „angemeldet“ handelt. Heutzutage muss die andere Quelle für neue APIs CORS verwenden.

Wir haben diese Legacy-APIs umgangen und dafür gesorgt, dass Inhalte nicht in den Prozess der Webseite gelangen konnten, wenn sie „falsch“ aussahen, und nannten sie ursprungsübergreifende Leseblockierung. In den oben genannten Fällen ist es also nicht zulässig, JSON in den Prozess aufzunehmen, da dieses Format für keine dieser APIs gültig ist. Mit Ausnahme von iFrames. Für iFrames wird der Inhalt in einem anderen Prozess platziert.

Damit haben wir SharedArrayBuffer in Chrome 68 (Juli 2018) wieder eingeführt, allerdings nur für Computer. Aufgrund der zusätzlichen Prozessanforderungen konnten wir das nicht auf Mobilgeräten machen. Es wurde auch festgestellt, dass die Lösung von Chrome unvollständig war, da wir nur „falsche“ Datenformate blockierten, während es zwar ungewöhnlich ist, dass gültige CSS-/JS-Dateien/Bilder unter erratenbaren URLs private Daten enthalten können.

Die Experten für Webstandards kamen zusammen, um eine umfassendere browserübergreifende Lösung zu entwickeln. Die Lösung bestand darin, Seiten die Möglichkeit zu geben, zu sagen: „Ich verzichte hiermit auf die Möglichkeit, Inhalte anderer Herkunft ohne ihre Zustimmung in diesen Prozess zu integrieren“. Diese Deklaration erfolgt über COOP- und COEP-Header, die mit der Seite bereitgestellt werden. Der Browser erzwingt dies und im Austausch erhält die Seite Zugriff auf SharedArrayBuffer und andere APIs mit ähnlichen Funktionen. Andere Ursprünge können das Einbetten von Inhalten über Cross-Origin-Resource-Policy oder CORS aktivieren.

Firefox hat in Version 79 (Juli 2020) zum ersten Mal SharedArrayBuffer mit dieser Einschränkung ausgeliefert.

Im Januar 2021 habe ich diesen Artikel geschrieben und Sie haben ihn gelesen. Hallo.

Und da sind wir jetzt. In Chrome 88 wird SharedArrayBuffer für Seiten, die ursprungsübergreifend isoliert sind, wieder in Android eingeführt. Chrome 92 stellt die gleichen Anforderungen an Computer, sowohl in Bezug auf Konsistenz als auch für eine vollständige ursprungsübergreifende Isolierung.

Änderung von Chrome auf dem Computer verzögern

Dies ist eine vorübergehende Ausnahme in Form eines „Ursprungstests“, der Nutzern mehr Zeit gibt, ursprungsübergreifende isolierte Seiten zu implementieren. Dadurch wird SharedArrayBuffer ermöglicht, ohne dass die Seite ursprungsübergreifend isoliert sein muss. Die Ausnahme läuft in Chrome 113 ab und die Ausnahme gilt nur für die Desktopversion von Chrome.

  1. Fordern Sie ein Token für Ihren Ursprung an.
  2. Fügen Sie das Token auf Ihren Seiten ein. Dafür gibt es zwei Möglichkeiten:
    • Fügen Sie im Header jeder Seite ein origin-trial <meta>-Tag ein. Das kann beispielsweise so aussehen:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Wenn Sie Ihren Server konfigurieren können, haben Sie auch die Möglichkeit, das Token mit einem Origin-Trial-HTTP-Header hinzuzufügen. Der resultierende Antwortheader sollte in etwa so aussehen:
      Origin-Trial: TOKEN_GOES_HERE

Weitere Informationen

Bannerfoto von Daniel Gregoire auf Unsplash