Shared memory and high-resolution timers were effectively disabled at the start of 2018 in light of Spectre. In 2020, a new, secure approach has been standardized to re-enable shared memory.
As a baseline requirement, your document needs to be in a secure context.
For top-level documents, two headers need to be set to cross-origin isolate your site:
To check if cross origin isolation has been successful, you can test against the crossOriginIsolated
property available to window and worker contexts:
const myWorker = new Worker("worker.js");
if (crossOriginIsolated) {
const buffer = new SharedArrayBuffer(16);
myWorker.postMessage(buffer);
} else {
const buffer = new ArrayBuffer(16);
myWorker.postMessage(buffer);
}
With these two headers set, postMessage()
no longer throws for SharedArrayBuffer
objects and shared memory across threads is therefore available.
Nested documents and dedicated workers need to set the Cross-Origin-Embedder-Policy
header as well, with the same value. No further changes are needed for same-origin nested documents and subresources. Same-site (but cross-origin) nested documents and subresources need to set the Cross-Origin-Resource-Policy
header with same-site
as value. And their cross-origin (and cross-site) counterparts need to set the same header with cross-origin
as value. Note that setting the Cross-Origin-Resource-Policy
header to any other value than same-origin
opens up the resource to potential attacks, such as Spectre.
Note that the Cross-Origin-Opener-Policy
header limits your ability to retain a reference to popups. Direct access between two top-level window contexts essentially only work if they are same-origin and carry the same two headers with the same two values.