Google Is Grooming Chrome As a Game Platform 127
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."
The very sadness of it all (Score:4, Funny)
I know Commander Taco used to like games, and now he's not alive to see this. Very sad.
Re: (Score:2)
Re: (Score:2)
he is alive, just not an editor for slashdot anymore
that makes a fate worse than death.
Re: (Score:3, Funny)
On the bright side, at least he outlived Jobs by 24 hours.
Re: (Score:1)
Who?
Re: (Score:1)
Crash in best case. In worst case - a silent exploit of the sandbox and infection of system.
Honestly, do we really need the ActiveX all over again? Or history wouldn't be history without repeating itself?
Re: (Score:2)
While it is possible, and sometimes desirable, to increase security just by paring away as much power as you can get away with, that doesn't fly in the broader market. People want their games, and their videos, and whatnot. If they can't get them in-browser, they'll get them by downloading every friendly
Re: (Score:2)
you just shove it off onto the OS
But we already did and it is widely accepted: anti-virus software.
which hasn't shown a brilliant track record of protecting people from the things they run,
But that the point of the responsibility separation. If user explicitly wants it, then you can't do anything against it - against the will of user. After all, computer exists to fulfill the commands given by the user.
You are sending us back to the old Outlook dilemma: how to send installer of a hot fix to a customer who urgently needs it? Because Outlook too can police attachments and instead of giving AV software a chance, simply drops
Re: (Score:2)
I would argue that this is doable: we now have a very good handle on sandboxing applications, and we even have good, almost-native-performance VMs. If we can make it so that all untrusted apps automatially run in a sandbox or VM, then this will work. So long as the "least work" state has the application running in a sandbox, that will prevent 90%
of infections through this vector.
Also, don't forget the fact that this will run cross-platform, and thanks to qemu(if it's x86 bytecode), on other arch's as well!
Re: (Score:2)
But we already did and it is widely accepted: anti-virus software.
Ha. AV software is an old dog that should be taken for a walk.
Re: (Score:1)
You could have saved all the trouble of typing out the poorly reasoned tripe and just said "get off my lawn."
Re:The very stupidity of it all (Score:5, Informative)
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: (Score:2)
If only they let the bytecode access directly the underlying opengl graphics primitives, we could implement our own rendering engines in this bytecode language and be done with html5 compatibility problems forever... (of course assuming that other browser vendors will use the same bytecode).
Re: (Score:1)
worst than flash (flash running in a vm and vm are usually portable), equals to active X
Write once, run anywhere? (Score:1)
Re: (Score:2)
HTML 5 and Javascript achieve that well. What native client gets you is SPEED.
Does anyone (Score:4, Insightful)
Re: (Score:2)
Yes. But, if they go for the locked ecosystem that seem to become so popular these days, they can try and solve the problem at the source.
Re: (Score:1)
Yes. But, if they go for the locked ecosystem that seem to become so popular these days, they can try and solve the problem at the source.
But Google is open. Why would they go from an open playing field to a locked down, curated, one?
Re: (Score:2)
How is Google open? They are very public about things, beta this alpha that but much of Googles software is closed.
Re: (Score:1)
How is Google open? They are very public about things, beta this alpha that but much of Googles software is closed.
You must not read any of their comments about Android.
Re: (Score:2)
There is code verification
If there is code verification for it to succeed, you must only allows a subset of X86 to be run else you run into the halting problem. If you only allow a subset you don't get native speed, you get the speed that your subset of instructions allows.
multiple sandbox layers
not native speed as to sandbox you must create a vm like system.
a secure API
Prove it, because of the halting problem isomorphism. A hint: design your API starting from proven math using a formal notation and prove that your generated implementation is correct if the CPU is
Re: (Score:2)
If there is code verification for it to succeed, you must only allows a subset of X86 to be run else you run into the halting problem.
I don't think you understand the meaning of the term "code verification" in this context, or for that matter the term "halting problem."
not native speed as to sandbox you must create a vm like system.
Go read up [chromium.org] on how Native Client actually works. It's not like it's a secret.
Re: (Score:3)
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 livenes
Re: (Score:1)
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.
Without infinite memory, no real computer is Turing complete. It therefore can't run a Turing-complete language fully. And whereas an arbitrary problem has the halting problem. One running under another system can be halted externally. Even the operating system can be halted. All computers have an Off button (of some description).
Re: (Score:3)
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: (Score:2)
Re: (Score:2)
if the CPU is behaving according to it's specifications
Oops. I haven't seen one do that yet.
Re: (Score:2)
If you only allow a subset you don't get native speed, you get the speed that your subset of instructions allows.
The inner sandbox uses static analysis to detect security defects in untrusted x86 code. Previously, 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 identified during disassembly. With reliable disassembly
Re: (Score:2)
and note most compilers won't do this
most games scripting engines will
Re: (Score:2)
Use Javascript. You already have one of the fastest script JIT compilers right there in the browser, no need to include one with your game.
Re: (Score:2)
Well, last I checked, a full VM wasn't *that* much slower than "native", at least in part due to most modern CPUs having a virtualization extension. So if it's too slow, we just get some enterprising developer to take the source code, have it use a nice hardware-enforced solution, and get *plenty* of speed.
Re: (Score:2)
I was not arguing against that. I don't hate vm, in fact I like them but to claim that they don't have a cost is bullshit as is the native speed claim. You could, at best, call it: close to native speed in some applications, that goes for NaCL to.
Re: (Score:2, Insightful)
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: (Score:2, Interesting)
I'm sure there are other people who also have not made the tiniest effort to read up on the security mechanisms of NaCl, and think the same as you.
Re: (Score:2)
what fun are apps that can't talk to each other?
but with chrome os, you wouldn't need this, all the potential security stuff is right in the javascript apis, just get the user to agree for you to read his mail box and you'll know exactly how to do it and how to tell his phone to call to your pay-line - with easy api's.
but this NaCl will be used for two things, to gain execution speed and to make things harder to reverse engineer. oh and third, to port stuff, chrome os needs nes emulators too.
Re: (Score:2)
Depends on what "sandbox" means to them.
If the API has no provision for generalized system calls or other i/o, and only allows i/o to its interface, then it should be no problem.
Or at least no more of a problem than the giant pile of un-verified code you're using to read this message and the vast number of invisible bytes it may or may not contain between its lines.
Re: (Score:1)
Every time NaCl comes up someone says "But... but... ActiveX!!!". Perhaps next time you could preface your comment with "I no nothing about the subject matter, but...."
Re: (Score:3)
Re: (Score:2)
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?
The point of NaCl is that it's a virtual machine bytecode language, and you can statically verify (without running the code) that the bytecode conforms to the spec. However, for performance reasons, the bytecode language and the virtual machine architecture just happen to line up with the native machine code and native architecture. NaCl provides only a subset of the full instruction set, though, and this prevents arbitrary pointer arithmetic or self-modifying code that could break outside the sandbox. N
Re: (Score:2)
ActiveX has the worst reputation because it was a fundamentally insecure architecture that also happened to be poorly written. And despite being a default installation on a default browser of the default operating system for over a decade now, the only place I can think where it is actively in use is Microsoft's own websites.
Remember, ActiveX was attempting to compete with Flash and Java. At that it failed miserably.
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
"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?
"
I couldn't agree with you more. IE 5 and IE 6 are the staple of proper security and good coding practices. Nevermind it let any ActiveX applet run automatically with full administrator access by simply browsing a page. I am sure its those evil hackers just targeting what e
Proprietary (Score:1, Insightful)
How is using Pepper different than ActiveX with Internet Explorer?
If you use pure html 5 with WebGL or Canvas 3D (for IE 9 or IE 10) you can create 3D games using the hosts GPU. Chrome's 3D and hardware acceleration for html 5 does lag considerable behind Firefox and IE 9/10. I wonder if it is because they want you to use Pepper instead?
Either way their actions go agaisn't the spirit of HTML 5. You can do all of that properly in the latest versions of the browsers that is cross platform.
Re: (Score:1)
How is using Pepper different than ActiveX with Internet Explorer?
One word: sandbox [google.com].
Re: (Score:3, Insightful)
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.
Re: (Score:3)
How is using Pepper different than ActiveX with Internet Explorer?
In at least one significant way: The Native Client code is all open source, [chromium.org] like Chromium itself.
Re: (Score:1)
Com/DCOM in activex are highly documented with source code available over MSDN. Sure it is not GNU, but it is still proprietary when other open standards exist like HTML 5
Re: (Score:2)
Re: (Score:2)
I've had to use them at work and it doesn't work anywhere near as well as folks think. Granted it probably does work if you've got the server onsite, but really, you shouldn't have a server onsite without a backup. The problems we had were that the server was being run offsite, and consequently whenever the gateway would be down we wouldn't be able to do portions of our job. And even when it wasn't completely down it might be as slow as molasses, which again would hurt productivity.
Sure it's convenient and
Re: (Score:2)
or find out who's downloading all the porn.
LoB
Re: (Score:2)
You're correct. In this case it was the fact that the person managing that infrastructure wasn't qualified and the gateway was kept in a room without adequate cooling.
That being said, there's other reasons why this isn't a wise idea, some of which are related to what happens when infrastructure 3 states away is having issues. I remember times when that would cause slow downs and problems. Granted that shouldn't be an issue these days, but then again companies should pay to have these things done correctly.
A
Re: (Score:2)
This is actually the way its been in Corporate IT for quite a while. It's much easier to make a web app that gets update once on the server than to manage thousands of client updates, worry about security issues, etc.
And before that it was Lotus Notes, and before that it was mainframes and AS/400s, etc. It has always been easier (and arguably better) to run certain types of applications on servers, particularly when the application's purpose is to give an arbitrary number of employees access to the same information store. Where the model has yet to be proven, IMHO, is when the purpose of the application is to enable an individual to perform an individual task (e.g. a word processor or a graphics program).
It's a sign you're on the right path (Score:1)
It must be the right way, because all the old programmers who don't want to learn anything new hate it.
Re: (Score:1)
Even the browser (another name for 'program suite') runs on the server.. A real thin client is just a keyboard and a monitor
Re: (Score:2)
How is keeping the thin client updated any different from keeping any standard set of programs updated on the computer?
we do weekly updates to our web apps, i shudder to think how you'd roll that out to hundreds of computers, laptops and mobile devices when it takes us something like 10 minutes per application to push them to the production server.
Re: (Score:2)
How about thinking of it more in terms of marketing, developer and consumer acceptance. In creating games to suit a platform, a market ecosystem must be built up of developers and consumers. This can be more readily created with relatively simple games in a web environment using the Google's cloud and aligned ISP's to provide the processing power for consumer to access and play games on relatively low cost devices.
From that basis the gaming environment game of course expand, no different to the expansion
MS (Score:2)
I would love to hear the howling if it was microsoft introducing this sandboxed native client.
Re: (Score:1)
Salty Sand (Score:5, Funny)
In other words, a saltbox.
Re: (Score:1)
ya so it kills all the snails
Re: (Score:2)
NaCl...Pepper...get it?
They should've called the API "Lime," but maybe that's just me (and about 10,000 hot chicks in bikinis at spring break...)
Re: (Score:1)
Should have gone with SiO2
Re: (Score:2)
Except it uses HTML5 instead of running through another box full of rendering.
Could be much more interesting from an interactivity standpoint.
Yer Mom is a game client. (Score:1)
Actually this is kind of exciting for if it seriously takes off, that means one can do some gaming in a linux platform. Especially if it's a pay to play thingy which I would imagine that is where they are going with a browser based game. Or free to play but be plagued with ads, or its a pay to win situation. That means the whiny Mac people could play as well. Face it, games is what is keeping Windows around. At least in my opinion.
games is what is keeping Windows around (Score:2)
And legacy applications, and Excel macros.
And the rest of MS Office (Score:1)
And SQL Server, and Visual Studio, and a bzillion different vertical apps put out by ISVs.
You hinted at that with "legacy applications" but the fact is that very little of the installed base of Windows applications counts as "legacy." Most are being actively developed.
Re: (Score:1)
Actually this is kind of exciting for if it seriously takes off, that means one can do some gaming in a linux platform.
I've been playing games using only GNU/Linux for many years and the main problem was lack of time to try them all, especially since the Humble Indie Bundle. Let alone all those games for Android. I highly doubt that I somehow travelled in time and started using NaCl even before Chromium was released.
I agree it can result in more cross-platform games, though.
Re: (Score:1)
Kind of obvious. (Score:2)
For what else would you like a native client in a consumer product.
Sandboxed salt... (Score:2)
Some Googlers seem to appreciate wordplay :)
It's not about security, its about market share (Score:2)
Once Google gets this out - knowing competitors will not pick it up - and leverage it's massive weight by paying devs and advertising everywhere - we may actually get some decent games done for it.
But only Chrome will play them, the open standard is just a trick there, as, once again, no one else will implement it for a long while.
Once Chrome has captured market, Google has end-to-end web control, and that is a little bit scary.
I'm confused here (Score:2)
Re: (Score:1)
Re: (Score:2)
well, they can run for example run an emulator core in the c++ side, so you could get "in browser" psx emulators and stuff like that, or the ai core.
more likely, they'll implement opengl inside from that c++ and some sound apis too, like in android.
Re: (Score:2)
Re: (Score:2)
So what? (Score:1)
Who cares if they're making HTML 5 games when they're doing browser detection that blocks other HTML5 capable browsers instead of doing feature detection to tell if the browser supports all the features needed to run?
HW acceleration with GPU... (Score:2)
Why they forced a disable is beyond me, there is no way to re-enable it except by going back to Chrome 7 or something like that.
Re: (Score:2)
Re: (Score:2)