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.
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.
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.