It's fair to say
SharedArrayBuffer has had a bit of a rough landing on the
web, but things are settling down. Here's what you need to know:
SharedArrayBufferis currently supported in Firefox 79+, and will arrive in Android Chrome 88. However, it's only available to pages that are cross-origin isolated.
SharedArrayBufferis currently available in Desktop Chrome, but from Chrome 92 it will be limited to cross-origin isolated pages. If you don't think you can make this change in time, you can register for an origin trial to retain the current behavior until at least Chrome 113.
- If you intend to enable cross-origin isolation to continue using
SharedArrayBufferevaluate the impact this will have on other cross-origin elements on your website, such as ad placements. Check if
SharedArrayBufferis used by any of your third-party resources to understand impact and guidance.
Cross-origin isolation overview
You can make a page cross-origin isolated by serving the page with these headers:
Once you do this, your page will not be able to load cross-origin content unless
the resource explicitly allows it via a
header or CORS headers
Access-Control-Allow-* and so forth).
There's also a reporting API, so you
can gather data on requests that failed as a result of
If you don't think you can make these changes in time for Chrome 92, you can register for an origin trial to retain current Desktop Chrome behavior until at least Chrome 113.
Check out the Further reading section at the bottom of this page for 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 who
think 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 the announcement for full details, but it essentially meant that code could use high-resolution timers to read memory that it shouldn't have access to.
To mitigate this, we reduced the resolution of our high-resolution timers such
performance.now(). However, you can create a high-resolution timer using
SharedArrayBuffer by modifying memory in a tight loop in a worker, and reading
it back in another thread. This couldn't be effectively mitigated without
heavily impacting well-intentioned code, so
SharedArrayBuffer was disabled
A general mitigation is to ensure a webpage's system process doesn't contain sensitive data from elsewhere. Chrome had invested in a multi-process architecture from the start (remember the comic?), but there were still cases where data from multiple sites could end up in the same process:
<link rel="stylesheet" href="https://your-bank.example/balance.json" />
<img src="https://your-bank.example/balance.json" />
<!-- …and more… -->
These APIs have a 'legacy' behavior that allows content from other origins to be used without opt-in from the other origin. These requests are made with the cookies of the other origin, so it's a full 'logged in' request. Nowadays, new APIs require the other origin to opt-in using CORS.
We worked around these legacy APIs by preventing content from entering the webpage's process if it looked 'incorrect', and called it cross-origin read blocking. So, in the above cases, we wouldn't allow JSON to enter the process, as it isn't a valid format for any of those APIs. That is, except iframes. For iframes we put the content in a different process.
With these mitigations in place, we reintroduced
SharedArrayBuffer in Chrome
68 (July 2018), but only on desktop. The extra process requirements meant we
couldn't do the same on mobile devices. It was also noted that Chrome's solution
was incomplete, as we were only blocking 'incorrect' data formats, whereas it's
possible (although unusual) that valid CSS/JS/images at guessable URLs can
contain private data.
Web standards folks got together to come up with a more complete cross-browser
solution. The solution was to give pages a way to say "I hereby relinquish my
ability to bring other-origin content into this process without their opt-in".
This declaration is done via COOP and COEP headers
served with the page. The browser enforces that, and in exchange the page gains
SharedArrayBuffer and other APIs with similar powers. Other origins
can opt-in to content embedding via
Firefox was the first to ship
SharedArrayBuffer with this restriction, in
version 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 brings
SharedArrayBuffer back to
Android for pages that are cross-origin isolated, and Chrome 92 brings the same
requirements to desktop, both for consistency, and to achieve total cross-origin
Delaying the Desktop Chrome change
This is a temporary exception in the form of an 'origin trial' that gives folks
more time to implement cross-origin isolated pages. It enables
SharedArrayBuffer without requiring the page to be cross-origin isolated. The
exception expires in Chrome 113, and the exception only applies to Desktop
- Request a token for your origin.
- Add the token to your pages. There are two ways to do that:
- Add an
<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 token
Origin-TrialHTTP header. The resulting response header should look something like:
- Add an
- A guide to enable cross-origin isolation
- How to cross-origin isolate your pages
- Why cross-origin isolation is needed