Google's Native Client: The second coming of evil ActiveX?

Why IT organizations will rightfully reject the company's latest attempt to extend its reach into the desktop

Is Google's Native Client the second coming of ActiveX? I ask because the more I learn about this nascent Web/PC integration technology, the more it strikes me as so much old wine in new wineskins.

Consider the similarities. Both technologies are designed to bridge the gap between the Web browser and the PC client. In ActiveX's case, this was accomplished via a native-compiled, Win32 program that was then specially wrapped and packaged for easy download/installation, with little or no user interaction. Native Client take a slightly different approach, with a plug-in architecture and additional layers of abstraction and security. However, the net result is the same: content that can be automatically downloaded from the Web, then run directly on your PC's hardware.

[ See why InfoWorld's Neil McAllister also fears the Google Native Client approach. | Discover exactly how bad ActiveX really is. ]

This last part is what keeps IT administrators up at night. We all know what a disaster ActiveX turned out to be. By enabling unrestricted Win32 executable files to be encapsulated in an otherwise innocent-looking Web page, Microsoft created as security hole big enough to drive a truck through. And despite years of patching and fixing, including ever more esoteric code-signing and runtime activation restrictions, Microsoft has never successfully put the ActiveX genie back in the bottle. It remains a dark episode in Internet Explorer history, one that weighs down the browser to this day.

Given that history, IT veterans are understandably squeamish about any idea that smells of ActiveX-like integration. And so far, Google is doing little to allay their fears. Yes, Google executives talk about the importance of security and how they're committed to keeping Native Client safe. However, the company's track record to date reeks of consumerism and poor self-discipline. Google likes to play the role of the disruptor in technology circles, and while this makes for great copy (we columnists love disruptive technologies), it puts them at odds with IT at nearly every turn.

Now we hear that that the latest developer release of Chrome has built-in Native Client support. This move signals the transition of the technology from incubation as a research project to (limited) release as a production-level capability. Native Client is literally at IT's doorstep, yet few shops fully grasp just what it means or how controversial its newly minted underpinnings truly are. After all, it was just a few months ago that a couple of university students poked enough holes in Native Client (including one serious enough to have allowed a potential system takeover exploit) to win the booby prize in a Google bug hunt contest.

These holes have since been patched, of course, and Google seems confident that its combination of sandboxing and static analysis will be sufficient to deflect threats from the majority of attack vectors. However, no security mechanism is foolproof (just ask Sun Microsystems), and the mere thought of what a malicious Native Client application might do if it were to find a way around Google's defenses is enough to send a shiver down the collective spine of the IT community.

Can Google overcome the stigma associated with native execution of Web content? Not likely. The PC is the PC, and the Web is the Web, and never the twain shall meet. When it comes to the separation of browser and OS, we IT folk like the status quo. It keeps us sane. And the harder Google tries to pry that Pandora's box back open, the tighter our grip becomes on the edges of the lid.

We've been down this dangerous road before. It's called ActiveX -- and Google's Native Client is looking more and more like its unwelcome second coming.

This story, "Google's Native Client: The second coming of evil ActiveX?," was originally published at Follow the latest developments in browsers and Windows at