The bummer with WASM threads is the COOP/COEP headers requirement once it dawns on you that this only works if you have control over the web server configuration (to set the required response headers).
This means WASM threads can't be used with popular hosting solutions like Github Pages, which in turn means that for library authors like me the feature is nearly useless because it splits the audience into people who have control over their web servers, and those who don't, which in turn means maintaining two code paths, one with and one without threading support. And even if you theoretically have control over the web server configuration it's still more hassle because the people who write the code are usually not the same people who configure the web servers. So instead of just dumping a couple of WASM files to IT you also need to find and ask the right people to tweak the web server configuration just for your use case.
Sometimes I don't understand what's going on in the heads of the people thinking this stuff up :/
> Sometimes I don't understand what's going on in the heads of the people thinking this stuff up :/
So this post made me look up[1][2] COOP/COEP, but as far as i can tell this seems to be a security measure. Seemingly because they don't know, at this point in time, how else to enable shared memory in WASM without this limitation.
So what in your mind could have been done better? I agree it really sucks having your WASM apps live in two camps, single and multithreaded, but it seems like we, as users conceptually have two choices:
1. Don't get shared memory at all. Or,
2. Get shared memory in limited scenarios
#2 still seems better than #1, no?
Or do you perhaps think the performance Opt-In is overly aggressive. Ie if we just enabled shared memory always we'd reduce the WASM split with minimal issues. Alternatively we could do the reverse, Opt-Out, such that for resource constrained environments the phone/whatever could connect to `mobile.example.com`.
Well, "obviously" the web should have a mechanism in place that allows to request security sensitive features without having to poke around in the web server configuration, because in many cases this is "off limits" to the people who author the files to be hosted. How this is achieved, I don't really care, I only know that the current solution is half-baked.
The underlying problem is that this is a classic finger-pointing-situation that will probably never be fixed, because the web security people point the finger at the web hosters, and the web hosters shrug it off because 99% of their customers don't need the features because they just host their static blog there.
HTML meta headers used to be the solution to this kind of stuff, like the <meta charset="UTF-8"> tag for example (which contains information you can also provide in a HTTP header).
maybe depending on the app, a layer can be created, so like a wasm inside a wasm, kinda like a docker type thing that would allow an app to live inside a wasm virtual machine
The Github Pages situation is definitely unfortunate. We tried to contact them for couple of months to ask to add an option for COOP/COEP before the deprecation, but didn't have any luck with our contacts.
TBH I wonder why response header requirements can't be set right in the meta tags in index.html. Would this be any different than having a provider-specific config file next to index.html from a security pov?
Some of them can be, but not all. Some headers are needed before the content is loaded. With ubiquitous virtualisation these days, I don't see why hosting providers can't allow users more control over their server without compromising security.
It seems the answer to the question "wouldn't this work" is "no", but I'd ask "shouldn't this work?" what's the problem with this being configured in a meta tag?
This seems like a GitHub pages problem more than anything. Setting a header is a reasonable way to direct the client to behave a certain way, GH just doesn’t want to set that yet?
That may be true, but it's up to the library users what hosting service they use. The people that decide to use (for instance) Github Pages shouldn't be left in the cold.
This means WASM threads can't be used with popular hosting solutions like Github Pages, which in turn means that for library authors like me the feature is nearly useless because it splits the audience into people who have control over their web servers, and those who don't, which in turn means maintaining two code paths, one with and one without threading support. And even if you theoretically have control over the web server configuration it's still more hassle because the people who write the code are usually not the same people who configure the web servers. So instead of just dumping a couple of WASM files to IT you also need to find and ask the right people to tweak the web server configuration just for your use case.
Sometimes I don't understand what's going on in the heads of the people thinking this stuff up :/