Re:Using WebAssembly threads from C, C++ and Rust
by flohofwoe on Wednesday July 21, 2021 @12:15PM
(#27908187)
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.
Re:Using WebAssembly threads from C, C++ and Rust
by brabel on Wednesday July 21, 2021 @04:18PM
(#27911589)
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).
Re:Using WebAssembly threads from C, C++ and Rust
by pjmlp on Wednesday July 21, 2021 @04:49PM
(#27911976)
Good use of past tense, given that they aren't the solution any longer.
Re:Using WebAssembly threads from C, C++ and Rust
by ori_b on Wednesday July 21, 2021 @09:22PM
(#27914267)
> 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.
Re:Using WebAssembly threads from C, C++ and Rust
by adkadskhj on Thursday July 22, 2021 @11:32AM
(#27920058)
It's not a security risk. The security risk was removed, and the provided feature is an expensive workaround to avoid the security risk.
Re:Using WebAssembly threads from C, C++ and Rust
by adminscoffee on Friday July 23, 2021 @03:02AM
(#27927989)
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
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