Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
Graal
GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Uno Platform
Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.
-
-
-
While a "host" application (for the WASM runtime used) is required to enable access to graphical output (or user input) it doesn't have to be a browser.
At the (almost) most basic level a chunk of memory can be used as a framebuffer--the host application would read the pixel data which the WASM bytecode wrote and then write it to the host display via OS-level routines.
There are some plans/experiments at making a framebuffer "device" available as part of WASI.
I've written a couple of graphical WASM host applications that aren't browsers (and which don't use memory for pixel data transfer just integer values returned from a function):
The "WebAssembly Calling Card (WACC) Viewer" is implemented via the Godot game engine and an addon that integrates the Wasmtime WASM runtime with the engine: https://wacc.rancidbacon.com
(Also implemented a WACC Viewer in Rust: https://gitlab.com/RancidBacon/rusty-wacc-viewer)
WACC specifies how to transform three integer values (returned from a function in a WASM module) into a coloured triangle in order to render it on screen.
Another "host application" I implemented was a libretro compatible plugin that loads a WASM module and then feeds the module with input from libretro & retrieves framebuffer pixel data (one pixel at a time :D ) via a WASM function call & writes it to the libretro framebuffer for display.
Numerous native runtimes for webassembly already exist[0], with the current popular choices apparently being Wasmer[1] and Wasmtime[2].
All one would need to do (AFAIK) is ship a client for all major platforms, as is done with Electron (and web browsers themselves, and everything else.)
[0]https://github.com/appcypher/awesome-wasm-runtimes
For me, the most interesting potential of WASM is it provides a platform-independent sandboxed way to run untrusted code written in multiple programming languages.
This means it's in theory possible to run the same code on an embedded hardware platform, a desktop app or in the browser.
And while I'm sure there's "serious" business uses for that capability :) I'm most interested in what it enables in terms of user customisation/modding of games.
Which was my main motivation for creating a Wasmtime WASM runtime add-on for the Godot game engine: https://gitlab.com/RancidBacon/godot-wasm-engine
And also designing the "WebAssembly Calling Card" specification as a way of demonstrating how the same code could produce graphical output that is then used in 2D or 3D environments: https://wacc.rancidbacon.com
Of course you could run Rust on the JVM (more precisely on GraalVM)!
Have a look at Project Sulong.
https://github.com/oracle/graal/tree/master/sulong
Rust has an interesting application for WASM where it can be used to pre-compile macros. Saves a bunch of compilation time by skipping the need to compile the macros up front.
https://github.com/dtolnay/watt
I won't surely change your mind, that is exactly what I am looking for.
WebAssembly made us regress 10 years, and we lost the great GUI based tooling for Web page creation and 3D games that are actually hardware accelerated without browsers doing blacklists.
https://platform.uno/
Hm not really but I do update my repo on github.com. It's all work in progress stuff being designed as I go.
https://github.com/alttpo/bsnes-plus/tree/wasm/bsnes/wasm
Yes, WA has a defined security scope: it's right between the host and the WA program, and if you choose to sidestep it by eval-ing the output of a potentially malicious WA program, or simply handing it secrets, obviously you can get poor outcomes.
No, WA has not solved the halting problem and fixed all bugs in sandboxed programs.
Yes, it's important for people developing WA-based systems to acknowledge the above limitations.
You've been brandying about this paper for the last year as if it means something that it doesn't [1-12]. Every time someone actually reads it they come to the same conclusion that this paper says nothing about the WA-host memory barrier -- and "everyone" includes the authors themselves [13]. And every time you respond by moving the goal posts with "but but WA isn't magic security pixie dust that solves all security problems". If I sound annoyed it's because I've been pushing back on your FUD with nary a direct response that acknowledges these limitations to your narrative and I am annoyed. Also, it's been a year now, where are all these papers that break WA that you keep promising? Are you privy to WA-host memory barrier breaking results that have yet to be published (and aren't just repackaged CPU vulnerabilities)? I'm open to evaluating the claim of such a break being found in the future, but there's no evidence for it yet.
[1-12]: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
[13]: https://news.ycombinator.com/item?id=24223979
I'm not sure you could hack the control flow when running bytecode on the JVM, but I strongly doubt that. (The JVM is "high-level" as pointed out previously and doesn't execute ASM like code. So there is no of the attack surface you have to care on the ASM level).
And capabilities are anyway something that belongs into the OS — and than programs need to be written accordingly. The whole point of the capability-security model is that you can't add it after the fact. That's why UNIX isn't, and never will be, a capability secure OS.
But "sanboxing" some process running on a VM is completely independent of that!
WASM won't get you anything beyond a "simple sanbox" ootb. Exactly the same as you have in the other major VM runtimes.
If you want capability-secure Rust, there is much more to that. You have to change a lot of code, and use an alternative std. lib¹. Of course you can't than use any code (or OS functionality) when it isn't also capability-secure. Otherwise the model breaks.
To be capability-secure you have actually to rewrite the world…
¹ https://github.com/bytecodealliance/cap-std