back to article Google's Native Client browser tech now works on ARM

Native Client (NaCl), the Google technology that allows developers to write client-side web application modules in compiled languages like C and C++, has been updated to work on devices based on the ARM processor architecture. Earlier versions of the technology, which enables running native binary code inside a browser window …


This topic is closed for new posts.
  1. nanchatte
    IT Angle

    Native Client...

    NaCl for ARM? I'd take this with a pinch of salt...

    1. Piro Silver badge

      Re: Native Client...

      Sodium Chloride is all I can see, too. intentional, of course.

  2. This post has been deleted by its author

  3. silent_count

    Is this for real?

    Sandbox or not, I still can't believe they're serious about wanting browsers to download and execute arbitrary code. I'm still waiting for the other shoe to drop, like maybe Google is getting their April Fools Day gag out of the way early this year.

    Either that or this is going to wind up being the poster child for the phrase, "what could possibly go wrong?"

    1. JDX Gold badge

      Re: Is this for real?

      Every web-page you visit executes arbitrary code within a sandbox. It's called JavaScript.

      And I guess it's much safer to download an application which runs un-sandboxed.

    2. Anonymous Coward
      Anonymous Coward

      Re: Is this for real?

      Try reading some of the technical papers on NaCl. There are several layers of security and the attack surface really isn't that large. With a bit of care it could easily be made more secure than a lot of the stuff that every browser is already doing. However, we can't just go on bloating out our browsers with new languages for ever, can we?

    3. Charlie Clark Silver badge

      Re: Is this for real?

      On Android I don't know if the security is really much more of an issue than using the AppStore and I suspect this is sketch of how apps might distributed in the future. Yes, it's sort of ActiveX all over again but then what else is new in the software world?

  4. bazza Silver badge

    Oh no, not another ruddy software ecosystem :(

    NaCl is yet another way in which a system can be opened up to a whole pile of security risks. Google almost certainly haven't ironed out all the bugs and flaws. The OS writers (*nix, Windows, etc) haven't managed to do that yet, and they've been at it for decades. Google are at the other end of the development cycle with NaCl. Look at the hell that Java's going through at the moment: would NaCl fair any better under the fiery gaze of the world's security researchers? Probably not.

    Want to run native code in a truly platform independent way? This ain't it yet. And their plan to move to LLVM is hardly upholding the meaning of 'native' in 'Native Client'. It will be more like 'Native-ish Client', which after all is all that JavaScript, Java, .NET and Dalvik give you.

    The only way in which native code can be truly platform independent is if there were only one software ecosystem, a lot of recompilation and a globally supported monopoly, but that's unlikely to happen any time soon. Something like an open source OS that everyone really believed in (so not Linux then, even though it is an impressive piece of work) would do the job, but that's rather at odds with profit motives and shareholder value.

    I'll give Google a tiny bit of credit for trying, but then at the same time they're very keen on Java/Dalvik for Android, they're very proud of how fast their JavaScript engine is, and so forth. It hardly amounts to a single focused development message.

    1. Jon Press

      Re: focused development

      Quite. And Java is a lot easier to sandbox than C++, never mind C. And we know just how secure that turned out to be..

      This isn't even innovation - it's a reinvention of Active X. And we know just how secure that turned out to be.

      Apple gets a lot of stick for investing too little in reasearch - perhaps Google should catch some heat for investing rather too much.

    2. Eddie Edwards

      Re: Oh no, not another ruddy software ecosystem :(

      The produced code can be as good as the LLVM C compiler will produce on your own computer. It's as native as it gets. Using LLVM is just moving the backend of compilation to the client. Since the high level of a compiler is fairly platform-independent and the low level is not, this split makes perfect sense. It is not the same at all as the strategies employed by JavaScript VMs, Java VMs, the .NET runtime, etc. Although it is fair to say those VMs are approaching the performance of native code from the other direction, they're still coming from the other direction.

      I'd like to see more details on how NaCl is supposedly secure, though.

  5. jxp
    Thumb Down


    So let's take an open standard that's supported by every connected device regardless of CPU and hobble it with hardware compatibility restrictions. Way to go Google.

    Can anyone explain how this is in any way different to IE6/ActiveX lock-in that many devs are still struggling to get rid of?

    1. JDX Gold badge

      Re: Terrible

      It's more cross-platform. If you write a normal browser plugin it effectively is just regular .dll/.exe (or other OS equivalent) which is loaded by the browser. So you have to compile separately one version for Windows, one for OSX, one (at least) for Linux, etc.

  6. fch

    new year's greetings from the ActiveX zombie ?

    ... and there was me thinking HTML5 succeeded killing it finally, once and for all.

    Foiled again ! The spectre never dies ...

    Time to buy Microsoft stock. They must've plastered that path with patents thrice over.

  7. Christian Berger

    Where is the advantage?

    Javascript systems are getting increasingly fast, even to a point where you can have decent emulators. However Javascript provides you with a high level programming language.

    The big problem I see. Even if all the security problems are fixed we'll see a huge bunch of new C and C++ programmers who have no idea about what they are doing.

    I fear that, just like in the 1990s, they will flood us with lots of crappy binary only code. Computer crashes, a thing people from the 1990s took as something normal, might become commonplace again, but now for websites.

    1. psyq

      Re: Where is the advantage?

      Err, why would a sandboxed userspace code cause "computer to crash" any more than anything else that runs in the userland? I see absolutely no point in that statement. If a computer crashes today, this is almost universally due to bad kernel-level 3rd party code such as drivers. NaCL has nothing to do with this any more than Javascript - both languages would execute in the userspace and, at the end, use OS supplied userspace APIs.

      And how is Javascript any higher-level than, say, C++ ?

      Sorry, the fact that the language is more open to script kiddies does not make it any more "high level", nor it does make buggy code any less likely to occur. Crappy code is crappy code, it is caused by the developer and not by the language.

      The advantage of the NaCL would be performance - if someone needs it say, for multimedia, gaming, etc... It does not mean that everybody needs to use it but it would be good to have it as an option. The fact that computers are getting faster does not render it any less relevant as modern multimedia/gaming is always pushing the limits of the hardware.

      1. Christian Berger

        Re: Where is the advantage?

        Of course in this case the "web application" would crash, again, assuming that the sandbox works. That's already bad enough.

        Javascript is higher-level than C++ in many points. For example in Javascript you have no way to intentionally or unintentionally access your return stack, something that's commonly done in C++ and C. Then look at memory management. On C/C++ it's easy to have a memory leak somewhere. There is no (standard) way of finding out which memory to free in order to do garbage collection. (Of course you can implement it yourself or use some library which may or may not work transparently)

        Performance is only a pretext. If you have the sourcecode in, let's say Javascript, you can just as well compile it to native code, just like you do with that semi-portable bytecode.

        You do however loose one important thing, the source code.

  8. Ian Yates

    "32-bit and 64-bit Intel processors"

    Poor AMD, getting completely fogotten. Especially since "x64" was originally their work...

    1. TeeCee Gold badge
      Black Helicopters

      The next sound you hear will be the Intel History Police kicking your door in.

  9. Stephen Channell

    Looks like an epic fail

    “already need to build separate modules for 32-bit and 64-bit Intel processors” is not true: NaCl is 32-bit only for a very specific reason.. it uses Intel segment registers to provide the sandbox (Newlib functions are the only ones allowed to change segment register values to access memory outside the sandbox). When the AMD/Intel CPU is in AMD64 mode, those segment registers are aliased to provide additional general purpose registers.

    Leaving aside the dependence on a deprecated feature of a legacy mode, NaCl was quite a neat solution to a complex problem, but the move to AMD64 (or ARM5/6/7 or PowerPC or Mips or …you get the idea) required a smarter approach. Portable NaCl (featuring LLVM) was billed as the future solution because an enhanced LLVM backend could add in the a software equivalent to the NaCl hardware sandbox.. but there was a problem: PnaCl bitcode was slower than V8 Javascript code for common tasks!

    So NaCl for ARM looks like an admission that Google just couldn’t get Portable NaCl to be fast enough to bother with! So NaCl developers face the prospect of providing different binaries for every different processor from every different manufacture (NB Snapdragon ARM may not be the same as Tegra ARM).. but that OK ‘cus even Google knows they are the only ones ever to use it, because they’re the only ones with an interest in Chromebook.. epic fail!

  10. idiot stick


    This sounds good for enterprise Intranet applications.

    Active X locked you into IE. This locks you into Chrome.

    1. P. Lee

      Re: Enterprise

      > Active X locked you into IE. This locks you into Chrome.

      ActiveX locked you to IE and Windows, neither of which you could port.

      Chrome is already OS-ported and anyone is welcome to add LLVM to their own browser.

      Hardly "locked."

  11. h3

    It sucks they won't let you use this or the appstore on Android. (Only place I use chrome).

    (I figure they know everything due to the simple fact of me using Android so using chrome is not noticeably worse.)

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2022