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

Jake Archibald
Jake Archibald
X Startseite
Eiji Kitamura

SharedArrayBuffer hatte einen etwas holprigen Start im Web, aber die Dinge beruhigen sich. Dazu sollten Sie Folgendes wissen:

Kurz zusammengefasst

  • SharedArrayBuffer wird derzeit in Firefox 79+ unterstützt und ist in Android Chrome 88 verfügbar. Sie ist jedoch nur für Seiten verfügbar, die ursprungsübergreifend isoliert sind.
  • SharedArrayBuffer ist derzeit in der Desktopversion von Chrome verfügbar, ab Chrome 92 jedoch nur noch auf ursprungsübergreifend isolierten Seiten. Wenn Sie diese Änderung nicht rechtzeitig vornehmen können, können Sie sich für einen Origin-Trial registrieren, um das aktuelle Verhalten bis mindestens Chrome 113 beizubehalten.
  • Wenn Sie die ursprungsübergreifende Isolation aktivieren möchten, um SharedArrayBuffer weiterhin zu verwenden, sollten Sie die Auswirkungen auf andere ursprungsübergreifende Elemente auf Ihrer Website, z. B. Anzeigen-Placements, prüfen. Prüfen Sie, ob SharedArrayBuffer von einer Ihrer Drittanbieterressourcen verwendet wird, um die Auswirkungen und Anleitungen zu verstehen.

Ursprungsübergreifende Isolierung – Übersicht

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

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

Danach kann Ihre Seite nur noch dann Inhalte aus anderen Quellen laden, wenn die Ressource dies explizit über einen Cross-Origin-Resource-Policy-Header oder CORS-Header (Access-Control-Allow-* usw.) zulässt.

Außerdem gibt es eine Reporting API, mit der Sie Daten zu Anfragen erfassen können, die aufgrund von Cross-Origin-Embedder-Policy und Cross-Origin-Opener-Policy fehlgeschlagen sind.

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

Weitere Informationen zur ursprungsübergreifenden Isolation finden Sie unten auf dieser Seite im Abschnitt Weitere Informationen.

Wie kam es dazu?

SharedArrayBuffer wurde in Chrome 60 eingeführt (Juli 2017 für alle, die Zeit lieber in Datumsangaben als in Chrome-Versionen messen). Für 6 Monate.

Im Januar 2018 wurde eine Sicherheitslücke in einigen beliebten CPUs aufgedeckt. Weitere Informationen finden Sie in der Ankündigung. Im Wesentlichen bedeutete dies, dass Code hochauflösende Zeitgeber verwenden konnte, um Speicher zu lesen, auf den er keinen Zugriff haben sollte.

Das war ein Problem für uns Browseranbieter, 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 kontrollieren möchten. Wenn Sie auf meine Website gelangen, sollte ich nichts von der Onlinebanking-Website lesen können, die Sie ebenfalls geöffnet haben. Ich sollte nicht einmal wissen, dass Sie die Website für Ihr Onlinebanking geöffnet haben. Das sind die Grundlagen der Websicherheit.

Um dieses Problem zu beheben, haben wir die Auflösung unserer Timer mit hoher Auflösung wie performance.now() reduziert. Sie können jedoch einen hochauflösenden Timer erstellen, indem Sie mit SharedArrayBuffer den Arbeitsspeicher in einer engen Schleife in einem Worker ändern und ihn in einem anderen Thread wieder lesen. Dieses Problem konnte nicht effektiv behoben werden, ohne dass gut gemeinter Code stark beeinträchtigt wurde. Daher wurde SharedArrayBuffer vollständig deaktiviert.

Eine allgemeine Maßnahme besteht darin, dafür zu sorgen, dass der Systemprozess einer Webseite keine sensiblen Daten aus anderen Quellen enthält. Chrome setzte von Anfang an auf eine Architektur mit mehreren Prozessen (erinnern Sie sich an den Comic?). Es gab jedoch Fälle, in denen Daten von mehreren Websites im selben 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 „Legacy“-Verhalten, das die Verwendung von Inhalten aus anderen Quellen ohne Opt-in der anderen Quelle ermöglicht. Diese Anfragen werden mit den Cookies des anderen Ursprungs gesendet. Es handelt sich also um eine vollständige Anfrage mit Anmeldung. Heutzutage müssen neue APIs den anderen Ursprung über CORS aktivieren.

Wir haben diese Legacy-APIs umgangen, indem wir verhindert haben, dass Inhalte in den Prozess der Webseite gelangen, wenn sie „falsch“ aussahen. Wir haben das Cross-Origin Read Blocking genannt. In den oben genannten Fällen würden wir also nicht zulassen, dass JSON in den Prozess einfließt, da es für keine dieser APIs ein gültiges Format ist. Das gilt nicht für iFrames. Bei iFrames wird der Inhalt in einem separaten Prozess platziert.

Nachdem wir diese Maßnahmen ergriffen hatten, führten wir SharedArrayBuffer in Chrome 68 (Juli 2018) wieder ein, allerdings nur auf dem Computer. Die zusätzlichen Prozessanforderungen haben dazu geführt, dass wir das auf Mobilgeräten nicht umsetzen konnten. Es wurde auch darauf hingewiesen, dass die Lösung von Chrome unvollständig war, da wir nur „falsche“ Datenformate blockiert haben. Es ist jedoch möglich (wenn auch ungewöhnlich), dass gültige CSS-/JS-/Bilddateien unter erratbaren URLs private Daten enthalten.

Webstandardexperten haben sich zusammengetan, um eine umfassendere browserübergreifende Lösung zu entwickeln. Die Lösung bestand darin, Seiten die Möglichkeit zu geben, zu erklären: „Ich verzichte hiermit auf die Möglichkeit, Inhalte anderen Ursprungs ohne deren Einwilligung in diesen Prozess einzubeziehen.“ Diese Deklaration erfolgt über COOP- und COEP-Header, die mit der Seite bereitgestellt werden. Der Browser erzwingt dies und im Gegenzug erhält die Seite Zugriff auf SharedArrayBuffer und andere APIs mit ähnlichen Berechtigungen. Andere Quellen können das Einbetten von Inhalten über Cross-Origin-Resource-Policy oder CORS aktivieren.

Firefox war der erste Browser, in dem SharedArrayBuffer mit dieser Einschränkung ausgeliefert wurde, nämlich in Version 79 (Juli 2020).

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

Und das ist der aktuelle Stand. In Chrome 88 wird SharedArrayBuffer für Android für ursprungsübergreifend isolierte Seiten wieder eingeführt. In Chrome 92 werden dieselben Anforderungen für Desktop-Computer eingeführt, sowohl aus Gründen der Konsistenz als auch um eine vollständige ursprungsübergreifende Isolierung zu erreichen.

Änderung bei Desktop-Chrome verzögern

Dies ist eine vorübergehende Ausnahme in Form eines „Origin-Trials“, die Nutzern mehr Zeit für die Implementierung von ursprungsübergreifend isolierten Seiten gibt. Sie ermöglicht SharedArrayBuffer, ohne dass die Seite ursprungsübergreifend isoliert sein muss. Die Ausnahme läuft in Chrome 113 aus und gilt nur für Desktop-Chrome.

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

Weitere Informationen

Bannerfoto von Daniel Gregoire auf Unsplash