81–90 of 287 posts
[flagged]
I tried using it for crypto, but WASM does not have instructions for crypto. So it basically falls back to be non-hw-accelerated. Tried to find out why and the explanation seems to be that it's not needed because JS has a `crypto` API which uses hw intrinsics.
WRT WebAssembly Components though, I do wish they'd have gone with a different name, as its definition becomes cloudy when Web Components exist, which have a very different purpose. Group naming for open source is unfortunately, very hard. Everyone has different usages of words and understanding of the wider terms being used, so this kind of overlap happens often.
I'd be curious if this will get better with LLM overseers of specs, who have wider view of the overall ecosystem.
> There are multiple reasons for this, but the core issue is that WebAssembly is a second-class language on the web
It would be nice if WebAssembly would really succeed, but I have to be honest: I gave up thinking that it ever will. Too many things are unsolved here. HTML, CSS and JavaScript were a success story. WebAssembly is not; it is a niche thing and getting out of that niche is now super-hard.
[flagged]
People have the impression that WebAssembly has failed. After so many years, I sort of agree with that notion. WebAssembly is soon 10 years old by the way:
Earlier quoted context omitted.
Novelty - JS has had more time and effort spent in hardening it, across the browsers, WASM isn't as thoroughly battle-tested, so there will be novel attacks and exploits.
> Novelty - JS has had more time and effort spent in hardening it Taking this argument to its extreme, does this mean that introducing new technology always decreases technology? Because even if the technology would be more secure, just the fact that it's new makes it less secure in your mind, so then the only favorable move is to never adopt anything new? Supposedly you have to be aware of some inherent weakness in…
Earlier quoted context omitted.
Novelty - JS has had more time and effort spent in hardening it, across the browsers, WASM isn't as thoroughly battle-tested, so there will be novel attacks and exploits.
That would be more true if WebAssembly didn't share so much sandboxing infrastructure with JS. If anything, I'd argue that WebAssembly is a much smaller surface area than JavaScript, and I think that will still be true even when DOM is directly exposed to WebAssemly.
By the same token, was Java or Flash more dangerous than JS? On paper, no - all the same, just three virtual machines. But having all three in a browser made things fun back in the early 2000s.
Earlier quoted context omitted.
Novelty - JS has had more time and effort spent in hardening it, across the browsers, WASM isn't as thoroughly battle-tested, so there will be novel attacks and exploits.
On one hand, yes, new attack surface is new attack surface. But WASM has been in browsers for almost a decade now.
Earlier quoted context omitted.
You can already compile malware to obfuscated asm.js. If anything, WASM blobs are easier to reverse engineer than obfuscated JS - good luck writing a ghidra plugin for JS source.
What about obfuscated WASM blobs? At least obfuscated JS is still basically source code being interpreted, with WASM we will be running proprietary obfuscated binaries in the browser.
No no no, wasm has shitty speed if you want to emulate something (it doesn't even support JIT), the problem is in its architecture (tons of restrictions like no self modifying code, no jumps).. this can't be fixed, we need something real, something like WebKVM.
I've created a proposal to add a fine-grained JIT interface: https://github.com/webassembly/jit-interface
It allows generating new code one function at a time and a robust way to control what the new code can access within the generating module.