API Concerns with Structured Clone for Wasm Modules

[flagxor]

Some have expressed concerns that structured clone for wasm modules is a bad choice of contact point into the web platform.
In particular, it has these drawbacks:

• It encourages modules with the origin in which WebAssembly.compile was done, rather than the url of the bytes came from.
• It encourages use of IndexedDB as an application managed compilation cache, rather than leveraging the existing caching mechanisms in the browser. Requiring middleware vendors to get the caching pattern right.
• It encourages use of postMessage for module for cross-origin shared modules.

We have casually assumed that the current mechanism would soon be augmented by support for WebAssembly.compile of a ReaderStream (for instance from fetch), to allow streaming compilation.
We've also discussed the possibility of surfacing wasm modules as es6 modules.

Have we found the right contact point?
Alternatives exist such as:

• Expand the Cache (service worker API) to support wasm compilation and explicit caching of wasm code, and knowing when it's actually compiled.
• Ensure Foreign fetch allows the possibility of sharing a wasm module cross-origin.
• Pass an URL instead of an ArrayBuffer to WebAssembly.compile. Using things like blob urls for dynamic cases.

We've already implicitly assumed we'll want to support more options.
Will any of those subsume the current interface to the point we'll want to deprecate it at some point?
Do we want to consider limiting the scope of structured cloning to plan for better future patterns?

[titzer]

Another option which I personally prefer would be to allow a new XmlHttpRequest response type (e.g. WebAssembly.Module), which doesn't introduce new API surface area and is an even stronger hint to the browser to start, e.g. streaming compilation while downloading.

[lukewagner]

The main two specific concerns that I've heard so far that make sense to me are:

• window.postMessage and window.onmessage are error prone APIs that are generally discouraged and we shouldn't be encouraging use of these APIs for people wanting cross-origin caching/reuse
• use of IDB to cache code in insecure contexts makes it easier for a one-time MITM attack (against the insecure origin) to permanently poison the site

If we all agree on these concerns, then I think both could be addressed conservatively by:

• disallowing structured clone of a Module to a window (only allowing postMessage to workers)
• disallowing the storing of a Module in IDB in insecure contexts (which follows from the general principle of restricting powerful new features to secure contexts)

Looking forward, and building on basic structured cloning support, we could then incrementally evolve to:

• have WebAssembly.compile/instantiate take a stream, as has been proposed
• integrate with Service Worker and the Cache API, leveraging Foreign-Fetch to support a safer-by-default way to cache/reuse code across origins

I think this strategy wins by supporting all the short-term caching and code-sharing needs of wasm without blocking on Service Workers (with new, to-be-defined APIs) in all browsers and also providing powerful primitives (viz., structured clone of modules) that can be used in other ways that wouldn't otherwise involve Service Workers (EWM etc).

There's also the idea to push all the caching into the browser (having all the APIs take URLs, using Blob-URLs for dynamically-generated content). Just from a predictability point of view (and taking into account all the arguments for Service Workers over the HTTP cache), I think this is not a great option. I totally agree we should make loading a wasm module as easy as a <script> tag, but I think that even in this case, caching should be handled by a Service Worker that intercepts the <script> request.

(cc'ing @annevk @bzbarsky @wanderview @asutherland for any comments)

[bzbarsky]

window.postMessage and window.onmessage are error prone APIs that are generally discouraged

This is the first I've heard about this so would appreciate concrete pointers. In particular, postMessage is supposed to be the API for cross-site communication, so if it's being dicouraged, what is being encouraged instead?

[lukewagner]

(Mostly forwarding @jeisinger's comments, so feel free to chime in)
@bzbarsky Maybe I overstated the case, but just these Security Concerns about needing to verify the sender's origin.

[bzbarsky]

Well, right, you have to do that. :)

[titzer]

Other advantages of using an XHR response type are:

• the browser gets to prepare for streaming compilation as soon as possible, e.g. even as it starts network requests
• WebAssembly.compile() is nominally implemented in the JS engine and it'd be weird for it to either have an API out to its embedder to handle URLs, or for it itself to be implemented by the embedder
• XHRs inherently have origin URLs attached to them, whereas Streams do not necessarily.

[esprehn]

As discussed in the other thread, I don't think postMessage of wasm modules makes sense. It seems to be addressing the issue that .compile() doesn't accept a URL like JS/CSS/etc. so the underlying system can't implement streaming and caching for you like we do for other resources.

In general I don't see a difference between WASM, JS, CSS, Images, and the other resource types. They all are:

• Expensive to parse and compile.
• Used in multiple frames on the same page.
• Need async and stream processing.
• Need caching.

So far the platform has handled the resource caching implicitly. Having the platform handle it has been hugely beneficial to us as we've evolved the underlying system to use different caching strategies over the past several years. Implementing an effective strategy yourself in script is very difficult because you don't have access to things like the system memory limits, pressure signals, number of open tabs and frames, what CPU state the device is in, if it's plugged in, etc.

Separately given the security issues of sending compiled code across the origin boundary, I don't think we can allow sending pre-compiled code cross origin. Anything you send will need to be recompiled on the other side. It's basically the same as sending a string and asking the other end to call eval() on it in JS today.

I think what's missing here is a .compile(url) => Promise<WebAssembly.Module> API, integration with <script src>, <link rel=preload>, integrity hashes, etc.

@titzer Having .compile() take a URL which is implemented in the embedder is no more weird than ES modules having import statements that need to be fetched by the embedder.

[esprehn]

@drufball @bfgeek

@esprehn The performance of wasm code depends on baking in information that depends on the target features and the resources allocated or promised. Many use cases have been deferred to being implemented in user code in a translation stage between the data streaming in and the web browser wasm compiler. For example: user defined code compression strategies; dealing with differences between web browsers in their wasm implementations; taking advantage for performance enhancements that might have spotty deployment; etc. Perhaps this strategy of deferring these use cases was just wishful thinking and not practical, but it might have a lot of benefits if practical.

This translation stage might practically run in a separate context if that helps, a context with limited inputs so that it could be re-run with only those inputs to generate the same output, but it still needs input of the target features and some of the allocated or promised resources.

This translation stage might need to re-run even between instances on the client side, for example to deal with feature changes between browser versions, or even just changes in the available resources. E.g. The first instance of a game might get a lot or fast memory, and the second only a limited amount of slower memory, both needing separately compiled binary code to run.

[jeisinger]

I would like to see an API that allows for strongly tying a WebAssembly module to an origin. We should require CORS for exceptions throwing inside a cross origin module to bubble to the embedder, and we should be able to do mixed content checking.

I think that once we tie modules to origins, all use cases that currently require structural cloning would naturally work.

You wouldn't need the other origin postMsg'ing a module to you, you can just request it by specifying the URL. You also don't need to have a message handler with proper origin checking, the browser does it for you. You don't need to store the module in an IndexedDB, the browser can do that for you as well. You can have a service worker that handles upgrading in the background. Once we have foreign fetch, you can support stuff like sharing an game engine on one origin with many other origins only hosting the actual game content.

My comment about message handler being suboptimal from a security point of view is that I don't that loading a cross origin script should require cross origin messages at all, and then not requiring that is better than requiring a message handler hoping that every site gets the origin checks right.

Also, if we add new response types, let's add them to the fetch api, not XHR :)

[jayphelps]

Also, if we add new response types, let's add them to the fetch api, not XHR :)

fetch does not support cancellation, and since the latest proposal was withdrawn I would much prefer that any response types supported by fetch were also supported by XHR so we can optionally cancel them. Pretty please 😄

We already have an awkward situation where Service Workers don't have access to XHR so they can't make requests that are cancellable.

[flagxor]

I believe using the collection of in-progress standards described here will make sense for the more common use cases once these APIs are finalized and available in all browsers. This was already the longer term direction we had intended to go, including rationalizing wasm modules in some way with ES6 modules.

However, I'm also skeptical that we can get the proper caching behavior right, in one go, in all the browsers in a fashion sufficiently coordinated to make the Web an appealing target for this kind of content.
A large part of the motivation for WebAssembly is to provide lower level mechanisms, because the high level mechanisms of the Web haven't consistently allowed developers to do what they need to be performant, even when they are highly motivated to do so (recall for this content the bar is identical content running as a native app).

Structured clone is definitely more low level than what we ideally want folks to use long term. But it is also expressed at a level that allows one to quickly determine that it exhaustively covers all the ways you might want to use it.

I have a hard time readily assessing what exactly the union of Service Workers, Streaming Fetch, Foreign Fetch, some kind of explicit/implicit code caching extension to the Cache API / XHR / Fetch, permits or denies developers. Can I cache content I generated synchronously? It also seems especially unclear what level of functionality this will make available in various browsers (as not all of them support the same set).

It's also useful to keep in perspective that the majority of content initially targeting wasm will come thru emscripten or Unity, which prescribes JS boilerplate we can vet for generality.

Besides the case of allowing storage to indexeddb in insecure origins (which I'm fine with disallowing), I'm not sure a concrete security concern has been raised. That said, I believe limiting things to same origin + secure origins for indexeddb storage is a reasonable starting point, as folks seem very worried bad patterns will get baked in.

Failing that, I would hope those suggesting other API surfaces can clarify whether those surfaces have support in all the major browsers, and what the polyfill options are when they don't (i.e. what do browsers without cache api do?, most other use cases can be polyfilled with indexedb + XHR). I'd be more comfortable with the suggestion of other contact points with the web platform, if it was clear that contact point can work additively in most forthcoming browser versions with only the addition of webassembly.

[pizlonator]

@esprehn link to separate thread discussing passing modules in postMessage?

@lukewagner I think I agree with what you're proposing. Specific thoughts:

The main two specific concerns that I've heard so far that make sense to me are:

window.postMessage and window.onmessage are error prone APIs that are generally discouraged and we shouldn't be encouraging use of these APIs for people wanting cross-origin caching/reuse
use of IDB to cache code in insecure contexts makes it easier for a one-time MITM attack (against the insecure origin) to permanently poison the site
If we all agree on these concerns, then I think both could be addressed conservatively by:

disallowing structured clone of a Module to a window (only allowing postMessage to workers)

Makes sense.

disallowing the storing of a Module in IDB in insecure contexts (which follows from the general principle of restricting powerful new features to secure contexts)

I think I agree with this.

Looking forward, and building on basic structured cloning support, we could then incrementally evolve to:

have WebAssembly.compile/instantiate take a stream, as has been proposed
integrate with Service Worker and the Cache API, leveraging Foreign-Fetch to support a safer-by-default way to cache/reuse code across origins
I think this strategy wins by supporting all the short-term caching and code-sharing needs of wasm without blocking on Service Workers (with new, to-be-defined APIs) in all browsers and also providing powerful primitives (viz., structured clone of modules) that can be used in other ways that wouldn't otherwise involve Service Workers (EWM etc).

I agree with not gating WebAssembly on other things. WebAssembly is a complex beast, so it shouldn't be too coupled to other complex beasts.

I think that if you enable WebAssembly in JSC then you will get it via the Objective-C API, too. That seems pretty neat, but in native apps there is no pre-existing caching engine to fall back to and it makes sense to let the client just do it however they like.

There's also the idea to push all the caching into the browser (having all the APIs take URLs, using Blob-URLs for dynamically-generated content). Just from a predictability point of view (and taking into account all the arguments for Service Workers over the HTTP cache), I think this is not a great option. I totally agree we should make loading a wasm module as easy as a <script> tag, but I think that even in this case, caching should be handled by a Service Worker that intercepts the <script> request.

Totally. Just as WebAssembly is engineered to get around all the wild dynamic JITing we do, it should probably get around the wild caching, too. Any claim otherwise has to answer: exactly how does the cache guarantee the same determinism as the current API?

@flagxor You said:

Will any of those subsume the current interface to the point we'll want to deprecate it at some point?

I'm not convinced that any of them subsume the current interface, but that may just be that I'm missing some context.

If I want the compiling megapause to happen once in a multi-worker app, how do I do it using the current interface and the alternate interfaces?

[flagxor]

Agreed I'm not sure it does cover all the cases.

As for your multi worker use case:

For the current api you compile once in one worker or via the async method on the main thread, then post it around.

With the other, presumably you need to post around a message to let everyone know the cache has been prime. One worker would have to compile and added things to the cache (through the cache API which isn't available everywhere), and also check that compilation is done (through some as yet unspeced API).

I suppose if we imagined some clarification of how wasm is rationalized as an es6 import, importScripts in each worker could arrange for a single compile to be shared.

[pizlonator]

@flagxor Thanks for that explanation.

For the current api you compile once in one worker or via the async method on the main thread, then post it around.

That is what I guessed. This feels very natural.

With the other, presumably you need to post around a message to let everyone know the cache has been prime. One worker would have to compile and added things to the cache (through the cache API which isn't available everywhere), and also check that compilation is done (through some as yet unspeced API).

I suppose if we imagined some clarification of how wasm is rationalized as an es6 import, importScripts in each worker could arrange for a single compile to be shared.

This feels less intuitive.

The compiling megapause is huge, and the result it produces could also be large - as big as an app binary. We want the client to be able to easily tell when the megapause happens and how long the result lives. Our current API gives us this, so we should stick with it.

Is anyone proposing any security-related extension to the current API beyond what @lukewagner proposed? Does everyone concur that @lukewagner's fix is sufficient?

Also, I don't understand how @titzer's XHR idea relates to this. Is this related to the security and API consistency concerns, or is this an unrelated optimization?