WASM Is the New CGI • Hacker News Board

Re: WASM Is the New CGI

#141

Post by d3VwsX » Thu, Oct 10, 2024, 10:32 AM UTC

afiori wrote: post #130

torginus wrote: post #83

Earlier quoted context omitted.

Apps like these were incredibly common on Windows from the late 90s-early 2010s era. They could do all this (except for the sandboxing thing). You just downloaded a single .exe file, and it ran self-contained, with all its dependencies statically linked, and it would work on practically any system. On MacOS, the user facing model is still that you download an application, drop it in the Applications folder, and it wo…

> They could do all this (except for the sandboxing thing). The sandbox is very very important, it is the reason I mostly do not worry about clicking random links or pasting random urls in a browser. There are many apps that I would have liked to try if not for the security risk.

The download of a single EXE to keep had a nice side-effect though, that it made it trivial to store (most) apps (or their installers) for future use. Not so sure if in-browser apps can do that (yet?) except maybe by saving an entire virtual machine containing the web browser with the app installed.

Re: WASM Is the New CGI

#142

Post by PoignardAzur » Thu, Oct 10, 2024, 10:47 AM UTC

fallous wrote: post #19

This article really does remind me of an old Law of Software that we used to invoke: Any sufficiently large and long-lived application will eventually re-implement the entire software stack it runs on, including the operating system.. and it will re-implement it poorly. I'm unsure of the source for this Law, but it certainly proves correct more often than not.

The witty version is known as Greenspun's tenth rule:

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

The general pattern is called the Inner-Platform Effect.

Re: WASM Is the New CGI

#143

Post by kaba0 » Thu, Oct 10, 2024, 10:47 AM 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…

I would add that most of it was politics.

The JVM is not fundamentally insecure the same say as neither is any Turing-complete abstraction like an x86 emulator or so. It’s always the attached APIs that open up new attack surfaces. Since the JVM at the time was used to bring absolutely unimaginable features to the otherwise anemic web, it had to be unsafe to be useful.

Since then, the web improved a huge amount, like a complete online FPS game can literally be programmed in just JS almost a decade ago. If a new VM can just interact with this newfound JS ecosystem and rely on these to be the boundaries it can of couse be made much safer. But it’s not inherently due to this other VM.

Re: WASM Is the New CGI

#144

Post by dkersten » Thu, Oct 10, 2024, 10:48 AM UTC

jauntywundrkind wrote: post #120

bigstrat2003 wrote: post #91

Earlier quoted context omitted.

Except worse, because everything has to run in a gigantic web browser even if it could be a small native app.

Every native app has to be run in a gigantic special OS when it could be a small webapps running in a medium sized browser. Many many ChromeOS (web based consumer OS) laptops are 4GB of ram. You do not want to try that with any normal OSes.

That’s because windows is loaded with trash. You can easily run desktop Linux with 4 GB or RAM, and people have been doing it for decades.

Re: WASM Is the New CGI

#145

Post by kaba0 » Thu, Oct 10, 2024, 10:53 AM UTC

DanielHB wrote: post #110

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…

> WASM proved to be secure and JVM did not. It is interesting to ask why that is the case, from my point of view the reason is that the JVM standard library is just too damn large. While WASM goes on a lower-level approach of just not having one. To make WASM have the capabilities required the host (the agent running the WASM code) needs to provide them. For a lot of languages that means using WASI, moving most of th…

> I think the first approach gives a lot more room for the host to create optimizations, to the point we could see hardware with custom instructions to make WASM faster

Heh, there were literally CPUs with some support for the JVM! But it turns out that “translating” between different forms is not that expensive (and can be done ahead of time and cached), given that CPUs already use a higher level abstraction of x86/arm to “communicate with us”, while they do something else in the form of microcode. So it didn’t really pay off, and I would wager it wouldn’t pay off with WASM either.

Re: WASM Is the New CGI

#146

Post by VyseofArcadia » Thu, Oct 10, 2024, 10:55 AM UTC

jauntywundrkind wrote: post #120

bigstrat2003 wrote: post #91

Earlier quoted context omitted.

Except worse, because everything has to run in a gigantic web browser even if it could be a small native app.

Every native app has to be run in a gigantic special OS when it could be a small webapps running in a medium sized browser. Many many ChromeOS (web based consumer OS) laptops are 4GB of ram. You do not want to try that with any normal OSes.

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

Re: WASM Is the New CGI

#147

Post by kaba0 » Thu, Oct 10, 2024, 10:56 AM UTC

silvestrov wrote: post #111

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…

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.

Re: WASM Is the New CGI

#148

Post by nicce » Thu, Oct 10, 2024, 10:57 AM UTC

ram_rattle wrote: post #127

feverzsj wrote: post #92

Companies choose wasm to avoid crawlers.

I do not understand this, can you please explain

Probably just a typical cat and mouse game. Some crawlers support React based websites already, for example, so they can render the content and crawl based on that. I believe crawlers do not execute yet the WASM code. But in time, they will.

Re: WASM Is the New CGI

#149

Post by akoboldfrying » Thu, Oct 10, 2024, 11:04 AM UTC

I don't know much about Wasm so this was helpful, thanks. It does seem like having the same language on both server and browser must make software delivery more flexible.

>Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons.

I don't follow -- is the Wasm runtime VM forbidden from JITing? (How could such a prohibition even be specified?) Assuming this is the case, I'm surprised that this is considered a security threat, given that TTBOMK JVMs have done this for decades, I think mostly without security issues? (Happy to be corrected, but I haven't heard of any.)

Re: WASM Is the New CGI

#150

Post by kaba0 » Thu, Oct 10, 2024, 11:07 AM UTC

titzer wrote: post #129

iainmerrick wrote: post #117

Earlier quoted context omitted.

I don't think there's any significant advance in the bytecode beyond e.g. JVM bytecode. The difference is in the surface area of the standard library -- Java applets exposed a lot of stuff that turned out to have a lot of security holes, and it was basically impossible to guarantee there weren't further holes. In WASM, the linear memory and very simple OS interface makes the sandboxing much more tractable.

I worked on JVM bytecode for a significant number of years before working on Wasm. JVM bytecode verification is non-trivial, not only to specify, but to implement efficiently. In Java 6 the class file format introduced stack maps to tame a worst-case O(n^3) bytecode verification overhead, which had become a DoS attack vector. Structured control flow makes Wasm validation effectively linear and vastly simpler to under…

Are they validating code to the same degree though? Like, there are obviously learned lessons in how WASM is designed, but at the same time JVM byte code being at a slightly higher level of abstraction can outright make certain incorrect code impossible to express, so it may not be apples to oranges.

What I’m thinking of is simply memory corruption issues from the linear memory model, and while these can only corrupt the given process, not anything outside, it is still not something the JVM allows.