Mozilla + Intel + Red Hat Form The Bytecode Alliance To Run WebAssembly Everywhere

[AsuMagic]

Browser should by default limit CPU time (or even power usage) per page or per site and should have implemented much stricter policy for memory or any computing resources, and this, again, secure by default. Any website can load infinitely long web page until browser crash. This endless scrolling web pages this should be limited by the browser not by laws

The study mentioned memory-bound mining. So... I don't have any idea what CPU usage you would have expected.
I feel it would be a little weird to have this on the browser level. If your browser properly runs JS in its own process, then you can use cgroups to apply that already (or so I think?)

[S.Pam]

Let me introduce you all to the Phoronix point.
A point where a thread shifts into a shitty, low-tier shitpost of a conspiracy theory.
Occurs in about every thread where morons think they can jam in their shitty opinion.

I was only partly ironical. In this case I am sure it will inevitably lead to quite severe security risks. Basically the web is transforming into running remote apps locally. I don't see how different this is from flash or java plugins?

[cynical]

A lot of people seem to be confused here. WebAssembly is not a replacement for JavaScript, and this particular use has nothing to do with the browser. This article is about using WASM to solve the security problem for those of us that are composing packages from repositories like crates.io or npm.

Right now, you are handing full access to the system for any packages you include in your application. The idea here is to isolate packages and only give them what they need to function, so that even if they contained malicious code (or were updated to contain malicious code in the future) or had some terrible bug, an attacker would be limited to some narrow path rather than having total freedom. So for example, you might grant a package access to a particular directory, but they would not be able to modify their code to read anywhere else. (and if you mistakenly passed a sensitive directory, it would only happen at the top level, where you could catch your mistake)

The real gain here is that they claim this mechanism (dubbed "nanoprocess") will be lighter than a container, vm, or even process. They claim it will be slightly slower than a function call. If true, this is huge, because this is the biggest security problem in modern software development. You either write everything yourself and it takes forever, or you trust in other packages but have no real chance of reviewing them all. On top of the security benefits, the idea is that you will be able to use software modules that might not even be in the same language.

That's really interesting, but it sounds like this project is a long ways off still.

[cynical]

I was only partly ironical. In this case I am sure it will inevitably lead to quite severe security risks. Basically the web is transforming into running remote apps locally. I don't see how different this is from flash or java plugins?

It's different in that WASM is sandboxed in the same way as JavaScript is, and subject to the same cross-origin restrictions, at least when embedded in a browser environment. It also relies on the same Web APIs. You can read more here and here. I believe JavaScript as an open language is great. Obfuscated or not, it is nice to have scripts being loaded from multiple domains and for you to be able to selectively block them if you choose. How are you going to do that if loading each site is no different than loading a typical binary? So despite the moaners on here, I don't think anyone wants JS to be replaced on the web.

The thing about WASM is that the web definitely needed some low level binary format for things like games or VR, where you can't sacrifice any performance. And it is designed to be run side by side with JS. So your application can be mostly JS, but then load WASM modules. Imagine a website where the ROM emulator was built into the page and you just clicked to load different games, as an example. Or something like Google Maps, but with real-time 3D viewing. Or a Chromebook with a video editing application.

Oh and I forgot the best part, it will use s-expressions!

(module
  (func (param $lhs i32) (param $rhs i32) (result i32)
    local.get $lhs
    local.get $rhs
    i32.add))

---

But in the context of people wanting forms or to run crap games in their browsers and such, WASM is preferable to Javascript.

Ahem

Is WebAssembly trying to replace JavaScript?


No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. Furthermore, it is expected that JavaScript and WebAssembly will be used together in a number of configurations:

• Whole, compiled C++ apps that leverage JavaScript to glue things together.
• HTML/CSS/JavaScript UI around a main WebAssembly-controlled center canvas, allowing developers to leverage the power of web frameworks to build accessible, web-native-feeling experiences.
• Mostly HTML/CSS/JavaScript app with a few high-performance WebAssembly modules (e.g., graphing, simulation, image/sound/video processing, visualization, animation, compression, etc., examples which we can already see in asm.js today) allowing developers to reuse popular WebAssembly libraries just like JavaScript libraries today.
• When WebAssembly gains the ability to access garbage-collected objects , those objects will be shared with JavaScript, and not live in a walled-off world of their own.

[yturmisil]

Its basically a reaction to the silly idea that everything should run in a web browser.

So instead of that web browser shit will run on everything now?

what a great time to be alive