WASM Is the New CGI • Hacker News Board

Re: WASM Is the New CGI

#181

Post by mmis1000 » Thu, Oct 10, 2024, 12:56 PM UTC

perching_aix wrote: post #160

vbezhenar wrote: post #59

Earlier quoted context omitted.

Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implementations were ridden with vulnerabilities and eventually browsers made them unusable. Other mentioned technologies didn't even promise that, I think. JavaScript did deliver its promise of unbreakable sandbox and nowadays browser runs JavaScript, downloaded fr…

> JavaScript did deliver its promise of unbreakable sandbox Aren't its VM implementations routinely exploited? Ranging from "mere" security feature exploits, such as popunders, all the way to full on proper VM escapes? Like even in current day, JS is ran interpreted on a number of platforms, because JIT compiling is not trustworthy enough. And I'm pretty sure the interpreters are no immune either.

Both chrome and firefox lock down the javascript that site is running into their own box. By using a standalone process and whatever mechanism system provided. A pwned site alone isn't enough to cause damage. You also need to overcome other layer of defenses (unlike something like flash that can be owned from it's script engine alone)

It usually require multi 0 day to overcome all those defense and do anything useful. (And it is also the highest glory in defcon)

The browser is surely frequently attacked due to the high rewards. But it also get patched really fast. (As long as you are not using a browser from 10 years ago).

Re: WASM Is the New CGI

#182

Post by flohofwoe » Thu, Oct 10, 2024, 12:56 PM UTC

torginus wrote: post #177

flohofwoe wrote: post #168

Earlier quoted context omitted.

> they made bad technical decisions in the design Considering that the most important design requirement was to have a security model that's good enough for running untrusted code in web browsers at near native performance, I think the WASM peeps did a pretty good job. Your requirements may be different, but then maybe WASM simply isn't the right solution for you (there are plenty of alternatives outside web browsers…

PNacl also had the same sandboxing requirement, yet had many of the features still missing today from WAsm (threads, 3d graphics API support, access to other native APIs), and it didn't suffer from slow startup times. It had pretty nice and quick uptake considering the tooling was very similar to native toolchains. According to this benchmark (first Google result I found), it was even faster: https://apryse.com/blog/…

I had been working both with NaCl and PNaCl back then, and truth be told, once Google made the switch from NaCl to PNaCl most advantages just disappeared. The compilation of the PNaCl bytecode on start (which was more or less just a subset of LLVM IR) took longer than even the first WASM implementations.

PNaCl definitely suffered hard from slow startup times because it ran LLVM for compilation from PNaCl bytecode to native code on startup, and LLVM is slow (I even noticed this compilation process on startup on my absolutely trivial test code). Only the predecessor NaCl didn't suffer from this problem.

There was no 'access to other native APIs', PNaCl created its own set of wrapper APIs to access browser features, and while some of those were better than their standardized web API counterparts, some NaCl/PNaCl APIs were worse than the web APIs they replaced - and for the future, PNaCl would have to create more non-standard APIs for every little feature available in browsers, because:

Integration with the webpage and Javascript was done via message passing, which was just terrible when compared to how easy and fast it is to call between WASM and JS.

The NaCl/PNaCl multithreading feature would have been hit just as hard by Spectre/Meltdown as the SharedArrayBuffer based threading in WASM.

Finally, when you look at the PNaCl toolchain versus Emscripten, Emscripten definitely comes out on top because Emscripten was much more concerned about integrating well with existing build systems and simplify porting of existing code, while NaCl/PNaCl had its own weird build system (in old Google NIH tradition). Working with NaCl/PNaCl felt more like working with the Android NDK, which is pretty much the worst developer experience in the world.

Re: WASM Is the New CGI

#183

Post by pjmlp » Thu, Oct 10, 2024, 12:56 PM UTC

pdpi wrote: post #178

pjmlp wrote: post #137

Earlier quoted context omitted.

WasmGC is there no matter what, unless we are talking about an incomplete implementation, also plenty of linear memory based bytecodes since 1958.

WasmGC is a feature you can opt in to, rather than a core feature of the platform. It's more of an enabler for languages that expect a GC from their host platform (for things like Dart and Kotlin). Inversely, other forms of bytecode might have linear memory, but the JVM isn't one of those. For the purposes of OP's question, the memory model difference is one of the key reasons why you might want to use wasm instead o…

JVM is one bytecode among many since 1958, no need to keep bashing against it as way to champion WASM.

Opt-in or not, it is there on the runtime.

Re: WASM Is the New CGI

#184

Post by VyseofArcadia » Thu, Oct 10, 2024, 1:02 PM UTC

jauntywundrkind wrote: post #161

VyseofArcadia wrote: post #146

Earlier quoted context omitted.

But the browser is running in that gigantic special OS. It's not like the OS magically disappears.

I've already mentioned ChromeOS as one counter-example. SerenityOS and Ladybird browser forked but until recently had a lot of overlap. LG's WebOS is used on a range of devices, derived from the Palm Pre WebOS released in 2009. The gigantic special OS is baggage which already has been cut loose numberous times. Yes you can run some fine light Linux OS'es in 4GB but man, having done the desktop install for gnome or kd…

I for one don't want to use web apps. I want the speed, convenience, and availability of native apps. I want to use applications that work if the internet isn't. I want to use applications that store my data locally. I want to use unglamorous applications that just work and use a native GUI toolkit instead of torturing a poor, overburdened document display engine into pretending it's a sane place for apps to run.

Not to mention, from the perspective of a developer, the relative simplicity of native apps. Why should I jump through all the hoops of distributed computing to, for example, edit a document in a WYSIWYG editor? This is something I could do comfortably on a Packard Bell in 1992.

Re: WASM Is the New CGI

#185

Post by foobarian » Thu, Oct 10, 2024, 1:03 PM UTC

vbezhenar wrote: post #59

junto wrote: post #8

Can someone explain to me what the difference really is between WASM and older tech like Java Applets, ActiveX, Silverlight and Macromedia Flash, because they don’t really sound much different to me. Maybe I’m just old, but I thought we’d learnt our lesson on running untrusted third party compiled code in a web browser. In all of these cases it’s pitched as improving the customer experience but also conveniently push…

Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implementations were ridden with vulnerabilities and eventually browsers made them unusable. Other mentioned technologies didn't even promise that, I think. JavaScript did deliver its promise of unbreakable sandbox and nowadays browser runs JavaScript, downloaded fr…

> There's only practical difference: WASM proved to be secure and JVM did not.

The practical reasons have more to do with how the JVM was embedded in browsers than the actual technology itself (though Flash was worse in this regard). They were linked at binary level and had same privileges as the containing process. With the JS VM the browser has a lot more control over I/O since the integration evolved this way from the start.

Re: WASM Is the New CGI

#186

Post by superkuh » Thu, Oct 10, 2024, 1:06 PM UTC

Anything that requires executing arbitrary untrusted code from arbitrary untrusted sources automatically is bad and is definitely not filling the same role as server side CGI.

Re: WASM Is the New CGI

#187

Post by bhelx » Thu, Oct 10, 2024, 1:24 PM UTC

torginus wrote: post #76

Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons. This sounds.. not right. Honestly,this is an essential feature for allowing workloads like hot reloading code cleanly. I'm quite convinced the alleged security argument is bull. You can hot reload JS (or even do wilder things like codegen) at runtime without compromising security. Additionally, you can…

The statement is correct. Wasm cannot mark memory as executable. It's effectively a Harvard Architecture. The code and memory are split. Furthermore you cannot jump to arbitrary points in code. There isn't even a jump instruction.

> I'm quite convinced the alleged security argument is bull. You can hot reload JS (or even do wilder things like codegen) at runtime without compromising security.

JIT here is referring to compiling native code at runtime and executing it. This would be a huge security compromise in the browser or in a wasm sandbox.

> I don't see any technical reason why this couldn't be possible. If this were a security measure, it could be trivially bypassed.

It's not because it's baked into the design and instruction set. You can read some more about how it works here: https://webassembly.org/docs/security/

> Also, WASM bytecode is very similar conceptually to .NET IL, Java bytecode etc., things designed for JIT compilation.

Yes, and like with Wasm, the engine is responsible for JITting. But giving the user the power to escape the runtime and emit native code and jump to it is dangerous.

Re: WASM Is the New CGI

#188

Post by [deleted] » Thu, Oct 10, 2024, 1:25 PM UTC

kaba0 wrote: post #147

silvestrov wrote: post #111

Earlier quoted context omitted.

Most of all the problem with Java Applets was that they were very slow to load and required so many resources that the computer came to a halt. They also took much longer to develop than whatever you could cook up in plain html and javascript.

Funnily enough, wasm also has the problem of “slow to load”. In that vein, a higher level bytecode would probably result in smaller files to transport. And before someone adds, the JVM also supports loading stuff in a streaming way - one just has to write a streaming class loader, and then the app can start immediately and later on load additional classes.

[deleted]

Re: WASM Is the New CGI

#189

Post by jasode » Thu, Oct 10, 2024, 1:27 PM UTC

vbezhenar wrote: post #59

junto wrote: post #8

Can someone explain to me what the difference really is between WASM and older tech like Java Applets, ActiveX, Silverlight and Macromedia Flash, because they don’t really sound much different to me. Maybe I’m just old, but I thought we’d learnt our lesson on running untrusted third party compiled code in a web browser. In all of these cases it’s pitched as improving the customer experience but also conveniently push…

Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implementations were ridden with vulnerabilities and eventually browsers made them unusable. Other mentioned technologies didn't even promise that, I think. JavaScript did deliver its promise of unbreakable sandbox and nowadays browser runs JavaScript, downloaded fr…

>So there's no fundamental difference between WASM and JVM bytecode. There's only practical difference: WASM proved to be secure and JVM did not.

There's more to it than just the sandbox security model. The JVM bytecode doesn't have pointers which has significant performance ramifications for any language with native pointers. This limitation was one of the reasons why the JVM was never a serious compilation target platform for low-level languages like C/C++.

E.g. Adobe compiled their Photoshop C++ code to WASM but not to the JVM to run in a Java JRE nor the Java web applet. Sure, one can twist a Java byte array to act as a flat address space and then "emulate" pointers to C/C++ but this extra layer of indirection which reduces performance wasn't something software companies with C/C++ codebases were interested in. Even though the JVM was advertised as "WORA Write-Once-Run-Anywhere", commercial software companies never deployed their C/C++ apps to the JVM.

In contrast, the motivation for asm.js (predecessor to WASM) was to act as a reasonable and realistic compilation target for C/C++. (https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-n....)

So the WASM-vs-JVM story can't be simplified to "just security" or "just politics". There were actual different technical choices made in the WASM bytecode architecture to enable lower-level languages like C/C++. That's not to say the Sun Java team's technical choices for the JVM bytecode were "wrong"; they just used different assumptions for a different world.

Re: WASM Is the New CGI

#190

Post by themoonisachees » Thu, Oct 10, 2024, 1:41 PM UTC

mdhb wrote: post #176

emporas wrote: post #172

Earlier quoted context omitted.

I was surprised when google has agreed to implement the capabilities model for Chrome. I would guess that asking the user for permission to access the microphone would not sit well with google. In smartphones they own the OS so they can ignore wasm's security model as much as they like.

I feel there’s a bit of a disconnect here between Google’s Ads division who are looking to basically do the bare minimum to avoid getting repeatedly spanked primarily by the EU but also now with talk of a breakup in the US and most other parts of Google who I say this entirely unironically are by far the best of all major options with regards to security in both the browser and their public cloud offerings. I’d even…

It is not my intention to be contrarian, but honestly this might be the most incorrect comment I've ever read on hacker news, in several different ways. Sure, some of these might be subjective, but for example chromeOS is Linux with a shiny coat in top, how could it be any better than, well, Linux, let alone miles ahead?