
Google nabs Square Enix and other game developers for native client Chrome games - evo_9
http://venturebeat.com/2011/12/08/google-nabs-square-enix-and-other-game-developers-to-do-native-chrome-games/
======
rakkhi
//Black hat on

The main concern for me with native client is webgl and the exposure of 3D
device drivers to the Internet. These drivers were not written with this use
in mind there have been webgl vulnerabilities in the past:
<http://www.contextis.com/research/blog/webgl2/>

While Google will be aware of these and actively working to provide a buffer
with via validation and sandboxing, with pessimistic hat on, I can see this
leading to a lot more security vulnerabilities.

~~~
tptacek
That's a valid concern; I know another HN user who might chime in with more
detail to back it up.

On the other hand, Google has built a particularly good security team for low-
level systems code problems like this, and they've done things (like the NaCL
security contest) to attract the right kind of attention from researchers.

~~~
daeken
I'm not the least bit concerned about NaCl's involvement here, but I'm still
deeply scared by the potential for things to go very badly in the lower levels
(but not enough so that I'm willing to disregard the benefits of these APIs,
mind you).

What it comes down to is that current GPUs do whatever you want with no
concern for security; that part depends on the driver and userspace 3d stack.
This isn't necessarily bad, but GPU manufacturers can't write code. Bounds
checking and all that are pretty well covered by things like ANGLE (translates
OGL to D3D on windows and acts as a sanity checker and shader validator
everywhere else) but that doesn't help you if, say, your driver improperly
compiles valid-but-malicious code. Avenues like that are effectively not
researched at all.

~~~
nkassis
It's a concerned but it's something GPU vendors are claiming they are working
on. There has been moves to improve driver security through the ARB_robustness
extension and for the browser vendors there is the ANGLE's project as you have
said but also plain blacklisting dangerous cards or drivers.

The reality is that web 3D's time seems to have arrived. It doesn't matter if
it's through WebGL, Flash, Unity the issue you raised is present in all those
solutions. Even Native client has that potential if the sandbox is not
watertight.

In all, if we want a more capable web these are risk I feel are worth taking.
But that's my personal view.

~~~
daeken
> There has been moves to improve driver security through the ARB_robustness
> extension

IMO, GL_ARB_robustness is almost completely worthless. The one thing it gives
you is the ability to time out rendering, in effect, which of course prevents
certain types of DoS attacks. There are many other provisions in the
extension, _but_ those are already universally implemented in ANGLE and the
like; they don't do anything to help with the security of the lower level.

> The reality is that web 3D's time seems to have arrived. It doesn't matter
> if it's through WebGL, Flash, Unity the issue you raised is present in all
> those solutions. Even Native client has that potential if the sandbox is not
> watertight.

NaCl has the same issues regardless of the sandbox, but I agree entirely:
hardware accelerated 3d on the web is worth the risk we'll be dealing with for
the first couple of years. I've stopped writing desktop 3d software/demos
entirely in favor of WebGL simply because I believe so much in it, but it's
not stopping me from doing security research into it as well.

At the end of the day, I'm convinced that a reasonably skilled attacker could
do terrible, terrible things to my system via WebGL. But the benefits outweigh
the risks for me.

------
zobzu
There you go: Google's embrace, extend, extinguish. Just like MS, but with
better cover. "Its open!" Of course, no one else will implement.

~~~
patrickaljord
NaCl uses the NPAPI which is pretty standard, it's used for flash for example
and is supported by Firefox, Opera and webkit. This means NaCl could be
plugged in those browsers without being reimplemented.

~~~
pcwalton
For now, that is true. However, NaCl is moving to the Pepper API, which is a
proprietary Chrome API for plugins.

~~~
souichi
> proprietary Chrome API

You keep using that word. I do not think it means what you think it means.
From Wikipedia:

"""Proprietary software is computer software licensed under exclusive legal
right of the copyright holder. The licensee is given the right to use the
software under certain conditions, while restricted from other uses, such as
modification, further distribution, or reverse engineering."""

Nothing of this applies to Pepper API or NaCl. Mozilla can implement Pepper
API and NaCl or can even just take NaCl as whole because it is, oh boy, oh
boy, open source with a permissive license.

~~~
beaumartinez
"Proprietary" ≠ "proprietary software".

~~~
esrauch
You think proprietary software is software that you can't use without license,
but proprietary API is something other than an API that you can't use without
license?

------
daeken
Iiiiinteresting. They mention Bastion, which is built with XNA and C#. I
wonder how they plan on porting it.

~~~
natfriedman
Bastion runs on Mono, and Mono runs on native client (including the JIT, which
required some special work in native client itself).

Actually all three apps they demo'd running on native client were also running
on Mono!

~~~
kevingadd
Do you know what the solution was for XNA? The last time I checked, all the
Mono XNA ports were in miserable shape. Considering Bastion makes use of
shaders and mixed mode 2d/3d rendering, it seems like it must be running on a
high quality port of a large portion of the XNA stack.

~~~
kevingadd
Replying to provide follow-up detail: I dug into the executables and it looks
like it uses OpenTK for rendering and FMod to sound, instead of using a port
of XNA. Both are freely available, so that's a pretty simple path to doing a
similar port for other XNA games. Neat.

~~~
VikingCoder
Wow, wow, wow.

So, can someone write a tutorial about how to develop a C# OpenTK + FMod
application, and get it running on Mono, in Native Client?

That would be awesome to see.

~~~
DonnyV
I have been looking everywhere and can't find one. Please post if someone
finds one.

------
tantalor
"To nab" means "to sieze", which implies Google bought out Square Enix.

Better title might be, "Google taps Square Enix".

------
carldall
Regarding Native Client: I don't think that Google is evil just because they
try to move web technologies forward in non w3c standardized ways, and I don't
even want to go into this discussion because there're (imho) valid arguments
for both sides, But: For web developers, this whole process is suboptimal to
say the least. It only adds to the already existing complexity of the web
technology stack but enforces more browser checks and fallbacks.

Even worse, as soon as you're working for a customer who isn't technical,
you'll land in a situation where he shows you a Native Client app and wants
"something like that" on his website but running in Firefox or Safari or (even
worse) Internet Explorer.

------
primigenus
The advent of Native Client combined with this move means the Chrome Web Store
is going to end up positioned as a direct competitor to Steam.

That's pretty interesting, honestly. It'll mean great things for consumers: I
bet playing a game in your browser could be really convenient compared to
downloading and installing Steam and then going through the motions for that
platform. But Steam has 7 years on the Web Store with all kinds of great
platform features like Steam Play, Cloud, Wallet, etc.

An exciting time to be a web and game developer, to be sure!

------
melling
How does native client solve the ARM vs Intel issue? Can a fat binary be
created so apps run on both an ARM Chromebook and an Intel PC? Finally, can
native client be adopted by Opera and Apple for use in their browsers?

~~~
azakai
Native Client does not solve the portability issue. Portable Native Client is
a research project trying to do that, but it is unclear whether it will
succeed, and if it does, with what compromises (speed, security, etc.)

Native Client can in theory be adopted by other browsers, since it is open
source, however no other browser has shown interest, the opposite in fact.
Native Client is a nonstandard technology that will remain only in Chrome.

