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

Jake Archibald
Jake Archibald
X Startseite
Eiji Kitamura

SharedArrayBuffer hat es im Web nicht leicht gehabt, aber die Lage beruhigt sich langsam. Dazu sollten Sie Folgendes wissen:

Kurz zusammengefasst

  • SharedArrayBuffer wird derzeit in Firefox 79 und höher unterstützt und wird in Android Chrome 88 eingeführt. 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 seiten, die ursprungsübergreifend isoliert sind. Wenn Sie diese Änderung nicht rechtzeitig vornehmen können, können Sie sich für einen Testzeitraum für den Ursprung anmelden, um das aktuelle Verhalten bis mindestens Chrome 113 beizubehalten.
  • Wenn Sie die plattformübergreifende Isolation aktivieren möchten, um SharedArrayBuffer weiterhin zu verwenden, sollten Sie die Auswirkungen auf andere plattformübergreifende Elemente auf Ihrer Website wie Anzeigen-Placements prüfen. Prüfen Sie, ob SharedArrayBuffer von Ihren Drittanbieterressourcen verwendet wird, um die Auswirkungen und Empfehlungen zu verstehen.

Ursprungsübergreifende Isolierung – Übersicht

Sie können eine Seite ursprüngsübergreifend isolieren, indem Sie sie mit den folgenden Headern ausliefern:

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

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

Außerdem gibt es eine Reporting API, mit der du Daten zu Anfragen erheben kannst, 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 Origin-Test registrieren, um das aktuelle Verhalten von Chrome auf dem Computer bis mindestens Chrome 113 beizubehalten.

Im Abschnitt Weitere Informationen unten auf dieser Seite finden Sie weitere Anleitungen und Informationen zur plattformübergreifenden Isolation.

Wie kam es dazu?

SharedArrayBuffer wurde in Chrome 60 eingeführt (Juli 2017, für diejenigen, die Zeit lieber in Datumsangaben als in Chrome-Versionen denken). Alles war in Ordnung. Für 6 Monate.

Im Januar 2018 wurde eine Sicherheitslücke in einigen beliebten CPUs entdeckt. Ausführliche Informationen finden Sie in der Ankündigung. Im Wesentlichen bedeutete das, dass Code mithilfe von hochauflösenden Timern Speicher lesen konnte, auf den er keinen Zugriff haben sollte.

Das war für uns als Browseranbieter 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 kontrollieren möchten. Wenn Sie meine Website aufrufen, sollte ich nichts von der Onlinebanking-Website sehen können, die Sie ebenfalls geöffnet haben. Eigentlich sollte ich gar nicht wissen, dass Sie Ihre Internetbanking-Website geöffnet haben. Dies sind die Grundlagen der Websicherheit.

Um dies zu vermeiden, haben wir die Auflösung unserer hochauflösenden Timer wie performance.now() reduziert. Sie können jedoch einen create mit SharedArrayBuffer erstellen, indem Sie den Arbeitsspeicher in einer engen Schleife in einem Worker ändern und in einem anderen Thread wieder lesen. Da sich das Problem nicht effektiv beheben ließ, ohne dass gut gemeinter Code stark beeinträchtigt wurde, wurde SharedArrayBuffer vollständig deaktiviert.

Eine allgemeine Maßnahme besteht darin, dafür zu sorgen, dass der Systemprozess einer Webseite keine vertraulichen Daten von anderen Stellen enthält. Chrome hatte von Anfang an in eine mehrstufige Architektur investiert (erinnern Sie sich an das Comic?). Es gab jedoch immer noch 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 „altes“ Verhalten, das die Verwendung von Inhalten aus anderen Ursprüngen ohne Einwilligung des anderen Ursprungs ermöglicht. Diese Anfragen werden mit den Cookies des anderen Ursprungs gesendet. Es handelt sich also um eine vollständige Anfrage im „angemeldet“-Status. Bei neuen APIs muss der andere Ursprung heutzutage CORS aktivieren.

Wir haben diese alten APIs umgangen, indem wir verhindert haben, dass Inhalte in den Prozess der Webseite aufgenommen wurden, wenn sie „falsch“ aussahen. Wir haben diese Funktion Cross-Origin Read Blocking genannt. In den oben genannten Fällen würden wir JSON nicht in den Prozess aufnehmen, da es für keine dieser APIs ein gültiges Format ist. Das gilt nicht für iFrames. Bei Iframes werden die Inhalte in einem anderen Prozess verarbeitet.

Nachdem wir diese Maßnahmen ergriffen hatten, haben wir SharedArrayBuffer in Chrome 68 (Juli 2018) wieder eingeführt, aber nur auf dem Computer. Aufgrund der zusätzlichen Prozessanforderungen war dies auf Mobilgeräten nicht möglich. Außerdem wurde darauf hingewiesen, dass die Lösung von Chrome unvollständig ist, da wir nur „falsche“ Datenformate blockieren. Es ist jedoch möglich (wenn auch ungewöhnlich), dass gültige CSS-/JS-/Bilderdateien unter ermittelbaren URLs personenbezogene Daten enthalten.

Die Webstandards-Experten haben sich zusammengesetzt, um eine umfassendere plattformübergreifende Lösung zu entwickeln. Die Lösung bestand darin, Seiten die Möglichkeit zu geben, zu erklären, dass sie Inhalte anderer Herkunft in diesen Prozess ohne deren Einwilligung einbeziehen dürfen. Diese Erklärung erfolgt über COOP- und COEP-Header, die mit der Seite ausgeliefert werden. Der Browser erzwingt dies und im Gegenzug erhält die Seite Zugriff auf SharedArrayBuffer und andere APIs mit ähnlichen Berechtigungen. Andere Ursprünge können das Einbetten von Inhalten über Cross-Origin-Resource-Policy oder CORS aktivieren.

Firefox war der erste Browser, der SharedArrayBuffer mit dieser Einschränkung in Version 79 (Juli 2020) eingeführt hat.

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

Und genau hier sind wir jetzt. In Chrome 88 wird SharedArrayBuffer für Android-Seiten mit ursprungsübergreifender Isolierung wieder eingeführt. In Chrome 92 werden dieselben Anforderungen auf Computern eingeführt, um für Einheitlichkeit zu sorgen und eine vollständige ursprungsübergreifende Isolierung zu erreichen.

Änderung für Chrome auf dem Computer verschieben

Dies ist eine vorübergehende Ausnahme in Form eines „Ursprungstests“, der Entwicklern 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 ab und gilt nur für Chrome auf dem Computer.

  1. Fordere ein Token für deinen Ursprung an.
  2. Fügen Sie das Token Ihren Seiten hinzu. Dafür gibt es zwei Möglichkeiten:
    • Fügen Sie dem Header jeder Seite ein origin-trial <meta>-Tag hinzu. Das könnte beispielsweise so aussehen:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Wenn Sie Ihren Server konfigurieren können, können Sie das Token auch über einen 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