Slashdot Mirror
Chrome To Deprecate PNaCl, Embrace New WebAssembly Standard (tomshardware.com)
An anonymous reader quotes Tom's Hardware
Google announced that its Portable Native Client (PNaCl) solution for making native code run inside the browser will be replaced by the new cross-browser web standard called WebAssembly... Even though Google open sourced PNaCl, as part of the Chromium project, Mozilla ended up creating its own alternative called "asm.js," an optimized subset of JavaScript that could also compile to the assembly language. Mozilla thought that asm.js was far simpler to implement and required no API compatibility, as PNaCl did. As these projects seemed to go nowhere, with everyone promoting their own standard, the major browser vendors seem to have eventually decided on creating WebAssembly. WebAssembly can give web apps near-native performance, offers support for more CPU features, and is simpler to implement in browsers and use by developers.
WebAssembly is a byte code for a virtual machine. It's not native.
PNaCl is a byte code for a virtual machine, with an interfaces based on an earlier native virtual container (NaCl).
these are secure if virtualization is complete. but all known implementations are still susceptible to row hammer as it's too difficult a problem to solve for VM implementers.
“Common sense is not so common.” — Voltaire
WebAssembly: Mozilla Won (Not a put-down to the excellent Chrome developers, but acknowledging the massive and important contribution Mozilla made here.)
We should be going the opposite direction and eliminating JavaScript altogether.
Though I agree with you and others that JavaScript has been abused, I disagree that the web ought to throw the proverbial baby out with the bathwater. In some cases, JavaScript dramatically improves the user experience in web applications. It makes others possible in the first place.
Say you want to let a user fill out a web form, but you don't want the poor experience associated with having to fill out the entire form and then perform a form submission and full page reload to catch the most common entry errors. The common way to improve the user's experience is by sending a short script that prevalidates the entries before the server validates them authoritatively, letting the user fix things before they're submitted.
Say you want to offer a chat service, where users send short strings of up to 100 characters or so to a channel and other users in the same channel receive them. You might consider putting up an IRC server, but your prospective users lack privileges to permanently install an IRC client on the devices that they use. You might try to do this as a web application without JavaScript, but you'll have to rely on users remembering to repeatedly click a "Check for New Messages" button to reload the iframe containing recent messages sent to a channel, which is a poor experience for users. In this case, the least bad option is a web application with a script that waits for new messages to arrive through a WebSocket and appends them to the list of recent messages.
Say you want to develop a real-time video game and allow members of the public to play it, but Valve, Apple, and the major console makers have turned your game down for one reason or another. So instead, you decide to offer the video game as a web application. The only interactivity possible without script is a form submission followed by a full reload of a page or iframe, but that's not possible for a real-time game. Thus script is again least bad.
If you're not convinced, I have more examples.
The advantage of WebAssembly over Java is that the former isn't owned by One Rich American Called Larry Ellison.
If there's more than one implementation of a particular platform released as free software, these implementations can compete on security. Chromium is free software, supports JavaScript, and will support WebAssembly. Likewise with Firefox.
But we didn't get that opportunity with Java or Flash. Last I checked, the license of the Java Language Specification prohibited publishing an incomplete implementation. This requirement to keep works-in-progress confidential within an organization in turn had the effect of keeping independent free implementations of Java from existing legally, ultimately leading to Oracle v. Google. Likewise, Adobe's SWF spec was intended for developers of tools that output SWF, and its license specifically banned using the spec to make a third-party SWF player until February 2009.
PNaCl and NaCl are *not* virtual machines!
Yes, they are sandboxed, but they are sandboxed by constraining the assembly language generated.
PNaCl differs only in that it sends the intermediate compiled code down to the browser to be processed in the final LLVM stage backend into assembly language within the browser.
The major reason for deprecating it is that a compiler back end is a lot to carry around for little benefit.
The reason the benefit is small, however, has less to do with PNaCl itself, and a lot more to do with how Google handles projects within Google, and my inability to actually pry my 20% time -- that I was promised when I was hired -- out of Google to do work on the problem.
I talk about it in another post.
The demise of PNaCl is really unfortunate.
"WebAssembly" is a virtual machine; it might as well be named "JVM".
PNaCl pushed down partially compiled code so that a compiler backend could localize it to Native code on the local machine. It used LLVM IMF (effectively) to implement ANDF -- Architecture Neutral Distribution Format, which was a promise Apple was never able to achieve -- which is why Apple has "Fat Binaries": single binaries with multiple images.
NaCl, by contrast, targeted a specific binary instruction set in the target, and people would use different wrappers for the actual code itself, via JavaScript, to select the architecture (ARM, x86, etc.) of the actual binaries being downloaded in NaCl form.
The question is whether you do the finalization work on the sender, or the receiver. Both systems, however, had as their primary intent the ability to extend JaveScript with native code plugins.
In the absolute limit, you'd write all your code in native code, and then ship it down with a small JavaScript shim, in order to call into that code's "main" with a thread context, and set it running as native code.
There are a number of Games which did this, and there's a (moderately common) use of NaCl to push down x86 games running in a PC emulator as a packaged lump in NaCl.
PNaCl -- which was platform independent -- and NaCl, which I would say has arguably failed as well -- failed because it was massively difficult to develop applications in it.
This is predominantly because there is insufficient glue code and no IDL in order to define JavaScript interfaces which also described C/C++ code containers for the compilers used to generate the native code on the front end.
This made it impractical to have what is -- in essence -- a browser-level jandboxed "JNI" equivalent for JavaScript.
So people simply didn't use it.
In other words, it was not a complete product, and like Mozilla in the early days, it was nearly impossible to build anything useful out of it that actually did anything that had any impact on anything.
NaCl -- apparently not (yet) deprecated -- still has this problem.
Think of it as having DCE or Sun RPC available as an interface between JavaScript and native code, and having no "rpcgen" and no "xdr" library available to use.
This is pretty typical of some Google products: they go 80% of the way there, and then, because they are organizationally not motivated to do things which are difficult -- because you can pretty much walk to any other job inside Google, should your manager ask you to do something you considered "unfun" -- no one finishes the remaining 20%.
I tried to resolve this in my 20% time at Google, but was rather constantly thwarted in the effort (the 20% time at Google is largely mythical) by providing an IDL in XML that would let you describe the interfaces, and then generate the JavaScript templates on one end, and the C code containers for the functions that needed to be written on the other, along with an "XDR" library for marshaling arbitrary data back and forth between the "C form" and the "externalized JavaScript" form.
Sadly, this project never came to fruition -- I was even, stupidly was writing it in Python, to make it politically acceptable to the people who were complaining the loudest, when I could have cranked it out in C in a couple of days -- Python is really slow/bad at XML, among other problem.
Personally, I think this deprecation and switch is a terrible idea.
Putting a bytecode interpreter into your browser is exactly what malware sites want you to do, when they bitch about you needing to install the Java plugin into your browser.
WebAssembly is exactly that, only renamed from "Java", and not uninstallable or turn-offable.
Massively bad mistake.
The only saving grace is that I have no doubt that it will be "about as popular as NaCl/PNaCl", and it'll stop at 80% of the way to "people are now likely to use this thing to do their projects".
The 'best' browser apps run literally thousands of times slower than what the native hardware is capable of.
If your computer happens to be something other than a Mac, a Mac app runs at zero speed.
If I lack the funding to develop my application for more than one platform, which of the following would reach the most users?
The way to do that is to literally pull out capabilities.
If you don't want it to be able to open files, you need to make it impossible to express "open a local filesystem file".
The browser DOMs are quite locked down in this regard, but they are still programs in themselves vulnerable to buffer overflows, etc. but - pretty much - you can't just access my camera, microphone, USB devices, arbitrary memory, etc. from a webpage.
If you're parsing the WebGL into a strict subset of OpenGL and providing virtualising memory etc. addresses that cannot be misconstrued or reveal other RAM, that's as good as you can get. And that's what browsers do.
The problem you describe is really just "I'm running a third-party program to run my other programs", not something different or defensible against.
Try writing a program in WebAssembly, though. Emscripten will compile C to WebAssembly if you want. On any up-to-date browser it's virtually impossible to make it do anything untoward except (maybe) use up CPU time. But you also can't access filesystems (Emscripten fakes a filesystem into a loopback area of memory, pre-allocated in one contiguous block at startup), access the network (Emscripten requires you to WebSocket anything you want to do on the net, and C sockets come out as WebSocket traffic requiring a WebSocet server somewhere - e.g. websockify - for it to interact with and convert the WebSockets back to normal network traffic. Not something you're going to be able to get a user to set up.), access devices or graphics RAM (but you can use WebGL), etc.
The browser is the interface, coupled with not being able to express malicious actions. Try to bypass it. Of course, it's not going to 100% impenetrable but NOTHING has yet proven to be except literally not doing anything useful. Hell, with RowHammer, code can actually interfere with "physically nearby" memory, and you can even detect the RF coming from a chip and intercept encryption by listening to the emissions. You have NO defence against those kinds of attacks.
But a browser running WebAssembly is no worse than a browser rendering plain HTML. An innocent action in a limited space. Until enough attention is garnered to warrant thousands of hours of attention from dedicated hackers trying to bypass it.
The fact is, however, that you still want to go on Netflix and watch your programs, log into your bank account, buy stuff on Amazon. And there's NO WAY to do that without taking exactly the same risks as running WebAssembly, which is contained only by your browser security model (Unlike Java and .NET which had their OWN security model separately and the browser just had to execute their code on the local machine and hope they'd done their job - they rarely had, which is why plugins are dead nowadays).
You think that you can bring all this stuff back to plain HTML, and - what? - Perl on the CGI backend of a server and be immune? We thought that 20 years ago, it didn't work out.
At some point you have to take user input, or input from a remote website, and interpret it in a way that cannot possibly be compromised while letting the user accomplish what they want to (e.g. play a movie, log in securely, etc.). If you find a way to do that, sell it to the world. Because they'd pay through the nose for it.
WebAssembly doesn't allow your code to do anything more than what normal JavaScript can do. It's really just a faster way to run JavaScript. It's not any kind of major shift except for allowing faster apps to be developed. There's really no need for signing as you wouldn't sign JavaScript either.