Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing WCGI: WebAssembly and CGI

wasmer.io

Post reply on HN
Print view View original

111–120 of 121 posts

Re: Announcing WCGI: WebAssembly and CGI

#111

Post by lukevp »

KyeRussell wrote: post #107
adam_arthur wrote: post #97

Earlier quoted context omitted.

Well, that's partly why WASM exists. It can be run outside a browser, and is much more performant than using the whole browser. The future is very likely going to consolidate around WASM and WebGPU, regardless of what hardware you're targeting. If you want more performant specs, it will be driven through a public and consensus driven way... there are far too many economies of scale to standardization for it not to be…

Yeah. You’re right. THIS will be the time that open wins. When most peoples primary computing is running an OS developed by one of two companies that have a strong incentive to maintain walled gardens. Largest /s imaginable. Your comment is pretty far into LARPing territory.

Heard of Kubernetes, Docker/OCI, and CNCF? A crapload of computing now is running within Linux (open) in containers (open). Sure, end users use MacOS and Windows as the base OS, but a lot of programs they interact with now are running in a browser or Electron (all open standards-driven things). WASM’s future is as a much more performant and lightweight alternative to containers, to the point where it could be run and used by anyone. containers require a shitload of configuration to be able to run them, but a wasm module can be packaged up in a native assembly that requires zero runtime setup for the end user. Just install and go.

Re: Announcing WCGI: WebAssembly and CGI

#112

Post by lukevp »

kllrnohj wrote: post #84
KRAKRISMOTT wrote: post #62

Earlier quoted context omitted.

Not just in the past, arbitrary program sandboxing is not possible even today.

Exactly, yet everyone pretends wasm is the exception for some reason...

Wasm is an exception. It’s designed from the ground up to have an extremely simplistic model of execution that prevents common exploits like buffer overflows and such. The WASM runtime only exposes “safe” things and at an incredibly low level. Everything has to be built on top of these abstractions. The JVM is not architected the same way, the VM has a bunch of APIs exposed to it and you have to attempt to constrain those down to make a program secure. WASM starts from a secure by default position and you grant it capabilities as needed to accomplish the task. If all you need is to take in a string, do some computation, and output a string, then you can run a WASM module with zero disk or network access whatsoever, no ability to integrate with processes, environment variables, or anything else on the system. Trying to run a program on the JVM or CLR but prevent it from reaching out of itself by blacklisting certain functions or something is an exercise in futility.

Re: Announcing WCGI: WebAssembly and CGI

#113

Post by 0xbadcafebee »

PoignardAzur wrote: post #57
0xbadcafebee wrote: post #16

PHP was compiled into WASM, so now you can run PHP apps "as WASM". How is this different from just running PHP, without WASM? Apparently it's faster, but also they make this claim: "Picture running Wordpress and not having to worry about attackers breaking into your system" uh, so, you sprinkled some WASM magic on some code and suddenly several decades worth of security research is obsolete? .....yeah, I'm gonna call…

Compiling a service to wasm to protect it "from itself" (ie from untrusted data) has trade-offs. On the one hand, you lose ASLR and other security features designed for native code. On the other hand, your program becomes immune to stack smashing, so arbitrary code execution becomes a lot harder for an attacker (at least that's my understanding).

But arbitrary code execution hardly features on the OWASP Top 10 for 2021:

  - Broken Access Control
  - Cryptographic Failures
  - Injection
  - Insecure Design
  - Security Misconfiguration
  - Vulnerable and Outdated Components
  - Identification and Authentication Failures 
  - Software and Data Integrity Failures
  - Security Logging and Monitoring Failures
  - Server-Side Request Forgery
If a modern hacker wants to exploit a web app, their first thought isn't shellcode.

Re: Announcing WCGI: WebAssembly and CGI

#114

Post by kllrnohj »

lukevp wrote: post #112
kllrnohj wrote: post #84

Earlier quoted context omitted.

Exactly, yet everyone pretends wasm is the exception for some reason...

Wasm is an exception. It’s designed from the ground up to have an extremely simplistic model of execution that prevents common exploits like buffer overflows and such. The WASM runtime only exposes “safe” things and at an incredibly low level. Everything has to be built on top of these abstractions. The JVM is not architected the same way, the VM has a bunch of APIs exposed to it and you have to attempt to constrain…

WASM was designed before spectre happened, so no it's not the exception. In-process sandboxing cannot be securely designed anymore. You can endlessly chase security exploits with increasingly expensive and convoluted workarounds, but that's about it.

> It’s designed from the ground up to have an extremely simplistic model of execution that prevents common exploits like buffer overflows and such.

So is the JVM and CLR and dozens of prior runtimes for that matter.

WASM for guests is mostly a security regression as all the design focus was on protecting the host. Things in the runtime got thrown under the security bus (such as no ASLR)

> The JVM is not architected the same way, the VM has a bunch of APIs exposed to it and you have to attempt to constrain those down to make a program secure.

You're confusing concepts here. The JVM bytecode runtime has very few APIs and WASM has no inherent requirement on being minimal or capability-based. WASI, which is what's being used here, has neither of those design attributes, for example. It's just regular POSIX apis. No permission system + massive API surface, yet still WASM all the same

Re: Announcing WCGI: WebAssembly and CGI

#115

Post by adam_arthur »

KyeRussell wrote: post #107
adam_arthur wrote: post #97

Earlier quoted context omitted.

Well, that's partly why WASM exists. It can be run outside a browser, and is much more performant than using the whole browser. The future is very likely going to consolidate around WASM and WebGPU, regardless of what hardware you're targeting. If you want more performant specs, it will be driven through a public and consensus driven way... there are far too many economies of scale to standardization for it not to be…

Yeah. You’re right. THIS will be the time that open wins. When most peoples primary computing is running an OS developed by one of two companies that have a strong incentive to maintain walled gardens. Largest /s imaginable. Your comment is pretty far into LARPing territory.

The browser/web is already open. People are writing cross platform apps in browser containers. Open is already the standard. WASM simply closes the performance gap between “widely accepted open standards” and native.

You seem confused… fewer and fewer people are writing software in OS locked apis/contexts. Back in the day it was much closer to 100%

Re: Announcing WCGI: WebAssembly and CGI

#116

Post by akira2501 »

KyeRussell wrote: post #109
akira2501 wrote: post #56

Earlier quoted context omitted.

> but 20 years ago you could run JVM apps in the browser without issues That was definitely not my experience at that time using a linux desktop.

I’m sure that compared to doing anything else on a Linux desktop it was just fine. You made your bed.

It was not. It was demonstrably worse. It had it's own janky UI that barely worked, it failed to understand the filesystem most of the time, and it failed to integrate cleanly with any other devices on the system.

Everything _else_ was able to do this just fine, in particular it's main competition, Adobe flash. That was actually _almost_ a first class experience and I didn't need to track down and install "icedtea" to make it all work. It just worked out of the box.

The JVM promised "write once, run anywhere." You can blame me for that failure, if you like, but it was then and always was a flat lie. You simply choose to ignore this.

Re: Announcing WCGI: WebAssembly and CGI

#117

Post by 0xbadcafebee »

lukevp wrote: post #111
KyeRussell wrote: post #107

Earlier quoted context omitted.

Yeah. You’re right. THIS will be the time that open wins. When most peoples primary computing is running an OS developed by one of two companies that have a strong incentive to maintain walled gardens. Largest /s imaginable. Your comment is pretty far into LARPing territory.

Heard of Kubernetes, Docker/OCI, and CNCF? A crapload of computing now is running within Linux (open) in containers (open). Sure, end users use MacOS and Windows as the base OS, but a lot of programs they interact with now are running in a browser or Electron (all open standards-driven things). WASM’s future is as a much more performant and lightweight alternative to containers, to the point where it could be run and…

You could say the same thing of Go apps, but they certainly haven't taken over computing. They got a lot of attention from certain corners, but I think everyone acknowledges now that it's just another compiled language. That doesn't solve all your problems, it just solves one. Maybe WASM solves two problems by not needing to be cross-compiled. But there's still a thousand problems left, many of which are addressed by containerization, but not addressed by WASM.

The innovation of "docker containers" as a total solution is more akin to a POSIX standard than the Go language. Containers only became popular because of Docker, not because of containers themselves. Docker is a solution to a dozen different problems. "A container" is really just a chroot in a unique namespace. Again, that's basically just one problem solved. The functional combination of all the features of container orchestration software and interoperability is where the actual value of containers lies. Not in the container, but in the 12 different problems that are now all solved in a universal way by all the different solutions that deal with containers in the same way.

If WASM can evolve an entire ecosystem and standard around all the problems needed to be solved to run software easier, then sure, it could be revolutionary. We'll see if that happens in a way that is easy to use. My bet is it won't happen.

Re: Announcing WCGI: WebAssembly and CGI

#118

Post by herdcall »

joncfoo wrote: post #7

Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode. We're hea…

Multi language support is just one of the selling points, you didn't mention the other two: sandboxed security with explicit capabilities and high performance. E.g., I have a Web Assembly module running on the server (Fermyon) that needs explicit capabilities defined to even make a network call to a Twilio endpoint or read a local file. That means you can run a random Web Assembly module that you with confidence, just like you can typically open a random website on the browser without concern. By contast, you can't say that when running a random Java class that you don't trust.

Re: Announcing WCGI: WebAssembly and CGI

#119

Post by syrusakbary »

benatkin wrote: post #94
joncfoo wrote: post #7

Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode. We're hea…

The delivery of assets sounds like a job for Bindle which is already integrated to Spin, which looks to be more similar to python's WSGI than this https://www.fermyon.com/spin https://www.fermyon.com/blog/bindle-what-is-it

Bindle is one of the worst specifications of a container format I've ever seen, I would personally recommend anyone to stay away from it.

No wonder they are ditching it in favor of OCI...

Re: Announcing WCGI: WebAssembly and CGI

#120

Post by syrusakbary »

benatkin wrote: post #95
paulgb wrote: post #4

I've always loved the simplicity and flexibility of CGI. To check my understanding: since CGI just takes a raw request over stdin and returns a response over stdout, would a WCGI wasm module be compatible with WAGI[1] and vice-versa? [1] https://github.com/deislabs/wagi

Matt Butcher who used to work at Deis, which developed WAGI, and Microsoft after it was acquired, now has a new startup, Fermyon, which has something called Spin which I think uses a new protocol that's different from CGI. https://www.fermyon.com/blog/introducing-spin That would make sense, anyhoo. CGI is plain text which I don't think is optimal for this stuff.

Hey Ben, why so many comments spamming Fermyon on this thread? Do you have any relation with them?
Post reply on HN