Google Revamps Native Client, but will it be taking it all the way?

Posted by Dionysios G. Synodinos on Feb 20, 2011

Sections

Architecture & Design

Topics

Architecture ,

Performance & Scalability ,

Google Native Client ,

Web Browser ,

Browsers

Share |

RELATED Research

About a year after it’s original announcement, Google released a new version of the Native Client (NaCl) SDK, which allows the safe execution of native code from a web browser. It is unclear though, if this ambitious project will be making it to production, or have the fate of other projects like Wave or Gears.

The new SDK features support for Chrome’s new plugin interface (Pepper), better security and other improvements:

The SDK now includes support for a comprehensive set of Pepper interfaces for compute, audio, and 2D Native Client modules. These interfaces are close to being stable, with some important exceptions that are listed in the release notes.

In addition, we’ve focused on improving security. We have enabled auto-update and an outer sandbox. This allowed us to remove the expiration date and localhost security restrictions we had adopted in previous research-focused releases. Beyond security, we’ve also improved the mechanism for fetching Native Client modules based on the instruction set architecture of the target machine, so developers don’t need to worry about this any more.

Native Client origins can be traced to Robert Wahbe et al. “Efficient software-based fault isolation”:

One way to provide fault isolation among cooperating software modules is to place each in its own address space. However, for tightly-coupled modules, this solution incurs prohibitive context switch overhead. In this paper, we present a software approach to implementing fault isolation within a single address space. Our approach has two parts. First, we load the code and data for a distrusted module into its own fault do main, a logically separate portion of the application's address space. Second, we modify the object code of a distrusted module to prevent it from writing or jumping to an address outside its fault domain. Both these software operations are portable and programming language independent. Our approach poses a tradeoff relative to hardware fault isolation: substantially faster communication between fault domains, at a cost of slightly increased execution time for distrusted modules. We demonstrate that for frequently communicating modules, implementing fault isolation in software rather than hardware can substantially improve end-to-end application performance.

In this release NaCl has several limitation like:

• On Mac requires Snow Leopard,
• Won’t work on Windows XP 64-bit systems,
• Is not available on all Linux distributions,
• All available Pepper functions must be invoked from the main Pepper/JavaScript thread of execution. Although traditional plugins in Chrome run only out of process, Pepper plugins only run in process and in the future the will be supported only within NaCl.
• No support for 3D graphics, file I/O, or peer-to-peer networking,
• No support for devices such as cameras and microphones.

If you what to give NaCl a try you must first enable it on Chrome v10, at the about:flags configuration page, and use the built-in Python HTTP server.

Mono developers can also directly target the Native Client:

The support for Native Client allows Mono's virtual machine, garbage collector and Just-in-Time compiler to be used inside a Native Client sandbox.

Google added JIT support to their Native Client engine to give users greater flexibility while using Native Client. In the past, Native Client was limited to running statically compiled code (Mono on AOT mode), but this would prevent interesting scenarios, prevent System.Reflection.Emit, scripting languages and other dynamic cases from working. We are incredibly excited about Google's work and Elijah's contributions on this area.

Similarly Qt developers might be interested in looking into how they can use NaCl for deploying Qt-based UIs.

The Native Client mission to bring sandboxed Intel x86 native code to the browser is a very ambitious one, so it is only fair for the community to wonder if Google can actually pull it off:

Can you guarantee that this is here for keeps and won't have its plug pulled like Wave?

Besides the cancellation of Wave, one can recall the highly acclaimed Gears project, which Google cancelled, although there were several hight profile deployments both from Google and 3rd-party. Especially one part of Gears, which aimed at relational browser storage, was even recently dropped by the W3C as an HTML5 spec all together.

With this track record, do you think that Google will be taking the Native Client all the way?

Dionysios G. Synodinos is a Web Engineer and a freelance consultant, focusing on Web technologies

1. Back to top

   Native Client

   by Javier Rovertson

   I've never seen anyone else use the abbreviation "NaCl" when referring to "Native Client." Especially since NaCl well known as another project (nacl.cace-project.eu/). You might want to update your post.
   
   
   [Logging in with a BugMeNot account since you don't seem to allow one-off replies]

   Reply

2. Back to top

   Re: Native Client

   by Dionysios Synodinos

   Hi Javier and thanks for the feedback!
   
   NaCl *is* common for reffering to Native Client:
   
   

   
   en.wikipedia.org/wiki/Google_Native_Client
   "Google Native Client (abbreviated as NaCl in an allusion to Sodium chloride or common salt) is a sandboxing technology..."
   

   Reply

3. Back to top

   Why? What are the benefits?

   by Bojan Antonovic

   16 years ago, Java was invented. It was portable, independent of the platform, and since version 1.3 it reached native speed.
   
   In 2011, NaCl comes with limitations which Java doesn't have.
   
   The only problem why developers moved away from Java (applets) was the lack of availability of the JVM at the client side.
   
   To use NaCl, the user needs Chrome, and a supported architecture. So, no problem solved.
   
   So why should I go back to C++, and try to reach a very small audience? What is the benefit of enwrapping my -possibly legacy- C++ application as a browser plugin? Why not leave it as a standalone application?
   
   If NaCl is the solution, what was the problem? The performance, which is solved by JIT-ed JavaScript?
   
   Enlightments are welcomed!

   Reply

4. Back to top

   Re: Why? What are the benefits?

   by Dan Tines

   There's several problems with Java.
   
   First is the way that Sun completely bungled applets. The install process was painful and the startup times were non-optimal. Sun never learned from Macromedia/Adobe, and it's doubtful that Oracle cares enough to address the remaining issues.
   
   Java applets obviously cannot run native C++ code.
   
   Google has little incentive to promote the JVM on the desktop considering Oracle's lawsuit.
   
   Applets just leave a bad taste in developers and users mouths. Even if all the issues of applets were solved, you can't change the historical perception of applets. Applets will never make a comeback.
   
   That said, I'm not sure what Chrome's strategy with this is. Obviously it'll never gain traction with other browsers. I like the concept, but with all things concerning the web, you tend to have to deal with the lowest common denominator - ie IE.

   Reply

5. Back to top

   Analogy to device drivers?

   by Hermann Schmidt

   I guess that the native interface for Chrome is what a device driver interface is for a classic operating system.
   If Google wants to run Chrome as a standalone platform similar to an OS, they need some way to access resources, which are not available in a browser.
   
   Maybe this is the primary motivation for this.

   Reply

6. Back to top

   Re: Why? What are the benefits?

   by Bojan Antonovic

   Hi Dan
   
   Thanks for the history lessen. I never worked with Applets. Only server side and console development.
   
   However you can replace Java and Applets with anything else. Why not using an existing VM? Use Mono? Why not any other language? Why inventing an other API?
   
   Well, maybe future will show it.

   Reply

7. Back to top

   Re: Why? What are the benefits?

   by Dan Tines

   Hi Bojan
   
   Probably the biggest reason that Google wouldn't use Mono or the JVM with a remake of the applets concepts is NIHS (Not Invented Here Syndrome). Google has deep pockets and lots of smart people, so why try to play ball with others when you can control the platform.
   
   Hermann made an interesting point, and I wonder if this plays into Google's ChromeOS strategy. I think ChromeOS is DOA, but who knows.

   Reply

8. Back to top

   Re: Why? What are the benefits?

   by Hermann Schmidt

   IMO it doesn't make any sense in a general web context. Who on earth would be willing to write a web app, which limits itself to a 15% (or so) global user base and locks itself out of almost all big enterprises (who tend to prefer IE)?
   
   As Dan said, it will never gain traction in other browsers. There is no motivation for the other browsers to follow, because for the aforementioned reason there can be no widespread killer app.

   Reply