SharedArrayBuffer updates in Android Chrome 88 and Desktop Chrome 92
Update, May 2022
To secure more time to introduce ways to relax the requirement to enable cross-origin isolation, we've decided to postpone the restriction on
SharedArrayBuffer on desktop described in this article to Chrome 106 (originally Chrome 103). You might need to update the token.
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 106.
- 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
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 92, you can register for an origin trial to retain current Desktop Chrome behavior until at least Chrome 106.
Update, December 2021
We've been exploring ways to deploy
Cross-Origin-Resource-Policy at scale, as cross-origin isolation requires all subresources to explicitly opt-in. And we have come up with the idea of going in the opposite direction: a new COEP "credentialless" mode that allows loading resources without the CORP header by stripping all their credentials. We hope this will lighten your burden of making sure the subresources are sending the
credentialless mode is available on Chrome from version 96, it's not supported by any other browsers yet, this may cause some developers find it challenging to deploy COOP or COEP at this stage.
Also, it's known that the
Cross-Origin-Opener-Policy: same-origin header will break integrations that require cross-origin window interactions such as OAuth and payments. To mitigate this problem, we are exploring relaxing the condition to enable cross-origin isolation to
Cross-Origin-Opener-Policy: same-origin-allow-popups. This way the communication with the window opened by itself will be possible.
If you want to enable cross-origin isolation to use
SharedArrayBuffer but are blocked by these challenges, we recommend registering for an origin trial and waiting until the new modes are available. We are not planning to terminate the origin trial until these new modes are available.
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 92 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 106, 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
To verify that it's working properly, install Chrome 92 for testing.
- A guide to enable cross-origin isolation
- How to cross-origin isolate your pages
- Why cross-origin isolation is needed