gzurl

Actually, that is one of the Wasm key features: being a platform-independent binary not tied to any specific HW architecture.

Translating x86_64 code to arm64 requires more CPU cycles than JITting Wasm into arm64 or x86_64.

Buy even more: in the use case covered in this article, the PHP interpreter won't change so it can be AoT compiled upon deployment to the target architecture. No JIT compilation needed :-)

SA-CORE-2020-013 is one of them.

Indeed! As an example, SA-CORE-2020-013 can be mitigated with Wasm. An that one is classified as Critical.

Yes, sure. WasmGPT this time :-)

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.

This article explores how Drupal can benefit from the capabilities-based security model offered by WebAssembly, a portable binary format that allows execution of code in a safe and efficient manner. By deploying Drupal within a WebAssembly-based stack, it gains an additional security layer, protecting against a wide range of vulnerabilities, including those that may not be public yet but can be preemptively mitigated through these mechanisms.

I didn't know about pandoc. Really useful!

Think in the minimum container you need to run some Python code (>300MB?). Now, compare that to just the Python interpreter compiled into Wasm (25MB). If you need deploy that into different nodes, that's a huge difference.

Also, Wasm modules don't have cold-starts as containers.

Regarding running untrusted code, ask the folks at AWS, Azure or Google Cloud dealing with that...