I'm beginning to believe NativeClient and PNaCl (LLVM on NaCl: http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf) has the best shot at becoming this.
Google is already including NaCl in Chrome developer builds, so I wouldn't be surprised if they enabled it in releases by the end of the year, and started releasing Native Client applications soon after.
Hopefully this was an inaccurate impression, because NaCl could have a huge impact on both the client and server
The best path to adoption would be for Google to very aggressively push NaCL as a Flash-like plugin. If they could get adoption -- through Unity3d on Facebook or something like that -- perhaps they'd win in the long run. If they just keep it part of Chrome it seems rather hopeless.
The problem is not that NaCl is insufficiently secure, but any vulnerability will be spun as "Google making your system insecure". I think an independent group doing the same thing would be no more or less secure, but wouldn't have the baggage that would come from being seen as a component of a much bigger entity.
Me too, although the biggest hurdles seem as much political as they are technical.
My hope is that Google can strong-arm NativeClient into active use, forcing otherwise recalcitrant browser makers (Mozilla, Apple, Microsoft) into adopting it.
I won't get into the details because there's tons of information out there (http://www.chromium.org/nativeclient/reference/research-pape...), but code must be compiled using a special NaCl compiler, then before it's executed the client runs it through the NaCl verifier to ensure it's safe to execute.
Of course it's possible there are bugs in NaCl, but Google won't enable it in Chrome by default until they're very confident it's secure.
It's possible that the design could be flawed, but the same is true for browser implementations and mobile application sandboxing.