Re: COOP, COEP for wasm threads

[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.

>

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/d9505b3b-13cc-4628-b729-9ae59fa81669n%40googlegroups.com.

Re: COOP, COEP for wasm threads

[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...
On Friday, 4 December 2020 at 09:02:58 UTC+1 hosti...@gmail.com wrote:

> >  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 
> `` (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:
>>
>  
>
>> 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?
>>>
>>

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/3287df53-2371-42f5-bc68-107bdc5be223n%40googlegroups.com.

Re: COOP, COEP for wasm threads

[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 
`` (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:
>
 

> 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?
>>
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/52da9fbb-d9c7-4bec-bdb7-abe8a2d0deb6n%40googlegroups.com.

Re: COOP, COEP for wasm threads

[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


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

> 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
>
> --
> 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-discuss+unsubscr...@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
> 
> .
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRgjU%3DKbBM83z57HsSnn-yicrGhZrfrdXWouNisNC2%3D3w%40mail.gmail.com.

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

-- 
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-discuss+unsubscr...@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.