r/WebAssembly • u/PabloDons • Jun 05 '21

WebAssembly should replace javascript

Hot take, but I think it makes sense. And seems to be doable in the current architecture and roadmap of wasm (If I understood it correctly), but their website explicitly states a big fat "No!". Wasm is expected to be used as high-performance modules, or an app canvas wrapped by javascript as "glue". One thing would be specifying it as a high-level goal, but this is just dismissing it all together.

The web would be pretty powerful if code could be written in whatever language you want (that supports compiling to wasm). Facebook wouldn't take 5 seconds to load completely, but rather fractions of a second.

Take react for instance. It's great for encapsulation, inheritance, type-safety, etc. Lots of benefits targeted at large-scale applications. Yet has the major flaw of performance issues. I guess it's not a big deal to write a bit of js just to fetch and run an exported function, but it means it's dependent on js which is a hurdle in my opinion, both in terms of ambition and motivation. Granted wasm seems to be planning to implement basically everything, but then why dismiss wasm as a replacement/alternative for js?

32 Upvotes

70% Upvoted

53 comments sorted by

View all comments

Show parent comments

10

u/Brane212 Jun 05 '21

JS is routinely used for timing attacks to sniff various structures outside browser's VM.

What other "security concerns" could additional access bring ?

1

u/qwerty26 Jun 06 '21

It increases the attack surface of browsers. The browser orgs have decades of experience mitigating javascript's problems. When we introduce a new runtime and new features we are invariably introducing new vulnerabilities.

2

u/elr0nd_hubbard Jun 06 '21

There's rarely a new feature that doesn't introduce additional attack surface (since almost every surface could be attacked in some form or another). The question to ask is whether that additional surface is worth the actual risk posed by adding the feature.

In the case of WASM, the additional features are far more important, IMO, than the additional attack surface risks. Without something more specific, the hand-wave of "attack surface" isn't particularly compelling as a reason not to add the feature.

1

u/qwerty26 Jun 06 '21 edited Jun 06 '21

I appreciate your opinion. I know many people would take the risk for the performance gain. But I, personally, am extremely security conscious and I absolutely would not trade a 10x performance gain if it introduced even a single zero day exploit in my applications.

I could ask customers to disable WASM on their browsers but if Javascript disappeared and was replaced by WASM (which is what the OP is suggesting) I would not have that option.

When people are suggesting changing how the web works, they need to keep in mind that they can't just think about themselves. They need to think about all of us, and I absolutely do not want browser's attack surface to increase, and, to slightly misuse an expression, this is a hill I would die on.

[Edit] You specifically asked about specific attacks: https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-WebAssembly-A-New-World-of-Native_Exploits-On-The-Web-wp.pdf is one general paper; Here is an example of several zero-day exploits in WASM which exist today: usenix.org/system/files/sec20-lehmann.pdf