Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Chrome The Internet Google Mozilla

Chrome To Deprecate PNaCl, Embrace New WebAssembly Standard (tomshardware.com) 108

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.
This discussion has been archived. No new comments can be posted.

Chrome To Deprecate PNaCl, Embrace New WebAssembly Standard

Comments Filter:
  • by Anonymous Coward

    None of this matters a bit to desktop users.

    • Right, become desktop users don't use browsers.

    • Web applications are not just for mobile. We've abandoned several applications because the browser no longer supports Java applets. Perhaps Webassembly will fill the gap.
  • by Anonymous Coward on Saturday June 03, 2017 @12:57PM (#54542717)
    WebAssembly: Mozilla Won [ocallahan.org] (Not a put-down to the excellent Chrome developers, but acknowledging the massive and important contribution Mozilla made here.)
  • by Anonymous Coward

    It's time to go back to Web 1.0, back when web sites could be used on Megabytes of RAM and just 56K modems. Modern sites have become so morbidly obese with HTML5 and autoplaying media that even my computer with 16 Gigabytes of RAM slow down. This Web assembly will be used to create even more bloated web sites with adblock defeating adverts and tracking. Firefox has jumped the shark too, with Version 57 being the death of "classic" Firefox.

    • by tepples ( 727027 )

      Would you prefer to have to install a separate native executable for each Internet-based application you use, provided it's even available for your operating system? How would something like YouTube work? Would you add the cat videos you want to watch to your cart, fill in your address, and then YouTube would burn them onto a DVD-R for you?

    • It's time to go back to BBS, back when a BBS could be used on kilobytes of RAM and just 300bps modems. Web sites have become so morbidly obese with HTML and images that even my computer with 4 MB of RAM slows down. This Web 1.0 will be used to create even more bloated web sites with ads. Netscape has jumped the shark too, with version 3 being the death of "classic" Mosaic.

      • Those who were around in the days of FidoNet and Compuserve will tell you that they handled communication and even some shopping on minimal hardware and very slow data lines substantially more quickly and efficiently than the current shambles.

        I'm increasingly finding myself in the "This Isn't working -- Let's back off and try again" camp.

  • I'm looking forward to the next hit browser that won't support javascript for just any ol' page and when it does, it uses an interpreter engine for increased security. It may require a new standard which means the W3C may have to fall (since they are backed by people pushing increasingly intrusive tech).

  • by tlambert ( 566799 ) on Saturday June 03, 2017 @02:15PM (#54542961)

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

    • by Anonymous Coward

      It's not a mistake if you want applications that do not only run on chrome.

      • I think the only people who care about this are Mozilla, Inc..

        Are you claiming that this is going to also be implemented in Safari or Microsoft Edge (the only othe browsers that matter)?

    • by roca ( 43122 )

      > Putting a bytecode interpreter into your browser is exactly what malware sites want you to do

      There is already an execution engine in your browser --- JS. WebAssembly applications can do exactly the same set of things that JS can do, so there's no new problem.

      Furthermore, PNaCl was pretty much the same from this point of view, or actually worse because it added quite a lot more attack surface than WebAssembly does (both in Pepper and all the LLVM code).

      • Furthermore, PNaCl was pretty much the same from this point of view, or actually worse because it added quite a lot more attack surface than WebAssembly does (both in Pepper and all the LLVM code).

        Incorrect. The PNaCl (and NaCl) attack surface was intermediated by what a web site was permitted to do through JavaScript.

        It would have been substantially more useful, and dangerous, had that not been the case.

        The question is whether the JIT'ed code in WebAssembly is going to be smarter about sandboxing than Crome itself currently is (I don't see how that can be the case; there are already OnClick based persistent DOM's that are created by malicious sites to pop up advertisements -- and they defeat the sa

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

      I feel like this is a stupid question, so this is probably over my head, but why is a bytecode interpreter worse on this front than an a compiler likewise accepting arbitrary code from the Internet?

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

        I feel like this is a stupid question, so this is probably over my head, but why is a bytecode interpreter worse on this front than an a compiler likewise accepting arbitrary code from the Internet?

        The issue is the ability to create outbound connections /not/ through WebSockets, and the ability to interpose and modify code on its way down.

        The advantage of WebSockets is that it has to connect to a server on the site where the script originated, in order to make an outbound socket connection. This makes it difficult to make a self-propagating attack vector, or a SPAM engine hidden in a game, and utilizing your outbound connection in order to relay SPAM in such a way as to distribute a SPAM engine, or a

    • by Anonymous Coward

      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.

      Man, you really have no clue what you're talking about. WebAssembly is just a more efficient (as in: more compact) serialization of asm.js, which itself is a subset of EcmaScript.
      So everything "bad" you claim you can do with wasm, you can already do with plain EcmaScript, only instead of text, the script source is now binary, so it wastes less bandwidth during page load.

  • Not only does WebAssembly not require packages to be signed, it does not even provide a slot in its standard for signatures. When are software engineers going to learn that you don't do these things after the fact? I am sick of browsers being cesspools for executing random, uncontrolled and unattributable code.
    • by James Carnley ( 789899 ) on Saturday June 03, 2017 @03:59PM (#54543323) Homepage

      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.

      • I consider the lack of signing support in JavaScript to be a flaw. Signing allows one to: 1) know that code you are running has not been tampered with. 2) whitelist certificate chains. 3) associate code with an actual author. Are these not good things? A sandbox is not enough, especially when more and more people's entire digital experience occurs within the browser. You are routinely finger printed by JavaScript running on your browser. Tampered JavaScript can allow people to capture your important
    • by roca ( 43122 )

      As ActiveX showed, code signing is useless in practice unless you require all code to be signed by some trusted third party. But the whole point of the Web is to avoid having a single gatekeeper.

      On the other hand, running untrusted code in a sandbox is a model that has worked for JS, and it will work for WebAssembly too.

      • by elgaard ( 81259 )

        Yes, and Java showed the same thing.

        Just because you might know who signed the applet, that does not mean you should let them take over your user account.

    • Not only does WebAssembly not require packages to be signed

      Every response sent over an HTTPS connection is signed by the TLS endpoint sending it. This includes js files and wasm files.

  • It's funny that I find out that the web runs on Phosphorus-enriched salt just as they get rid of it!
  • The PNaCL version didn't work right for a year, providing me with a number of support headaches. Not excited about doing that again.
  • I didn't even know that Phosphorus would bind with table salt.

System restarting, wait...

Working...