2 ms·

I explicitly stated I was talking about WASM being used in traditionally native process contexts - like in a serverless/microservices architecture. The first ob

I explicitly stated I was talking about WASM being used in traditionally native process contexts - like in a serverless/microservices architecture. The first obvious step of someone offering that is to just import libc so existing code can migrate to it. You seem to be continually focusing exclusively on the current existing extremely limited WASM-in-a-browser usage. WASM's current limitations aren't intentional, it's because it's not finished & wasn't necessary for the MVP. In fact, it already has some of the things you are claiming it doesn't have - both threads & shared memory are available already in Chrome & Firefox's stable releases ( https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md https://github.com/WebAssembly/threads/blob/master/proposals... & https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ ). Which means it also has accurate timers. WASM very intentionally allows the host to expose whatever feature set it wants. That's a very core design element. You can't just ignore that and focus on the ~nothing that the "spec" itself delivers & pretend that's by-design. WASM isn't a standalone runtime and isn't trying to be.

emn13 6y ago
Ah, threads got enabled, and quite a while ago. However, not in a way that's spectre sensitive; only in a site-isolation context (https://groups.google.com/a/chromium.org/g/blink-dev/c/_0MEXs6TJhg?pli=1 https://groups.google.com/a/chromium.org/g/blink-dev/c/_0MEX...). You state WASM's limitations aren't intentional; they just weren't finished - but being able to use those securely is part of being finished, and they weren't enabled in browsers until they were. Obviously other hosts may do whatever they want. That's a valid hypothetical, but just as valid a hypothetical is that WASM implements relevant defense in depth features before such poorly sandboxed hosts become commonplace; it's not like they're not aware of the issue (https://webassembly.org/docs/security/ https://webassembly.org/docs/security/). Hypothetically it might be "safer" than SELinux; but... today none of this matters, and the missing features don't appear to be intrinsic. It's not like native programs have had ASLR since day 1 either, right? Or maybe WASM stays in the "highly isolated" niche which is fine too, and would still allow various usages outside the browser too (e.g. for most apps that don't interact with other apps outside of a few carefully controlled primitives). If people make poor choices about future development, things may end up less secure than they are today: sure. So, on the one hand I can't dispute what your saying - I just think it's not the best thing to be focused on, because a trivial summary would make it seem like there's a real risk in having WASM as it is today, and that's not the case. We should be very careful in the future, yes, but let's not throw out the baby with the bathwater; wasm's portability and sandboxing in practice today are likely quite useful and more secure (in a browser context) than a native app (outside of a browser context).

emn13 6y ago

Ah, threads got enabled, and quite a while ago. However, not in a way that's spectre sensitive; only in a site-isolation context (https://groups.google.com/a/chromium.org/g/blink-dev/c/_0MEXs6TJhg?pli=1 https://groups.google.com/a/chromium.org/g/blink-dev/c/_0MEX...). You state WASM's limitations aren't intentional; they just weren't finished - but being able to use those securely is part of being finished, and they weren't enabled in browsers until they were. Obviously other hosts may do whatever they want. That's a valid hypothetical, but just as valid a hypothetical is that WASM implements relevant defense in depth features before such poorly sandboxed hosts become commonplace; it's not like they're not aware of the issue (https://webassembly.org/docs/security/ https://webassembly.org/docs/security/). Hypothetically it might be "safer" than SELinux; but... today none of this matters, and the missing features don't appear to be intrinsic. It's not like native programs have had ASLR since day 1 either, right? Or maybe WASM stays in the "highly isolated" niche which is fine too, and would still allow various usages outside the browser too (e.g. for most apps that don't interact with other apps outside of a few carefully controlled primitives). If people make poor choices about future development, things may end up less secure than they are today: sure. So, on the one hand I can't dispute what your saying - I just think it's not the best thing to be focused on, because a trivial summary would make it seem like there's a real risk in having WASM as it is today, and that's not the case. We should be very careful in the future, yes, but let's not throw out the baby with the bathwater; wasm's portability and sandboxing in practice today are likely quite useful and more secure (in a browser context) than a native app (outside of a browser context).