Google Is Grooming Chrome As a Game Platform

An anonymous reader writes with this snippet from Conceivably Tech: "On Friday I noticed that Google is heavily pushing New Game, a game developer conference that is focused on HTML5-based gaming content — and, of course, content that runs in web browsers. The fact that such an event already exists and that there is game content being developed in HTML5, is quite stunning by itself. However, Google also noted that a sandboxed native client (NaCl) with 3D (in addition to 2D) will be available in Chrome soon, which will allow the browser to connect to traditional C and C++ code via its integrated Pepper API."

Comments

The very sadness of it all

[Anonymous Coward]

I know Commander Taco used to like games, and now he's not alive to see this. Very sad.

Re:The very sadness of it all

[Anonymous Coward]

On the bright side, at least he outlived Jobs by 24 hours.

Does anyone

[phantomfive]

Does anyone else see this as a giant security hole? As in, various schemes like this have been tried since the days of ActiveX, and the only reason ActiveX has the worst reputation is because it's the only one that gained widespread use?

Re:Does anyone

[JonySuede]

The article you pointed nacl_paper.pdf, proved my point, they limit the instruction to a subset of the full X86 capabilities...
from p3 :

reviously, such analysis
has been challenging for arbitrary x86 code due to such
practices as self-modifying code and overlapping instruc-tions. In Native Client we disallow such practices through a
set of alignment and structural rules that, when observed,
insure that the native code module can be disassembled
reliably, such that all reachable instructions are identied
during disassembly.

And the halting problems is the impossibility of deciding if a given program will halt on execution or not. It is proven that for a Turing complete language (full X86 is) it can't be shown if an arbitrary program will halt or not. There is also another proof that enables you to reduce the analysis of any given property of a programs that must be preserved during is liveness to the halting problem. Sure, a class of program where it can be shown that it will halt exist but this is only a subset of all the possible programs.

Re:Does anyone

[JonySuede]

and in nacljit, where they talk about platform independent SFI of self modifying code they admit :

We found that the Mono and V8 platforms, and their x86-32 and x86-64 variants, spanned a wide range in terms of the porting
effort required and the sandboxing slowdown incurred. At one end, Mono-32, porting effort was low and the measured overhead is near
negligible. At the other extreme, V8-64, porting took a few weeks and sandboxing slowdown is between 51% and 60% on average,
but 196% in one benchmark (due to a porting shortcut, as explained

See, you do not get the full speed while sand-boxing non trivial program.

However, our language-independent sandboxing does not aim to
preserve high-level language semantics, and the implementation of
our mechanisms is unencumbered by those semantics.

This is kind of bad, but without any details on what was dropped we can't know if it really is.

It sufces to extend traditional SFI techniques with a few new features, including new safety constraints that apply inductively on the structure
of machine code, even across code modication.

Subset, just like I said....

Re:Does anyone

[ninetyninebottles]

That's damn wrong. ActiveX's widespread usage is NOT the only reason. The most significant reason is that ActiveX had basically NO security - one wrong decision by the user and their whole system is compromised. There is no "sandbox filesystem actions" like in Java model for instance. The second glaring issue is that the user does not always gets to decide - lots of objects were marked "safe for scripting" - that is for use from JavaScript, when in fact their interfaces never meant to be secure.

I would add that being a closed source, single vendor project, there was no competition. If MS's implementation was insecure, well you're SOL. With an open standard implementation of NaCl with an open source reference implementation you have a different beast. If Google doesn't fix a problematic hole MS or Apple or Nokia or Canonical or Adobe can and will. Competition drives improvement, including security improvements.

Re:Does anyone

[juancn]

ActiveX is fundamentally different than NaCl. ActiveX security was based on the component being signed and that's about it. NaCl uses a very strict code verification (similar to what the JVM does, but with a subset of x86), runs in a process that has no permissions to do anyhting, and can only use a few APIs. It's not worse than Javascript.

Salty Sand

[FrankDrebin]

sandboxed native client (NaCl)

In other words, a saltbox.

Re:The very stupidity of it all

[Goaway]

Actually, Google wants to introduce LLVM bytecode, which will run on both x86 and ARM. They're making an OS for ARM processors, you know, they are aware it exists.

x86 is just the first step on the way.

Re:Proprietary

[PCM2]

How is using Pepper different than ActiveX with Internet Explorer?

In at least one significant way: The Native Client code is all open source, like Chromium itself.

Re:Cats shit in sandboxes all the time.

[ninetyninebottles]

They're [sandboxes] a theoretical concept that have never worked well in the real world. They've been tried time and time and time and time again. They aren't a new concept, but nobody ever seems able to implement them properly, even when some of the biggest names in the field are involved, and even when they have nearly unlimited resources and people to throw at the problem.

Well, except Apple with iOS, Google with Android, the NSA with their SELinux improvements, a crap-ton of people who worked on and use TrustedBSD, Bitfrost in the OLPC, and every security researcher for the last 20 years who has relied heavily on VMs. But yeah aside from those and probably a bunch more I don't know about, no one has successfully implemented sandboxes.

Maybe what you meant to say was that Microsoft hasn't been able to implement them properly.