Google Native Client: web deluxe, or ActiveX redux?

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?

Advertisements
Advertisement




39 Responses to Google Native Client: web deluxe, or ActiveX redux?

    • For security purposes, yes. But I don't think the point of Native Client is to be able to write in C++ — the whole idea is to get beyond virtual machines and run native code for performance on intensive computations.

      • The 'point' is to give greater flexibility than JavaScript alone, while still being cross-platform, it has nothing to do with performance. I'd much rather write in Python or Ruby, and I'm sure many others would as well.

        • That may be your point, but I don't think that's why Google is exploring Native Client. They're in it for the performance. They don't have a problem using JavaScript otherwise.

        • JavaScript isn't *THAT* fast, but it's not horrendously slow if used properly, the big issue is you can't do a lot with it. Sure, you can manipulate the DOM, and you can send stuff to a server without a page refresh, but there's a huge list of things you can't do (at least easily) with it.

          This is still more to native code than performance.

    • For security purposes, yes. But I don’t think the point of Native Client is to be able to write in C++ — the whole idea is to get beyond virtual machines and run native code for performance on intensive computations.

      • The ‘point’ is to give greater flexibility than JavaScript alone, while still being cross-platform, it has nothing to do with performance. I’d much rather write in Python or Ruby, and I’m sure many others would as well.

        • That may be your point, but I don’t think that’s why Google is exploring Native Client. They’re in it for the performance. They don’t have a problem using JavaScript otherwise.

        • JavaScript isn’t *THAT* fast, but it’s not horrendously slow if used properly, the big issue is you can’t do a lot with it. Sure, you can manipulate the DOM, and you can send stuff to a server without a page refresh, but there’s a huge list of things you can’t do (at least easily) with it.

          This is still more to native code than performance.

  1. I don’t think ActiveX failed because native code is inherently insecure. Insecurity came from other causes, like the installation process or single platform support. Java applets have been able to use machine resources for a decade. In this case the problem was the brain-dead procedure to sign an applet and install it later.

    I think that the success here would come from something that works simply and seamlessly on any browser/platform. Yes, like Flash, that more or less does that.

    Anything that only works in Chrome won’t fly. But a jitted language that can be plugged into any browser and work on any platform would be an instant success.

  2. I don't think ActiveX failed because native code is inherently insecure. Insecurity came from other causes, like the installation process or single platform support. Java applets have been able to use machine resources for a decade. In this case the problem was the brain-dead procedure to sign an applet and install it later.

    I think that the success here would come from something that works simply and seamlessly on any browser/platform. Yes, like Flash, that more or less does that.

    Anything that only works in Chrome won't fly. But a jitted language that can be plugged into any browser and work on any platform would be an instant success.

  3. Locking in yet another generation of x86 code. Why the hell don’t they transport some intermediate representation to the browser, or even the source code itself. At least then, you would have a chance of it being able to work cross platform, e.g. on browsers in handsets. The plugin would then be a fast, lightweight compiler.

  4. Locking in yet another generation of x86 code. Why the hell don't they transport some intermediate representation to the browser, or even the source code itself. At least then, you would have a chance of it being able to work cross platform, e.g. on browsers in handsets. The plugin would then be a fast, lightweight compiler.

  5. I like the fact that it’s cross-platform, but I presume that the executables have to be compiled for each operating system.

    You presume wrong. One .nexe works on all platforms. Please read the paper.

  6. I like the fact that it’s cross-platform, but I presume that the executables have to be compiled for each operating system.

    You presume wrong. One .nexe works on all platforms. Please read the paper.

  7. I like the fact that it’s cross-platform, but I presume that the executables have to be compiled for each operating system.

    You presume wrong. One .nexe works on all platforms. Please read the paper.

  8. In case anyone is unclear about this, this is, as Chip said, about speed. Its about speed. Javascript can't hold a candle to the amount of performance NaCl can get from native execution. Could you imagine Javascript running a quake client? It starts choking on even simple programs.

    As far as not using an intermediate language or representation, like java or bytecode, the reason is again speed. Using the x86 architecture locks them into x86 assembly, but the reality is that most computers out there nowadays are Intel. While Java and bytecode may be truly "portable" the fact is that its just not that fast. I'm sure people can give a laundry list of benchmarks stating that Java is comparable, but real world usage clearly says otherwise. I have no doubt that Java can be compiled to run to something native comiparable, but right now, at this moment in time, its not as fast, not as rich and looks to be fading. x86 is here for the forseable future.

    A few more points: 1) you can always run x86 under emulation on other chips. This is a lot easier than running bytecode. So, while x86 might not be the most elegant of assemblies, there still is the possibility of forward compatibility. 2) NaCl (as far as I can tell) decompiles in a consistent way, checks to make sure it doesn't jump execution to outside of valid block and doesn't allow execution if it does. You make sure the execution isn't going where you don't want it to, you have a guarantee that the code is safe. This excludes some programs and type of programming styles but still allows for more than enough freedom to create quality software. They also put sandbox's in sandbox's, so that even if one layer manages to break out, there are some more safeguards, but I'm not sure how that exactly works.

    Sorry for the long post, but it really burns me to have people dismiss this (imo quality) idea by just waving their hands and saying "java did it". Java doesn't do it. Javascript doesn't do it. Lisp doesn't do it. There is nothing out there today, right now, that allows me to write an application that comes close to getting the performance I can get from native compilation…and of course thats also open source (thats an important point as well).

    • Bzzzt. Java is as fast as native code. Bytecode is compiled into native x86 code. The only problem with Java is startup time. When running a Java applet, the JVM has to:

      1) Download the remote jar file

      2) Uncompress the .jar file into memory

      3) Verify the bytecode to make sure it's not evil/corrupt

      4) Launch the app

      4.5) Compile the bytecode into native x86 instructions (or native SPARC instructions or whatever is native)

      5) Run at native speed (including processor specific features that ahead-of-time compilation can't anticipate)

      So Java is as fast as native code providing similar features (such as array bounds checking, garbage collection, etc). So the real argument for the native client plugin would be to improve startup speed compared to Java.

      Java is as fast as C++. Stop spreading the FUD.

  9. In case anyone is unclear about this, this is, as Chip said, about speed. Its about speed. Javascript can't hold a candle to the amount of performance NaCl can get from native execution. Could you imagine Javascript running a quake client? It starts choking on even simple programs.

    As far as not using an intermediate language or representation, like java or bytecode, the reason is again speed. Using the x86 architecture locks them into x86 assembly, but the reality is that most computers out there nowadays are Intel. While Java and bytecode may be truly "portable" the fact is that its just not that fast. I'm sure people can give a laundry list of benchmarks stating that Java is comparable, but real world usage clearly says otherwise. I have no doubt that Java can be compiled to run to something native comiparable, but right now, at this moment in time, its not as fast, not as rich and looks to be fading. x86 is here for the forseable future.

    A few more points: 1) you can always run x86 under emulation on other chips. This is a lot easier than running bytecode. So, while x86 might not be the most elegant of assemblies, there still is the possibility of forward compatibility. 2) NaCl (as far as I can tell) decompiles in a consistent way, checks to make sure it doesn't jump execution to outside of valid block and doesn't allow execution if it does. You make sure the execution isn't going where you don't want it to, you have a guarantee that the code is safe. This excludes some programs and type of programming styles but still allows for more than enough freedom to create quality software. They also put sandbox's in sandbox's, so that even if one layer manages to break out, there are some more safeguards, but I'm not sure how that exactly works.

    Sorry for the long post, but it really burns me to have people dismiss this (imo quality) idea by just waving their hands and saying "java did it". Java doesn't do it. Javascript doesn't do it. Lisp doesn't do it. There is nothing out there today, right now, that allows me to write an application that comes close to getting the performance I can get from native compilation…and of course thats also open source (thats an important point as well).

    • Bzzzt. Java is as fast as native code. Bytecode is compiled into native x86 code. The only problem with Java is startup time. When running a Java applet, the JVM has to:

      1) Download the remote jar file
      2) Uncompress the .jar file into memory
      3) Verify the bytecode to make sure it’s not evil/corrupt
      4) Launch the app
      4.5) Compile the bytecode into native x86 instructions (or native SPARC instructions or whatever is native)
      5) Run at native speed (including processor specific features that ahead-of-time compilation can’t anticipate)

      So Java is as fast as native code providing similar features (such as array bounds checking, garbage collection, etc). So the real argument for the native client plugin would be to improve startup speed compared to Java.

      Java is as fast as C++. Stop spreading the FUD.

  10. Wooooohhhoooooo!!!

    Good times to come for us Phishing-, Virus- and Trojan-horse-writers.

    Merci beauuuuuuucoup Google!!!!

  11. Wooooohhhoooooo!!!

    Good times to come for us Phishing-, Virus- and Trojan-horse-writers.

    Merci beauuuuuuucoup Google!!!!

  12. Does this all seem to be reverting back to client/server? The only real difference seems to be that the code is downloaded from the server on demand now, instead of being installed via CD… What’s old is new again!

    • Indeed, Shaune, there are parallels. Pretty soon after the web model was introduced, it became apparent that the web’s thin client model presented some real challenges for running any application that’s highly interactive. People have been trying to solve that problem in many ways, and this is one more.

  13. Does this all seem to be reverting back to client/server? The only real difference seems to be that the code is downloaded from the server on demand now, instead of being installed via CD… What's old is new again!

    • Indeed, Shaune, there are parallels. Pretty soon after the web model was introduced, it became apparent that the web's thin client model presented some real challenges for running any application that's highly interactive. People have been trying to solve that problem in many ways, and this is one more.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.