Note interaction with import assertions

[guybedford]

This adds a section on import assertions following up on the recent dicussions wrt the security properties of Wasm imports.

This makes it clear that an assert { type: 'wasm' } is not a supported pattern and that instead it is only evaluator attributes that may interface with the ESM integration.

[annevk]

Can WebAssembly itself import things through the same conceptual model? Does that support these kind of assertions so it can distinguish between JS+Wasm / JSON?

[xtuc]

@annevk we planned to add the import assertions abilities to Wasm but we don't have a proposal yet, but ideally it's same as JS. I'm not sure to understand the second question, do you mean restricting what the Wasm module can import?

[annevk]

Great, yeah, that if you import something in Wasm without an assertion that it won't allow JSON and if you assert JSON it won't allow Wasm or JavaScript.

(Note that treating JavaScript and Wasm as equivalent will also require HTML Standard changes, though assertions itself is also not done yet so...)

[devsnek]

we had discussed a custom section for esm assertions at some point, but the proposal was a lot more nebulous back then. we could probably spec out something more concrete at this point.

[xtuc]

@devsnek yes I agree and I'm happy to start something. It also depends on the outcome of #44.

[littledan]

I think the answer here depends on the resolution to #44 . If importing a Wasm module gives you a WebAssembly.Module object, then it is in fact lower-privilege than importing JS, and should come with an import assertion. However, the current proposal is equivalent privilege, so it may be OK to leave it out.

I'd like to include @rniwa in this conversation, as he expressed a preference for including the type explicitly, though stated that omitting it would be not as problematic as the JSON/CSS case.

[guybedford]

I've updated this PR based on the current status - no longer referencing the evaluator attribute proposal, moving the text to the linking section and clarifying that import assertions should not be mandated for Wasm.

[takikawa]

Thanks, this makes sense to me. One place where I wanted to clarify my understanding is the point Dan brought up a while back:

If importing a Wasm module gives you a WebAssembly.Module object, then it is in fact lower-privilege than importing JS, and should come with an import assertion. However, the current proposal is equivalent privilege, so it may be OK to leave it out.

The current proposal only supports providing an instance. But in the future this may be extended in the case of module linking and the import reflections proposal that you're working on. In that future, this lower-privilege behavior would be entirely specified with just the reflection type and no need for an assertion in addition right?

Relatedly, does this mean the moduleType in the HTML spec for Wasm modules imported with Wasm/ESM should have "javascript" type or is this a separate issue?

[guybedford]

@takikawa appreciated for the review.

In that future, this lower-privilege behavior would be entirely specified with just the reflection type and no need for an assertion in addition right?

Yes exactly, the import reflections proposal by definition implies a lower level of privilege on its own without any other assertion being necessary for security (although one could be used as it does still support assertion syntax).

The module type issue in HTML is one this spec might need to tackle when it comes to HTML integration, possibly renaming "javascript" to "moduleexec" or something similar. Alternatively Wasm could define its own type, and refactor the HTML spec to not immediately associate the type until later on using a book-keeping process instead for assertion validations rather than immediate type association.

[guybedford]

@takikawa would you be happy to go ahead and merge this PR then?