Comment by nu23 | Hacker News Reader

Comment by nu23 | Hacker News Reader

Parent Full thread

I agree with what you are saying in the beginning - We definitely need a proper standard and not a single company having design control. I am not so much defending the way Google is going about it, but rather the value of something which plays the essentially same role.

Ideally, I would like the web developer to have as much freedom as a developer for a native application - the freedom to choose a programming language and the ability to compile to a reasonably low level target for performance while still being cross-platform. Now, this somehow needs to be done without the security nightmares of ActiveX plugins. (Though, I dont see the non-security problems with a bunch of shared libraries stored on the browser. This is essentially what the OS does, and my goal is to replace the OS with the browser. Bandwidth will probably improve so that downloading libraries shouldn't be a problem and if not, the web site maintainer can still choose not to develop in a large library environment The popular ones will be cached in any case.)

You seem to be saying that the technical difficulties of doing this in a well-specified (memory and control-flow), secure and cross-platform way are intractable. Maybe this can be solved by moving the VM to a more abstract level.

I don't know how to be more clear. I'm not talking about the technical difficulties by themselves, out of context. The technical difficulties are formidable -- but not insuperable for Google with its many engineers.

I'm saying that in context of market realities, the other browsers won't use shared Google-source as the "implementation is the specification" for NaCl/Pepper, and no one can write a real NaCl/Pepper spec by which any browser could implement an independent and interoperable workalike in less than decades.

So why try if the OSes can do their own non-interoperating workalikes? (And they are already doing this, from what I hear.) If safe native code on the web is mainly for plugins, there's no problem. Plugins are OS-specific today and likely to remain so, safety or no.

Moving the Web VM to a more abstract level... hmm, sounds like JS as better compiler target over time. See also https://github.com/kripken/emscripten/.

OK, Thanks for clarifying. Again, my purpose is not defending NaCl and if this can be done by making JS a better target or by a translator from another VM, that's great, and I hope these projects succeed. And these are worth trying even when the OSes have incompatible workalikes, precisely because they are incompatible. Thanks again for all your work on JS and the open web.

In the very long run, could OS-specific CFI enforcement toolchains and runtimes merge into a single standard, usable on the web?

Maybe, but that is beyond my prediction horizon. Either OS vendors or browser vendors (if there's a difference) would have to standardize a butt-load of APIs.

Since the '60s, researchers have dreamed of universal object files (ANDF, e.g.). It would be too funny if far-future JS merges into this single standard too!

("too funny" in my experience means this will definitely happen...)

Reply on news.ycombinator.com