Comment by austincheney | Hacker News Reader

Comment by austincheney | Hacker News Reader

Parent Full thread

The goal: Allow a uniform execution context (compile target) in the browser via a standard byte code. That means executing an application written in any language, provided a corresponding compiler, as an island in a web page.

In practical terms the language of the browser is JavaScript, but what if JavaScript doesn't do what you need, or it isn't fast enough, or you simply don't like JavaScript. Instead you want to write some application in Rust (just using that as an example). The language of the web is still JavaScript and not Rust so your new application will not run directly in a web page. That's unfortunate, because the web is a fantastic distribution platform because things that run in web pages do not require a separate installation step or a separate download step, since web page assets are downloaded automatically as called by the web page. If you compile your Rust application to WASM it can run in a web browser.

To be clear though WASM isn't replacing JavaScript or even in any way competing with JavaScript, because that is certainly what it sounds like. WASM is a separate and isolated execution instance in the browser, even from the page that contains it. JavaScript, on the other hand, executes directly in the context of the page that requests it.

You might hear some discussion of wanting WASM to replace JavaScript, but that is clearly stated by the WASM project as not a design goal. You might also hear that if only the containing page's DOM were available to WASM it would replace JavaScript, but that isn't a design goal either. That part about the DOM is the confluence of a misunderstanding about the DOM and about WASM's security goals of a separate execution context. There is work, however, on providing some Web API capabilities to WASM so that a WASM instance may have some awareness of its execution context or to allow some manner of external interaction of the WASM instance from the surrounding page. I don't know the status of that work though.

* WASM project site - https://webassembly.org/

* Web APIs, a list of de facto standards for interacting with web browsers from JavaScript - https://developer.mozilla.org/en-US/docs/Web/API

* DOM specification, the DOM is a language agnostic dynamic tree model that represents markup and containing content - https://dom.spec.whatwg.org/

> You might hear some discussion of wanting WASM to replace JavaScript, but that is clearly stated by the WASM project as not a design goal.

Unfortunately, that appears to be a huge miss. There are a lot of programmers in other (non-JS) languages that would very much like to create front end pieces for their web applications.

Hopefully when the interface types proposal (or whatever) happens, direct access to the DOM does become a thing and non-JS programmers really can do their front end work without JS.

Check Qt, Blazor or Uno.

Thanks, but Qt isn't really suitable for web apps. :(

eg PgAdmin, which went from a good desktop application (v3) to unusable in non-trivial cases on the desktop when they switched to Qt (web). :(

Blazor / Uno seem to be C#? Not (personally) going to touch that with a long stick. ;)

Nobody from the WASM working group is working on that though, so the probability of direct access to the page’s DOM is close to zero. Programmers have been hoping for this for years but WASM has been very clear that isn’t in the project’s design path. The are intentional design objectives limiting that work officially but likely the largest hurdle is overcoming various security and privacy concerns already in place due to the isolation of WASM instances from their containing page.

Far more likely, and this already exists in various unofficial examples, is that WASM instances ship with a DOM for accessing markup provided by or requested into the WASM instance.

> ... WASM instances ship with a DOM for accessing markup provided by or requested into the WASM instance.

Sounds like it would achieve the same end goal? eg direct access to the page elements, without needing to go through JS

Or is that my not really understanding the problem space? :)

No, a DOM that is provided by a WASM instance will provide access to markup contents available to that WASM instance, such as markup requested or shipping with the WASM code, but not outside the WASM instance such as the containing page.

Interesting. What's the intended use case for that?

Trying to think of something, but nothing is coming to mind.

If your WASM application makes use of any kind of XML or HTML content you need to parse it or it’s just a string.

No worries, thanks. :)

While replacing JavaScript might not be a design goal, the experience on Android and iOS shows what happens when there is a native layer for other eco-systems to plug into the platform.

For me, WebAssembly will be the revenge of browser plugins.

We already have Flash, Java applets and Silverlight being made available on WebAssembly, even if not at same feature level as their former selfs.

Without the security holes, hopefully.

Well, given that WebAssembly has decided that doing bounds checking inside a linear memory segment, or memory tagging wasn't worth the effort...

Meanwhile real hardware is adopting memory tagging (with exception of x86/x64).

I’m well aware of hardware support for enforcing memory safety, but that’s not quite what I’m talking about here: browser plugins have historically been poorly sandboxed, while WebAssembly should be an improvement in this area.

Which I doubt, given that it depends on what is being compiled into WebAssembly anyway.

It is really nothing new here, just the politics to have a bytecode execution platform that everyone agrees on.

For example, if I can replicate a Flash security flaw with CheerpX, should I blame Flash, CheerpX for being a good implementation, or WebAssembly for allowing Leaning Technologies to faithfully re-implement Flash?

Memory tagging or inner bound checks have no effect on sandboxing. The wasm guarantee is that a module cannot escape it's sandbox, not that it is logically correct.

the security model of the web site based on executing arbitrary code, so you would need to assume that the wasm you receive tagged it's memory in the most malicious way possible anyway.

the way I see it real hardware needs this kind of checks more because they have worse sandboxing

AFAIK WebAssembly can't do more harm than JS since it lives in the same sandbox, so that's not a concern? You're basically running Flash in a small VM.

Also, Flash vulnerabilities were about escaping the execution sandbox of the web, so you should blame bad the implementation/specification of wasm in your case.

Reply on news.ycombinator.com