[gzurl]

I think you missed this paragraph:

The Apache HTTP server and the Drupal packages remain unchanged. However, instead of loading the libphp.so extension module, it incorporates mod_wasm.so. In addition, instead of relying on the traditional PHP interpreter, it utilizes a PHP build in the WebAssembly binary format.

[SoftTalker]

So instead of trusting libphp.so, you have to trust mod_wasm.so that is running a php interpreter internally. Is this a win? Genuine question.

[assambar]

The biggest gain comes from mod_wasm using a Wasm runtime to run the PHP interpreter in a sandboxed environment. And mod_wasm can be used the same with Python or Ruby, or anything that builds for WebAssembly.

- No errors (even fatal) from the Wasm module will bring down Apache HTTPD. - mod_wasm's code base is small enough to inspect thoroughly and test thoroughly to ensure it is secure - Indeed you will now have to trust the embedded Wasm runtime (wasmtime as of today). As a naïve analogy, this is the equivalent of trusting a virtual CPU(Wasm)+OS(WASI), which gets tested in thousands of other scenarios than the ones used in mod_wasm and issues get fixed and corrected asap.