NaCl for ARM? I'd take this with a pinch of salt...
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 …
NaCl for ARM? I'd take this with a pinch of salt...
Sodium Chloride is all I can see, too. intentional, of course.
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?"
And I guess it's much safer to download an application which runs un-sandboxed.
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?
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?
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.
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.
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.
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?
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.
... 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.
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.
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.
You do however loose one important thing, the source code.
"32-bit and 64-bit Intel processors"
Poor AMD, getting completely fogotten. Especially since "x64" was originally their work...
The next sound you hear will be the Intel History Police kicking your door in.
“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.
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!
This sounds good for enterprise Intranet applications.
Active X locked you into IE. This locks you into Chrome.
> 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.
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.)