2 ms·
This is nothing new, memory space of a process in all modern OSes is protected so that segfaults are safe too. Combined with original UNIX idea of small tools t
by rini17 7y ago
This is nothing new, memory space of a process in all modern OSes is protected so that segfaults are safe too. Combined with original UNIX idea of small tools that communicate by pipes it was fine.
But now the processes are behemoths with gigabytes of dynamically linked libraries that are too hard to secure and to restrict system access, we just enable everything. This will happen to wasm. I'm sure there are WASM blobs configured with unfettered access to DOM in the wild already.
- Dylan16807 7y ago> This is nothing new, memory space of a process in all modern OSes is protected so that segfaults are safe too. Right, but look at what I'm replying to. "The way they said it, though, makes it sound like WebAssembly is implemented with full process sandboxing or something, which is patently false." Unlike with Javascript, the program hosting a WASM script is immune to corrupt pointers inside the script. That's equivalent to OS-level isolation, which is pretty good! > But now the processes are behemoths with gigabytes of dynamically linked libraries that are too hard to secure and to restrict system access, we just enable everything. This will happen to wasm. I'm sure there are WASM blobs configured with unfettered access to DOM in the wild already. There will inevitably be bugs in the code handling the html/css/dom/rendering. But WASM greatly reduces the attack surface of the scripting VM. The types of bugs most likely to still exist with WASM are the types where isolating it in a separate process that communicates by pipes wouldn't help.