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?
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.
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
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.
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!
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?