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 post has been deleted by its author
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?"
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?
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.
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.
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.
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?
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.
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.
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.
“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!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
