I'd have the WebAssembly spec spell its own name out fully :)

I can picture some different editorial choices here (e.g., using an HTML-style wording-based hook rather than a ES-style abstract operation), but I'm happy with the decisions here personally.

Is there cross-browser consensus on these semantics? In particular, does anyone want to any sort of CSP checks when constructing an instance from an already-compiled module?

Is there a PR I can review for how these hooks are implemented by another specification?

Otherwise LGTM.

Is there cross-browser consensus on these semantics?

No.

OK, I'd suggest waiting to land this patch until we can work out the differences.

I'm OK for this patch moving forward without consensus, since it's an outstanding proposal repository. I think we can iterate here in this overall direction, and reach consensus separately with webappsec people's input.

Is the disagreement documented somewhere?

@annevk our implementations diverge significantly, and we haven't agreed on where to converge. WebAssembly/design#1092 has some fo the discussion. This proposal tries to get to a point where we agree, but I don't feel like it's at a point where we can evaluate a full picture that we'd agree on.

I'm happy moving forward as Erik proposes here, and later discussing a full proposal and try to agree on it.

Maybe we should have a higher level conversation about what goes in the specification and how we want to go about resolving compatibility issues for WebAssembly between implementations. In my mind, the goal of writing a specification for a feature that already shipped would be making implementations compatible; I'd like to understand others' perspectives. This is coming up in a number of places at once.

@littledan I'm looking to try and move this proposal forward. Some progress was made on alignment after this PR, see for example #16. It seems that the main disagreement was whether instantiation needs to be CSP-gated in addition to compilation (or is there more disagreement that I'm missing?)

This PR still looks reasonable to me editorially.

Is there a matching definition of these hooks somewhere (e.g., in the Web API spec + the CSP spec)?

Do we know if WebKit is OK with these semantics, given the explanations made in #16? @saambarati @kmiller68

If we all agree that compilation rather than instantiation is the right place to block WASM that's fine. I'd still prefer to do the check at instantiation in case a module "leaks" across origins but I'm not going to fight it.

To double check, it's semantically unobservable to check at both instantiation and compilation? If that's not the case then I want to say we should require checks in both places. That's probably what JSC is going to want to implement given the spec doesn't check at instantiation only.

Is anyone aware of a downside to checking in both places in the spec? I am not sure it is completely unobservable.

@kmiller68 you mean same-site-cross-origin or something else? Why is CSP the right place to enforce that?

Is anyone aware of a downside to checking in both places in the spec? I am not sure it is completely unobservable.

I'm guessing a CSP check is relatively small compared to the cost of instantiation, so if we need to check at compilation and instantiation, it's probably OK from that perspective.

OTOH, I don't really see how a Wasm module could "leak" into an environment with stricter CSP requirements, but that may just be my ignorance w.r.t. CSP works.

IIRC, we'd discussed whether one should be able to postMessage a Module (or something similar) between parts of a page with different capabilities. CSP was one example, but this was in a wider context of "what if some code is allowed to compile but not instantiate, and another is allowed to instantiate but not compile, should it be possible for one to compiler then had off to the other for instantiation", as well as other combinations of capabilities.

Since postMessage()'s security-design is by-and-large object-based capabilities and the receiver is in control it's not clear to me how it matters that the sender and receiver might have different policies. And note that CSP isn't the only policy in play here, there's also referrer policy, permissions policy, etc. It's very likely those will differ, also between a document and a worker, which cannot have all of the same policies. (Also, Module is restricted to an agent cluster (at most a site, but if you want to use shared memory an origin) so you're already pretty limited in what you can do.)

@kmiller68 does JSC still generate code during instantiation? Is that part of the concern here?

@annevk

Since postMessage()'s security-design is by-and-large object-based capabilities and the receiver is in control it's not clear to me how it matters that the sender and receiver might have different policies.

Do you mean that a CSP policy check would be done when the Module object is received, or am I misunderstanding?

The opposite, I don't think it makes sense to do policy checks around messaging. I suppose you could limit object creation and that in turn would influence what can be messaged, but you might be able to work around that as well if there are inconsistent policies across documents.