4 ms·

This is a great take, I agree 100%. I'm curious, would you mind elaborating on your use-cases for sandboxed backend application code? This is clearly the direc

This is a great take, I agree 100%. I'm curious, would you mind elaborating on your use-cases for sandboxed backend application code? This is clearly the direction in which it's all headed, yet is still mentioned relatively rarely in WASM-related discussions on here.

bborud 2y ago
Look at my other reply for a use-case. In general I think being able to run user-supplied code in a sandbox is the most interesting use-case for WASM and backends/Go. Compiling entire applications to WASM and running them in a WASM runtime is of no interest to me. So for instance WASI isn't actually useful to me since I'd only want to project a very narrow set of APIs into the runtime for the (WASM) code to call. I certainly do not want to give it access to my system and then have to clamp down what access I give it. I think what the original post points to is an interesting step in the right direction. If someone were to figure out an ergonomic and safe way to support structs, []byte slices as both parameters and return values that would probably open up a lot of new possibilities by lowering the barriers for adoption. If it is Go specific, I can live with that. If it can be done in a manner that supports lots of other languages, that would be fantastic, but to me, right now, it isn't critical. If it were up to me I'd say forget about WASI for now and solve that problem instead. Yes WASI may be slightly useful some day (I can't see that I'll ever use it), but actually being able to have sandboxed runtimes where I can project in my APIs is vastly more useful. (I'm not saying WASI is not useful. I'm saying that it is not useful to me. And I think that if projecting Go APIs into a sandbox is easy, then WASI probably isn't going to be important to most people doing backends as they can project more application specific, narrower and more strictly guarded APIs into the sandbox)
- boomskats 2y ago
  Thanks, appreciate the response. I read your other answer too. Given what you've just described, do you have an opinion on the component model & WIT[0]? [0]: https://component-model.bytecodealliance.org/design/wit.html#built-in-types https://component-model.bytecodealliance.org/design/wit.html...
  - bborud 2y ago
    I wasn't aware of WIT. I'll have a look. Thanks for the link!
- synergy20 2y ago
  why not just a slim podman?
  - bborud 2y ago
    I wouldn't want to run code from a third party in a container.
    - synergy20 2y ago
      why is that? how is it different from WASM? podman can be rootless, and it runs inside its own sandbox on the server side as much as WASM runtime does. Plus there are many sandbox options on linux for podman.
      - bborud 2y ago
        In a sandbox you start out with access to nothing except the apis that you explicitly expose into the sandbox. In Podman you start out with a huge attack surface which you then have to clamp down. One of those surfaces is the kernel. Another is the network. Using containers to run untrusted third party code is horribly risky. Containers provide nowhere nearly enough isolation and separation.
        synergy20 2y ago
        these days containers run well-known open source code or your own code, and are used widely in the field. Linux does have namespaces and other security approaches to safeguard them further. yes they are less secure than WASM but security is always a compromise between convenience and cost. Anyway, points taken, thanks.
- apitman 2y ago
  Check out Extism
  - Nezteb 2y ago
    I came here to say this. Here are their SDK docs: https://github.com/extism/extism#run-webassembly-in-your-app https://github.com/extism/extism#run-webassembly-in-your-app
twoodfin 2y ago
Database stored procedures / user-defined functions written in arbitrary languages is a live use case on several platforms today.
cogman10 2y ago
> I'm curious, would you mind elaborating on your use-cases for sandboxed backend application code? When working with backend systems you generally have 2 choices, a less secure containerized environment that does a very good job of distributing resources or a bulky VM which has a fixed memory cost that you might not need. WASM sits right in the middle of the two. It has a durable sandbox that prevents bugs in the application logic from exposing the whole machine to exploit (and it itself can be further isolated using the same containerization security practices) but also has the benefits of single app like resource requirements. Another prime benefit of WASM (not related to the sandboxing) is that WASM is a write once run anywhere standard. That means you don't need a different x86 and ARM wasm deployable. Similar to Java's JAR.

bborud 2y ago

Look at my other reply for a use-case. In general I think being able to run user-supplied code in a sandbox is the most interesting use-case for WASM and backends/Go. Compiling entire applications to WASM and running them in a WASM runtime is of no interest to me. So for instance WASI isn't actually useful to me since I'd only want to project a very narrow set of APIs into the runtime for the (WASM) code to call. I certainly do not want to give it access to my system and then have to clamp down what access I give it. I think what the original post points to is an interesting step in the right direction. If someone were to figure out an ergonomic and safe way to support structs, []byte slices as both parameters and return values that would probably open up a lot of new possibilities by lowering the barriers for adoption. If it is Go specific, I can live with that. If it can be done in a manner that supports lots of other languages, that would be fantastic, but to me, right now, it isn't critical. If it were up to me I'd say forget about WASI for now and solve that problem instead. Yes WASI may be slightly useful some day (I can't see that I'll ever use it), but actually being able to have sandboxed runtimes where I can project in my APIs is vastly more useful. (I'm not saying WASI is not useful. I'm saying that it is not useful to me. And I think that if projecting Go APIs into a sandbox is easy, then WASI probably isn't going to be important to most people doing backends as they can project more application specific, narrower and more strictly guarded APIs into the sandbox)

boomskats 2y ago
Thanks, appreciate the response. I read your other answer too. Given what you've just described, do you have an opinion on the component model & WIT[0]? [0]: https://component-model.bytecodealliance.org/design/wit.html#built-in-types https://component-model.bytecodealliance.org/design/wit.html...
- bborud 2y ago
  I wasn't aware of WIT. I'll have a look. Thanks for the link!
synergy20 2y ago
why not just a slim podman?
- bborud 2y ago
  I wouldn't want to run code from a third party in a container.
  - synergy20 2y ago
    why is that? how is it different from WASM? podman can be rootless, and it runs inside its own sandbox on the server side as much as WASM runtime does. Plus there are many sandbox options on linux for podman.
    - bborud 2y ago
      In a sandbox you start out with access to nothing except the apis that you explicitly expose into the sandbox. In Podman you start out with a huge attack surface which you then have to clamp down. One of those surfaces is the kernel. Another is the network. Using containers to run untrusted third party code is horribly risky. Containers provide nowhere nearly enough isolation and separation.
      - synergy20 2y ago
        these days containers run well-known open source code or your own code, and are used widely in the field. Linux does have namespaces and other security approaches to safeguard them further. yes they are less secure than WASM but security is always a compromise between convenience and cost. Anyway, points taken, thanks.
apitman 2y ago
Check out Extism
- Nezteb 2y ago
  I came here to say this. Here are their SDK docs: https://github.com/extism/extism#run-webassembly-in-your-app https://github.com/extism/extism#run-webassembly-in-your-app

twoodfin 2y ago

Database stored procedures / user-defined functions written in arbitrary languages is a live use case on several platforms today.

cogman10 2y ago

> I'm curious, would you mind elaborating on your use-cases for sandboxed backend application code? When working with backend systems you generally have 2 choices, a less secure containerized environment that does a very good job of distributing resources or a bulky VM which has a fixed memory cost that you might not need. WASM sits right in the middle of the two. It has a durable sandbox that prevents bugs in the application logic from exposing the whole machine to exploit (and it itself can be further isolated using the same containerization security practices) but also has the benefits of single app like resource requirements. Another prime benefit of WASM (not related to the sandboxing) is that WASM is a write once run anywhere standard. That means you don't need a different x86 and ARM wasm deployable. Similar to Java's JAR.