SharedArrayBuffer finally works in the browser again, but it only does so when a page is cross-origin isolated – a state that requires two response headers. Adding those headers forced me to drop every third-party script on my site, a move that reshaped how the whole front end is built and what data it leaks.

Why the headers matter

SharedArrayBuffer enables true multithreading in JavaScript, a prerequisite for running ffmpeg inside a tab. Modern browsers re-enabled the feature after Spectre-style mitigations, but they tied it to cross-origin isolation. To achieve that isolation a server must send:

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

The second header, require-corp, tells the browser that any external resource must either carry a Cross-Origin-Resource-Policy header or be fetched with CORS (Cross-Origin Resource Sharing). Most third-party services don’t set those headers, so their scripts, fonts, and iframes are blocked outright.

What fell away when isolation was turned on

The moment the headers went live, a cascade of failures appeared:

  • Analytics – most providers load their tracking code with a simple <script> that makes a no-CORS request. Without a CORP header the request is rejected, so the tracker never runs.
  • Google Fonts – the stylesheet is fetched from fonts.googleapis.com without CORS. The browser discards it, leaving the page without its custom typography.
  • Embedded media – YouTube iframes and widget scripts lack CORP, so they stop rendering.
  • OAuth pop-ups – the window.opener relationship is broken by the strict same-origin policy, breaking the usual popup-based login flow.

In short, any asset that relied on a third-party domain vanished unless that domain opted into the new header regime.

Rebuilding without the middlemen

Faced with a broken site, I rewrote the front-end stack around self-hosted assets:

  • Fonts and images are now served from my own origin, eliminating the need for external stylesheets.
  • Data APIs are built on a private backend that I control, so every request stays inside my domain.
  • Analytics turned into a tiny Cloudflare Worker that accepts POST events and stores them in a private bucket. The client side is just a dozen lines of fetch code.
  • Error reporting and session replay tools such as Sentry were dropped entirely; any crash is now logged to my own endpoint.

If an external resource is still required, the only viable path is to proxy it through a server you own, adding the necessary CORP header before the browser sees it.

Privacy gains versus operational cost

The immediate benefit is clear: the site no longer leaks usage data to ad networks, font providers, or video platforms. All telemetry stays under my control, and I can delete it whenever I wish. That level of privacy is hard to achieve with the typical third-party stack.

The trade-off is the extra maintenance burden. Hosting fonts, handling analytics storage, and keeping a proxy up to date are tasks that most developers outsource to specialized services. The approach also means losing out on features those services provide – for example, real-time error aggregation or detailed funnel visualisations.

Counter-point: will the ecosystem adapt?

Some argue that third-party vendors will eventually add the required headers, making cross-origin isolation painless to adopt. A few already do, but the majority of widely used services still don’t. Until the ecosystem catches up, developers must decide whether the privacy upside outweighs the engineering effort required to self-host.

How to verify you’re truly isolated

Before you start rewriting, confirm the browser sees your page as isolated:

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

If either check fails, the headers are not being applied correctly, and SharedArrayBuffer will remain unavailable.

What’s next for developers?

As more web-apps seek the performance boost of multithreaded JavaScript, the pressure on third-party providers to adopt CORP will increase. In the meantime, any project that needs SharedArrayBuffer should plan for a self-hosted asset strategy or a lightweight proxy layer. Watching browser release notes for changes to the isolation requirements will also be essential.

Вывод: Включение изоляции cross-origin для разблокировки SharedArrayBuffer ставит перед трудным выбором: сохранить удобство сторонних скриптов или пожертвовать им ради более строгой, полностью контролируемой модели конфиденциальности. Это решение меняет как техническую архитектуру, так и структуру потоков данных современных веб-сайтов.