Here is an explanation of SharedArrayBuffers:
[developer.mozilla.org...]

My guess is that you are using a plugin or widget that is using webGL to render content, and webGL is using the SAB's.

The easy fix, would be to add the COOP/COEP headers, see the security section in the mozilla link above for details.

Thanks for your quick reply.

I need to investigate this a bit more because my website is basically hand coded (using Microsoft Expressions to help) and as far as I am aware it does not use any plugins or widgets.

SharedArrayBuffers can be used for more than WebGL rendering. They function as communication memory between multiple JavaScript tasks. But if your site is hand coded, it seems weird to me that you used these buffers, it requires high level JS programming knowledge to use and synchronize multiple JS tasks in parallel.

For a layman's overview of what they are, you can look at A cartoon intro to ArrayBuffers and SharedArrayBuffers [hacks.mozilla.org]

SharedArrayBuffers have a bad reputation, because they were used in the Spectre attacks in 2018 and have been disabled by browsers by default, although some browser versions are allowing them again.

Thanks for the response. Yes the site is hand coded, with a little help from Microsoft Expressions.

I do have some JavaScript on the site but very simple and basic. I have very little technical website programming knowledge and I am the only one who has written the website.

It may be a mistake by Google, that has happened before, I will wait and see for the moment. I will however take a look at the cartoon explanation you suggest, but I think that my technical expertise is so limited that even cartoons on this subject may prove challenging!

WebGL is used for graphics, like drawing charts and graphs or 3D graphics, possibly even 3D fonts. It is possible that Microsoft Expressions is rendering some graphical components using WebGL

Unconfirmed, but this may (ironically) be caused by Google Analytics: [twitter.com...]

May not trigger for everyone, though, as noted in that thread.

So have a look at third-party scripts you're loading.

Any Update on this one guys?

@RustyBrick this is where you usually drop knowledge on us and we all bow to you.

Still a bit of a mystery. Google's kept mum so far.

If not Analytics, then AdSense perhaps? Or simply a false positive.

(Haven't received the message myself.)

Disclaimer: I have not received the aforementioned message and am responding (as apparently no one else in this thread understands the context) based solely on conversations within the web ad industry and my own subject knowledge.

The critical point for most/all webdevs is to ignore the message. Do not, I say again, do not add COOP/COEP headers to your site.

Unless you know your site itself uses SharedArrayBuffers (SABs) aka third-party storage adding the headers will probably break many/all ads and possibly the site itself as scripts stop working.
There now, did I freak you out enough?

The reality:
At least one major third party ad vendor currently uses SABs as part of a built in measurement/analytics methodology. And they (and any others similar) are who actually need to ‘fix’ their scripts by May 25 (projected Chrome 91 release date).

Note: the most common ad usage of SABs is as a third party cookie replacement.

Google being dumb software sees the SABs as being used by your site rather than by a third party. Can you say lack of sorcerer’s apprentice oversight?

Note: it is also possible that other (non-ad) JavaScript on your site may be running SABs - something to check with the developers in question. A quick and dirty rule of thumb (not to be trusted as certain) is that if everything works as designed in FireFox then SABs are unlikely present given that FF has long restricted SAB - this is Chrome also tightening up.