Google Native Client (NaCl) Alternative To ActiveX, Flash and Java

Matasano Security in an article “The Security Implications Of Google Native Client” takes a close look at Google Native Client (NaCl) , a technology that was launched in Dec 2008 and is meant to enable running of native code on the web.  The article goes into the details of the various approaches currently available like ActiveX, Flash and Java and compare them with the Google Native Client. It says –

Google NaCl is, on its face, a crazy-talk idea. It’s a browser plugin that downloads native x86 code from a website and runs it on your machine. If this sounds familiar, it’s because Microsoft tried it over a decade ago with ActiveX. If you’re skeptical about the idea, it’s because ActiveX was a security calamity; O.K. an ActiveX control, and it owns your machine almost completely…

Repurposing an idea from the mid-’90s, NaCl employs a very simple trick to make native X86 programs reliably verifiable. And if you can verify an X86 program, you don’t need a layer between the program and the OS: you can just have rules, and refuse programs that break the rules…

There is a very important difference between what NaCl is doing and what Java is doing. Java’s security measures are chaperones. They’re always there and always checking your actions. NaCl’s mechanisms are just rules. They’re checked once, and then the program is on its own. NaCl promises to be faster than Java. More importantly, to build a NaCl program for your customers browsers, you don’t have to port to Java; you just have to use the NaCl build environment (a patched GCC that targets a simple ELF module) on your existing C code. Google, for instance, ported Quake…

While the Google Native Client hasn’t drawn much attention as yet, it looks bound to soon become mainstream and popular as it moves from beta to a final release.