Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google Is Grooming Chrome As a Game Platform

timothy posted more than 2 years ago | from the ok-you'll-need-these-special-dice dept.

Chrome 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."

cancel ×

127 comments

The very sadness of it all (4, Funny)

Anonymous Coward | more than 2 years ago | (#37235896)

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 (1)

Cyko_01 (1092499) | more than 2 years ago | (#37236198)

he is alive, just not an editor for slashdot anymore

Re:The very sadness of it all (0)

Anonymous Coward | more than 2 years ago | (#37236246)

looks like you missed the funny

Re:The very sadness of it all (1)

eexaa (1252378) | more than 2 years ago | (#37236426)

he is alive, just not an editor for slashdot anymore

that makes a fate worse than death.

Re:The very sadness of it all (3, Funny)

Anonymous Coward | more than 2 years ago | (#37236962)

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

Boom (0)

Anonymous Coward | more than 2 years ago | (#37235914)

BOOM BOOM BOOM.

The browsers will start crashing in spectacular ways again :(

Re:Boom (0)

ThePhilips (752041) | more than 2 years ago | (#37235964)

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:Boom (1)

fuzzyfuzzyfungus (1223518) | more than 2 years ago | (#37236124)

Arguably, we Do Not need ActiveX all over again; but we do need an (actually competent) implementation of what things like ActiveX were trying to accomplish...

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 .exe that somebody offers them, which isn't exactly a triumph of security(particularly since prompting for elevated rights is standard behavior for installers...)

If you cannot protect somebody from something running in-browser, you don't actually solve the problem by not trying, you just shove it off onto the OS, which hasn't shown a brilliant track record of protecting people from the things they run, and offers less convenience in things like install/uninstall/update/synchronization...

Turning it on, without prompts, for all domains, by default, unless you are very, very certain is, of course, a terrible plan; but there is nothing fundamentally more hopeless about protecting people from browser plugins than protecting people from downloaded binaries, and history suggests that if they can't have what they want from the former, they'll enthusiastically click through whatever the latter asks them for...

Re:Boom (1)

ThePhilips (752041) | more than 2 years ago | (#37236248)

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 anything with extension .exe. Or any archive which contains an .exe file. Or anything what looks to Outlook even remotely suspicious.

But you are sort of suggested solution: this Google's effort should be concerted with the AV vendors. Or the effort would go either the way of ActiveX (permanently disabled) or the way of Outlook (let's be smarter than user, making software in the end even more useless than it was to begin with).

Re:Boom (1)

RobbieThe1st (1977364) | more than 2 years ago | (#37236766)

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! So long as the Pepper API and source code is available, I can't see any problem with it. It will basically put *all* OS's on the same footing, without quite so much in the way of hacks like Wine. ...And who wants to bet that this api uses OpenGL/webGL instead of DirectX, at least internally?

Re:Boom (1)

pspahn (1175617) | more than 2 years ago | (#37237218)

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.

A new generation making the same mistakes. (0)

Anonymous Coward | more than 2 years ago | (#37236162)

Each generation of programmers lasts about 10 years. During these 10 years, which are delimited by the periodic boom-and-bust cycle of the economy, the first 6 years will be spent making horrible mistakes. The next 2 years will be discovering (as we'll see, often actually rediscovering) the proper way, and the last 2 years will be trying frantically to implement the proper approaches and techniques. But after 10 years, the developers who have learned the correct way to do things will have retired, switched to a completely different industry, or moved high up enough in the management chain to a position where they have no direct influence over the technology development.

JavaScript and ActiveX were among the crowning mistakes of the last generation of developers (the "Web 1.0 generation").

Of the so-called "Web 2.0 generation", we're currently at the late stages of the initial 6-year phase. The worst mistakes are being made at this point, and their severity will soon be felt. The lessons will probably be relearned by 2014, and undoing this technology will probably be in effect by 2016. That'll be just in time for another batch of young developers to start the process all over again, recreating these very same problems.

Re:A new generation making the same mistakes. (1)

The Dawn Of Time (2115350) | more than 2 years ago | (#37236392)

You could have saved all the trouble of typing out the poorly reasoned tripe and just said "get off my lawn."

Re:A new generation making the same mistakes. (0)

Anonymous Coward | more than 2 years ago | (#37236588)

I don't think he's telling you to "get off his lawn". Maybe he just doesn't want you webniks to be making the same mistakes that previous generations have made?

Re:A new generation making the same mistakes. (0)

Anonymous Coward | more than 2 years ago | (#37237648)

Actually that post matches my experience quite well. I was a programmer for about ten years. The first six spent making horrible mistakes, the next two learning how to do things right, the last two trying to do things right. After that I couldn't do it anymore and left for greener pastures.

The very stupidity of it all (0, Insightful)

Anonymous Coward | more than 2 years ago | (#37235918)

Google wants to introduce x86 native code to the web at the time when ARM platforms are attracting all the buzz. This is a step backwards, akin to Flash or ActiveX.

Re:The very stupidity of it all (5, Informative)

Goaway (82658) | more than 2 years ago | (#37236100)

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:The very stupidity of it all (0)

Anonymous Coward | more than 2 years ago | (#37237654)

https://secure.wikimedia.org/wikipedia/en/wiki/Virtual_Processor

Been there seen it done it.

Chris

Re:The very stupidity of it all (0)

Anonymous Coward | more than 2 years ago | (#37237708)

Mod parent up _please_

Re:The very stupidity of it all (0)

Anonymous Coward | more than 2 years ago | (#37236104)

*cough* http://www.chromium.org/nativeclient/reference/arm-overview

Yes, there is one for ARM. It uses a different strategy to the NaCl for x86 (no segment registers -- mercifully -- on ARM). And, no, it's not ActiveX.

Re:The very stupidity of it all (0)

JonySuede (1908576) | more than 2 years ago | (#37236144)

worst than flash (flash running in a vm and vm are usually portable), equals to active X

Write once, run anywhere? (1)

Uncle Ira (586682) | more than 2 years ago | (#37235936)

So is Chrome Google's current attempt to finally cut Java out of their web application strategy?

Re:Write once, run anywhere? (1)

cgenman (325138) | more than 2 years ago | (#37238074)

HTML 5 and Javascript achieve that well. What native client gets you is SPEED.

Does anyone (3, Insightful)

phantomfive (622387) | more than 2 years ago | (#37235944)

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 (1)

obarthelemy (160321) | more than 2 years ago | (#37235966)

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:Does anyone (1)

fidget42 (538823) | more than 2 years ago | (#37236228)

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:Does anyone (1)

foniksonik (573572) | more than 2 years ago | (#37237208)

How is Google open? They are very public about things, beta this alpha that but much of Googles software is closed.

Re:Does anyone (1)

fidget42 (538823) | more than 2 years ago | (#37237902)

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:Does anyone (0)

Anonymous Coward | more than 2 years ago | (#37235996)

No. Native Client's security has been discussed ad nauseum and is many times more sophisticated than ActiveX's (which basically amounted to a yay/nay pop-up). There is code verification, multiple sandbox layers, and a secure API that exposes functionality to a NaCl app. In theory its as secure as running Javascript, but at native speeds.

Re:Does anyone (1)

JonySuede (1908576) | more than 2 years ago | (#37236134)

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 behaving according to it's specifications.

Re:Does anyone (1)

PCM2 (4486) | more than 2 years ago | (#37236188)

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:Does anyone (2)

JonySuede (1908576) | more than 2 years ago | (#37236282)

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 (0)

Anonymous Coward | more than 2 years ago | (#37236690)

I do not see the relevance of the halting problem in this discussion, it is just theory. When the end user presses Ctrl-C, the power cable is disconnected or the big crunch happens every process will halt.

  I do not know anything about NaC - but is the issue of the code verification not the interfaces rather than if the process will encounter the END command in finite time?

Re:Does anyone (1)

Anonymous Coward | more than 2 years ago | (#37236742)

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:Does anyone (0)

Anonymous Coward | more than 2 years ago | (#37236992)

Overlapping instructions are not used by modern compilers. Self-modifying code isn't done either except by the PE loader. Hits to NaCl performance will come from other differences, not in the two areas you cited.

Re:Does anyone (2)

JonySuede (1908576) | more than 2 years ago | (#37236540)

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 (1)

hairyfeet (841228) | more than 2 years ago | (#37238024)

What is sad to me is here we see a clear admission that Mono is easier to port, has less overhead, but because of religious zealotry it will NEVER be accepted because those that treat OSes like religions will go "ZOMG! It is by teh M$ it is teh evil! Burn teh witch ZOMG!" and thus it doesn't have a prayer. Meanwhile those of us on Windows will just use .NET and think their religion like the other kooky beliefs is just freaky.

As for TFA? I don't think it will work worth a shit for anything more complex than farmville, and here is why: There are only two ways to go really when it comes to security of third party code being run from the big bad web. One there is the Apple "Wall the living fuck out of it!" model, where you either give one company COMPLETE control to lock it down tighter than a nun's thighs or you're fucked, and the MSFT "Meh, we'll take care of it with a GPO" model, where you basically leave it open and let the users and the corps lock it down themselves. See ActiveX as to why that isn't the smartest of ideas.

The simple fact is gaming is the ONLY real popular thing that tries to get as close to bare metal as it can anymore and that is because of the big performance gains. If all you are doing is rendering a 2D farmville style game nobody gives a shit if you wrap it in a dozen VMs, as the machine will have more than enough juice to waste the extra overhead. But drawing even a game from 2k4 like Far Cry requires a hell of a lot of polygons AND physics AND AI AND 5.1 surround sound...you get the picture. A bunch of security crap placed to keep some .ru website from Goatse'ing your PC with the "free cool game yo!" means it will royally suck ass.

Part of the appeal of this wild and wooly web of ours is how free it is, how ANYBODY can set up a site and offer their games, like those indie packs. But if you have the games running inside the browser, away from the AV and OS security permissions? You either choose the Apple or the MSFT model, and both have serious issues. Personally I'd rather just download my games, scan them, and then choose whether i want it to run or not than give Google total control or have another ActiveX, thanks anyway Google.

BTW if anybody thinks Google isn't trying to become the MSFT of the mobile world? I have some nice swampland in AR you might be interested in. They WILL end up just as locked down as Apple (notice how they don't allow GPL V3?) and just as big an asshole as the Gates era MSFT, they will just have a catchy slogan, like "Think Different" or "Windows 7 was my idea!". Frankly I hope the guy that wrote the "Do no evil" marketing bullshit got a hell of a bonus, because it is fricking brilliant. I bet Jobs wishes he'd have known something so simple could work so powerfully. Made his RDF look like a bad joke really.

Re:Does anyone (1)

blair1q (305137) | more than 2 years ago | (#37236638)

if the CPU is behaving according to it's specifications

Oops. I haven't seen one do that yet.

Re:Does anyone (1)

Late Adopter (1492849) | more than 2 years ago | (#37236686)

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 as a tool, our validator can then insure that the executable includes only the subset of legal instructions, disallowing unsafe machine instructions. The inner sandbox further uses x86 segmented memory to constrain both data and instruction memory references. Leveraging existing hardware to implement these range checks greatly simplifies the runtime checks required to con- strain memory references, in turn reducing the performance impact of safety mechanisms.

As long as you weren't trying to write self-modifying code (and note most compilers won't do this), your performance impacts are basically restricted to checking non-local jumps. Not strictly native, but close enough.

not native speed as to sandbox you must create a vm like system.

That's provably untrue. See AppArmor and SE-Linux, both of which operate without creating a virtual machine (only implementing replacement system calls).

Re:Does anyone (1)

JonySuede (1908576) | more than 2 years ago | (#37236754)

and note most compilers won't do this

most games scripting engines will

Re:Does anyone (1)

icebraining (1313345) | more than 2 years ago | (#37236858)

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:Does anyone (0)

Anonymous Coward | more than 2 years ago | (#37237056)

Everything should _be_ in JavaScript. NaCl is for JS code which is unacceptably slow. Most modern development is already done this way today in conjunction with C/C++ interop.

Re:Does anyone (1)

RobbieThe1st (1977364) | more than 2 years ago | (#37236814)

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:Does anyone (1)

JonySuede (1908576) | more than 2 years ago | (#37236908)

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.

More things to fuck up. More places to be insecure (-1)

Anonymous Coward | more than 2 years ago | (#37236218)

All of those "features" are actually just creating a far greater attack surface. They open up the possibility of many more attack vectors, including some that the programming community doesn't yet have much experience with.

What you say may hold true in theory. In practice, this will likely be a massive disaster. It may far outrank other recent disasters, like the UI redesigns of GNOME 3 and the new release practices of Firefox.

Re:Does anyone (0)

Anonymous Coward | more than 2 years ago | (#37236094)

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.

Re:Does anyone (2, Insightful)

ninetyninebottles (2174630) | more than 2 years ago | (#37236864)

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 (1)

Nov8tr (2007392) | more than 2 years ago | (#37236098)

Yeah, 5000 Chinese hackers licking their lips and going ahhhhhhhhhh.

Re:Does anyone (1, Interesting)

Goaway (82658) | more than 2 years ago | (#37236116)

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:Does anyone (0)

Anonymous Coward | more than 2 years ago | (#37236334)

...and yet the only reason why 99% of the people on this planet still have ActiveX on their boxes is exactly due to this "anything goes" security policy.

Re:Does anyone (1)

blair1q (305137) | more than 2 years ago | (#37236628)

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:Does anyone (1)

Anonymous Coward | more than 2 years ago | (#37236720)

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:Does anyone (2)

juancn (596002) | more than 2 years ago | (#37236934)

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.

Re:Does anyone (1)

CTachyon (412849) | more than 2 years ago | (#37237996)

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. NaCl authors actually need to recompile their code to x86 NaCl or ARM NaCl as a distinct GCC compiler target, instead of plain old x86 or ARM, because the NaCl targets are easily distinguishable from the native ones when you examine the machine code bytes. (The most important feature: all jumps are aligned and no ops cross an alignment boundary, so there's only one possible machine code interpretation for each byte of NaCl code.)

Needless to say, this is a vastly different model compared to ActiveX, which was "we'll trust any old native code to make arbitrary system calls, just so long as there's an RSA signature attached". NaCl ditches the central trusted authority model that Microsoft preferred, and instead goes with the Java/JavaScript/Lua/LISP model of "you can only perform side effects that the interpreter chooses to expose to your code". As with the interpreted languages your NaCl code is Turing-complete, so you can waste CPU and RAM until the cows come home, but you can't actually touch the filesystem, create GUI elements, or modify the address space of other processes unless Chrome decides to permit it. The only difference is that you don't run at some fraction of native code speed, but exactly at native code speed, and you can statically optimize as much or as little as you like, or write in any language you want (so long as someone's written a NaCl target for your language's compiler).

There will probably be a few bugs in the static verification logic that allow not-quite-NaCl code to slip through, but this is no worse than the sandboxing problems we already face from Javascript in the browser. With JavaScript, this has even included double free bugs that allowed overwriting arbitrary memory with native code and executing it. The risks with NaCl are no different.

Re:Does anyone (1)

cgenman (325138) | more than 2 years ago | (#37238104)

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:Does anyone (1)

phantomfive (622387) | more than 2 years ago | (#37238138)

Rumor is that ActiveX caught on in Korea on very many websites. Not speaking Korean, I cannot personally verify this.

Proprietary (1, Insightful)

Billly Gates (198444) | more than 2 years ago | (#37235952)

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:Proprietary (1)

Seferino (837142) | more than 2 years ago | (#37235992)

How is using Pepper different than ActiveX with Internet Explorer?

One word: sandbox [google.com] .

Cats shit in sandboxes all the time. (-1)

Anonymous Coward | more than 2 years ago | (#37236278)

When you were a child, did you ever play in a sandbox? Did you ever have the experience of thinking you were playing with pristine sand, only to find out that you'd just touched a large nugget of buried cat shit? Did that ever happen to you? I suspect it didn't, because otherwise you'd know the truth about sandboxes.

They're 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.

While technology like this may sound like a good idea, we'll soon fine one piece of cat shit after another in this sandbox. This cat shit will often be in the form of undetected security flaws that are easily exploited. Also like the cat shit, these flaws won't be visible on the surface. You won't know how fucked you are until after you've been directly hit.

Re:Cats shit in sandboxes all the time. (3, Insightful)

ninetyninebottles (2174630) | more than 2 years ago | (#37236894)

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:Proprietary (2)

PCM2 (4486) | more than 2 years ago | (#37236152)

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:Proprietary (1)

Billly Gates (198444) | more than 2 years ago | (#37237542)

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

The "browser" is becoming the new thin client (0)

countertrolling (1585477) | more than 2 years ago | (#37235962)

.. all connected to the Great and Wonderful Google... pay no attention to the man behind the curtain

Re:The "browser" is becoming the new thin client (1)

papasui (567265) | more than 2 years ago | (#37236006)

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. The current place I work about 80% of the applications are web apps with a few ones yet to make the move (MS Office being the primary one, but even that might be changing with Microsoft's cloud pushes).

Re:The "browser" is becoming the new thin client (1)

hedwards (940851) | more than 2 years ago | (#37236096)

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 all, but we're hardly at the point where having a web server handling this sort of thing is wise.

Re:The "browser" is becoming the new thin client (1)

Locutus (9039) | more than 2 years ago | (#37236170)

hiring better network personnel might be a concept to consider. Or even a one-time consultant after getting bids and proposals from a few.

or find out who's downloading all the porn.

LoB

Re:The "browser" is becoming the new thin client (1)

hedwards (940851) | more than 2 years ago | (#37237154)

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.

And ultimately, mission critical infrastructure should only be off site as a backup or in cases where the users aren't all in one place. If you've got most of your employees in one or two buildings, then its' really not a great idea to have the infrastructure somewhere else completely without some means of caching or otherwise working when the machines are down.

Re:The "browser" is becoming the new thin client (1)

PCM2 (4486) | more than 2 years ago | (#37236242)

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).

Re:The "browser" is becoming the new thin client (0)

Anonymous Coward | more than 2 years ago | (#37236306)

"Sure it's convenient and all, but we're hardly at the point where having a web server handling this sort of thing is wise."

But... but.. but it's on the web! The WEB! With HTML *5* and and canvas! And XML! And using databases! And TMZ and GCI... or whatever those other buzzwords in my management manual were. So it MUST be the right way!

It's a sign you're on the right path (1)

The Dawn Of Time (2115350) | more than 2 years ago | (#37236430)

It must be the right way, because all the old programmers who don't want to learn anything new hate it.

Re:It's a sign you're on the right path (0)

Anonymous Coward | more than 2 years ago | (#37236612)

Old programmers have seen this shit before.

"Web apps" are a sad excuse for being incompetent in writing a real application. Even the name is shorter. Relying on javascript to do the work for you is a sign of incompetence, as is the constant magnatudes of security flaws that pop up in js engines / software. PHP is another sign of weakness.

People who program "web apps" are wasting millions of potentially useful man-hours. NaCl is a sorry joke, there's no way any seasoned programmer would take it seriously for more than a toy.

You can hedge your bets, but in the end - "web apps" are just another bubble that will pop.

Re:The "browser" is becoming the new thin client (0)

Anonymous Coward | more than 2 years ago | (#37236216)

How do you keep the thin clients updated then?

Will there be "thousands of client updates, worry about security issues, etc."? If not, how is it different?

How is keeping the thin client updated any different from keeping any standard set of programs updated on the computer?

The browser as a platform to do everything is a dumb idea. Sure, if you want the Internet to be a big television, go for it.

Re:The "browser" is becoming the new thin client (1)

countertrolling (1585477) | more than 2 years ago | (#37237278)

Even the browser (another name for 'program suite') runs on the server.. A real thin client is just a keyboard and a monitor

Re:The "browser" is becoming the new thin client (1)

rtb61 (674572) | more than 2 years ago | (#37236354)

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 of the PC gaming environment over the years of development, into more complex and demanding games and obviously more powerful gaming platforms.

Basically from the phone, to the tablet, to the smartbook and tad dah, the desktop (the desktop either being a more powerful notebook or an actual desktop, perhaps even an open console or more likely a big screen built in optional accessory). Google thrives in an open market and the more areas of the computer ecosystem that are open and available to it the more opportunities it currently has.

MS (1)

mingot (665080) | more than 2 years ago | (#37235978)

I would love to hear the howling if it was microsoft introducing this sandboxed native client.

Re:MS (1)

leoplan2 (2064520) | more than 2 years ago | (#37236008)

It wouldn't be open source, it would be Windows-only...

Re:MS (1)

danish94 (2427678) | more than 2 years ago | (#37236146)

It would be IE only.

Salty Sand (5, Funny)

FrankDrebin (238464) | more than 2 years ago | (#37235984)

sandboxed native client (NaCl)

In other words, a saltbox.

Re:Salty Sand (1)

Anonymous Coward | more than 2 years ago | (#37236026)

ya so it kills all the snails

Re:Salty Sand (1)

blair1q (305137) | more than 2 years ago | (#37236654)

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:Salty Sand (0)

Anonymous Coward | more than 2 years ago | (#37236850)

NaCL is salt you doofus. Sodium chloride. Pepper on the other hand is made out of brimstone and sins.

Re:Salty Sand (0)

Anonymous Coward | more than 2 years ago | (#37238146)

I believe blair1q WAS referring that the "Pepper API" be renamed to "Lime". Woosh

Re:Salty Sand (0)

Anonymous Coward | more than 2 years ago | (#37238124)

CH3COOH, a fork gone sour...

Shockwave (0)

Anonymous Coward | more than 2 years ago | (#37236204)

reminds me of Shockwave, but with sandboxing?

Re:Shockwave (1)

blair1q (305137) | more than 2 years ago | (#37236668)

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. (0)

lexsird (1208192) | more than 2 years ago | (#37236270)

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 (1)

sourcerror (1718066) | more than 2 years ago | (#37236340)

And legacy applications, and Excel macros.

And the rest of MS Office (1)

brokeninside (34168) | more than 2 years ago | (#37237416)

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:Yer Mom is a game client. (1)

Tuuresairon (865732) | more than 2 years ago | (#37237840)

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.

Security hole (0, Funny)

Anonymous Coward | more than 2 years ago | (#37236450)

system("format c");
That was all.

Re:Security hole (1)

Anonymous Coward | more than 2 years ago | (#37236918)

  1. 1) format.exe: Invalid drive specification.
  2. 2) format.exe: Access Denied as you do not have sufficient privileges. (Limited user access.)
  3. 3) system: The current directory is invalid. (Low integrity mode.)
  4. 4) nacl-gcc: 'system' was not declared in this scope (Not implemented by libc/msvcrt.)

Re:Security hole (0)

Anonymous Coward | more than 2 years ago | (#37237756)

system("format c");

$ format c
bash: format: command not found

Re:Security hole (0)

Anonymous Coward | more than 2 years ago | (#37237916)

system("format c");

$ format c

bash: format: command not found

Yes, it is working correctly. If there is a security hole, you can hear it being fixed (or if you have bad ears, just watch the HD LED). If there was no security hole found, you get the message from the quote.

Kind of obvious. (1)

drolli (522659) | more than 2 years ago | (#37236594)

For what else would you like a native client in a consumer product.

Sandboxed salt... (1)

tenco (773732) | more than 2 years ago | (#37236678)

... with integrated pepper?

Some Googlers seem to appreciate wordplay :)

It's not about security, its about market share (1)

kangsterizer (1698322) | more than 2 years ago | (#37237170)

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 (1)

ILongForDarkness (1134931) | more than 2 years ago | (#37237374)

What is the benefit other than porting native apps to run in a browser? The article linked to says that the Pepper interface is a binding layer that converts the native calls into stuff that can be done in HTML5. That's great but ... native apps will now be limited to the performance of the HTML5 engine unless I'm missing something. So yeah you can get platform independence as long as you are willing to have an interpreted layer between your code and the OS. Isn't that the same thing Java gives you? How about Windows game developers Direct X support etc? Are developers really going to just throw that away and redesign things to perform well on an interpreted HTML5 interface rather than port the program over to a web language entirely?

Re:I'm confused here (0)

Anonymous Coward | more than 2 years ago | (#37238056)

The benefit is that Google will further their desktop penetration. The less reasons you have to run anything outside of Chrome, the better for them. By running things in Chrome Google can better track behaviors, which is why Google exists: ad revenue (or big-government-watching-you for you conspiracy theorists.)

Surf the web? Just use Google's browser.

Mail? Just use Google Mail.

Office apps? Just use Google Apps.

Games? (Eventually) Just use Google's browser.

Once Eclipse runs in a browser (which is happening) and Photoshop then you won't need anything other than some lightweight Linux-based OS. They'll rule the world.

Re:I'm confused here (1)

ILongForDarkness (1134931) | more than 2 years ago | (#37238092)

You might be right. To me though gamers always want something more powerful, emulation/browser based isn't going to be it. For moderately good graphics there is already a huge number of things, silverlight, java, flash, etc. They really shouldn't be able to call it a native interface, yeah it is an interface from native but that is like saying "we can take your really optimized program and running in a crappy emulation layer, woo hoo.

Bocoup on HTML 5 game development (0)

Anonymous Coward | more than 2 years ago | (#37238132)

Bocoup has a good blog on HTML 5 game development [bocoup.com] for chrome, by the way.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...