This article is more than 1 year old

Google Chrome OS goes native (code)

We hate plug-ins. Except our own

The new Active X?

"There is a security concern," Opera's Bolstad says. "I'm not saying there's anything in particular that's insecure about their current implementation. But the moment you start executing native code, there is a trust issue. Users may not realize that they're allowing native code to execute when they visit a webpage."

Google does acknowledge the difficulty of ensuring security with such a platform. But the company is confident it has taken the necessary precautions. "To help protect users from malware and to maintain portability, we have defined strict rules for valid modules," Google said when it first open sourced the project.

"At a high level, these rules specify 1) that all modules meet a set of structural criteria that make it possible to reliably disassemble them into instructions, and 2) that modules may not contain certain instruction sequences. This framework aims to enable our runtime to detect and prevent potentially dangerous code from running and spreading."

But no matter how secure the plug-in is in and of itself, Native Client is still a plug-in. Folks like Buckler question whether Google is opening the same Pandora's Box it opened with Google Chrome Frame, the infamous plug-in that turns Microsoft browsers into Google browsers. Buckler cites the rather convincing argument against Chrome Frame laid down by Mozilla vp of engineering Mike Shaver.

"Although Chrome Frame is a niche solution to a known problem, Mozilla is worried that the web could become fragmented if companies eschew web standards in favor of plugin-based solutions," he says.

After the release of Chrome Frame - which essentially put a browser inside a browser - Shaver questioned whether Google's plug-in would send netizens into a state of confusion. "The user’s understanding of the web’s security model and the behaviour of their browser is seriously hindered by delegating the choice of software to the developers of individual sites they visit," he said.

"It is a problem that we have seen repeatedly with other stack-plugins like Flash, Silverlight and Java, and not one that I think we need to see replayed again under the banner of HTML5."

Google with NaCl

Shaver tells The Reg that Native Client is a slightly different case, but he still sees Buckler's concern. And he still prefers HTML5. "[Native Client] is not as clean when - in terms of what the user's mental model is - compared to HTML5, which is what we would prefer," he says.

"[Native Client] is not quite a problem to the same degree as [Google Chrome Frame]. It's not as problematic structurally. But if you can implement a complete web stack with standards without having to mix-and-match components, I think it's better for web users."

But Google is going to do what it's going to do. As he discussed the possibility of hardware acceleration on Chrome OS at that November press conference, Matthew Papakipos went so far as to say: "We do think Native Client is an important part of this story." Not that he was ready to go into detail. But surely, we can connect the dots. ®

More about

TIP US OFF

Send us news


Other stories you might like