SharedArrayBuffer werkt eindelijk weer in de browser, maar dat is alleen als een pagina cross-origin geïsoleerd is – een staat die twee response headers vereist. Het toevoegen van die headers dwong me om elk third-party-script op mijn site te verwijderen, een stap die de manier waarop de hele front-end is opgebouwd en welke data er lekt, volledig heeft veranderd.

Waarom de headers belangrijk zijn

SharedArrayBuffer maakt echt multithreading in JavaScript mogelijk, een vereiste voor het draaien van ffmpeg in een tabblad. Moderne browsers hebben de functie opnieuw ingeschakeld na Spectre-stijl mitigaties, maar ze hebben het gekoppeld aan cross-origin isolatie. Om die isolatie te bereiken, moet een server het volgende sturen:

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

De tweede header, require-corp, vertelt de browser dat elke externe bron ofwel een Cross-Origin-Resource-Policy header moet hebben, ofwel moet worden opgehaald via CORS (Cross-Origin Resource Sharing). De meeste third-party services stellen deze headers niet in, waardoor hun scripts, fonts en iframes direct worden geblokkeerd.

Wat er wegviel toen de isolatie werd ingeschakeld

Op het moment dat de headers live gingen, ontstond er een cascade aan fouten:

  • Analytics – de meeste providers laden hun trackingcode met een simpel <script> dat een no-CORS verzoek doet. Zonder een CORP-header wordt het verzoek geweigerd, waardoor de tracker nooit draait.
  • Google Fonts – het stylesheet wordt opgehaald van fonts.googleapis.com zonder CORS. De browser negeert het, waardoor de pagina zonder de aangepaste typografie blijft.
  • Embedded media – YouTube iframes en widget-scripts missen CORP, waardoor ze niet meer worden weergegeven.
  • OAuth pop-ups – de window.opener relatie wordt verbroken door het strikte same-origin beleid, wat de gebruikelijke popup-gebaseerde loginflow doorbreekt.

Kortom, elke asset die vertrouwde op een third-party domein verdween, tenzij dat domein koos voor het nieuwe header-regime.

Opnieuw opbouwen zonder tussenpersonen

Voor een kapotte site heb ik de front-end stack herschreven rondom zelf-gehoste assets:

  • Fonts en afbeeldingen worden nu geserveerd vanaf mijn eigen origin, waardoor externe stylesheets niet meer nodig zijn.
  • Data API's zijn gebouwd op een private backend die ik controleer, zodat elk verzoek binnen mijn domein blijft.
  • Analytics veranderde in een kleine Cloudflare Worker die POST events accepteert en ze opslaat in een private bucket. De client-zijde bestaat slechts uit een dozijn regels fetch-code.
  • Error reporting en session replay tools zoals Sentry zijn volledig verwijderd; elke crash wordt nu gelogd naar mijn eigen endpoint.

Als een externe bron nog steeds nodig is, is de enige levensvatbare weg om deze te proxien via een server die je zelf bezit, waarbij de benodigde CORP-header wordt toegevoegd voordat de browser deze ziet.

Privacyvoordelen versus operationele kosten

Het directe voordeel is duidelijk: de site lekt geen gebruiksgegevens meer naar advertentienetwerken, font-providers of videoplatforms. Alle telemetrie blijft onder mijn controle en ik kan het verwijderen wanneer ik wil. Dat niveau van privacy is moeilijk te bereiken met de typische third-party stack.

Het nadeel is de extra onderhoudslast. Het hosten van fonts, het beheren van analytics-opslag en het up-to-date houden van een proxy zijn taken die de meeste ontwikkelaars uitbesteden aan gespecialiseerde services. Deze aanpak betekent ook dat je functies misloopt die die services bieden – bijvoorbeeld real-time foutaggregatie of gedetailleerde funnel-visualisaties.

Tegenargument: zal het ecosysteem zich aanpassen?

Sommigen beweren dat third-party leveranciers uiteindelijk de vereiste headers zullen toevoegen, waardoor cross-origin isolatie moeiteloos kan worden toegepast. Een paar partijen doen dat al, maar de meerderheid van de veelgebruikte services doet dat nog niet. Totdat het ecosysteem is ingehaald, moeten ontwikkelaars beslissen of de privacywinst opweegt tegen de technische inspanning die nodig is voor zelf-hosting.

Hoe je controleert of je echt geïsoleerd bent

Voordat je begint met herschrijven, controleer of de browser je pagina als geïsoleerd ziet:

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

Als een van de controles mislukt, worden de headers niet correct toegepast en blijft SharedArrayBuffer onbeschikbaar.

Wat is de volgende stap voor ontwikkelaars?

Nu meer web-apps streven naar de prestatieverbetering van multithreaded JavaScript, zal de druk op third-party providers om CORP te adopteren toenemen. In de tussentijd moet elk project dat SharedArrayBuffer nodig heeft, plannen voor een strategie met zelf-gehoste assets of een lichtgewicht proxy-laag. Het in de gaten houden van browser release notes voor wijzigingen in de isolatie-eisen zal ook essentieel zijn.

Kernpunt: Het inschakelen van cross-origin isolatie om SharedArrayBuffer te ontsluiten dwingt tot een moeilijke keuze – het gemak van scripts van derden behouden of dit inruilen voor een strikter, zelfbeheerst privacymodel. De beslissing hertekent zowel de technische architectuur als de gegevensstroom-voetafdruk van moderne websites.