Google Chrome 31 Is Out: Web Payments, Portable Native Client 123
An anonymous reader writes "Google today released Chrome version 31 for Windows, Mac, and Linux. The new version includes support for Web payments, Portable Native Client, and 25 security fixes. 'Under the hood, PNaCl works by compiling native C and C++ code to an intermediate representation, rather than architecture-specific representations as in Native Client. The LLVM-style bytecode is wrapped into a portable executable, which can be hosted on a web server like any other website asset. When the site is accessed, Chrome fetches and translates the portable executable into an architecture-specific machine code optimized directly for the underlying device. This translation approach means developers don’t need to recompile their applications multiple times to run across x86, ARM or MIPS devices.' You can update to the latest release now using the browser's built-in silent updater, or download it directly from google.com/chrome."
Write Once, Exploit Everywhere (Score:1)
Java for the 21st century. And you thought applets were dead...
Re: (Score:2)
There's no virtual machine executing the code here, just some vmish technologies compiling it.
So it's more like ActiveX!
When will chrome support 64 bit java? (Score:2)
Very annoying that chrome wont support 64 bit java. If you make 64 bit java the default on your computer, because say you want to run minecraft's latest server, then you can't run java in chrome cause it won't work and it uses the default path installed java.
Re: (Score:2)
This and the ctrl+f window disappearing upon navigation are why I still use firefox. Otherwise chrome is nice due to how fast it renders pages like the guides on lolking.net compared to firefox.
Re: (Score:2)
Or, on some platforms where 32-bit Java is no longer an option (Mac OS X), Chrome is useless for any site implementing Java.
You get a nice message saying that you need to download something that doesn't exist.
Security? (Score:2, Interesting)
How they maintain security with C and C++ applets?
-- hendrik
Re: (Score:2, Funny)
With security fixes of course: "Tuesday December 24, 2013 ... Google Chrome 214 is Out: this update includes 14 security fixes in the Portable Native Client which should plug all the security holes. Yes we know we said the same thing in the last 5 updates yesterday, the day before, and last week, but this time we've fixed all the, ahem, known security flaws. Promise."
Re:Security? (Score:5, Informative)
Same way they do as JS. They control what APIs it can call.
C code without any APIs can't exploit a potato. It isn't inherently able to talk to the kernel.
Re: (Score:3, Insightful)
Same way they do as JS.
That's not particularly reassuring.
Re: (Score:2, Informative)
And by "again and again" you mean "twice over the 7 years this contest is held".
Re: (Score:3)
Re: (Score:1)
Re: (Score:2)
Same way they do as JS.
That's not particularly reassuring.
Well, since the bytecode they are presumably using is much simpler than the mess javascript is, it should actually be easier to make it secure.
Re: (Score:2)
To be fair, it is very difficult to exploit a potato.
Re: Potato exploit (Score:5, Funny)
One day, hear knock on door.
Man ask "Who is?"
"Is potato man, I come around to give free potato"
Man is very excite and opens door.
Is not potato man, is secret police.
Re: (Score:3)
You haven't met a Russian then.....
Re: (Score:1)
Wrong.
((void(*)(void))"\012\123\234\345...")();
Re: (Score:2)
Is that a challenge?
Re: (Score:1)
C code without any APIs can't exploit a potato. It isn't inherently able to talk to the kernel.
How does not being able to make french fries relate to not being able to make popcorn? And how does this make the code safer? (Even if you thought it was cheesy it is still funny.)
Re: (Score:2)
As long as you have pointers and an idea where the return address of your function is stored, you can jump wherever you want.
Jumping wherever you want inside a sandboxed process is like walking into whatever corner of your prison cell you want to go to. I.e., not very useful.
Re: (Score:1)
Security? Hell, this seems it was designed by the NSA.
Re: (Score:3)
https://developers.google.com/native-client/dev/overview#security [google.com]
The only interaction between this process and the outside world is through sanctioned browser interfaces.
Re:Security? (Score:5, Informative)
How they maintain security with C and C++ applets?
-- hendrik
NaCl (in its standard, non-Portable flavor) is essentially a bytecode that happens to be directly executable as machine code (either x86-64 or ARM). The bytecode can be statically verified to mathematically prove that the instructions obey certain rules (e.g. exactly one interpretation for any bytecode, execution only leaves the verified bytecode by calling trusted functions, can only read/write memory in the sandbox, cannot write to bytecode, etc.). As I understand it, PNaCl is similar to classic x86/ARM NaCl but trades fake bytecode for real bytecode (LLVM's intermediate representation, last I heard) and statically compiles it to native machine code after the bytecode verification step. Basically, in this scheme the verified C code can run at near-native speed, but it can only communicate with the world outside the sandbox by calling trusted functions that the enclosing app chooses to expose.
Theoretically, Java ought to be just as strongly sandboxed as NaCl: Java code in a JVM sandbox can only call trusted functions that the JVM chooses to expose, too. But in practice the Java standard library exposes a ridiculously broad attack surface, giving sandboxed apps plenty of chances to exploit bugs and escape the sandbox. (For instance, java.lang.String is a final class today because folks discovered that you could subclass it to make it mutable, pass a sandbox-approved value to e.g. a file I/O function, then modify the value to a sandbox-forbidden value after the security check but before the OS system call.) Basically, Java's attack surface is broad and leaky because Java was designed for running embedded devices and servers, not for sandboxed applets downloaded from hostile sites on the Internet. Applets were a distant afterthought compared to Java's "let's write an OS for set-top cable boxes" origin.
In contrast with Java, Chrome's implementation of [P]NaCl only exposes the Pepper API, and the Pepper API was designed from the ground up to be called by sandboxed code fetched from a malicious website. Looking at the Pepper C API site [google.com], the attack surface seems... bigger... than I would have expected. But most of the functionality I see there is also exposed to JavaScript, where the code is every bit as hostile. Almost any "attack surface, WTF" argument would also argue against JavaScript and all modern web design. And if they're smart, one API is hopefully built on top of the other (plus a thunk layer made of machine-generated code), so that there's only one pool of security bugs to fix.
Summarized (Score:2)
Basically you are saying this:
NaCl tries to do the same as java, but with marginally less attack surface and a static compile. The marginally less attack surface is considered "safe" because JavaScript has the same surface and we all trust that.
This seems to me as Google's attempt to kill java. NodeJS is already gaining popularity on the server side and once the version of V7 that is in NodeJS will be able to do NaCL, it will be able to replace it both on the server and the client side. Even though I agre
Re: (Score:1)
Google doesn't use nor do they care about NodeJS, and nobody with a brain uses Java applets for anything. These actions have little to do with Java or NodeJS and everything to do with providing a lightweight language agnostic platform for rich web applications that can compete with native apps (especially those on iOS). Read the leaked internal Dart/Dash memo for more insight into what they're after.
Re: (Score:2)
... the attack surface seems... bigger... than I would have expected. But most of the functionality I see there is also exposed to JavaScript, where the code is every bit as hostile. Almost any "attack surface, WTF" argument would also argue against JavaScript and all modern web design.
yeah, and look at the marvels that "modern web design" has brought us: static websites that have a shitload of stuff running in the background doing God-knows-what.
using HTML/CSS only is enough for any read-only web page. using hover and the checkbox hack, [dabblet.com] you can make all the user interaction you need. the only thing i would add is dynamic content requests and for interactive editing, hooking content to textboxes with regex or some other translating syntax. the most devious thing you could do is infinite
Re: (Score:2)
Indeed, it looks quite safe compared to JS.
The only disadvantage of NaCl code is that it only runs on one brand of browser. Sigh.
Re: (Score:2)
NaCl (in its standard, non-Portable flavor)
You mean before it's ground up and put into little shakers?
Why? (Score:1)
The browser is not the place to run "native" applications.
I understand the desire by websites not to force a shift in focus,
but for the sake of security, we shouldn't be allowing the browser such low level access.
Re: (Score:3, Insightful)
It's a fallacy to think that 'native' equates to insecure.
Re: (Score:2)
Perhaps 'vulnerable' is more your taste? Ask a native American about their insecure imigration policy.
Re: Why? (Score:2)
For the sake of security then we shouldn't be allowing the browser to run any remotely fetched code, whether it is high level or low level is irrelevant. Fundamentally it is a form of remote code execution fire both JavaScript and c/c++. If you are going to allow it, the chrome team has come up with a good method to make it as secure as possible running all such code in a managed sandbox environment with extremely limited APIs.
Re: (Score:2)
If you are going to allow it, the chrome team has come up with a good method to make it as secure as possible running all such code in a managed sandbox environment with extremely limited APIs.
You've just described what the NaCl project has been about all along! They already have this "managed sandbox environment with extremely limited APIs" that you're talking about. What PNaCl adds is plaform-independent "binaries" for long-term compatibility (well, the files *are* binary, but in a subset of LLVM bitcode).
Re: (Score:2)
Good news everyone! Chrome isn't just a browser. It's an OS.
Re: (Score:2)
Browsers have been slowly becoming self-contained OSs for a decade now.
Re: (Score:2)
Dumb terminals evolved into "smart" PCs as networking evolved from mainframe computing to powerfull clients.
The the Web shifted things back to server side computing with the browsers as dumb terminals. Now those formerly dumb terminals become smarter and do more of the workload client-sided. I can see a pattern here.
The next step that already started in paraless is moving the servers to become clients on a SaaS platform as GoogleAppEngine or Amazon AWS.
Re: (Score:3)
Dumb terminals evolved into "smart" PCs as networking evolved from mainframe computing to powerfull clients.
No they didn't, that's utter bullshit, young man. PCs started out as hobbyist affairs, with the Altair, which was an IC version of the early tube computers. Like mainframes, they were improved on and by the late 1970s there were stand-alone "microcomputers" like Osbourne and Apple and Commodore. VisiCalc brought these hobbyist machines into the office. IBM brought out its toy (their term), the IBM-PC.
Re: (Score:2)
What? (Score:4, Informative)
"Chrome fetches and translates the portable executable into an architecture-specific machine code optimized directly for the underlying device. This translation approach means developers donâ(TM)t need to recompile their applications multiple times to run across x86, ARM or MIPS devices.'
Ummmm... sounds like Java?
Re: (Score:2)
It's using LLVM, so yes.
Re: (Score:1)
Re: (Score:2)
I honestly don't know who NaCl is for, or what problem it's trying to solve that can't be addressed with asm.js
NaCl stands for native client. i.e. you download software compiled for x86 or ARM instructions and run it in your browser at native speeds. It is sandboxed and limited to what it can do within its sandbox. But having to recompile the same code for each architecture is obviously a pain, so PNaCl allows devs to compile once to LLVM and run anywhere.
Asm.js is an important thing to pursue but it fundamentally a hack. Tools like Emscripten compiled code to LLVM (like PNaCl), and then emit equivalent JS. Then
Re: (Score:1)
More like CLR.
Java is a stack virtual machine, this has horrible implications for translation performance. PNaCl (LLVM) and CLR (.net) use named storage bytecode (in the case of LLVM, single static assignment), which trivialises register allocation and doesn't impose the burden that JVM does of having to unwind stack operands to attempt to assign them to registers, which is slow and often results in inefficient translated code, and makes instruction reordering to suit different architectures pipelines diffi
Re: (Score:2)
Nothing you just posted said anything at all about why or if NaCL running on LLVM should be considered more secure than Java running on a JVM. The reason so many people have been against Java in the browser has a lot more to do with constant security issues than performance. This NaCL system seems like it would be a ripe target for exploits.
Re: (Score:2)
Except that the JVM isn't really a stack machine. It looks like one, but the verification requirements in the JVM mean that each stack operation can be analyzed statically and replaced with a register operation. That's why Android is able to translate most JVM class files (at least those generated from Java sources) into its Dalvik VM.
JVM JIT compilers do the same analysis, so there's practically never a need for an actual instruction stack. It's all register-colored and optimized before it's translated int
That sounds familiar. (Score:2, Funny)
That approach sounds familiar. What's to stop this being Just Another Vulnerability Apparatus?
Re: (Score:2)
PNaCl (Score:3)
FeCsSO3 (Score:2)
Seems like Ferro-Cesium Sulfate is more appropriate
What about FeCsSO3 makes it better?
Re: (Score:2)
Re:ActiveX was such a good idea after all.... (Score:5, Informative)
Re: (Score:2)
I do. The browser should not be scriptable, period. Whatever dynamic generation is needed should be done on the server. If you want an interactive application, build executables for the target. Fuck SaaS.
Re: (Score:2)
yeah, 'cos having everyone download a native application just to provide a decent type-ahead drop-down would improve security on the web a ton.
no, you'd need some way to sign the code to ensure that what you downloaded was what you expected. you'd need some kind of sandboxing to ensure that the native code didn't steal all your secrets. you'd need some kind of UI/communications framework that worked well on every operating system, so companies didn't have to develop 5 different versions of their application
Re: (Score:2)
You should probably stop posting on the interactive application known as Slashdot then.
Re: (Score:1)
The big problem with ActiveX was the installation policy was way too loose. IE3 would automatically download and run any ActiveX which was signed, which practically meant everyone who could afford a $100 certificate. Later versions tried to hide that behind more and more OK/Cancel dialogs, because that's what passes for browser security.
The other big problem was that COM is way too general of a mechanism because it's used by nearly every other Windows application. So if you have any random program which ins
Re: (Score:2)
The reason ActiveX got the heat was that authors were meant to self-declared controls as safe for scripting, and IE honoured that declaration. If I had installed BadlyWritenControl then any website could instantiate it and exploit i
Re: (Score:2)
The other major weakness of ActiveX was that it used pre-compiled native binaries. At least if you use an intermediate bytecode you can sanitize it when translating it to native x86/ARM. You can enforce certain standards too, like stack checking.
Even when running with low permissions there is a danger that an exploit could elevate to a higher level, and having intermediate bytecode makes that much more difficult.
Re: (Score:1)
ActiveX was such a good idea after all....
This is the opposite of ActiveX.
ActiveX allowed trusted code (native code with local binary privileges) to be created and controlled from untrusted source (a web page served from anywhere).
NativeClient runs untrusted code from untrusted sources, with the privileges of untrusted content. Untrusted code never controls a component that is trusted.
The javascript in this page has the same privileges as a native client program.
Re: (Score:2)
Why would that have anything to do with this native client thing? Active X were a bunch of DLLs that would only run on windows/X86 and the standard was such that only IE would be able to run the applications. I don't see a bytecode, VM or architecture independence happening with ActiveX, while those are the main characteristics of NaCL. The only thing in common here is the ability to run code on the client. I don't really see ActiveX being "such a good idea" compared to NaCL, regardless of who made it.
I se
It has come to this... (Score:3, Interesting)
Sadly browser wars turned into the race to rebuild AOL. Why so much bloat? Browser should do one, and only one thing well - render web pages. Native client? Web Payments? Why not throw in TurboTax, because more the merrier, right?
Re: (Score:2)
> Yeah, god forbid an idea can grow and change over time. By this same logic phones should do one thing, and one thing well - send and receive phone calls. MMS? email? internet? Bah! thats not what the first version of it was meant to do!
Sounds good to me.
Re: (Score:2)
Back in my day we had Gopher and we liked it that way.
Damn kids, get off my lawn!
Re: (Score:2)
Yes, a smartphone is a hack-job idea, but it did take off because not-the-phone part of a smartphone was in demand. People want portable computing-entertainment device with an internet connection. It happens that that functionality got strapped to a phone, because phone already had "portable technology" aspect solidified in people's minds. It could have easily been a smartcalculator or smartcar-keys and it would have been used in exactly same way as a smartphone. Too bad for people that still want a cellpho
Re: (Score:2)
I think this is more strategic. They want to replace the traditional app model with web sites or at least web-based SaaS applications.
The existing web technologies (html, js, css, etc) are awful for non trivial apps, so this nacl stuff lets you build real apps within the web SaaS model.
The Web is no longer about pages (Score:3)
World Wide Web is no longer about seeing pages to present you with information. It's about running applications to give you functionality. This effectively turned the web browser into a not-so-thin application client.
I believe this whole thing happened because Microsoft had control of what gets installed on desktop for a long while, and the only application-client technology installed on al
ANOTHER Notifications tool (Score:1)
The browser recommended by Section 31. (Score:1)
n/t
Re:Keep pushing your tech on us, Google (Score:4, Insightful)
I don't get this "Google's software isn't really open because they control the direction it goes in" bullshit. I'm not sure if it's stupid people or paid Microsoft plants.
If they're paying for the development they get to choose what goes in the their codebase. They release the source under an open source license, so be happy and shut the fuck up or fork it and try to out do them (which we all know you will fail at).
Fuck you.
Re: (Score:1)
Even if the GP was a bit harsh, I don't understand why you think its wrong to be suspicious of Google's motives? What happening is fairly obvious. They want to become a platform like Windows/Linux/OSX and establish control. Chrome (the browser) + NaCl is the trojan horse to accomplish this. I personally would definitely *NOT* want a future with a SaaS model where running applications on my machine would necessitate internet access to Googles servers.
Your 'if you don't like it, fork it' attitude is misplace
Viability (Score:4, Interesting)
There is a small group of people that see a problem in this and I personally think their arguments are valid. The thing is, over 90% of people just use technology like a supermarket. Milk comes from supermarkets, it tastes the way the supermarket makes it taste and they know what taste of milk is best for you. The whole thing about starting your own diary farm and breeding cows and such is totally lost to these people. Once the nations largest supermarket starts adding bath salts to the milk, to keep people coming back for more groceries, those 90% will not complain and even actively defend the super market, because they like bath salts added to the milk and you should get your own cow and sell the excess milk if you don't like it.
I might be slightly exaggerating here, but you're defending a company that is trying to pull "a MicroSoft" on us all. Once Google has control of the UI we all use and the API, they get to say what applications run on it, who makes the money and who gets all the juicy information about the users of these products. Don't forget that currently, all NaCL applications are approved by Google and are exclusively distributed by "Google Play". You may say there are alternative markets, but those are fragmented and most are riddled with malware and pirated software. Anything commercially viable, apart from maybe Cydia is run and/or controlled by Google.
People that own an official Android device will in the near future have the ability to use all their Android apps on all their devices, providing they run Google's Chrome, not some other browser that just happens to support NaCl. This will mean a very large domination of the application market for Google, rendering all other web browsers and end-user operating systems insignificant. With Google being the only party to effectively censor what applications we get to use and who gets what slice of the pie, I think we have a right to be worried here. It's not about the ability, but the viability of a fork. Even if it were technically superior, it'd still lose.
Re:Viability (Score:4, Insightful)
Once Google has control of the UI we all use and the API, they get to say what applications run on it
Except that after Google proves out an idea (or while Google is proving out an idea), they also work with standards committees to help turn the new technologies into standard which all browsers can implement, and which any web app developers can use.
Don't forget that currently, all NaCL applications are approved by Google and are exclusively distributed by "Google Play".
Umm, that's not... oh, you already know that's not true.
You may say there are alternative markets, but those are fragmented and most are riddled with malware and pirated software. Anything commercially viable, apart from maybe Cydia is run and/or controlled by Google.
So what you're saying is that Google doesn't run and/or control everything. Agreed. And since all of this stuff is open source and will be standardized, Google can never run and/or control it completely. Of course, if they do such an excellent job that no one has any incentive to set up a competing system, it'll appear that they're in charge, but only in the same sense that Linus Torvalds runs and/or controls Linux. Yes, he does... but only as long as and to the extent his decisions and actions serve most everyone's interests. Open source is like that.
People that own an official Android device will in the near future have the ability to use all their Android apps on all their devices
Cite? I work for Google and I haven't heard this. It would seem to make sense, but I haven't heard of anything in that direction. And I don't see how it's related to NaCl, given that Android is a Java-based platform and it would be easier to use existing JVMs plus an appropriate set of libraries to support Android apps on other devices.
providing they run Google's Chrome, not some other browser that just happens to support NaCl
Uh, why will Chrome be required? And I'm still not clear how NaCl relates. You've lost me.
This will mean a very large domination of the application market for Google, rendering all other web browsers and end-user operating systems insignificant.
That would be a bad outcome for Google. Seriously. Not only would it offend the sensibilities of the 20+K engineers at Google (that's putting it mildly... I see torches and pitchforks at TGIF), it would put Google in a very tenuous position with respect to anti-trust regulators. Google has already been facing anti-trust investigations, and has largely beaten them all precisely because Google is careful not to lock users in.
I think we have a right to be worried here. It's not about the ability, but the viability of a fork. Even if it were technically superior, it'd still lose.
It would only lose as long as Google didn't actively exploit the control you're theorizing. As soon as they did, forks would spring up to compete. Heck, there's already at least one serious and successful fork of Android: Amazon's OS, which has a non-trivial fraction of the Android tablet market and which pretty much completely locks Google out.
(ObDisclaimer: I work for Google, but I don't speak for Google.)
Re: (Score:2)
And since all of this stuff is open source and will be standardized, Google can never run and/or control it completely.
Standardized by whom?
I don't know which organization. I'd guess W3C. I'm sure you could google it.
Is Google going to consult apple, mozilla, opera, microsoft, etc before deciding on features to NaCl?
Yes. Not only does Google have a long history of cooperating well with standards bodies, Google's real goal with all of this stuff is to be able to use it in its own applications, and Google does not want those applications to work only on Chrome. Unless you're also assuming that Chrome is going to wipe out all browser competition, in which case NaCl is the least of the concerns.
e.g. Acer forced to cancel their "non compatible" android fork
Acer wasn't forced. They could have continued, with n
Exciting, but... (Score:1)
Just when I thought I'd never go back to FF (Score:2)
... suddenly, all my extensions weren't running under incognito mode without disabling and enabling them again every time I went into incognito mode.
Back to FF I go.
No more "plugins" please (Score:2)
GOOG: Cookie monster epitaph (Score:2)
Chrome now operates as an unregistered vehicle transporting executable code handing off to server farms who knows what...surely not - YOU
Re: (Score:2)
Yes, and oral sex pregnancies are possible too.
http://abcnews.go.com/Health/Wellness/teen-girl-vagina-pregnant-sperm-survival-oral-sex/story?id=9732562 [go.com]
Re: (Score:2)
I really wish people would stop trotting that out as if it really indicated you could get pregnant by oral sex. You're probably being humorous, but I've actually seen morons using that story to push their "abstinence only" crap.
The fact that there was a knife raked through her abdomen makes kind of a big difference, and the truth is that a girl should probably already be taking care to avoid people who will stab her in the goddamn stomach, long before that particular oddity.
Re: (Score:2)
Actually I was more impressed by pregnancy without a vagina. I didn't know there was a condition where they would be vaginaless yet fertile prior to reading that story, I assumed that implied a guaranteed non-functional placenta previously (which apparently is usually the case with that condition, even though the ovaries and eggs are fine.)
I'm probably the last person you'd ever see advocate abstinence though. I've made it pretty clear in the past that I think prostitution should be legalized - Germany seem
Re: (Score:2)
Wait, you were actually interested in the biological oddity of it?
Don't you know all the actual nerds left ./ in the "Ultima Exodus of 2002?"