Google’s Search Central issued a clarification over a confusing message sent out last week by the Google Search Console regarding SharedArrayBuffer issues. Google also updated it’s guide to guide to enabling cross-origin isolation.
What is a SharedArrayBuffer?
According to the Mozilla web workers documentation:
“Web Workers are a simple means for web content to run scripts in background threads.”
And according to another Mozilla developer page:
“With the SharedArrayBuffer, both web workers, both threads, can be writing data and reading data from the same chunk of memory.”
The Mozilla developer page further explains:
…In a typical app, the work is all taken care of by a single individual—the main thread.
…And under certain circumstances, ArrayBuffers can reduce the amount of work that the main thread has to do.”
It goes on to explain that sometimes it’s not enough to split up the work and that’s where the above-mentioned web workers come into play, sharing the same chunk of memory.
Google’s Martin Splitt summarized it like this in 2017 when SharedArrayBuffers were a coming feature:
Messages that transfer large amount of data in TypedArrays or ArrayBuffers cause large memory cost due to data being cloned
…SharedArrayBuffers are an upcoming feature, allowing data to be shared between threads.”
Why You Received the SharedArrayBuffer Message
According to Google:
“The usage might be due to frameworks, libraries, or other third-party content included within your website.”
Why is SharedArrayBuffer (SAB) a Problem?
SABs became problematic after the discovery of the Spectre and Meltdown Vulnerabilities.
These vulnerabilities affect all Computer Processing Units (CPUs) and allow an attacker to read what’s in the memory. The attack affects all computer devices including Internet of Things devices.
Chrome initially suspended the use of SABs but then re-allowed them after a workaround that essentially isolated the processes.
Chrome and Firefox Change How SharedArrayBuffers are Handled
The reason for the email was an attempt to get the word out about how Chrome will be handling SharedArrayBuffers and to help publishers get on board with processes that will make their sites and their site visitors safer.
In late May 2021, Chrome 91 will be released with a new restriction that will provide a more robust defense against the Spectre and Meltdown vulnerabilities.
So what’s going on with Chrome 91 and what Google is requiring is setting security policies on resources and essentially locking down what’s allowed according to Chrome’s (and Firefox’s) policies for protecting site visitors and publishers against Spectre vulnerabilities.
That’s good for site visitors but could be bad for site publishers who use SharedArrayBuffer objects without cross-origin isolation.
According to Google’s clarification (making reference to Chrome version 91):
“…cross-origin isolation was standardized as a way to safely enable the SharedArrayBuffer object. Starting with version 91, planned to be released in late May 2021, Chrome will gate the SharedArrayBuffer object behind cross-origin isolation.
…After Chrome 91 is released, the SharedArrayBuffer object without cross-origin isolation will no longer be functional.”
What You Have to Do to Fix SharedArrayBuffer Issue
There are two tasks that need to be accomplished.
- Identify SAB use on your website.
- Fix or remove the functionality
Identifying SAB Usage
Google recommends these steps for identifying SharedArrayBuffers:
“You have two options:
Use Chrome DevTools and inspect important pages.
(Advanced) Use the Reporting API to send deprecation reports to a reporting endpoint.
Learn how to take the above approaches at Determine where in your website SharedArrayBuffer is used.”
Google’s guide to cross-origin isolation offers instructions for using Chrome Dev Tools for identifying use of SharedArrayBuffers.
- “Open the Chrome DevTools on the page you suspect might be using SharedArrayBuffer.
- Select the Console panel.
- If the page is using SharedArrayBuffer, the following message will show up:[Deprecation] SharedArrayBuffer will require cross-origin isolation as of M91, around May 2021. See https://developer.chrome.com/blog/enabling-shared-array-buffer/ for more details. common-bundle.js:535
- The filename and the line number at the end of the message (for example, common-bundle.js:535) indicate where the SharedArrayBuffer is coming from. If it’s a third-party library, contact the developer to fix the issue. If it’s implemented as part of your website, follow the guide below to enable cross-origin isolation.”
Link: How to Enable Cross-origin Isolation
A Lot to Take In
This is a lot to take in because there is a significant amount of development jargon and acronyms to memorize.
The various developer pages are difficult to understand because they tend to define multiple acronyms at the beginning of 2,000 word articles then exclusively refer to the acronyms with no further explanation throughout the article, as if the reader is able to easily retain the meaning of COEP or COOP.
Official Google clarification:
Clarifications About the SharedArrayBuffer Object Message
Security header background information resource: ScottHelme.co.uk
COEP COOP CORP CORS CORB – CRAP That’s a Lot of New Stuff!
Mozilla developer page about what SharedArrayBuffers are:
A Cartoon Intro to ArrayBuffers and SharedArrayBuffers
Google developer page on analyzing cross-origin isolation
A Guide to Analyzing Cross-origin Isolation
Google developer page on enabling cross-origin isolation
How to Enable Cross-origin Isolation