Intent to ship: WebAssembly Threads

[Michael Hablich]

Contact emails (alphasorted)

bi...@chromium.org, dsc...@chromium.org, hab...@chromium.org, tit...@chromium.org

Explainer

Provide low-level building blocks for pthreads-style shared memory: shared memory between threads, atomics and futexes.

New atomic memory operators, including loads/stores annotated with their atomic ordering property, will follow a model compatible with the C++11 memory model (with some differences), similarly to the PNaCl atomic support and the SharedArrayBuffer support in JavaScript. Even when there are data races, WebAssembly will ensure that the nondeterminism remains limited and local.

There is ongoing work to formalize the memory model used by SharedArrayBuffer. This can be used by WebAssembly threads, since both JavaScript and WebAssembly are intended to be able to communicate through SharedArrayBuffer.

More details can be found in https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md.

Design doc/Spec

Spec issue: https://github.com/WebAssembly/design/issues/1073

Design doc: https://docs.google.com/document/d/1e0Ye-75niAVqdsCDCxJEMYjAh3OC3ezQIsLc4YcFHj4/edit

Tracking issue: https://bugs.chromium.org/p/chromium/issues/detail?id=754910

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/GMZIcOoFFqw

Link to “Intent to Experiment” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/41XDSl0-QIU/SuiUjCs4CwAJ

Summary

See explainer section.

Link to Origin Trial feedback summary

• Around 40 signups

• Actual live usage in e.g. Google Earth and Soundation

The reception around the OT was very positive. The API is sufficient.

Other partners, that were not using the OT but simply used the flag to experiment, mentioned that the asymmetric nature of the main thread vs. web workers can cause difficulties for developers. Toolchains like Emscripten provide some facilities to help.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Support on Windows, Mac, Linux, Chrome OS. Android does not support general Site Isolation and thus Threads/SABs/etc. are switched off there.

Demo link

See https://developers.google.com/web/updates/2018/10/wasm-threads for demos and usage examples.

Debuggability

No additional support needed.

Risks

Interoperability and Compatibility

Edge: Public support;

Firefox: In development/done, currently waiting on shipping solutions that enable Site Isolation mechanisms in Firefox e.g. via https://github.com/whatwg/html/issues/4175.

Safari: No signals

Web / Framework developers: Very positive signals, see https://www.youtube.com/watch?v=zgOGZgAPUjQ&list=PLNYkxOF6rcIDjlCx1PcphPpmf43aKOAdF&index=24&t=0s for examples like Soundation

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

• SharedArrayBuffer (already shipped)

• BulkMemory support in WebAssembly (shipped together with this)

• Web Workers and postMessage support (already shipped)

• JS Atomics (already shipped)

• Mutable global export (already shipped)

• Sign extension ops (already shipped)

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

• Emscripten supports POSIX threads emulation

• A Web Fundamentals post on how to use Wasm Threads is already live

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Spec core tests: https://github.com/WebAssembly/threads/blob/master/test/core/atomic.wast

Spec JS tests: https://github.com/WebAssembly/threads/commit/0b80037ebc7825db0e67c2433f556dd8d07118a2

CL for WPT: https://chromium-review.googlesource.com/c/chromium/src/+/1443959

Entry on the feature dashboard

https://www.chromestatus.com/features/5724132452859904 .

Cheers,

Michael

[Anne van Kesteren]

On Thu, Jan 31, 2019 at 10:35 AM Michael Hablich <hab...@chromium.org> wrote:
> Firefox: In development/done, currently waiting on shipping solutions that enable Site Isolation mechanisms in Firefox e.g. via https://github.com/whatwg/html/issues/4175.

As I understand it this is also the plan for Chrome on Android. Would
it not be better to have the same requirements on desktop, in order to
avoid fragmenting the web? And provide more protection to subresources
that CORB cannot handle?

[Chris Palmer]

Thanks for raising this, Anne.

I don't necessarily agree that we are fragmenting the web by gating SAB and WASM threads on different enablement mechanisms. Different browsers on different platforms have different ways of creating agent clusters, and different ways of setting the "high-res clock enabled" bit, and that can be OK. Lots of specifications have implementation-defined behavior, because it's often necessary.

Part of the reason it is OK to ship WASM threads this way is that we all face real side-channel attack risk now, with or without high-res clocks. SAB and WASM threads are by no means the only clocks with sufficient resolution for Spectre/similar attack. I'm quite convinced by https://gruss.cc/files/fantastictimers.pdf, and I'm sure most other security people are, too. I believe the difficulty of exploiting timing side-channel attacks (micro-architectural or otherwise) is marginally easier with a straightforward high-res clock — but only marginally. I don't believe we should be thinking, "we're safe enough even without process isolation, because we turned high-res clocks off." (Just for starters, I'd be amazed if there is not already some almost-ns-resolution clock in the OWP that we haven't noticed!)

This is not to say that it's OK to ship high-res clocks because we're all going to die anyway. It's OK because every browser and every platform has or will soon have some form of mitigation against side-channel and micro-architectural bugs, and because there is a lot of positive value in the OWP having these multi-threading capabilities.  

Another part of the reason I think it is OK to ship WASM threads this way is that ultimately, the header-based approach is going to transition from "necessary some browsers/platforms to set the high-res clock bit; beneficial on others" to "nice to have for related but different reasons" and then possibly to "vestigial". Ultimately, we need process isolation for all origins in all browsers on all platforms. Getting there is a long road, and we face risk at every step of the way. But we have to keep walking forward.

Finally, Chrome has already committed to shipping high-resolution clocks on Desktop where Site Isolation is turned on (by default, everywhere, now), and we won't create API churn by turning it back off unless the origin sends the headers. Of course, the origin should send the headers anyway — for the short and medium term, and possibly the long term, that's going to be best practice. We'll need to continue to communicate that to web developers.

[Boris Zbarsky]

On 1/31/19 3:55 PM, 'Chris Palmer' via blink-dev wrote:
> Ultimately, we need process
> isolation for all origins in all browsers on all platforms.

Chris,

I believe Anne's point is that process isolation is _not_ sufficient to
prevent cross-origin data leaks on its own in the face of
high-resolution clocks, that other mitigations are probably necessary
(including CORB or something along those lines, but that is also not
sufficient), and that enabling high-resolution clocks without those
other mitigations are in place is somewhat irresponsible.

Put another way, even if Firefox were shipping process isolation right
now, we would probably not enable SAB except in cases that have those
other mitigations in place. And right now that would involve opt-in via
the header that Anne mentioned.

You're right that in the end even with lower-res clocks there is
cross-origin leakage possible here, and the end result is that one has
to consider the speed of the leakage compared to the size of the data
being protected, etc. And maybe different browsers want to put
different priorities on preventing such leakage. But if we're going to
be able to converge on a single web platform behavior, we really need to
have this conversation, and that hasn't been happening.

> Finally, Chrome has already committed to shipping high-resolution clocks
> on Desktop where Site Isolation is turned on

Yes, in spite of objections from other browsers who feel that this
creates unacceptable cross-origin leakage, even with process isolation
in place.

> Of course, the origin should send the headers
> anyway — for the short and medium term, and possibly the long term,

What is your exact plan for dealing with the cross-origin information
leakage issues not addressed by CORB and process isolation in the long
term? Last I had checked it was "pretend they don't exist"...

-Boris

[Michael Hablich]

Hi,

please also keep in mind that this particular intent to ship is (more or less) about enabling the same capabilities in Wasm, that are already available in JS: Atomics.

Cheers,

Michael

[Chris Palmer]

On Thu, Jan 31, 2019 at 1:37 PM Boris Zbarsky <bzba...@mit.edu> wrote:

I believe Anne's point is that process isolation is _not_ sufficient to
prevent cross-origin data leaks on its own in the face of
high-resolution clocks, that other mitigations are probably necessary
(including CORB or something along those lines, but that is also not
sufficient), and that enabling high-resolution clocks without those
other mitigations are in place is somewhat irresponsible.

Process isolation and CORB are the minimum necessary mechanisms. They may not ultimately be sufficient on their own, but they are also the leading edge of Spectre defense right now (as well as enabling good defense against less esoteric and more common attacks).

It's wishful thinking to believe that high-resolution clocks are uniquely problematic, and that exfiltration throughput is the key enabler of practical Spectre attacks. Attackers can exfiltrate the pretty small pieces of data they need (CSRF tokens, cookies, passwords, keys) even without high throughput. Knowing where important things are on the heap is already bread and butter for attackers in this class.

(In fact, high throughput might very well be a non-goal for some attackers, since it's noisy (network traffic, CPU cost) and makes a hard-to-detect attack more detectable.)

 

Put another way, even if Firefox were shipping process isolation right
now, we would probably not enable SAB except in cases that have those
other mitigations in place.  And right now that would involve opt-in via
the header that Anne mentioned.

I agree that sending the headers in all cases will be best practice for developers. My original dream for the headers (back at the first f2f meeting we had) was for the headers to enable browsers that don't yet have SI by default to conditionally trigger additional side-channel defense, thus enabling us all to avoid fragmentation of OWP capabilities.

The headers are nice on their own, now, and Chrome is going to implement and honor them. (CORP is now done, for example.) If Firefox wants to require both Site Isolation and the headers before enabling high-res timers, that's great and will serve to reinforce best practice.

You're right that in the end even with lower-res clocks there is
cross-origin leakage possible here, and the end result is that one has
to consider the speed of the leakage compared to the size of the data
being protected, etc.  And maybe different browsers want to put
different priorities on preventing such leakage.  But if we're going to
be able to converge on a single web platform behavior, we really need to
have this conversation, and that hasn't been happening.

It's happening here, and in the headers discussion group and face-to-face, and has been going on for a while now. These are all public discussions about public standards, and Chrome's position on high-res timers is not at all new.

 

> Finally, Chrome has already committed to shipping high-resolution clocks
> on Desktop where Site Isolation is turned on

Yes, in spite of objections from other browsers who feel that this
creates unacceptable cross-origin leakage, even with process isolation
in place.

I won't be sad if the near-term result is that people end up doing both the headers and process isolation; I love defense in depth.

But if you're saying that the platform can't ever have high-res clocks, we'll have to agree to disagree. :) And again, high-res clocks are not the unique gateway to effective Spectre exploitation. I can't emphasize that enough.

What is your exact plan for dealing with the cross-origin information
leakage issues not addressed by CORB and process isolation in the long
term?  Last I had checked it was "pretend they don't exist"...

I'd be amazed if anybody from any browser ever said that. Maybe your tone of voice here is joking, but I can't tell over email and I haven't met you in person. We're all committed to delivering a high-capability, safe platform for the people of the world.

Gradually narrowing the leakage from side-channel attacks (of all kinds) is the work of decades (Lampson's paper is from 1973), and it's been a hard problem all along, even before Spectre. I am fairly loudly pushing back on new, explicit side-channel mechanisms as they are proposed. (And they are being proposed.) But clocks and threads per se are not vulnerabilities, and they are just too important for the future of the platform for us to simply say No to.

Ultimately, it's going to (continue to) be a combination of maximizing the defensive value of OS and hardware primitives, driving vendors to give us new primitives, fixing our numerous mundane cross-origin and OOB read vulnerabilities, promoting web developer best practice, improving developer ergonomics (SI is good here but the headers are not great, I'm sorry to say), and so on.

[Boris Zbarsky]

On 1/31/19 5:30 PM, Chris Palmer wrote:
> Process isolation and CORB are the minimum necessary mechanisms

They are necessary, but they are not "the minimum necessary", in my
opinion. More than that is necessary.

> may not ultimately be sufficient on their own

They're obviously insufficient.

> It's wishful thinking to believe that high-resolution clocks are
> uniquely problematic

Sure. The uniquely problematic thing is getting your hands on any
cross-site content that did not opt in to you doing that. If we're
serious about fixing this problem, that is what needs to get addressed.
The question is how to get there.

> I agree that sending the headers in all cases will be best practice for
> developers.

See, the problem is that the people sending the headers, in the current
setup I've seen proposesd, need to be the ones who are grabbing other
people's cross-site content. As in, the possible attackers.

What is their incentive to send the headers? If their incentive is "you
can't have feature X that your really want (and that incidentally would
make an attack much easier, all else being equal) without opting out of
being a possible attacker", then they have an incentive to send the
headers, and thus opt out of being a possible attacker, by virtue of
opting out of being able to get at not-opted-in cross-site content.

> My original dream for the headers (back at the first f2f
> meeting we had) was for the headers to enable browsers that don't yet
> have SI by default to conditionally trigger additional side-channel
> defense

I don't see what having SI or not has to do with it. We need to trigger
additional side-channel defenses (e.g. CORS on every load) to actually
get traction on this problem. This can't be done by default on the web
yet, so what's being proposed are opt-ins. The fact that the same
mechanism could trigger something SI-like in browsers, again as an
opt-in, is nice, but isn't the main point, long-term, since as you note
long-term browsers will likely all have SI.

> If Firefox wants to require both Site Isolation and the
> headers before enabling high-res timers, that's great and will serve to
> reinforce best practice.

See, this is where it feels like a prisoner's dilemma to me, with Chrome
defecting. Yes, it would be best if all sites opted in to not being a
Spectre attacker, or if we could make it the default mode, but how do
you propose we get there given Chrome's current policy stance?

> It's happening here, and in the headers discussion group

> <https://groups.google.com/a/chromium.org/forum/#!forum/isolation-policy> and

> face-to-face, and has been going on for a while now.

Yes, I'm aware of these conversations. They have not really been
addressing my concerns above.

> and Chrome's position on high-res timers is not at all new.

I am well aware.

> I won't be sad if the near-term result is that people end up doing both
> the headers and process isolation; I love defense in depth.

You're still making it sounds like the headers are a nice-to-have. At
the moment, they're the only proposal for an actual "can't execute a
Spectre attack" setup, no?

> But if you're saying that the platform can't ever have high-res clocks,
> we'll have to agree to disagree. :)

I'm not saying that. I'm saying that if I get to make that call, you
only get high-res clocks if you opt out of being a Spectre attacker.

> And again, high-res clocks are not the unique gateway to effective Spectre exploitation.

No one is saying they are. But they're certainly the _easy_ way.

> What is your exact plan for dealing with the cross-origin information
> leakage issues not addressed by CORB and process isolation in the long
> term?  Last I had checked it was "pretend they don't exist"...
>
> I'd be amazed if anybody from any browser ever said that. Maybe your
> tone of voice here is joking

It wasn't. The above is the impression I have been given multiple times
now by various responses to me raising the problem of general
subresource protection from Spectre. The way it's actually phrased is
typically "it's not in our threat model" or so.

> Gradually narrowing the leakage from side-channel attacks (of all kinds)
> is the work of decades

Yes.

> I am fairly loudly pushing back on new, explicit side-channel
> mechanisms as they are proposed.

Much appreciated.

> Ultimately, it's going to (continue to) be a combination of maximizing
> the defensive value of OS and hardware primitives, driving vendors to
> give us new primitives, fixing our numerous mundane cross-origin and OOB
> read vulnerabilities, promoting web developer best practice, improving
> developer ergonomics (SI is good here but the headers are not great, I'm
> sorry to say), and so on.

I think we agree on all that. I think we disagree on how to most
effectively make progress here.

I'm going to stop tying up your mailing list with a rehash of this now,
since it's clear that you all have made your decision and are going to
stick with it. But again, to me it feels like a defection in a
prisoner's dilemma.

-Boris

[a...@google.com]

I'll refrain from commenting on the security side of this story beyond what has

already been brought up here, but I want to come back to the web fragmentation

aspect mentioned by Anne.

(For the record, I would summarize the status quo as following:

- SAB and WASM threads provide known ways to build timers that allow attackers

  to use Spectre to exfiltrate non-CORB-eligible cross-origin resources (e.g.

images) by loading them in `no-cors` mode. This is possible even in browsers

with full Site Isolation.

- There are likely other timers in the OWP that provide attackers with similar

  capabilities (e.g. performance.now() + edge thresholding), but so far they

haven't been convincingly, publicly demonstrated to be equivalently useful to

attackers in this context.)

If Chrome ships features that enable high-res timers without gating them on

restrictive mechanisms like html/4175 mentioned above, one of the following

will happen:

1. Other browsers similarly ship WASM threads et al. without restrictions. We

cement into the platform the ability to subvert the SOP via a class of attacks

that we currently know to be possible.

2. Other browsers gate these features on restrictive mechanisms. Then, either

of the following happens:

  2a. Developers use these features without making their applications

compatible with the restrictions necessary in other browsers. These

applications become usable only in Chrome; developers get a lot of bug reports.

  2b. Developers build their applications to work under both models (e.g. with

auto-upgrading of `no-cors` fetches to `cors` and without).

Unless we embrace #1, my guess is that we will effectively force developers

into #2b, where in order to have a site that works cross-browser they will have

to take into account two very different resource fetching models. Practically

speaking, this is likely to cause a substantial amount of pain especially

because non-trivial applications may load external resources at any point, have

dependencies on external libraries which can change what they load at runtime,

etc. (We've seen some of these problems in allowlist-based CSP deployments;

similar problems will arise here, but they will be harder to find and debug.)

Under #2b the amount of developer pain due to browser differences in the long

term seems to outweigh the short-term pain if Chrome moves to a model which

requires html/4175 for the use of WASM threads & SABs. This is especially true

if we expect the use of WASM threads etc. to grow significantly over time; i.e.

if a decade from now they have 100x more adoption, will it still have been a

good deal to not force the users we have today into a model that's consistent

cross-browser?

As a security engineer, I worry -- significantly -- about #1. As a developer, I

worry about both #2a and #2b. It would really seem like a Good Thing for

browsers to align here.

Cheers,

-Artur

[Yoav Weiss]

I share Artur's concerns. Shipping this without `no-cors` restrictions on some platforms/browsers but not others would lead to bad outcomes on the security front, the compatibility front, or both.

Unless we are convinced that other browsers will be able to follow Site Isolation's footsteps and avoid that requirement, I'd be very wary of shipping this without restrictions that other browsers (or even other Chromium platforms) will most likely need to ensure their users' safety.

How far away is the CORS-only future all the cool kids keep talking about?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c1d4401d-5f01-4ef7-9c9a-c0d438e9cf95%40chromium.org.

[Michael Hablich]

Hi,

I think it would be beneficial to split this thread into two pieces:

- The actual intent to ship about the actual API that should ship (Wasm Atomics), which do not add more relevant attack surface to the WP, than what is already available anyway (JS Atomics).

- Gating high precision timer potential behind headers or not ... which AFAIK is already happening around https://github.com/whatwg/html/issues/4175 anyway?

Cheers,

Michael

[Chris Palmer]

On Fri, Feb 1, 2019 at 2:43 AM Michael Hablich <hab...@chromium.org> wrote:

I think it would be beneficial to split this thread into two pieces:

- The actual intent to ship about the actual API that should ship (Wasm Atomics), which do not add more relevant attack surface to the WP, than what is already available anyway (JS Atomics).

- Gating high precision timer potential behind headers or not ... which AFAIK is already happening around https://github.com/whatwg/html/issues/4175 anyway?

I agree. For the purposes of this Intent To Ship, I agree with Michael that this Intent does not create new risk beyond has already shipped.

For the wider high-res clocks discussion, I'll fork a new thread. For safety, let's stop sharing memory between this thread and that one, since that can become a kind of clock. ;)

[Chris Palmer]

To judge how bad #2b would be/how long the badness would last, I think it's crucial to get an answer to Yoav's question: "How far away is the CORS-only future all the cool kids keep talking about?" Do we have a shipping plan for that?

From a security point of view, a CORS-only future is beautiful indeed, and (like Site Isolation) would address a wide variety of problems (including the cross-origin performance timing stuff). It might turn out that, even if Chrome doesn't end up requiring CORS-only for SAB/WASM/precise clocks, Chrome might require it for enough other things that it ends up being common enough, soon enough, that scenario #2b is short-lived and/or not too bad.

To Artur's point about the lack of an open source coarse-grained clock attack, I consider https://alephsecurity.com/2018/06/26/spectre-browser-query-cache/ (scroll down to "Overcoming the data timing mitigations with a low resolution and jittered timer") a bit too close for comfort. (Note that they say Firefox' reduction of performance.now to 2 ms resolution stymied them in this case. I continue to believe that it's not likely to be possible to even enumerate all the explicit and implicit clocks* in the OWP, let alone hammer them all down to something like 2 ms.)

Finally, I'll reiterate that micro-architectural side-channel vulnerabilities, as awesome as they are, are not worlds apart from other problems we have always had to deal with:

  * Regular C/C++ OOB reads are rampant, and using them to quietly exfiltrate cross-origin or browser memory has long been public (example from about a decade ago, probably not the oldest example). (Here is a subset of the public OOB reads in Chromium.)

  * Sandbox escapes are, even if not rampant, Generally A Thing.

  * OWP-defined timing and size side-channels abound (both accidental and intentional).

Again, a CORS-only world will help with a lot of that, and we should try to get there. But the game is about reducing risk and increasing benefits, not about Sudden Total Perfection. I agree that we could reduce more risk faster if we ship and require CORS-only mode for powerful capabilities as soon as possible.

But at the same time, we have to provide stable benefits on a brisk schedule. We need the OWP to remain a high-value platform for developers to ship good apps on, because it's the most open platform that has a modern security stance.

* That bug is private for now, but some Chromium and Mozilla people have access. Ping me if you have a need and are a browser security friend.

[Michael Hablich]

Thanks for splitting the discussion Chris.

On Fri, Feb 1, 2019 at 11:26 AM Yoav Weiss <yo...@yoav.ws> wrote:

I share Artur's concerns. Shipping this without `no-cors` restrictions on some platforms/browsers but not others would lead to bad outcomes on the security front, the compatibility front, or both.

Unless we are convinced that other browsers will be able to follow Site Isolation's footsteps and avoid that requirement, I'd be very wary of shipping this without restrictions that other browsers (or even other Chromium platforms) will most likely need to ensure their users' safety.

In order to make sure your concerns are answered directly: WebAssembly Threads do not provide a bigger surface than the already available SAB+JS Atomics. They are like JS Atomic's twin. It would be surprising for developers to require a special header for Wasm Atomics.

[Ben L. Titzer]

On Mon, Feb 4, 2019 at 1:27 PM Michael Hablich <hab...@chromium.org> wrote:

Thanks for splitting the discussion Chris.

On Fri, Feb 1, 2019 at 11:26 AM Yoav Weiss <yo...@yoav.ws> wrote:

I share Artur's concerns. Shipping this without `no-cors` restrictions on some platforms/browsers but not others would lead to bad outcomes on the security front, the compatibility front, or both.

Unless we are convinced that other browsers will be able to follow Site Isolation's footsteps and avoid that requirement, I'd be very wary of shipping this without restrictions that other browsers (or even other Chromium platforms) will most likely need to ensure their users' safety.

In order to make sure your concerns are answered directly: WebAssembly Threads do not provide a bigger surface than the already available SAB+JS Atomics. They are like JS Atomic's twin. It would be surprising for developers to require a special header for Wasm Atomics.

It's also worthwhile to point out that the addition of an atomics API offers no new threat beyond SABs. The timer construction with SAB does not require, nor benefit from, atomics.

[Anne van Kesteren]

On Mon, Feb 4, 2019 at 1:50 PM 'Ben L. Titzer' via blink-dev
<blin...@chromium.org> wrote:
> It's also worthwhile to point out that the addition of an atomics API offers no new threat beyond SABs. The timer construction with SAB does not require, nor benefit from, atomics.

To be clear, the concern is not about new threats beyond SABs. It's
that some of us consider Chrome's SAB precedent bad and not likely to
lead to an interoperable end state. Further cementing the SAB decision
with additional features would therefore not be helpful and go counter
to the goal of having an interoperable web.

I also wanted to ask for a clarification. Early on Chris Palmer said

"Lots of specifications have implementation-defined behavior, because

it's often necessary." I don't share that experience. Apart from
various resource limits and performance characteristics, web standards
go to great lengths to not have undefined behavior as this is often a
source of issues. Where does the sentiment come from that lots of
specifications nevertheless have implementation-defined behavior?

[Chris Palmer]

On Mon, Feb 4, 2019 at 5:41 AM Anne van Kesteren <ann...@annevk.nl> wrote:

I also wanted to ask for a clarification. Early on Chris Palmer said
"Lots of specifications have implementation-defined behavior, because
it's often necessary." I don't share that experience. Apart from
various resource limits and performance characteristics, web standards
go to great lengths to not have undefined behavior as this is often a
source of issues. Where does the sentiment come from that lots of
specifications nevertheless have implementation-defined behavior?

(To be clear, implementation-defined behavior is not the same as undefined behavior.)

There are tons of examples. In C/C++, there's lots of implementation-defined behavior, including some that affects the OWP (e.g. the number of bits in size_t). Even on 64-bit systems, for example, the OWP does not guarantee that a document/origin/script/thing can use more than (say) 4 GiB of memory. (Indeed, we have tried to assert a memory size limit for renderers in Chrome. We've had to loosen it a few times, but we were not adhering to a definition in the JS or WASM specs, for example.) Tons of specs have MAYs and SHOULDs; tons of specs are vague on crucial details, and give implementations lots of freedom. (This is a feature!) For example, the Workers spec says:

"""

When a user agent is to run a worker for a script with URL url, an environment settings object settings object, and a URL referrer it must run the following steps:

Create a separate parallel execution environment (i.e. a separate thread or process or equivalent construct), and run the rest of these steps in that context.

"""

[Anne van Kesteren]

On Mon, Feb 4, 2019 at 8:25 PM Chris Palmer <pal...@chromium.org> wrote:
> There are tons of examples. In C/C++, there's lots of implementation-defined behavior,

I don't think that really counts as far as web standards go. In fact,
C/C++ are often used as an example of the type of thing that does not
work on the web.

> For example, the Workers spec says:

Thanks, I filed https://github.com/whatwg/html/issues/4339 on that. It
really needs to be much clearer here. A dedicated worker creates an
agent and a shared worker an agent cluster (with an agent for itself
therein).

Also, I agree that implementation strategies should be allowed to vary
in the realm of resource limits, performance, and "black box" details.
But my point is that this is not that. Code that would execute on
Chrome not for Android would throw on Chrome for Android. That's very
different from whether an implementation puts a new agent in a thread
or a process.

[Chris Harrelson]

The API owners met to discuss this intent yesterday.

Our consensus was that that this new feature does not introduce additional security issues beyond what is already present.

However, we also had consensus that it is not clear whether we will achieve eventual cross-browser interop on this feature, because of possible disagreement on whether cross-origin resources should be blocked or sufficiently restricted. We think this issue makes the interop story incrementally worse than it already is with SharedArrayBuffer. Also, we predict that other future features may also suffer from the same problem.

To resolve this, we believe more discussion is needed about how to achieve eventual interop.

Chris

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78gTMVwxBFxDrVG0GgYDB-wcfbVOQdcNDzEwpp947NDopw%40mail.gmail.com.

[Chris Harrelson]

(API owner hat off...)

PSA: To help move things along, I have started some conversations along these lines within Chrome.

[Chris Palmer]

Additionally :) :

Chrome and Chrome Security are committed to (and excited by!) developing standards for an eventual future in which browsers won't load 3rd-party subresources with credentials or without CORS. Presumably this would first be by the document's or origin's opt-in, but ultimately we'd love to see that as the default behavior on the web.

We appreciate that Site Isolation doesn't fully protect people from side-channel attacks. We're committed to investing in a solution and engaging with other browsers and the OWP community on a design.

[Chris Palmer]

Additional addition, for clarity: This includes aspiring to unify the behavior across Desktop Chrome and other browsers as soon as would be possible.

[Anne van Kesteren]

On Fri, Feb 22, 2019 at 12:17 AM Chris Palmer <pal...@chromium.org> wrote:
> This includes aspiring to unify the behavior across Desktop Chrome and other browsers as soon as would be possible.

Thank you, that sounds terrific. Mozilla would also love to ship this
soon as I hope we made clear in the isolation-policy meetings. Looking
forward to making it happen together!

[Rick Byers]

It sounds to me like there's no good reason to block shipping WASM threads in chromium at this time, so LGTM1 from me.

But I agree that it's really important that we actively invest (together with Mozilla and others) in fully addressing the underlying security issues here by fixing the architecture of the web such that security boundaries can reasonably be fully aligned with OS process boundaries. So far our site isolation work has been constrained by a goal of preserving all existing web semantics, and I agree it's time to relax that requirement. I've volunteered to support Chris and the security team in formulating a migration path (guided by concrete web-compat data) for making the necessary breaking changes. But that's obviously going to be an ongoing journey - not something we can reasonably block every new timer on without a really compelling security threat.

Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78hmLLyvo9sokvKv_e%3Dpngk8AzxumFGc2Geqg9M0fojOQQ%40mail.gmail.com.

[Anne van Kesteren]

On Fri, Feb 22, 2019 at 5:22 PM Rick Byers <rby...@chromium.org> wrote:
> It sounds to me like there's no good reason to block shipping WASM threads in chromium at this time, so LGTM1 from me.

That's not how I read this at all. All the reasons stated upthread
still apply. In particular, shipping this would make it more difficult
to arrive at a solution that's interoperable cross-browser; e.g.,
isn't different between Chrome and Chrome for Android.

> But I agree that it's really important that we actively invest (together with Mozilla and others) in fully addressing the underlying security issues here by fixing the architecture of the web such that security boundaries can reasonably be fully aligned with OS process boundaries. So far our site isolation work has been constrained by a goal of preserving all existing web semantics, and I agree it's time to relax that requirement. I've volunteered to support Chris and the security team in formulating a migration path (guided by concrete web-compat data) for making the necessary breaking changes. But that's obviously going to be an ongoing journey - not something we can reasonably block every new timer on without a really compelling security threat.

This is not at all what I was referring to. It sounds interesting, but
this is not something I've seen discussed thus far.

[Rick Byers]

On Fri, Feb 22, 2019 at 11:40 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Fri, Feb 22, 2019 at 5:22 PM Rick Byers <rby...@chromium.org> wrote:
> It sounds to me like there's no good reason to block shipping WASM threads in chromium at this time, so LGTM1 from me.

That's not how I read this at all. All the reasons stated upthread
still apply. In particular, shipping this would make it more difficult
to arrive at a solution that's interoperable cross-browser; e.g.,
isn't different between Chrome and Chrome for Android.

Thanks, I understand. I'm saying I agree with palmer@'s perspective on this and trust the judgement of the chromium security team to strike the right balance here for the chromium project in terms of security risk vs. availability of powerful features.

In terms of interop risk, I fail to see how the interop risk is fundamentally different from any other capability that ships in some browsers/platforms ahead of others (or potentially never in others). The capability here is "access to high-res timers without opting into any restrictions on which sub-resources can be loaded and how". Even once we have shipped features for enabling restrictions, we believe that unrestricted capability will be a valuable property for chromium to provide where it's believed to be safe to do so (as Chris says, we have no plans to block SAB access on desktop). Chrome security feels comfortable with chromium desktop supporting that capability, believes we will be able to also ship the capability to Android in the future, and has plans to significantly further strengthen defenses against timing attacks to reduce the security risks of having this capability.

Since access to high-res clocks is reasonably feature-detectable, this doesn't seem fundamentally different in terms of "fragmenting the web" to me than, for example, shipping PaymentRequest on Chrome Android before it's ready to ship in other browsers and chromium platforms. I understand and respect that Mozilla and others would prefer that capabilities are added to the web only when there is consensus to make those capabilities available broadly / consistently. But In general we aren't willing to let a lack of implementation/investment in one context (in this case, Chrome on Android and other engines) delay availability of capabilities we feel are urgent to the success of the web in other contexts (in this case gaming and other uses cases for SAB and WASM threads on desktop chromium browsers and Chromebooks).

It's possible I'm missing something here though - this obviously an area in which I lack deep technical expertise. If so, perhaps we could make it more concrete by focusing on the tests? Is there an example of a reasonable web-platform-test which would pass in one context (eg. chrome desktop) but fail in another (eg. chrome android or Firefox) due to reasons other than the API it's trying to use not being present? To me, such examples would be concrete interop risk we need to evaluate and likely mitigate to pass the blink launch bar.

IMHO "interop risk" in the context of the blink launch process is not about trying to ensure a capability is either available everywhere or nowhere, it's about maximizing the chance that when an API is available to web developers, that capability behaves consistently and predictably and that we've done everything reasonable to minimize the cost for future implementations should there be such interest.

I assume chromium will stick to it's plan to continue to make SAB available on desktop browsers without restriction, while continuing to invest in mitigating the security threats of timing attacks. It sounds like Firefox has no plans to ever make SAB available in such a configuration. That's fine - it sounds like we just need to agree to disagree on the availability of this capability for now (as we have with so many other capabilities). Perhaps chromium will ultimately be convinced by new security threats, or perhaps Mozilla will ultimately be convinced by the utility of the capability and reduced threat from future mitigations (or perhaps neither). 

But that's all a separable decision from choosing to collaborate on the restriction features which can be used to further increase security and availability of high-res timers in more contexts. It sounds like there's good agreement around the importance of that, and so that's where we can get the most value out of collaborating.

[Chris Palmer]

On Fri, Feb 22, 2019 at 9:48 AM Rick Byers <rby...@chromium.org> wrote:

I assume chromium will stick to it's plan to continue to make SAB available on desktop browsers without restriction, while continuing to invest in mitigating the security threats of timing attacks. It sounds like Firefox has no plans to ever make SAB available in such a configuration. That's fine - it sounds like we just need to agree to disagree on the availability of this capability for now (as we have with so many other capabilities). Perhaps chromium will ultimately be convinced by new security threats, or perhaps Mozilla will ultimately be convinced by the utility of the capability and reduced threat from future mitigations (or perhaps neither).

Well, not quite. By "aspire to unify" I meant that, in the medium-term, we would start applying the same policy on Desktop as on Android as on other browsers — whatever that might end up being. Time will tell what we end up needing, what's possible, what's effective, and what's compatible. And in the long term, no-creds-for-subresources-without-CORS/similar* should obviate many of our current problems.

For the sake of developers and everyone, I would very much like the OWP to present a single, simple story for How To Get SABs In Your App. But for now, Chrome has made a commitment to press forward, and so we shall.

* We're going to need a more catchy name. ;)

[Rick Byers]

Sorry for the confusion. I'm OK with such a plan as well if we can pull it off. Definitely that's preferable if we can do it in a reasonable fashion. My point only was that it's not reasonable to block shipping WASM threads on figuring out the concrete plan (unless we also decide to unship SAB again as well).

[Yoav Weiss]

That plan sounds *extremely* reasonable to me. Striving for unification around SAB restrictions would be great indeed, and such a restricted mode will potentially enable us many more things beyond just high-res timers.

I don't think we currently know exactly what those restriction should look like, and which use-cases, if any, won't be covered. (and how we can make sure that critical use-cases won't be left behind)

Therefore, and given the fact that WASM threads don't increase our exposure beyond the already-shipped SAB, I don't think it would be reasonable to block this intent on figuring out all the details.

LGTM2

* We're going to need a more catchy name. ;)

 

NCFSWC just rolls off the tongue :P 

[Chris Harrelson]

My reasoning is very similar to that Yoav already stated. In particular, given what Chris Palmer stated from the security team's perspective, I see a path to eventual interop (and I think this thread played a useful role in understanding these issues and helping the web get there sooner). In the meantime, this feature does not increase exposure beyond SAB, so LGTM3.

Happy launching.

 

LGTM2

* We're going to need a more catchy name. ;)

 

NCFSWC just rolls off the tongue :P 

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhLSWhGXmJiwQcaRQjf6jHvWr696TOGuaJxQ4AnD%3DtDpA%40mail.gmail.com.

[Michael Hablich]

Thanks, folks!

[Rick Byers]

I just wanted to add that after talking more with some folks privately (both Google and Mozilla), I realize I did not articulate my concern for the real interop risk here adequately enough. In this whole space of nanoscale timers, there is indeed real serious interop risk whenever Chrome Desktop permits weaker restrictions than other browsers (eg. games launching which run only on Chrome desktop due to not having sufficient incentive to enable the restrictions). We must work hard to find a consistent set of restrictions that most major implementations are comfortable with, and be willing to accept some level of breaking change in Chrome in the future to achieve unification ("accepted interop risk" criteria).

There is some risk that we won't be able to find an acceptable trade-off (eg. if it boils down to asking developers to choose between shared memory and any reasonable ability to monetize their application). But it probably wasn't worthwhile to speculate here on what we should do in that case (certainly there is no consensus, even within Chrome team). Suffice it to say that we generally don't hold important new capabilities hostage only based on fear of this sort of fragmentation risk.

Hopefully it goes without saying that we will always put the security of our users first, and so reserve the right to eliminate any platform capability from Chrome if doing so meaningfully improves user security in practice (and we invest heavily across at Google to monitor the real threat landscape). In an emergency such changes aren't even subject to this blink launch process so Chrome security team has final say without even consulting Blink API owners. The longer we run without shipping agreed-upon risk mitigation restrictions, the greater the risk that we'll again find ourselves in a position of needing to entirely disable SAB and Wasm threads without notice due to a security incident. So it should be clear to everyone involved that work on restriction APIs is high priority.

Anyway I'm sorry for down-playing the real interop risk here. As always, while boldly shipping to unblock important use cases, we need to work together on a consensus for the right long-term design for the web as a whole.

Rick 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF2MX8iioPr7PgrRAURnA_nu7AJALN026b9EzDu%2BG567oo_k3A%40mail.gmail.com.