Jake Archibald

Eiji Kitamura

It's fair to saySharedArrayBuffer has had a bit of a rough landing on theweb, but things are settling down. Here's what you need to know:

In brief

• SharedArrayBuffer is currently supported in Firefox 79+, and will arrive in AndroidChrome 88. However, it's only available to pages that arecross-origin isolated.
• SharedArrayBuffer is currently available in Desktop Chrome, but from Chrome92 it will be limited to cross-origin isolated pages. If you don't think youcan make this change in time, you canregister for an origin trial to retain the current behavior until at least Chrome113.
• If you intend to enable cross-origin isolation to continue usingSharedArrayBuffer evaluate the impact this will have on other cross-originelements on your website, such as ad placements. Check ifSharedArrayBufferis used by any of your third-party resources to understand impact andguidance.

Cross-origin isolation overview

You can make a pagecross-origin isolated by serving the page with theseheaders:

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

Once you do this, your page will not be able to load cross-origin content unlessthe resource explicitly allows it via aCross-Origin-Resource-Policyheader orCORS headers(Access-Control-Allow-* and so forth).

There's also areporting API, so youcan gather data on requests that failed as a result ofCross-Origin-Embedder-Policy andCross-Origin-Opener-Policy.

If you don't think you can make these changes in time for Chrome 92, you canregister for an origin trial to retain current Desktop Chromebehavior until at least Chrome 113.

Check out theFurther reading section at the bottom of this pagefor more guidance and information on cross-origin isolation.

How did we get here?

SharedArrayBuffer arrived in Chrome 60 (that's July 2017, for those of you whothink of time in dates rather than Chrome versions), and everything was great.For 6 months.

In January 2018 a vulnerability was revealed in some popular CPUs. See theannouncementfor full details, but it essentially meant that code could use high-resolutiontimers to read memory that it shouldn't have access to.

This was a problem for us browser vendors, as we want to allow sites to executecode in the form of JavaScript and WASM, but strictly control the memory thiscode can access. If you arrive on my website, I shouldn't be able to readanything from the internet banking site you also have open. In fact, I shouldn'teven know you have your internet banking site open. These are fundamentals ofweb security.

To mitigate this, we reduced the resolution of our high-resolution timers suchasperformance.now(). However, you cancreate a high-resolution timer usingSharedArrayBuffer by modifying memory in a tight loop in a worker, and readingit back in another thread. This couldn't be effectively mitigated withoutheavily impacting well-intentioned code, soSharedArrayBuffer was disabledaltogether.

A general mitigation is to ensure a webpage's system process doesn't containsensitive data from elsewhere. Chrome had invested in a multi-processarchitecture from the start (remember the comic?), but there werestill cases where data from multiple sites could end up in the same process:

<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… -->

These APIs have a 'legacy' behavior that allows content from other origins to beused without opt-in from the other origin. These requests are made with thecookies of the other origin, so it's a full 'logged in' request. Nowadays, newAPIs require the other origin to opt-in usingCORS.

We worked around these legacy APIs by preventing content from entering thewebpage's process if it looked 'incorrect', and called itcross-origin read blocking.So, in the above cases, we wouldn't allow JSON to enter the process, as it isn'ta valid format for any of those APIs. That is, except iframes. For iframes weput the content in a different process.

With these mitigations in place, we reintroducedSharedArrayBuffer in Chrome68 (July 2018), but only on desktop. The extra process requirements meant wecouldn't do the same on mobile devices. It was also noted that Chrome's solutionwas incomplete, as we were only blocking 'incorrect' data formats, whereas it'spossible (although unusual) that valid CSS/JS/images at guessable URLs cancontain private data.

Web standards folks got together to come up with a more complete cross-browsersolution. The solution was to give pages a way to say "I hereby relinquish myability to bring other-origin content into this process without their opt-in".This declaration is done viaCOOP and COEP headersserved with the page. The browser enforces that, and in exchange the page gainsaccess toSharedArrayBuffer and other APIs with similar powers. Other originscan opt-in to content embedding viaCross-Origin-Resource-PolicyorCORS.

Firefox was the first to shipSharedArrayBuffer with this restriction, inversion 79 (July 2020).

Then, in January 2021, I wrote this article, and you read it. Hello.

And that's where we are now. Chrome 88 bringsSharedArrayBuffer back toAndroid for pages that are cross-origin isolated, and Chrome 92 brings the samerequirements to desktop, both for consistency, and to achieve total cross-originisolation.

Delaying the Desktop Chrome change

This is a temporary exception in the form of an 'origin trial' that gives folksmore time to implement cross-origin isolated pages. It enablesSharedArrayBuffer without requiring the page to be cross-origin isolated. Theexception expires in Chrome 113, and the exception only applies to DesktopChrome.

1. Request a token for your origin.
2. Add the token to your pages. There are two ways to do that:
   • Add anorigin-trial<meta> tag to the head of each page. For example,this may look something like:
     <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
   • If you can configure your server, you can also add the tokenusing anOrigin-Trial HTTP header. The resulting response header shouldlook something like:
     Origin-Trial: TOKEN_GOES_HERE

Further reading

• A guide to enable cross-origin isolation
• How to cross-origin isolate your pages
• Why cross-origin isolation is needed

Banner photo byDanielGregoire onUnsplash