COOP, COEP for wasm threads

[Dan C]

Hi everyone,

I noticed this message when loading threaded wasm with Firefox.

Worker.postMessage: The WebAssembly.Memory object cannot be serialized. The Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy HTTP headers will enable this in the future.

My understanding is that this is caused by https://bugzilla.mozilla.org/show_bug.cgi?id=1562663

Is this problem something we expect to ever impact any other browsers or is it Firefox only? Would this problem be fixed in Firefox or the module needs to be built differently?

Thanks,

Dan

[Alon Zakai]

This will affect all browsers eventually, as it is the agreed direction in the standards bodies.

I'm not an expert on COOP/COEP, but I don't think you need to build the module differently. You may need to change the webserver's responses, though. See for example what our browser test suite does,

https://github.com/emscripten-core/emscripten/blob/20ecfa2f8101fb21a9c0f9d75e3aa2dee6468e95/tests/runner.py#L1332

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/f2c12ce0-2156-4cee-bf84-790d10a4ebde%40googlegroups.com.

[Hostile Fork]

>  I'm not an expert on COOP/COEP, but I don't think you need to build the module differently.

> You may need to change the webserver's responses

*In theory*...you should only need the headers to be on your main "index.html" to get the ball rolling.  Then you could use the crossorigin attribute to get around it on sites you don't fully control, by writing `<script src="..." crossorigin="anonymous" />` (note that when doing this programatically on DOM elements, it's `crossOrigin`)

Having this `crossorigin` workaround is important, as sites like S3--that are good for hosting the kinds of large files Emscripten makes--do not offer these headers.

*In practice*, you run into problems with web workers, as they can't access the DOM to build script tags.  Instead they load using `importScripts()` which has no `crossorigin` exemption.  D'oh.

QUESTION: Since there's already a common practice of pre-fetch()'ing web worker source in order to `URL.createObjectURL(workerJsBlob)` ... might it be possible to have a mode where there is only one .js file with all the cwraps/etc. that is polymorphic, and can act as either worker-or-not?  Then the workerJsBlob would have everything it needed and would not need to use importScripts().  Hence the createObjectURL workaround would be enough in situations where you are using S3 or other hosts, where complete header control is not an option.

(At first I thought of just doing that on the fly by fetch()'ing the two parts and fusing them together in JS, replacing `importScripts()` with an `importScriptsHack()` that eval()'d the cwrap JS.  But given the immutability of blobs and JS strings that's all going to be pretty inefficient.  But if it were something a build switch could do, it would not be that bad...the wasm file is a lot bigger than the .js, at least in my case...and the wasm can be loaded by the main thread where crossorigin is available.)

On Tuesday, June 2, 2020 at 4:34:11 PM UTC-4 Alon wrote:

This will affect all browsers eventually, as it is the agreed direction in the standards bodies.

I'm not an expert on COOP/COEP, but I don't think you need to build the module differently. You may need to change the webserver's responses, though. See for example what our browser test suite does,

https://github.com/emscripten-core/emscripten/blob/20ecfa2f8101fb21a9c0f9d75e3aa2dee6468e95/tests/runner.py#L1332

On Tue, Jun 2, 2020 at 12:52 PM Dan C wrote:

[Floh]

Wrong place to whine about it I guess, but it would be really great if those COOP/COEP response header requirements could also be defined *inside* the index.html as meta-tags (or some sort of 'manifest file' uploaded together with index.html etc to the web server). Because otherwise multi-threaded WASM will never be an option when using hosting services where the user has no control over the web server configuration (such as github-pages).

Hrmpf, not a big fan of this feature...

[Hostile Fork]

On Friday, December 4, 2020 at 3:36:41 PM UTC-5 Floh wrote:

Wrong place to whine about it I guess, but it would be really great if those COOP/COEP response header requirements could also be defined *inside* the index.html as meta-tags (or some sort of 'manifest file' uploaded together with index.html etc to the web server). Because otherwise multi-threaded WASM will never be an option when using hosting services where the user has no control over the web server configuration (such as github-pages).

I'd actually come up with the "manifest"-style suggestion as well.  So, er...good thinking!  :-P

 

Hrmpf, not a big fan of this feature...

Their agenda does not strike me as the product of rigorous thought.  (I'm reminded of using a chat program where you can type to someone...and then you try to send them a file...and it fails with some "operation prohibited" error.  But since you can type, you can still uuencode things.)

You either have a connection, or you don't.  You either check a signature or hash, or you don't.  These are the mechanisms and tools of security--you have to start there.  The rest of this comes across to me as obfuscation and theater.

While I do appreciate there is a reason "make me a sandwich" and "sudo make me a sandwich" are different...what's being offered here seems--when considered generously--a weak and disjoint analogy to that.  If anything, it leads to people with legitimate needs being forced into using *less* secure methods.  I compared to JSONP (an analogy apparently too deep to grok...who knew?)

https://bugzilla.mozilla.org/show_bug.cgi?id=1586217

But as the threads like that show, there's really nowhere else to whine.  It all bottoms out in silence, or some AWS thread where they ask if you saw the CORS header settings when you were asking about something completely different.  :-(

So after thinking about it a bit today, I feel like I've gotten the message: no one considers this feature important enough to design in a coordinated way.  They've broken it repeatedly--and will likely continue to do more and more weird things--without consideration for the few users they have.  Asyncify may not be ideal due to generating 2x size binaries, but it's fast enough (big thanks to those responsible!).  Thus I think I'm just going to treat the threads as DOA, and let the idea go.