Google Native Client - A Detailed Discussion

By Angsuman Chakraborty, Gaea News Network
Saturday, January 3, 2009

Native Client is an open-source research technology for running x86 native code in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps.

Google Native Client is the recent project by Google to give you a technology that will help you improve upon your web application experience many folds. In the earlier stage Google had devised a version of Native Client for Ubuntu - the flavor of Linux that Google runs. Now with time, versions of Native Client for Windows XP and Mac OS X have been developed and tested. Native Client works with Firefox, Safari, Opera, and Google Chrome, with plans to support ARM and PowerPC.

What is the Intention?

The main point is Google has long been disappointed with the way how web browsers play the middle role between running a web application and CPU utilization. Today’s web applications can access only a small fraction of this computational power. If web developers could use all of this power, the richness and dynamism would have increased by many folds. That is what Google Native Client intends to do. Let me give you an example from Google only which is obviously very relevant.

Imagine that you run a photo-sharing website and want to let your users touch up their photos without leaving your site. Today, you could provide this feature using a combination of JavaScript and server side processing. This approach, however, would cause huge amounts of image data to be transferred between browser and the server, leading to an experience that would probably be painfully slow for users who just want to make a few simple changes. With the ability to seamlessly run native code on the user’s machine, you could instead perform the actual image processing on the desktop CPU, resulting in a much more responsive application by minimizing data transfer and latency.

How is it Browser Neutral?

Well the above example actually is enough to talk about browser neutrality. Actually what Google wants to do is to allow application and content creators to build their applications without needing to tweak for different browsers’ idiosyncrasies or different levels of support for web standards. It will be a free and open standard which will be compatible for all the browsers. Is it possible? Well it is if the both ends stretch their hands.

How Safe is it?

One of the serious problems in allowing web-based applications to execute code at the OS level is that it opens massive security vulnerabilities. One can never forget how ActiveX came and exploited many a Windows operating systems with large security loopholes. So does Google Native Client do anything about it? The answer is yes. Google has been really serious about the safety of this project.

The NaCL modules are divided into two core sandboxes with one sandbox into another concept. They have a system of two sandboxes - called the inner and outer sandboxes - to prevent untrusted modules from the web running amok on your machine. The Google Native Client developers have targeted a multi-level of exploits checking. Namely,

• inner sandbox: binary validation
• outer sandbox: OS system-call interception
• service runtime binary module loader
• service runtime trampoline interfaces
• IMC communications interface
• NPAPI interface

Where Does it Stand in front of Competitors


Well activeX is still there I know, but it should be a thing of the past for sure. Where Google beats ActiveX is the level of security it imposes on NaCl. The research paper clearly says that,

[ActiveX's] dependency on the user making prudent trust decisions is commonly exploited. ActiveX provides no guarantee that a trusted control is safe, and even when the control itself is not inherently malicious, defects in the control can be exploited, often permitting execution of arbitrary code. In contrast, NaCl is designed to prevent such exploitation, even for flawed NaCl modules.

Google believes that its security model has the potential to be far more robust and effective than the code-signing system of trust used by ActiveX.

Flash and Adobe AIR

Let’s be realistic. Flash is on 95% web applications already. Why would every one hang on to NaCl all on a sudden? Flash, Silverlight and JavaFX are working hard to bring OpenGL acceleration and near-desktop math processing support. Though Adobe AIR is still not free and Google NaCl wants to cash in on that, I don’t think that Google Native Client is gonna make inroads in a short period of time.


With Native Client Google actually dreams of the next step. With all the sophisticated dual-core and quad core machines and proposed GBPS internet connections, internet will be THE destination for anyone who uses a computer. The browsers will be working as mini operating systems having multiple plug-ins and rich interfaces and all the workabilities which even today’s OSes can not in some ways (Let’s take Mozilla 4 for an e.g.). So building up an environment which will directly link the CPU to the web applications environment, giving a darn look to everything else in the computer, is the future that Google eyes. I just hope that with time NaCl doesn’t crystallize as its chemical namesake. It would have been so much better if Adobe, Sun, Microsoft and Google had worked upon an all compatible web environment to create the most effective web environment rather than making a simile of multiple ones. I know I am a dreamer…


June 16, 2009: 3:37 am

Hello, can you please post some more information on this topic? I would like to read more.

January 20, 2009: 12:02 pm

I am unable to understand this post. But well some points are useful for me.

January 19, 2009: 4:18 am

[...] Google Native Client - A Detailed Discussion Posted in Highlights Tags: Chrome, Google, Native Client RSS feed for comments on this post Send trackbacks to: [...]

will not be displayed