eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Net Applications made waves last week when it told reporters Google is masking origins of some of the traffic streaming out of its Mountain View, Calif., headquarters.
Google dumped fuel on the fire by unveiling Native Client, an open source runtime engine, browser plugin and compilation tool set to boost Web application performance on computing devices. Some observers think Native Client could be combined with Google’s fresh from beta Chrome browser, Gears and to form some of Microsoft Windows-killing Web operating system.
eWEEK caught up with some of the men behind Native Client, which interestingly is a research project but not a famed 20 percent time project, to find out what Google’s up to. Google’s Linus Upson, director of engineering, Brad Chen, engineering manager for Native Client and Henry Bridge, product manager for Native Client, obliged eWEEK’s questions.
Questions, which address what Native Client is and why it’s such a hard nut to crack, were formed with help from Gartner’s Ray Valdes. Answers include jokes about Google’s product secrecy and jibes about how Microsoft has conflated the definition of what an operating system is.
Q: The Net Applications folks sparked a lot of interest with their notion of hidden traffic traits at Google, and suggesting that Google is using some other operating system we don’t know about. Then, conveniently, you release Native Client, leading some people to connect the dots that if you take Native Client and combine it with Google Gears, Chrome and Android, you could create a Web operating system. So, let’s start with the Native Client overview. What is it?
Upson: I’ll let Brad and Henry talk about the Native Client details, but as far as these user agents with no identifier, I can honestly tell you I have no idea. I can also tell you that when we were developing Chrome, we didn’t want some people to see some new user agent on our Web sites, and so since we used the same rendering engine as Safari, we just claimed to be Safari on Windows, and so we were very careful not to leak any user agent stuff. Several people have looked into it and no one’s figured it out yet, but I can also tell you quite definitively it has nothing to do with Native Client.
Q: OK, so is there a Google operating system in the works then?
Upson: We don’t comment on rumors like that, just like when people ask us about all kinds of crazy things.
Q: Similar to like how you denied the existence of Chrome before you announced Chrome?
Upson, joking: Just like with Chrome, just like with the space elevator and the zeppelins. I can’t talk about them.
Security in Native Client Is Lock Tight
Q: What is Native Client and why function-targeted extensions (such as Google Gears) cannot fill the gap for specific horizontal scenarios?
Bridge: We view Native Client as a function-targeted extension. Basically, what Native Client is, is a technology for allowing Web developers to get access to the enormous computational power that exists on users’ machines today. There’s a significant gap today between the computational performance you can achieve with a program running natively on a machine and what you can do via JavaScript in a Web browser. So, really we’re trying to bring that power to developers so that they can create new types of applications that employ native code. We released this this week is that it was at a stage that we felt like it was ready to share with the open-source community and the security community to get feedback from them. We want the security community to really try and break out of it so that if we decide to incorporate it inside a product down the line we’ve hopefully addressed the security issues in the technology. The security community on the Internet and the open-source community have a great history of finding things that are incredibly obscure.
Q: When we’re dealing with Web applications, security is always a concern, but why is this such a big concern with Native Client?
Bridge: Native code is generally viewed as very scary. Native code is what the applications on your computer run right now and that means when it’s installed on your computer it has access to the underlying parts of your system, such as the hard drive and the network subsystem. It allows applications to do scary things like erase your hard drive or spread malware over the network. The approach that we’ve taken with Native Client is that we’ve only allowed the native code to run on these models to do a select set of things, so you can’t access the network or the files on the computer. It keeps users safe from all kinds of security concerns.
Q: So what did you do to lock up the native code for Native Client? [Warning: the following answer is best enjoyed if you’re a developer].
Chen: Native code modules typically have full access to the operating system interface and that’s the way they get access to the network and file system. In the Native Client container, we give the native code module access to the browser, so it can interact with the browser the same way JavaScript with the browser, that is safely interacting with the DOM and such. The system prevents the native code module from interacting with the operating system. What we need to implement is reliable disassembly of x86 code and that’s sort of like the holy grail if you will, or the very difficult problem that other people have sometimes considered not possible. We basically set up a set of rules and have a static validator that dissembles the code and is able to check that the rules are followed and because the rules are followed, we’re able to check that we’re getting reliable disassembly. Then we can determine which instructions we do allow or do not allow in the native code module.
Upson provides a high-level answer for us non-geeks: With modern programming techniques, it’s very hard to know what a program does, and that makes it difficult to say whether something is going to do something bad to your machine. Basically what we’ve done with Native Client, is made it so that with the native client module, you can’t do a lot of the tricky things that make it difficult to understand what the program is doing. You can only do the core functionality of what the programs are allowed to do. That allows us to look at it and see whether it is going to do something dangerous.
So Is Native Client Designed to Gouge Microsoft or Adobe?
Q: Native Client runs on Firefox, Safari, Opera and Google Chrome and supports any modern Windows, Mac or Linux system that has an x86 processor. Why no support for Internet Explorer?
Chen: We’ve actually been working on Internet Explorer, but the fact is all the browsers we do support all use NPAPI (Netscape Plugin Application Programming Interface) and is implemented fairly similar to the way that NetScape and Mozilla created it. Internet Explorer doesn’t support NPAPI at all. The Mac OS version of Safari has an NPAPI version that is quite different from the others. We’re working on both of those and consider them essential, but they just weren’t at the level of function and stability that we thought it made sense to include them in the first research release.
Q: In your blog post from Dec. 9, you outline image processing as a potential use case for Native Client, which enables image processing on the desktop CPU to improve application performance. What’s another use case?
Bridge: Physics requires a lot of computational power and is used in a variety of games today. Games like Quake are a great example of that. You could also see Native Client used in scientific applications. Basically, anything that requires a lot of computational power but requires that a user can interact with it in real time rather it going out to a server and going back to a user’s computer.
Q: The Native Client has provoked some discussion about what technologies it’s intended to challenge, such as Microsoft Silverlight, or Adobe Flash or Air. What technology does Native Client threaten?
Upson: I don’t think there’s anything out there that competes with Native Client. There’s two things that it really enables. One, is performance. You can get full hardware performance out of it. You can low-level numerical computation much faster than even in the fastest JavaScript implementations. The second thing is it allows Web developers to access large, existing C and C++ code bases that they can use in there Web applications safely. There’s a physics simulation engine written in C++, but if you wanted to build a 3D game with physics in it, you’d have to rewrite that whole physics engine in JavaScript. Being able to take that existing code base and have it run inside of a browser is pretty powerful. These guys (Bridge and Chen) basically took the whole Quake source code, and within a short period of time had it up and running in the browser. So I don’t think there’s anything else out there that does what Native Client does. It complements a lot of the work that’s going on in the Web. You can use it with Flash, Silverlight, HTML and JavaScript.
Q: So, people are throwing out Chrome, Android, Gears and Native Client. Would all of these ingredients together or in some combination form the basis for a Web operating system?
Upson: Ever since the Microsoft antitrust trial, I don’t know what an operating system is anymore. They drew the circle very wide and basically said it’s anything we call Windows. My computer science 101 textbook had a much narrower definition of what an operating system was. I can’t define an operating system in any kind of reasonable way. But I can tell you what we’re trying to do with things like Chrome, Native Client and Gears. We really want to make it possible for people to build Web apps that are as rich, responsive and powerful as desktop applications. We really want to close the gap between the Web and the desktops. We’re very committed to doing that with open source and open standards.