Forgot your password?
typodupeerror
Chrome Chromium Google

Google Chrome 31 Is Out: Web Payments, Portable Native Client 123

Posted by Soulskill
from the onward-and-upward dept.
An anonymous reader writes "Google today released Chrome version 31 for Windows, Mac, and Linux. The new version includes support for Web payments, Portable Native Client, and 25 security fixes. 'Under the hood, PNaCl works by compiling native C and C++ code to an intermediate representation, rather than architecture-specific representations as in Native Client. The LLVM-style bytecode is wrapped into a portable executable, which can be hosted on a web server like any other website asset. When the site is accessed, Chrome fetches and translates the portable executable into an architecture-specific machine code optimized directly for the underlying device. This translation approach means developers don’t need to recompile their applications multiple times to run across x86, ARM or MIPS devices.' You can update to the latest release now using the browser's built-in silent updater, or download it directly from google.com/chrome."
This discussion has been archived. No new comments can be posted.

Google Chrome 31 Is Out: Web Payments, Portable Native Client

Comments Filter:
  • by Anonymous Coward

    Java for the 21st century. And you thought applets were dead...
     

    • There's no virtual machine executing the code here, just some vmish technologies compiling it.

      So it's more like ActiveX!

    • Very annoying that chrome wont support 64 bit java. If you make 64 bit java the default on your computer, because say you want to run minecraft's latest server, then you can't run java in chrome cause it won't work and it uses the default path installed java.

      • This and the ctrl+f window disappearing upon navigation are why I still use firefox. Otherwise chrome is nice due to how fast it renders pages like the guides on lolking.net compared to firefox.

      • Or, on some platforms where 32-bit Java is no longer an option (Mac OS X), Chrome is useless for any site implementing Java.

        You get a nice message saying that you need to download something that doesn't exist.

  • Security? (Score:2, Interesting)

    by hendrikboom (1001110)

    How they maintain security with C and C++ applets?

    -- hendrik

    • Re: (Score:2, Funny)

      by Anonymous Coward

      With security fixes of course: "Tuesday December 24, 2013 ... Google Chrome 214 is Out: this update includes 14 security fixes in the Portable Native Client which should plug all the security holes. Yes we know we said the same thing in the last 5 updates yesterday, the day before, and last week, but this time we've fixed all the, ahem, known security flaws. Promise."

    • Re:Security? (Score:5, Informative)

      by cheater512 (783349) <nick@nickstallman.net> on Tuesday November 12, 2013 @10:33PM (#45408433) Homepage

      Same way they do as JS. They control what APIs it can call.

      C code without any APIs can't exploit a potato. It isn't inherently able to talk to the kernel.

      • Re: (Score:3, Insightful)

        by Jah-Wren Ryel (80510)

        Same way they do as JS.

        That's not particularly reassuring.

        • Same way they do as JS.

          That's not particularly reassuring.

          Well, since the bytecode they are presumably using is much simpler than the mess javascript is, it should actually be easier to make it secure.

      • by Twigmon (1095941)

        To be fair, it is very difficult to exploit a potato.

      • by Anonymous Coward

        Wrong.
        ((void(*)(void))"\012\123\234\345...")();

      • by jrumney (197329)

        C code without any APIs can't exploit a potato.

        Is that a challenge?

      • by dewrox (1646725)

        C code without any APIs can't exploit a potato. It isn't inherently able to talk to the kernel.

        How does not being able to make french fries relate to not being able to make popcorn? And how does this make the code safer? (Even if you thought it was cheesy it is still funny.)

    • by Anonymous Coward

      Security? Hell, this seems it was designed by the NSA.

    • It is native code but still running in a sandbox.
      https://developers.google.com/native-client/dev/overview#security [google.com]
      The only interaction between this process and the outside world is through sanctioned browser interfaces.
    • Re:Security? (Score:5, Informative)

      by CTachyon (412849) <chronos&chronos-tachyon,net> on Tuesday November 12, 2013 @11:33PM (#45408909) Homepage

      How they maintain security with C and C++ applets?

      -- hendrik

      NaCl (in its standard, non-Portable flavor) is essentially a bytecode that happens to be directly executable as machine code (either x86-64 or ARM). The bytecode can be statically verified to mathematically prove that the instructions obey certain rules (e.g. exactly one interpretation for any bytecode, execution only leaves the verified bytecode by calling trusted functions, can only read/write memory in the sandbox, cannot write to bytecode, etc.). As I understand it, PNaCl is similar to classic x86/ARM NaCl but trades fake bytecode for real bytecode (LLVM's intermediate representation, last I heard) and statically compiles it to native machine code after the bytecode verification step. Basically, in this scheme the verified C code can run at near-native speed, but it can only communicate with the world outside the sandbox by calling trusted functions that the enclosing app chooses to expose.

      Theoretically, Java ought to be just as strongly sandboxed as NaCl: Java code in a JVM sandbox can only call trusted functions that the JVM chooses to expose, too. But in practice the Java standard library exposes a ridiculously broad attack surface, giving sandboxed apps plenty of chances to exploit bugs and escape the sandbox. (For instance, java.lang.String is a final class today because folks discovered that you could subclass it to make it mutable, pass a sandbox-approved value to e.g. a file I/O function, then modify the value to a sandbox-forbidden value after the security check but before the OS system call.) Basically, Java's attack surface is broad and leaky because Java was designed for running embedded devices and servers, not for sandboxed applets downloaded from hostile sites on the Internet. Applets were a distant afterthought compared to Java's "let's write an OS for set-top cable boxes" origin.

      In contrast with Java, Chrome's implementation of [P]NaCl only exposes the Pepper API, and the Pepper API was designed from the ground up to be called by sandboxed code fetched from a malicious website. Looking at the Pepper C API site [google.com], the attack surface seems... bigger... than I would have expected. But most of the functionality I see there is also exposed to JavaScript, where the code is every bit as hostile. Almost any "attack surface, WTF" argument would also argue against JavaScript and all modern web design. And if they're smart, one API is hopefully built on top of the other (plus a thunk layer made of machine-generated code), so that there's only one pool of security bugs to fix.

      • Basically you are saying this:

        NaCl tries to do the same as java, but with marginally less attack surface and a static compile. The marginally less attack surface is considered "safe" because JavaScript has the same surface and we all trust that.

        This seems to me as Google's attempt to kill java. NodeJS is already gaining popularity on the server side and once the version of V7 that is in NodeJS will be able to do NaCL, it will be able to replace it both on the server and the client side. Even though I agre

        • by Anonymous Coward

          Google doesn't use nor do they care about NodeJS, and nobody with a brain uses Java applets for anything. These actions have little to do with Java or NodeJS and everything to do with providing a lightweight language agnostic platform for rich web applications that can compete with native apps (especially those on iOS). Read the leaked internal Dart/Dash memo for more insight into what they're after.

      • ... the attack surface seems... bigger... than I would have expected. But most of the functionality I see there is also exposed to JavaScript, where the code is every bit as hostile. Almost any "attack surface, WTF" argument would also argue against JavaScript and all modern web design.

        yeah, and look at the marvels that "modern web design" has brought us: static websites that have a shitload of stuff running in the background doing God-knows-what.

        using HTML/CSS only is enough for any read-only web page. using hover and the checkbox hack, [dabblet.com] you can make all the user interaction you need. the only thing i would add is dynamic content requests and for interactive editing, hooking content to textboxes with regex or some other translating syntax. the most devious thing you could do is infinite

      • Indeed, it looks quite safe compared to JS.

        The only disadvantage of NaCl code is that it only runs on one brand of browser. Sigh.

      • NaCl (in its standard, non-Portable flavor)

        You mean before it's ground up and put into little shakers?

  • The browser is not the place to run "native" applications.
    I understand the desire by websites not to force a shift in focus,
    but for the sake of security, we shouldn't be allowing the browser such low level access.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      It's a fallacy to think that 'native' equates to insecure.

    • by reub2000 (705806)

      Good news everyone! Chrome isn't just a browser. It's an OS.

      • by SB9876 (723368)

        Browsers have been slowly becoming self-contained OSs for a decade now.

        • Dumb terminals evolved into "smart" PCs as networking evolved from mainframe computing to powerfull clients.

          The the Web shifted things back to server side computing with the browsers as dumb terminals. Now those formerly dumb terminals become smarter and do more of the workload client-sided. I can see a pattern here.

          The next step that already started in paraless is moving the servers to become clients on a SaaS platform as GoogleAppEngine or Amazon AWS.

          • by mcgrew (92797) *

            Dumb terminals evolved into "smart" PCs as networking evolved from mainframe computing to powerfull clients.

            No they didn't, that's utter bullshit, young man. PCs started out as hobbyist affairs, with the Altair, which was an IC version of the early tube computers. Like mainframes, they were improved on and by the late 1970s there were stand-alone "microcomputers" like Osbourne and Apple and Commodore. VisiCalc brought these hobbyist machines into the office. IBM brought out its toy (their term), the IBM-PC.

        • Which is a symptom of OSes not doing their work properly. Of course, the demand for network-distributed, compound documents with extensible and replaceable components has been here ever since the 1970s. Since the OSes currently in use don't implement any of it, many people have logically resorted to trying to do that in the closest thing they new: the web. I wouldn't blame them, it's not their fault.
  • What? (Score:4, Informative)

    by brunes69 (86786) <slashdot AT keirstead DOT org> on Tuesday November 12, 2013 @10:23PM (#45408363) Homepage

    "Chrome fetches and translates the portable executable into an architecture-specific machine code optimized directly for the underlying device. This translation approach means developers donâ(TM)t need to recompile their applications multiple times to run across x86, ARM or MIPS devices.'

    Ummmm... sounds like Java?

    • Ugh, exactly—except Java runs in more browsers. I honestly don't know who NaCl is for, or what problem it's trying to solve that can't be addressed with asm.js.
      • by DrXym (126579)

        I honestly don't know who NaCl is for, or what problem it's trying to solve that can't be addressed with asm.js

        NaCl stands for native client. i.e. you download software compiled for x86 or ARM instructions and run it in your browser at native speeds. It is sandboxed and limited to what it can do within its sandbox. But having to recompile the same code for each architecture is obviously a pain, so PNaCl allows devs to compile once to LLVM and run anywhere.

        Asm.js is an important thing to pursue but it fundamentally a hack. Tools like Emscripten compiled code to LLVM (like PNaCl), and then emit equivalent JS. Then

    • by Anonymous Coward

      More like CLR.

      Java is a stack virtual machine, this has horrible implications for translation performance. PNaCl (LLVM) and CLR (.net) use named storage bytecode (in the case of LLVM, single static assignment), which trivialises register allocation and doesn't impose the burden that JVM does of having to unwind stack operands to attempt to assign them to registers, which is slow and often results in inefficient translated code, and makes instruction reordering to suit different architectures pipelines diffi

      • by brunes69 (86786)

        Nothing you just posted said anything at all about why or if NaCL running on LLVM should be considered more secure than Java running on a JVM. The reason so many people have been against Java in the browser has a lot more to do with constant security issues than performance. This NaCL system seems like it would be a ripe target for exploits.

      • by jfengel (409917)

        Except that the JVM isn't really a stack machine. It looks like one, but the verification requirements in the JVM mean that each stack operation can be analyzed statically and replaced with a register operation. That's why Android is able to translate most JVM class files (at least those generated from Java sources) into its Dalvik VM.

        JVM JIT compilers do the same analysis, so there's practically never a need for an actual instruction stack. It's all register-colored and optimized before it's translated int

  • by Anonymous Coward

    That approach sounds familiar. What's to stop this being Just Another Vulnerability Apparatus?

  • by OhSoLaMeow (2536022) on Tuesday November 12, 2013 @10:29PM (#45408401)
    Why would chrome even need phosphoric sodium chloride? Seems like Ferro-Cesium Sulfate is more appropriate.
  • by sinij (911942) on Tuesday November 12, 2013 @10:42PM (#45408509) Journal

    Sadly browser wars turned into the race to rebuild AOL. Why so much bloat? Browser should do one, and only one thing well - render web pages. Native client? Web Payments? Why not throw in TurboTax, because more the merrier, right?

    • I think this is more strategic. They want to replace the traditional app model with web sites or at least web-based SaaS applications.

      The existing web technologies (html, js, css, etc) are awful for non trivial apps, so this nacl stuff lets you build real apps within the web SaaS model.

    • Well, in case you didn't get the memo, the definition of World Wide Web has changed dramatically since the 1990s.

      World Wide Web is no longer about seeing pages to present you with information. It's about running applications to give you functionality. This effectively turned the web browser into a not-so-thin application client.

      I believe this whole thing happened because Microsoft had control of what gets installed on desktop for a long while, and the only application-client technology installed on al
  • Instead of using the native OSX notifications, they added their own spammer to the menu bar... complete fail.
  • I like the idea of running native code in the browser, but I will be really excited when (if?) this becomes a standard. Ever since the now-defunct NPAPI stopped being the cross-browser solution of choice, we've been in dire need of something that is both native (i.e., not Javascript) and standard (i.e., not Chrome NaCl). Interesting nonetheless!
  • ... suddenly, all my extensions weren't running under incognito mode without disabling and enabling them again every time I went into incognito mode.

    Back to FF I go.

  • The worst thing about Flash weren't its security implications. The problem was that Flash put islands of non-HTML in the middle of HTML pages, complicating their description, their development, their deployment, and therefore complicating the software implementations required to render them; also, increasing the time required to train people into writing web pages, and introducing the conflicts between two standards that are planned and evolve independently, yet have to intercommunicate. Often only to obtai
  • Chrome now operates as an unregistered vehicle transporting executable code handing off to server farms who knows what...surely not - YOU

It is impossible to enjoy idling thoroughly unless one has plenty of work to do. -- Jerome Klapka Jerome

Working...