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.
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.
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?