Slashdot Mirror
Google Demonstrates Chrome Native Client With Bastion
Multiple readers sent word that Bastion, an action RPG from indie developer Supergiant Games originally made for Xbox Live Arcade, has shown up in the Chrome Web Store. The purpose of the move is to showcase the browser's Native Client technology. From the article:
"Ian Ellison-Taylor, Google's director of product management for the open Web platform, said that Native Client, also called NaCl, can currently improve browser performance by 1 to 10 times. 'What would it be like if we could run native code inside the browser,' he asked the crowd, and he enumerated two goals for the Native Client project. He said Google wants to bring native applications to the Web for performance and security reasons, and it wants to enrich the Web ecosystem by bringing popular, long-in-use programming languages to the Web."
This is so revolutionary. Now we can run native applications on our computers! Just imagine the possibilities! Oh, wait. We already can. And they aren't inhibited by some horrid browser-based sandbox.
can currently improve browser performance by 1 to 10 times
- this reminds me of the quote from the historical documents:
-Good Lord! That's over 5000 atmospheres of pressure!
-How many atmospheres can the ship withstand?
-Well, it was built for space travel, so anywhere between zero and one.
You can't handle the truth.
no u
How would that be more secure? I can only think of things that make it less secure. It is also Satan's anus poised over web standardization.
The Official Site of 1337 Pwnage
Improve performance ten-fold? I'll take that statement with a pinch of salt.
Like I really want anyone and their uncle to be running native code on my machine. We went to a sandbox model for a reason! If this is active now, how do we shut it off?
1. 2.
I tried Bastion this morning on my arguable beefy 8-core 8 GB machine. SLOW AS SNOT. So either it's slow or I need to change some configuration setting. Maybe I'm missing something, but wasn't doing this crap in the browser supposed to make it "just work" (tm)?
Mad Software: Rantings on Developing So
Personally, I am most entertained that the web client is called sodium chloride.
I am a little uneasy of making a web browser a proprietary platform. PcMag had an article about Chrome being the next IE 6 of the browser wars 2.0.
IE 6 was a great browser in 2001 regardless of its security shortcomings found years later. Everyone on slashdot back then admitted to using it but were scared and assumed the WWW would die soon because of it. Everyone seems to be oblivious that Google is another evil big corporation no different than Microsoft. Actually synergy is behind Google now, like it was with MS a decade ago.
Dart is chrome only, the javascript libraries are Chrome only or particulary run much better on Chrome (google ones like V8), this and many other proprietary HTML 5 code like that site with the band a few months ago that only work in Chrome. This game will use HTML 5 but has other proprietary hooks to make sure it wont run in any browser.
Google is making it clear they look at the browser as an operating system. At least Microsoft today is running away from ActiveX and trying to do good with IE 10 which will be the most open and standards compliant browser to date. Firefox is dying and is losing popularity. In a year or two from now it will be a IE vs Chrome world.
Anyone else bugged or am I just paranoid? I just want a great browser and not a simple fast one, but with the real goodies underneath it that are dependent on Chrome.
http://saveie6.com/
What would it be like if we could run native code inside the browser?
The massive swamp of security vulnerabilities that was ActiveX?
Hey... I have some great proprietary technology that can increase the performance of any program by at least 1 times. Please send $1 to Happy Dude, at 742 Evergreen Terrace...
Can someone describe the differences between NaCl (Salt?) and ActiveX? They both seem to be methods to run native code inside a browser sandbox. What are the ways Google's offering is superior? Is it better at all than the current implementation of ActiveX? I like Google, but this particular initiative seems kind of backwards thinking.
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
Why do you insist that sandboxes are the only solution to security problems?
So how exactly do you propose to run native code securely without some kind of sandbox?
Why do you get so excited about a technique that's actually quite ancient?
Because we're making fun of mainstream PC operating system developers who can't figure out application sandboxing by themselves.
NaCl defines a subset of x86 instructions that are verifiably type-safe, just as .NET IL and JVM bytecode are verifiably type-safe. The browser verifies the binary before executing it.
I agree completely that Firefox is currently on its way out. Mozilla has made one fucking mistake after another with Firefox lately, and it is indeed killing it faster than I had even originally anticipated. But Firefox doesn't have to die. Mozilla could quickly reverse the flood of users away from it very simply.
Here's what they need to do:
1) Give the "designers" the boot. Applications "designed" by failed web "designers" are fucking unusable, like recent Firefox releases have been. These people are fucking clueless.
2) Undo every stupid decision made starting with Firefox 4. That means put the menus back, put the status bar back, put the protocol back in the URL bar, and quit trying to put so many fucking rounded corners and fucking gradients all over the place.
3) Fix the fucking performance problems and memory leaks. We've told them about these problems for years now. They're damn easy to reproduce. All you need to do is download Firefox, install it, and use it for 10 minutes. The poor performance will be obvious, and the memory usage will be shitty. Since it's so easy to reproduce these problems, Mozilla should have no problem fixing them.
4) Stop the stupid release schedule. Release a few times a year, and make sure these releases are solid. And for crying out loud, stop breaking add-ons with each release!
Through those simple steps, Mozilla will be able to save Firefox. If they don't to this, however, Firefox will indeed be a mere footnote in the history of web browsers.
For crying out loud, what is it with you wheel freaks? Why do you insist that wheels are the only solution to transportation problems? Why do you get so excited about a technique that's actually quite ancient?
Fuck, I first remember using wheels back in the 1970s on some Ford pintos, and it probably wasn't even a new technique then. All through the 1980s, 1990s and 2000s it became a pretty common feature of most land yachts. Hell, even Chrysler and GM have excellent wheel rotating support, and have had it for a long time. That's not even considering Hyundai, Kia, and the other existing and well-established platforms that have wheels! These days we've also got Saab, BMW and many other systems we can run on roads.
Look, wheel rotation is one transportation technique among many. If getting rid of wheels causes you that much of a problem, THEN YOU'RE DOING TRANSPORTATION REALLY FUCKING WRONG!
FTFY
Run native code WITHOUT the browser. Revolutionary idea, I know. You could pass on all the frameworks required to shoe-horn procedural programming onto a stateless protocol, give HTML and XML markup a miss, not write any javascript, and... just... write an application. And maybe it won't need 34MB to run in, and maybe it'll actually be instantly responsive. Maybe... just maybe... that's what you really need to do.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
For someone who 'remembers' the 1970s you are really clued out about security basics.
Your Shitty Car Analogy is quite shitty, even for a Shitty Car Analogy. In fact, you actually proved the GP's point in your perverse attempt to ridicule it.
You're totally missing the fact that wheels are basically the only thing that'll allow most cars today to move. You take the wheels off, and your car isn't going anywhere. That's exactly the problem that the GP is describing with these sandboxing afficionados. They think of sandboxing as their only option, and thus it's the only option they employ. You take it away, and they're shit out of luck.
Sensible people, on the other hand, see sandboxing as just one more tool in the toolbox. It's not the only approach they use to ensure the security of their systems, so taking it away causes little to no harm. They have employed multiple other techniques to help ensure the security and the safety of their systems.
You're only able to use a set of formally verified "safe" instructions. I'm no expert on this, so look here for more detail on the way it works, from people trying to break it.
Pepper is the plug-in API that NaCl modules use to communicate with browser-managed resource, JS, etc.
That is in itself a form of sandboxing no?
... rubbing salt in Adobe's wound.
Native Client is like a plugin that makes all other plugins obsolete.
-It can do everything you can do with Flash, Unity, Silverlight, etc.
-You can use any language to develop for it, C, C++, ObjC, Python, C#, you name it.
-Can access everything JS can (using the Pepper plugin API).
-It's from a trusted vendor (Google), so most people will not be afraid to install it.
-Will come pre-installed in the soon to be most popular web browser.
-It's open source
-It's much more secure than existing plugins due to sandboxing.
And, yes, I can understand HTML5 purists, but the truth is that:
1) Not everything can be made into a web application using HTML5+JS.
2) There's way too much code and applications written in other languages..
3) Cross-Platform web deployment is very attractive. Compile for x86 and ARM and 99.999% of the devices on the planet can be supported.
So, disable it if you don't want it, but this is a very attractive idea with a lot of potential for us developers, and even Adobe is trying somehting similar with Alchemy on Flash. It's a much more realistic way to bring actual real applications to the web than the dream that HTML5+JavaScript is.
Java tops for hackers, warns Microsoft:
http://www.theregister.co.uk/2011/12/02/microsoft_java_vulnerabilities/
&
Java Apps Have the Most Flaws, Cobol the Least:
http://developers.slashdot.org/story/11/12/09/1533252/java-apps-have-the-most-flaws-cobol-the-least
---
* Some "Food 4 Thought" in regards to your statement requoted here next:
"Early on there were some JVM bugs that allowed malicious apps to break out of the sandbox, but those have been fixed, and sandboxed Java code is sandboxed very effectively." - by swillden (191260) on Friday December 09, @07:00PM (#38321060) Homepage
Then how come the above's happening & EXTREMELY recently?
APK
P.S.=> I program in JAVA myself, but realize it's fallen short of its initial promises on safety/security...
... apk
If this was microsoft this comment would have been marked +5 "insightful". google shills have really taken over.
Sandboxes aren't the only solution, and only a fool employs only one layer of security alone, trusting that the sandbox in and of itself will stop any possible attack. In the same way, however, sandboxing is a great tool that does block of lot of more obvious problems, and throwing it away unnecessarily would be just as foolish. The article is about a native client that doesn't use sandboxing; they've removed a layer of defense and reduced the number of techniques being used to ensure the security and safety of their systems. The tradeoff is for speed on some calculations, particularly video rendering: games. Sacrificing a layer of security for games. That might be okay for home users who want to play the latest in-browser version of Zeus-Kelihos' Fantabulous Iranian FarmVille 3D: Sino-Russian Winter Edition on their own machines, but it's got to rub corporate IT the wrong way.
One plugin to rule them all, one plugin to find them,
One plugin to bring them all and in the "sandbox" hack them.
Democracy Now! - uncensored, anti-establishment news
It is quite surprising that, up until now, no one has thought of using a bytecode solution, that guarrantees portability and performance.
We have gone from the one extreme, i.e. an interpreted dynamic language, to the other extreme, i.e. native code. There is a sweet spot in between, that of bytecode, that offers portability and good performance on par with native code, and also better security than native code.
Sensible people, on the other hand, see sandboxing as just one more tool in the toolbox.
So please enlighten us. How do you run untrusted code on your machine without some kind of sandbox?
Unfortunately I get the message "requires an OpenGL card" on Windows XP SP3 with an NVidia GTX260, which definitely has working OpenGL. I've seen reports of this problem on MacOS too.
Hope Supergiant Games can fix this - since this is a web-delivered application, I'd hope they can grab hardware/OS details, with user permission, to help in resolving the issue.
Think of how most developers are using Javascript nowadays: it's a target language for their compilers.
Whether the source was Java (GWT compiler) or Javascript itself (YUI compressor, Google closure compiler) the fact remains that what browsers are given to run is not what the developers wrote. Which is standard practice in the software business (it's called compilation) and for good reasons.
Now, JS makes for a poor machine language. So we could either beat around the bush with an intermediate bytecode language (Java went there, and Python and all the others too, with varying results) or go for the real thing and come up with a good x86 sandboxing and code verification standard.
Remember, x86 is currently in use by 99% of desktop machines. When other architectures will gain momentum, websites will just offer two or more compiled versions of their code. In the mean time, they will just have to emulate or translate the x86 instruction set, a task for which a large open source code base has already been developed, and which would still be more efficient than parsing plain Javascript, by several orders of magnitude.
So what's the problem with that, again?
He said Google wants to bring native applications to the Web for performance and security reasons,
Perhaps it's just me and the security advantages of running native code instead of JS or anything on the JVM are immediately obvious to everyone else, but this sounds like Google is somewhat out of touch nowdays and lets marketing people "sell" the technology decisions to geeks...
"I love my job, but I hate talking to people like you" (Freddie Mercury)
I own Bastion already on Steam. It works perfectly fine. I thought I'd give the Chrome demo a shot. Nothing but a black screen in-game. Don't waste your time for now.
'What would it be like if we could run native code inside the browser..."
This sounds awesome. Maybe I will finally be able to run a browser inside my browser.
"Umm, yeah, like there's no bias there. Find me a reputable source for those statements." - by swillden (191260) on Saturday December 10, @10:09AM (#38325754) Homepage
Security study of FireFox -> http://news.slashdot.org/story/11/12/10/1349212/google-funded-study-knocks-firefox-security except that MS' study uses a program to perform its checks... rather than just make statements.
PLUS: The test was done by a PROGRAM testing for flaws, & whatever results it put out, should be laid to blame as the "biased" tool, not Microsoft (who are pretty reputable after all, being one of the largest software oem's in existence).
---
"Complete red herring. That article isn't about security flaws in the JVM, it's about programmer errors in apps written in Java. It's also a really, really poorly done study." - by swillden (191260) on Saturday December 10, @10:09AM (#38325754) Homepage
You missed this portion of that article regarding the JVM itself, here's the "pertinent quote":
---
"The JRE contained some of the most common exploits, he said. Vulnerabilities in the Java Virtual Machine (JVM) and Java Development Kit (JDK) for Java SE were also popular targets. Between a third to a half of all exploits detected by Microsoft's anti-malware were Java exploits."
---
Also - Does it MATTER where the flaws come from?
Flaws are flaws, be they in SUN Java's VM, or in the code written that is interepreted by the Virtual Machine...
THUS, it wouldn't matter WHERE THE ERRORS COME FROM, they cause hassles for END USERS... period!
---
"Nope. Try again. But see if you can find something *real* this time (you can't)." - by swillden (191260) on Saturday December 10, @10:09AM (#38325754) Homepage
This is as "real" as it gets (though I prefer posting real-world practice findings as I did above & in my initial post you replied to) -> http://secunia.com/advisories/product/12878/ & you can check NISTS' National Vulnerabilities Database for the same type of information if you wish...
APK
P.S.=> I posted the last link, since it seems you're more of a "statistics man" apparently, & because you wish "unbiased sources"...
So, the last link above is exactly that (SECUNIA's db for unpatched security vulnerabilities & specifically for JAVA)...
... apk
You missed this portion of that article regarding the JVM itself, here's the "pertinent quote":
---
"The JRE contained some of the most common exploits, he said. Vulnerabilities in the Java Virtual Machine (JVM) and Java Development Kit (JDK) for Java SE were also popular targets. Between a third to a half of all exploits detected by Microsoft's anti-malware were Java exploits." from http://www.theregister.co.uk/2011/12/02/microsoft_java_vulnerabilities/
---
The article says it all for me, vs. your stating this earlier here in this exchange:
"That article isn't about security flaws in the JVM" - by swillden (191260) on Saturday December 10, @10:09AM (#38325754) Homepage Journal FROM -> http://games.slashdot.org/comments.pl?sid=2567136&cid=38325754
So much for THAT, eh? I say that, because what's JUST ABOVE IT IN MY REPLY HERE, direct from the article, just puts your words back in your mouth
APK
P.S.=> Sandboxes get broken, even Java's before -> http://developers.slashdot.org/story/04/11/24/1323228/Cross-Platform-Java-Sandbox-Exploit
( ... & yes, the Java VM (& other portions around it) have unpatched security vulnerabilities, even the latest models, per my sources on that also)
... apk
Sensible people, on the other hand, see sandboxing as just one more tool in the toolbox.
So please enlighten us. How do you run untrusted code on your machine without some kind of sandbox?
Root someone else's machine and run it there.
Like Tolkien wrote years ago: Ash NaCl durbatulûk, ash NaCl gimbatul, Ash NaCl thrakatulûk agh burzum-ishi krimpatulgoogle.
They are really strong technological strength,Envy ah!cheap ugg boots