SharedArrayBuffer funktioniert im Browser endlich wieder, aber nur, wenn eine Seite cross-origin isoliert ist – ein Zustand, der zwei Response-Header erfordert. Das Hinzufügen dieser Header zwang mich dazu, jedes Drittanbieter-Skript auf meiner Seite zu entfernen, ein Schritt, der den Aufbau des gesamten Frontends und die Art der Daten, die es preisgibt, grundlegend verändert hat.

Warum die Header wichtig sind

SharedArrayBuffer ermöglicht echtes Multithreading in JavaScript, eine Voraussetzung für das Ausführen von ffmpeg in einem Tab. Moderne Browser haben die Funktion nach den Mitigations im Stil von Spectre wieder aktiviert, aber sie haben sie an die Cross-Origin-Isolation gekoppelt. Um diese Isolation zu erreichen, muss ein Server Folgendes senden:

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

Der zweite Header, require-corp, teilt dem Browser mit, dass jede externe Ressource entweder einen Cross-Origin-Resource-Policy-Header tragen oder per CORS (Cross-Origin Resource Sharing) abgerufen werden muss. Die meisten Drittanbieter-Dienste setzen diese Header nicht, weshalb deren Skripte, Schriftarten und iframes schlichtweg blockiert werden.

Was wegfiel, als die Isolation aktiviert wurde

In dem Moment, als die Header live gingen, trat eine Kaskade von Fehlern auf:

  • Analytics – die meisten Anbieter laden ihren Tracking-Code über ein einfaches <script>, das eine No-CORS-Anfrage stellt. Ohne einen CORP-Header wird die Anfrage abgelehnt, sodass der Tracker nie ausgeführt wird.
  • Google Fonts – das Stylesheet wird ohne CORS von fonts.googleapis.com abgerufen. Der Browser verwirft es, wodurch die Seite ohne ihre benutzerdefinierte Typografie bleibt.
  • Eingebettete Medien – YouTube-iframes und Widget-Skripte verfügen über kein CORP, weshalb sie nicht mehr gerendert werden.
  • OAuth-Popups – die window.opener-Beziehung wird durch die strikte Same-Origin-Policy unterbrochen, was den üblichen Popup-basierten Login-Flow zerstört.

Kurz gesagt: Jedes Asset, das auf eine Drittanbieter-Domain angewiesen war, verschwand, es sei denn, diese Domain hat sich für das neue Header-Regime entschieden.

Neukonstruktion ohne Zwischenhändler

Angesichts einer defekten Website habe ich den Frontend-Stack auf selbst gehostete Assets umgeschrieben:

  • Schriftarten und Bilder werden nun von meiner eigenen Origin ausgeliefert, was externe Stylesheets überflüssig macht.
  • Daten-APIs basieren auf einem privaten Backend, das ich kontrolliere, sodass jede Anfrage innerhalb meiner Domain bleibt.
  • Analytics wurden in einen winzigen Cloudflare Worker umgewandelt, der POST-Events akzeptiert und sie in einem privaten Bucket speichert. Die Client-Seite besteht nur aus einem Dutzend Zeilen Fetch-Code.
  • Fehlerberichterstattung und Session-Replay-Tools wie Sentry wurden komplett entfernt; jeder Absturz wird nun an meinen eigenen Endpunkt protokolliert.

Falls eine externe Ressource weiterhin benötigt wird, ist der einzige gangbare Weg, sie über einen eigenen Server zu proxien und den erforderlichen CORP-Header hinzuzufügen, bevor der Browser sie sieht.

Datenschutzgewinne versus Betriebskosten

Der unmittelbare Vorteil ist klar: Die Website gibt keine Nutzungsdaten mehr an Werbenetzwerke, Schriftanbieter oder Videoplattformen preis. Die gesamte Telemetrie bleibt unter meiner Kontrolle, und ich kann sie jederzeit löschen. Dieses Maß an Datenschutz ist mit einem typischen Drittanbieter-Stack schwer zu erreichen.

Der Nachteil ist der zusätzliche Wartungsaufwand. Das Hosting von Schriftarten, die Verwaltung der Analytics-Speicherung und das Aktualisieren eines Proxys sind Aufgaben, die die meisten Entwickler an spezialisierte Dienste auslagern. Dieser Ansatz bedeutet auch den Verzicht auf Funktionen, die diese Dienste bieten – zum Beispiel Echtzeit-Fehleraggregation oder detaillierte Funnel-Visualisierungen.

Gegenargument: Wird sich das Ökosystem anpassen?

Einige argumentieren, dass Drittanbieter schließlich die erforderlichen Header hinzufügen werden, was die Einführung der Cross-Origin-Isolation mühelos machen würde. Einige tun dies bereits, aber die Mehrheit der weit verbreiteten Dienste tut es noch nicht. Bis das Ökosystem nachzieht, müssen Entwickler entscheiden, ob der Datenschutzvorteil den technischen Aufwand für das Self-Hosting rechtfertigt.

So verifizieren Sie, dass Sie wirklich isoliert sind

Bevor Sie mit dem Umschreiben beginnen, stellen Sie sicher, dass der Browser Ihre Seite als isoliert erkennt:

crossOriginIsolated   // should be true
typeof SharedArrayBuffer   // should be "function"

Falls eine der Prüfungen fehlschlägt, werden die Header nicht korrekt angewendet, und SharedArrayBuffer wird weiterhin nicht verfügbar sein.

Was steht als Nächstes für Entwickler an?

Da immer mehr Web-Apps den Performance-Schub durch Multithreading in JavaScript suchen, wird der Druck auf Drittanbieter steigen, CORP zu übernehmen. In der Zwischenzeit sollte jedes Projekt, das SharedArrayBuffer benötigt, eine Strategie für selbst gehostete Assets oder eine leichtgewichtige Proxy-Schicht planen. Es wird zudem wichtig sein, die Release Notes der Browser auf Änderungen der Isolationsanforderungen zu beobachten.

Fazit: Die Aktivierung der Cross-Origin-Isolation, um SharedArrayBuffer freizuschalten, erzwingt eine schwierige Entscheidung – den Komfort von Drittanbieter-Skripten beizubehalten oder ihn gegen ein strengeres, selbst kontrolliertes Datenschutzmodell einzutauschen. Diese Entscheidung gestaltet sowohl die technische Architektur als auch den Datenfluss-Fußabdruck moderner Websites neu.