Intent to ship: returning shared memory to the web

[Anne van Kesteren]

At the end of August 2019 we expressed an intent to prototype the
re-enablement of SharedArrayBuffer[1]. Many bugs and design
iterations later, we’re happy to announce that it’s now ready. We
would like to ship this in Firefox 79 or 80.

To do this in a post-Spectre-safe manner we have worked with others
to add the cross-origin isolated primitive to the web platform, which
provides sites that opt into it with their own process that cannot
pull in non-consenting external resources. In that process they get
to use high-resolution clocks and shared memory.

To address novel attacks, we have added the ability to throttle
JavaScript execution with JSExecutionManager[2]. With more
implementation work, we could also use this capability to reduce
resource consumption and improve battery life, e.g., by enabling it
for background tabs.

Here’s a summary of the changes:

* We have already shipped[3] JavaScript’s Atomics and
SharedArrayBuffer to release, although globalThis.SharedArrayBuffer
returns undefined as long as the cross-origin isolated primitive is
false. This included support for the shared:true parameter of
WebAssembly.Memory’s constructor.
* As part of this intent we’ll ship the Cross-Origin-Opener-Policy
and Cross-Origin-Embedder-Policy headers, that when set to the
same-origin and require-corp values respectively, for a top-level
document, enable its browsing context group to be cross-origin
isolated. (Cross-Origin-Opener-Policy also helps sites close a
security hole in the web platform by preventing themselves from
being opened in a popup an attacker might control.)

If a document is cross-origin isolated:

* globalThis.crossOriginIsolated will return true.
* globalThis.SharedArrayBuffer will no longer return undefined.
* postMessage() can be used to message SharedArrayBuffer objects,
restricted to the agent cluster[4] (the smallest unit a browser
could isolate in a process) it was created in.
* Agent clusters within a cross-origin isolated browsing context
group are keyed on origin rather than site: this means that 1)
shared memory is bound to a single origin (postMessage()’ing
elsewhere results in a messageerror) and 2) document.domain is
ineffective (it returns just before changing the origin, for
maximum compatibility with existing libraries that reportedly set
it a lot, but don’t really care if it works). (With Fission this
would allow us to use actual processes at the origin boundary
too, but we have not looked into that much thus far.)
* Timers are no longer throttled, including performance.now().

Chrome plans to match this model by August 2020 for Android, March
2021 for all except sites that opt-out, and May 2021 for all without
exceptions.[5]

It’s being standardized primarily in the Fetch and HTML standards,
through a number of pull requests that are close to done:

* https://github.com/whatwg/html/pull/5334 (COOP)
* https://github.com/whatwg/html/pull/5454 (COEP)
* https://github.com/whatwg/fetch/pull/1030 (COEP)
* https://github.com/w3c/ServiceWorker/pull/1516 (COEP)
* https://github.com/whatwg/html/pull/4734 (cross-origin isolated)
* https://github.com/w3c/hr-time/issues/89 (timers; not much progress
on this unfortunately; timers in general are a somewhat poorly
defined piece of infrastructure)

Shipping bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1619649.

(Following this work we plan to change the header parsers from strict
byte sequence comparisons to using structured headers, which will
also pave the way for adding reporting functionality. We also plan to
eventually support cross-origin isolated for shared and service
workers and roll all of this out on mobile.[6])

In no particular order, many thanks to Nika, Tom, Valentin, Eden,
Jens, Luke, Bas, Neha, Andrew (x2), Hsin-Yi, Perry, Steve, Mike,
Lars Thomas, Jeff, Junior, Selena, Yaron, and Eric for their help
getting this done in Firefox!

[1] https://groups.google.com/d/msg/mozilla.dev.platform/IHkBZlHETpA/dwsMNchWEQAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1563335
[3] https://groups.google.com/d/msg/mozilla.dev.platform/yl0BXW-_ou0/u9CKDvuABgAJ
[4] https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-agent-cluster-formalism
[5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/_0MEXs6TJhg/QzWOGv7pAQAJ
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1563480

[Lars Hansen]

I want to add that enabling shared memory in Firefox also enables wasm
thread operations [1]. That proposal is only at stage 2 in the Community
Group, but has been in Chrome release since v74, is used in live content on
the web (eg Google Earth), and is therefore in its final form for all
practical intents.

--lars

[1] https://github.com/webassembly/threads

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>