[pjmlp]

Actually only when one did not bothered to spend any effort with Security Managers, Classloaders separation and JAAS.

All the tools were there.

WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking.

[readittwice]

> WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking.

Unsafe applications won't ever be magically safe when compiling them to WebAssembly. Neither would this be the case when compiling to Java bytecode - if this was possible at all.

IMHO WebAssembly is a compilation target and therefore not the right layer to solve this. This is the responsibility of the language or the specific application. If you want to solve this in WASM, I predict you couldn't just compile all different languages to WASM anymore without significant changes to the codebases. If this would be feasible at all..

Rewriting those huge C/C++ codebases is simply not an option, new applications can be written in safe languages and then compiled to WASM.

[pjmlp]

Java bytecode requires bound checking and null pointer validation, as per the JVM specification.

CLR proves the contrary, by having C++ support, with the difference between safe Assemblies (where typical memory corruption opcodes are not allowed, compilation via /CLR) and unsafe Assemblies, where WASM like opcodes are allowed.

To load an unsafe Assembly, the host has to explicitly allow it.

Similar examples on IBM and Unisys language environments, e.g. on ClearPath, the admin must allow the execution of binaries tainted with unsafe code.

[readittwice]

WASM has bounds checking on the linear memory as well.

[pjmlp]

Care you point it where in the standard, because I don't see it on the memory access opcodes.

[readittwice]

> A linear memory is a contiguous, mutable array of raw bytes. Such a memory is created with an initial size but can be grown dynamically. A program can load and store values from/to a linear memory at any byte address (including unaligned). Integer loads and stores can specify a storage size which is smaller than the size of the respective value type. A trap occurs if an access is not within the bounds of the current memory size.

[kevingadd]

In general the groups doing standardization for browser APIs and runtimes don't seem to care much about whether web applications are compromised, only whether the browser or host platform are compromised. It's reasonable for the latter two to be priorities, but when we're talking about huge gmail-tier applications running unsafe C in a sandbox that have access to All Your Important Data, we're going to massively regret letting type safety and other features slide.

[otabdeveloper1]

> ...we're going to massively regret letting type safety and other features slide.

PHP is memory safe, and yet is a larger source of data breaches and security bugs than C by (rough guess) an order of magnitude.

C is not the bogeyman you're looking for.

[ComputerGuru]

PHP may be memory safe but the shitload of poorly written C extensions enabled by default on all hosts that shipped with the distribution from 1995 to 2010 sure as hell weren't.

[otabdeveloper1]

C extensions wasn't the part of PHP that broke the amateur Internet, SQL injections were.

[TomMarius]

Using the WASM GC part instead of lieanr memory will solve that, right? I know it's not a possibility for all programs, but overall, it'll help?

[pjmlp]

Not at all, because a large majority of applications being ported to WASM are written in C and C++, with all security caveats it entails.

Garbage Collected implementations of C and C++ do exist, and only thing that their GC fixes is use after free.