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

[1]: https://web.dev/coop-coep/ [2]: https://www.youtube.com/watch?v=XLNJYhjA-0c&t=4s

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

Good use of past tense, given that they aren't the solution any longer.

> So what in your mind could have been done better?

If it's a security risk, there shouldn't be an option. Setting up a web server is a low bar for malicious actors.

It's not a security risk. The security risk was removed, and the provided feature is an expensive workaround to avoid the security risk.

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.

Well something as basic as CSP is also crippled without access to the server to set headers. And a lot of other stuff.

The more relevant question here is why so few (if at all) web hosting solutions allow the user to configure custom server rules?

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.

You don't even need virtualization at all. Apache have allowed this for twenty years!

All PHP (Apache) hosting provider I know allow user-defined configuration on a per-directory level.

> something as basic as CSP is also crippled without access to the server to set headers

Why would communicating sequential processes be crippled by this?

Ah, I see. A different namespace.

I've not try that but wouldn't the html meta tag work as well?

Something like

  <head>
    <meta http-equiv="Cross-Origin-Embedder-Policy" content="require-corp" />
    <meta http-equiv="Cross-Origin-Opener-Policy" content="same-origin" />
    ...
  </head>

No, http-equiv only supports a hard-coded whitelist of headers. https://html.spec.whatwg.org/multipage/semantics.html#pragma...

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?

Apparently not, but I haven't tried myself:

https://stackoverflow.com/questions/67259043/can-coop-coep-h...

You should still provide a fallback without sharedarraybuffers and atomics because safari doesn't provide them.

> COOP/COEP headers requirement

Just like CORS proxies maybe someone can make a public COOP/COEP proxy.

Stupid requirements will lead to stupid workarounds.

Actually you could probably just use CloudFront if you don't mind spending a couple bucks a month and configure it to add some headers.

Ran into the same issue using Github Pages with an FFmpeg/Wasm project. Hoping they add support for these headers soon.

I could use something like Netlify, but I like the convenience of the gh-pages branch and deployment.

Agreed, couldn't "I hereby relinquish my ability to bring other-origin content into this process without their opt-in" be a JS API call (one-way)?

HTTP headers should not affect app functionality in this way.

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?

It's worth noting that Netlify is a much superior solution to GitHub pages that's just as easy to use, and it supports custom headers.

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.