[web-api] Deprecate cross-origin Module sharing

[camillelamy]

Currently, modules can be serialized and shared with other context in the same agent cluster (see spec here). Agent clusters are scoped to sites instead of origins by default, which means that modules can be shared with a same-site but cross-origin contexts. To improve mitigations against attacks like Spectre, we are aiming to make agent clusters scoped to origins instead. To do this we must deprecate document.domain (see plan) and sharing of WASM modules cross-origin. The latter is used by 0.06% of web pages at best according to our metrics, so we could proceed with deprecation right away. The plan would be to store the origin as well as the agent cluster in the serialization step, and to check it when passing the module.

[Ms2ger]

Have browser vendors made public statements on their intentions to do this?

[camillelamy]

I am writing on behalf of Chrome Security OWP, and we would like to deprecate this in Chrome.

[mikewest]

/cc @annevk who's been thinking about this from Mozilla's perspective. I filed mozilla/standards-positions#517 in the hopes of getting an official position.

[annevk]

Even if you can prevent deserialization, how do you prevent handing a reference to a same-site cross-origin frame? I worked through a whole [SameOrigin] IDL attribute for serializable objects until I realized it would not work.

See whatwg/html#4940.

[mikewest]

I think this breaks into two pieces: the one piece governs the cross-origin serialization (this issue), the other governs access to cross-origin frames (deprecating document.domain). It seems reasonable to me to address them separately, as the latter is going to take much more time to address than the former, given their respective usage.

[annevk]

Well, but what scenarios are you really breaking if they can hand over the module without using the serialization infrastructure?

[mikewest]

We're reducing the problem to document.domain, which both chips away at the underlying problem, and prevents folks from adopting patterns we're aiming to remove. That doesn't solve the problem, but it does make it smaller.

[annevk]

I'm not sure how that answers my question?

Let me ask another question, what would the new checks be? Would they match the PR I referenced above?

[mikewest]

Skimming that PR, I think we're talking about the same checks. I simply disagree with your conclusion in whatwg/html#4940 (comment).

[camillelamy]

Yes this is the same kind of checks. While changing Agent Cluster keying is the better long term solution, this requires both usage of document.domain and WASM module sharing to be low. The latter one is already very low, and we wouldn't want to see it increase while we work on driving down the former. Introducing this kind of checks helps achieving that.

[annevk]

It might, or it might keep people sharing it directly. They have no reason to use postMessage() for the scenario under discussion, which is why I'm not really convinced it's worth the effort. (And acting as if it's origin-bound while it's really not might also give a false sense of security.)

Have you considered storing the origin on WebAssembly.Module instances and making WebAssembly.instantiate() reject cross-origin instances?

Also, in the back of my mind there's a thing @lars-t-hansen once told me, that sharing WebAssembly.Module instances across process boundaries is perfectly feasible. I'm not sure if the Wasm folks are still considering that, but that would make this kinda moot.

[lars-t-hansen]

I could believe that I did say that, though I suspect what I had in mind was for a module to be serialized (as we serialize it now to cache the compiled representation) and deserialized in the other process. "Sharing"? Sort of. We might think that, as there is a serialized representation, there is also a way of placing the module (and only the module) in a shared memory segment, and indeed sharing that segment. That's probably more of a leap; the deserialized representation may in principle have parts that depend on per-process state, eg GC, executable memory managers, and so on.

[annevk]

That's my bad on the imprecise language, I did indeed mean serialized, not transferred (or shared in the memory sense).

[dtig]

I'm looking for some guidance on how to proceed, there seems to disagreement on the the premise of the checks themselves. @camillelamy/@mikewest do you have more information on the status of document.domain deprecation and/or are able to give us alternate approaches for the checks that have consensus across browsers?

It might, or it might keep people sharing it directly. They have no reason to use postMessage() for the scenario under discussion, which is why I'm not really convinced it's worth the effort. (And acting as if it's origin-bound while it's really not might also give a false sense of security.)

Have you considered storing the origin on WebAssembly.Module instances and making WebAssembly.instantiate() reject cross-origin instances?

The module itself is too low level to have that information, he Web spec references the HTML spec, and doesn't have its own notion of an origin.

Also, in the back of my mind there's a thing @lars-t-hansen once told me, that sharing WebAssembly.Module instances across process boundaries is perfectly feasible. I'm not sure if the Wasm folks are still considering that, but that would make this kinda moot.

Instances (which are the executable units) are not shareable across cross process boundaries. While we do cache compiled modules it's not "shared" in the same sense. But maybe I'm misunderstanding the premise of this point?