Throughout the brief history of the web, we’ve seen various attempts to make the browsing experience more interactive:  Java applets, JavaScript (and AJAX techniques), ActiveX, Flash, and Silverlight to name a few.  All of the above except for ActiveX achieve a certain level of security from malicious code through the use of runtime-interpreted languages.  The interpreter layer helps to assure security by not providing access to certain types of operations.

An ActiveX control, on the other hand, is native executable code — so it can do anything you can write an executable to do.  That includes access to the local file system and other resources to which the current user has permissions.  Thus, if you install an ActiveX control from an untrusted source, who knows what you’re getting yourself into?  Soon after the release of ActiveX, one developer famously put up a page on the web (I can’t find it now) that would reboot your system without asking — just to demonstrate the security vulnerabilities inherent in the design.  Not long after that, Microsoft added a security feature to Internet Explorer to ask you before loading any ActiveX controls.

The vulnerabilities associated with ActiveX put most web aficionados off the idea of embedding native code in the browser, even though it naturally performs much better than an interpreted language (although recent improvements in JavaScript performance mitigate that somewhat).  But now Google is reopening the possibility of running native code in the browser, in order to provide a richer Internet experience.  Unlike ActiveX, this technology (appropriately named Native Client) is designed to run in many different browsers (Firefox, Safari, Opera, and Chrome — note no IE), and across various client platforms (Linux, OS/X, and Windows are already supported on x86).

Handling the security issues

Chad Perrin of TechRepublic recently posted his concerns about the security of Native Client.  Apparently, when Native Client loads an executable, it decompiles it to insure that the code follows certain “structural criteria” and doesn’t perform any prohibited action, like creating files on the local file system or accessing the network.  Google admits that this security model presents some challenges.  It seems to me it would be next to impossible to prevent all forms of attack — but hey, Google employs some pretty smart people.  I just hope they aren’t misguided on this.

Google’s Native Client team wants your help in testing to see if you can break their security mechanisms.

Taking it for a spin

To try it out, you must first have Python 2.4 or 2.5 installed on your system (it’s not directly used by Native Client, but it is used for the build and test environments).  Download the software, and follow the build instructions.

Just like ActiveX controls, a Native Client executable can be run within a stand-alone application, or within a web page (if you install the Native Client plugin for your browser).  The tests provided in the download offer both options.  Here’s one of my favorite programs (Conway’s Life simulation) running as a stand-alone app on Windows XP:

And here it is inside Firefox:

The same executable (life.nexe on Windows) is used in both cases — it just uses a different loader in each (a stand-alone executable or a browser plugin).  This example runs very quickly.  You can use the mouse to add cells wherever you click.  I could watch this all day.

The API Reference for Native Client can be found here.  I haven’t read through all of it yet.  The API is written in C++.  I like the fact that it’s cross-platform, but I presume that the executables have to be compiled for each operating system.  Judging from the Python code in the stand-alone loader, I’m guessing that the browser plugin’s loader will automatically look for the platform-correct executable on the host system (UPDATE: Sven corrected my assumption – the .nexe’s generated from the compilation are platform-independent).  But I haven’t tried creating any Native Client modules of my own yet.

This technology is designed to handle processing loads that are deemed too onerous for pure JavaScript, or a combination of JavaScript and server-side processing.  One example would be image editing, which would be quite difficult to do in pure JavaScript (even if you can rely on the Canvas object).  But sending commands to the server to modify the image and ship it back to the client gets expensive in a hurry.  The ideal model would be to perform all the image manipulation in the client and then send the final result back to the server (if needed).

What do you think?  Will Native Client finally give us the processing power we’ve always wanted in the web client?  Or will it open too many security vulnerabilities? Will NaCl be worth its salt?