Native Client: An OS in Your Browser


Earlier this week, I wrote about the launch of Google’s (s goog) Native Client, and how the company hoped that the new software would help web-based apps run faster and more securely. After the post appeared, I got an email from Google, asking me if I wanted to find out a bit more about Native Client, and suggesting that they could help “clarify some misunderstandings” in the piece I wrote. Since I hate to think that there’s something I might have missed or described poorly in a post, I agreed.

What resulted was a phone call with three Google engineers: Linus Upson, an engineering director; Brad Chen, the engineering manager for Native Client (who wrote this post on the Google blog); and Henry Bridge, a product manager for Native Client. (Note: It was difficult for me to tell who was speaking during the call, and I only got their names after the conversation was over, so I can’t attribute comments to any specific individual; if any of them want to email me and identify who said what, I would be happy to include that).

One thing that the Google team wanted to clarify was that Native Client isn’t a “scripting language,” which is the way I described it in my original post. So how should it be described? Well, it’s kind of a platform — but at the same time it’s not really a platform. One of the Google engineers said it’s “a platform for creating modules” that can be written in a variety of different languages, but at the same time “it’s not a platform in itself.” Another said that Native Client “isn’t a place where an entire app would live; it’s a way for an app to access the machine code and make it easier to run it faster.” (one Slashdot commenter described it on Slashdot as “a little operating system”).

Another thing the Google staffers wanted to clarify was that Native Client isn’t really a competitor for Javascript or ActiveX or Flash (although some definitely see it as a competitor for Java). “You could use it in conjunction with ActiveX or Flash,” said one. “Or with Javascript, or whatever you want to use.” What Native Client does, he said, is to enable any web-based app — regardless of which technology was used to create it — to access the machine code of a user’s computer (provided it uses Intel’s (s intc) x86 series of processors) and thereby run apps a lot faster. ActiveX and Flash can run machine code, one of the Google team said, “[B]ut you take a security risk by doing that. Native Client means you can run native machine code without sacrificing security.”

No one had any issue with the bottom line in my original post, which was that Native Client is yet another move by Google to turn the web into an actual operating system, or at least to blur the line between desktop and “the cloud.” One of the team members said that the company sees it as a way to “close the gap between what you can do in a web app and what you can do with a desktop app.”

As for having a grand vision of creating a web operating system, one of the engineers, who was working at Netscape during that period (or as he put it, “When Microsoft (s msft) was ripping us limb from limb”), said that, “No one was really thinking along those lines — we were just trying to get the browser working so we could stay in business.” So while it may not have been top of mind while Netscape was struggling for survival, there’s no question that Google is coming close to realizing the overall vision of a web OS — and Native Client is one of the factors that could help make it a reality.



Known internally as “Sulu’s Ear” the ultimate placement engine for ad sense.


So let me get this straight, web OS = OS inside of a browser which is inside of an OS? Brilliant.


Do I miss something, or where is the magical thing that makes it so secure.
Machine security is a matter of handling uncertainty, you can either limit it by limiting functionality (really globally restrictive sandbox ) or you try to force it to allow local applications only to do certain things(SeLinux). Both models will break (SeLinux later, since it deals with more specifics, but a pain to get right) , because there is always the creativity of the human brain to introduce the unknown at a later time. So what’s Google’s silver bullet and why is it so much better then everybody else.
Also don’t you have to deal with at least three latencies, Sever application and load, Network and local. Fixing one, nice, but no cigar, specially my machine lately always waits for some ad network, one is owned by Google. Which leads one to believe the business model needs some fixing too.

On the other hand if a research Engineer can not explain in clear abstracts what he is building,you will end up in a mess if you put that system in production and have it maintained for a while. Since there is no clear guideline of what is what and why it’s there.
A few questions that come to mind:
What’s their definition of an OS?
If it’s an OS, they run an OS-App-OS or a VM-(OS-APP-OS)*n why? Where is the advantage of that convoluted setup for the user.
They already have fault separation in Chrome don’t they? How many times do they have to do that?
What’s their goal, it’s called research for a reason, and not re-guided for the same reason.


You must be doing something right to get three Google engineers on the phone!

Comments are closed.