Slashdot Mirror
Google Chrome 31 Is Out: Web Payments, Portable Native Client
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."
"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?
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."
That approach sounds familiar. What's to stop this being Just Another Vulnerability Apparatus?
Why would chrome even need phosphoric sodium chloride? Seems like Ferro-Cesium Sulfate is more appropriate.
They can take my LifeAlert pendant when they pry it from my cold dead fingers.
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.
It's a fallacy to think that 'native' equates to insecure.
Same way they do as JS.
That's not particularly reassuring.
When information is power, privacy is freedom.
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?
I don't think that ActiveX itself was a bad idea.. Setting the email client to "local" security context instead of "untrusted", and marking activex controls that can access the file system as "safe for scripting" while the browser is allowed to run in "administrator" security context.. those were poor decisions all around.. but having a flexible plugin architecture in and of itself isn't a bad idea.
Michael J. Ryan - tracker1.info
It is native code but still running in a sandbox.
https://developers.google.com/native-client/dev/overview#security
The only interaction between this process and the outside world is through sanctioned browser interfaces.
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.
You haven't met a Russian then.....
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, 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.
Range Voting: preference intensity matters
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.
Mod me down, my New Earth Global Warmingist friends!
And by "again and again" you mean "twice over the 7 years this contest is held".
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.
I was promised a flying car. Where is my flying car?
Well, in case you didn't get the memo, the definition of World Wide Web has changed dramatically since the 1990s.
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 all machines was a web browser. If all machines were shipped with an X server or a VNC client or some other application-client technology, maybe things could have been different. But we are where we are, and because of that features like Canvas, HTML5, WebGL, NaCl, very fast JavaScript JIT engines get added to the browser to make it more efficiant APPLICATION client, not a page browser.
--Coder
I mean.. technically.. that it again and again.
Security problems came as a corollary of all this.
JavaScript wasn't chosen as the official language for interactive HTML pages because of technical advantages of the language itself. It was chosen because it was already standardised, it was platform-neutral, and it was already ubiquitous. Those motivations still hold, against the adoption of NaCL.
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. It would be two more decades before these small machines would be networked, and meanwhile the dumb terminals connected to mainframes were in the office, side by side with the Wang word processing dumb minicomputer terminals and IBM/Sun/etc. mainframe terminals.
Don't try to teach history to your elders, we've lived through it and didn't have to read it in a book or, like you, simply guess at how it must have been.
Free Martian Whores!