denis bider

Various thoughts

The Holy Grail: Native Client

Posted Mar 24, 2009 at 17:16 by denisbider

Last edited Mar 24, 2009 at 17:49 by denisbider

Google programming technology

It looks like researchers at Google have created the Holy Grail: Native Client, a framework that allows untrusted, native, possibly hostile x86 code to run securely in a browser.

Here's the paper:

Native Client: A Sandbox for Portable, Untrusted x86 Native Code

They are also offering a contest to find any security vulnerabilities. The first prize is $8,192. It finishes May 5.

If this makes it into the mainstream, it is going to revolutionize web applications. No more lame, slow-ass websites that fail to provide a quarter of the performance and capability of native applications. If Native Client becomes widespread, web applications are going to be full-fledged, and there is not going to be any reason any more to write installable native applications. Editors, spreadsheets, games, development tools, image manipulation software: they are all going to run in browsers. And I don't mean lame-ass browser versions, like we have today. I mean real, high-performance editors, spreadsheets, games, development environments.

Kudos to Google for this. I was considering the same idea, but by the time I was shelving it as probably too error-prone / too difficult, they were apparently already halfway there.

Great work. I hope this makes it to our desktops ASAP.

Hat tip to Ben Laurie.

List older posts

Showing 3 out of 3 comments, oldest first:

Comment on Mar 30, 2009 at 06:49 by Anonymous

HTML was created with web pages in mind. What we're actually doing today is abusing this technology to build applications, which is of course something entirely different.

We've always had applications. And we have virtual machines. Why not combine a lightweight, preconfigured VM with a bootstrapping protocol - then we could forget the "web 2.0" trauma completely. It would be so much more powerful, instead of inventing yet another standard.

Comment on Mar 30, 2009 at 11:21 by boris_kolar

Google's achievement is admirable in technological sense. I hope their technology becomes mainstream.

There are, however, reasons it might take a long time before that happens, if it ever does:
- porting an application to NativeClient is at least as hard as porting to another operating system (and for existing applications even switching from Visual Studio compiler to GCC can be a nightmare)
- not all applications can be ported easily (especially not JIT compilers)
- if you have to modify compiler tool chain, you might as well target your program to entirely different architecture like LLVM or Typed Assembly Language
- the 386 instruction set is inferior to many others because of larger code size, code complexity, and dependence on specific set of hardware
- rapid rise of mobile devices make decision to commit to 386 instruction set more difficult

Comment on Mar 30, 2009 at 14:33 by denisbider

Anonymous: two words - installed base. Same reason why we're stuck with SMTP for email. It's shitty, but there it is.

Boris: Native Client is most definitely better from the porting standpoint than HTML + JavaScript are. While you can port Quake to Native Client, there's just no way you can port it to HTML + JavaScript.

Also, I am talking primarily about the potential for creating new rich networked application, not about recycling existing PC-based software.

I think your last argument (mobile devices) is the most salient. Yes, stuff like the iPhone mostly runs on ARM processors. But a client for x86 code probably could be developed for these devices. The resulting performance might not be much of an improvement over HTML with JavaScript, but it would allow a (largely the same) x86 web application to run on mobile devices as well as Linux, Windows, or Mac - where it already runs.