- What is a SharedArrayBuffer?
- Why you received the SharedArrayBuffer message
- Why is SharedArrayBuffer (SAB) a problem?
- Chrome and Firefox are changing the way they handle SharedArrayBuffers
- What to do to fix SharedArrayBuffer problem
- Identify SAB usage
- A lot to see
A confusing message was posted on Google Search Central last week by the Google Search Console regarding SharedArrayBuffer issues. Google also updated the guide to enable cross-origin isolation.
What is a SharedArrayBuffer?
According to the Mozilla Web Worker documentation:
"Web workers are a simple means for web content to run scripts in background threads."
And according to another Mozilla developer site:
"With the SharedArrayBuffer, both web workers, both threads, can write data and read data from the same memory area."
Read on below
The Mozilla developer page explains the following:
… In a typical app, the work is done by a single person – the main topic.
… And under certain circumstances, ArrayBuffers can reduce the workload on the main thread. "
It goes on to explain that sometimes it is not enough to divide up the work, and this is where the web workers mentioned above come in, who share the same area of memory.
Google's Martin Splitt summed it up like this in 2017, when SharedArrayBuffers were an upcoming feature:
Messages that transfer large amounts of data in TypedArrays or ArrayBuffers cause high storage costs due to the cloning of data
… SharedArrayBuffers are an upcoming feature that will allow data to be exchanged between threads. "
Read on below
Why you received the SharedArrayBuffer message
According to Google:
"Usage may be due to frameworks, libraries, or other third-party content included on your website."
Why is SharedArrayBuffer (SAB) a problem?
SABs became problematic after the Specter and Meltdown vulnerabilities were discovered.
These vulnerabilities affect any computer processing unit (CPU) and could allow an attacker to read what is in memory. The attack affects all computing devices, including Internet of Things devices.
Chrome initially suspended the use of SABs, but re-allowed them after a workaround that essentially isolated the processes.
Chrome and Firefox are changing the way they handle SharedArrayBuffers
The reason for the email was to try to spread the word about how Chrome will handle SharedArrayBuffers and to help publishers incorporate processes that will make their websites and website visitors safer.
In late May 2021, Chrome 91 will be released with a new restriction that provides a more robust defense against the Specter and Meltdown vulnerabilities.
So what's going on with Chrome 91 and what Google needs is to set security policies for resources and lock down the policies allowed under Chrome (and Firefox) policies to protect website visitors and publishers from Specter vulnerabilities.
This is good for website visitors, but it can also be bad for website publishers who use SharedArrayBuffer objects with no native isolation.
According to the clarification from Google (with reference to Chrome version 91):
"… The cross-origin isolation was standardized in order to safely activate the SharedArrayBuffer object. Starting with version 91, which is due to be released at the end of May 2021, Chrome will control the SharedArrayBuffer object behind the cross-origin isolation.
… After the release of Chrome 91, the SharedArrayBuffer object will no longer function without source isolation. "
Read on below
What to do to fix SharedArrayBuffer problem
There are two tasks that must be accomplished.
- Identify SAB usage on your website.
- Correct or remove functionality
Identify SAB usage
Google recommends the following steps to identify SharedArrayBuffers:
"You have two options:
Use Chrome DevTools and check out key pages.
(Advanced) Use the reporting API to send expiration reports to a reporting endpoint.
To learn how to use the approaches above, see Determine Where Your Website Is Using SharedArrayBuffer. "
The Google Guide to Cross-Origin Isolation has instructions on how to use the Chrome Dev Tools to identify the use of SharedArrayBuffers.
- Open the Chrome DevTools on the page you suspect are using SharedArrayBuffer.
- Select the console window.
- If the page uses SharedArrayBuffer, the following message is displayed: (Obsolete) SharedArrayBuffer requires cross-origin isolation starting with M91 as of May 2021. See https://developer.chrome.com/blog/enabling-shared-array -buffer / for more details. common-bundle.js: 535
- The file name and line number at the end of the message (e.g. common-bundle.js: 535) indicate where the SharedArrayBuffer came from. If it is a third-party library, contact the developer to resolve the issue. If it's implemented as part of your website, follow the instructions below to enable lineage isolation. "
Read on below
Shortcut: Enable cross-origin isolation
A lot to see
This is a lot to consider as there is a considerable amount of developmental jargon and acronyms to remember.
The various developer pages are difficult to understand as they tend to define multiple acronyms at the beginning of 2,000 articles of speech. They then refer solely to the acronyms with no further explanation throughout the article, as if the reader could easily keep the meaning of COEP or COOP.
Official Google clarification:
Explanations of the SharedArrayBuffer object message
Background information source for safety headers: ScottHelme.co.uk
COEP COOP CORP CORS CORB – CRAP That's a lot of news!
Mozilla developer's site about SharedArrayBuffers:
A cartoon introduction to ArrayBuffers and SharedArrayBuffers
Google developer page to analyze origin isolation
A Guide to Source Isolation Analysis
Google developer page to enable cross-origin isolation
Enable cross-origin isolation