SharedArrayBuffer updates in Android Chrome 88 and Desktop Chrome 91
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:
In brief #
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 91 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 Chrome 93.
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
Cross-Origin-Resource-Policy 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 91, you can register for an origin trial to retain current Desktop Chrome behavior until Chrome 93.
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 as
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 altogether.
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 access to
SharedArrayBuffer and other APIs with similar powers. Other origins can opt-in to content embedding via
Cross-Origin-Resource-Policy or CORS.
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 91 brings the same requirements to desktop, both for consistency, and to achieve total cross-origin isolation.
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 93, and the exception only applies to Desktop Chrome.
- Request a token for your origin.
- Add the token to your pages. There are two ways to do that:
- Add a
<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 using an
Origin-TrialHTTP header. The resulting response header should look something like:
- Add a
Further reading #
- A guide to enable cross-origin isolation
- How to cross-origin isolate your pages
- Why cross-origin isolation is needed