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

Comments

Write Once, Exploit Everywhere

[Anonymous Coward]

Java for the 21st century. And you thought applets were dead...
 

Re: Write Once, Exploit Everywhere

[Anonymous Coward]

No! It!s different! The buzzwords are not the same.

Re:Write Once, Exploit Everywhere

[binarylarry]

There's no virtual machine executing the code here, just some vmish technologies compiling it.

So it's more like ActiveX!

Security?

[hendrikboom]

How they maintain security with C and C++ applets?

-- hendrik

Re:Security?

[Anonymous Coward]

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?

[cheater512]

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:Security?

[Anonymous Coward]

Sounds pretty ... well ... neutered.

Re:Security?

[Jah-Wren Ryel]

Same way they do as JS.

That's not particularly reassuring.

Re:Security?

[Anonymous Coward]

Same way they do as JS.

That's not particularly reassuring.

It should be. Chrome has a very good track record with JS security.

Re:Security?

[Anonymous Coward]

Security? Hell, this seems it was designed by the NSA.

Re:Security?

[Twigmon]

To be fair, it is very difficult to exploit a potato.

Re:Security?

[anon mouse-cow-aard]

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.

Re:Security?

[Anonymous Coward]

put him on the streets, people love disabilities.

Re:Security?

[LoRdTAW]

You haven't met a Russian then.....

Re:Security?

[CTachyon]

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.

Re:Security?

[Anonymous Coward]

Wrong.
((void(*)(void))"\012\123\234\345...")();

Re: Security?

[Anonymous Coward]

At least it doesn't have Java's attack surface of Jupiter nor it spawns bazillion threads to bring even 8 cores to crawl like the JVM does.

Re:Security?

[jrumney]

C code without any APIs can't exploit a potato.

Is that a challenge?

Re:Security?

[Anonymous Coward]

So why does it get exploited again and again in the pwn2own competition?

Re:Security?

[Anonymous Coward]

C code without any APIs can't exploit a potato. It isn't inherently able to talk to the kernel.

Well, an "API" is nothing magical. Its just a memory jump. As long as you can control the instruction pointer, you can make all the API calls you want.

Re:Security?

[Anonymous Coward]

And by "again and again" you mean "twice over the 7 years this contest is held".

Re:Security?

[Anonymous Coward]

As long as you have pointers and an idea where the return address of your function is stored, you can jump wherever you want. Including to the entry point of your OS kernel API.

Re:Security?

[Gravis Zero]

... 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, 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 content loading. i cant think of any page designs that would suffer by changing to this scheme that aren't needlessly retarded or should be applications.

if your site is so "advanced" that you need javascript then you are writing an application, not a web page. wrote a PC emulator in javascript? cool but it's not a webpage, it's an application. got a page with a live ticker scrolling some bullshit all the time or an advertisement that pops up after being on the page a couple minutes? a) fuck you b) it's an application.

a "javascript executable" file that you could download seems more appropriate than injecting it into a page and calling it a "modern" web page.

Re:Security?

[K. S. Kyosuke]

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:Security?

[StripedCow]

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:Security?

[StripedCow]

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:Security?

[Metabolife]

I mean.. technically.. that it again and again.

Re:Security?

[Anonymous Coward]

That may be a way to trick a bytecode parser, but that is not what API means.

The API can be one provided by the browser, or by the kernel (system calls). On a modern operating system (I.e. anything newer than DOS), user programs don't get to talk to the hardware directly. No writing to the network card, no writing to 0xB800 video memory. Everything needs to go through system calls. If you try anyway, the kernel is going to stop your process immidiately. On *nix, this is called segmentation violation (segmentation fault on Linux), Windows calls it the program has caused an illegal operation and needs to close.

Now, if Chrome can remove access to the kernel system calls (this needs help from the kernel, but any OS that can support a virtual machine should be able to do this), and provide its own API, only that API is available. That way, you don't need to worry about what the native code is doing, only what the API can do.

Still lots of chance to have holes due to bug in the API, but that goes for anything, including the OS API. The model itself is sound.

Re:Security?

[nightsky30]

Technically that's once and again.

Re:Security?

[Anonymous Coward]

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

You can still do that if the Reflections API is not disabled. Just take a String object and make the member variables non-final at runtime.

Re:Security?

[dewrox]

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: Security?

[Anonymous Coward]

Nobody can escape a sandbox! That's why they build vaults out of them.

Re:Security?

[cavebison]

NaCl (in its standard, non-Portable flavor)

You mean before it's ground up and put into little shakers?

Re:Security?

[Anonymous Coward]

Interested in your comments (particularly the one in bold) since http://dabblet.com/gist/1506530 doesn't render at all unless you have javascript enabled. Nevertheless you are right in principle.

Re:I need help?

[Anonymous Coward]

Yes. That's where lawyers come from.

Why?

[TubeSteak]

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:Why?

[Anonymous Coward]

It's a fallacy to think that 'native' equates to insecure.

Re:Why?

[Anonymous Coward]

but for the sake of security, we shouldn't be allowing the browser such low level access.

You sound like a fascist.

Pointer arithmetic for all!

Re:Why?

[Anonymous Coward]

The browser is not the place to run "native" applications.

Why not?

but for the sake of security, we shouldn't be allowing the browser such low level access.

There is no low-level access. Read TFA.

Re:Why?

[reub2000]

Good news everyone! Chrome isn't just a browser. It's an OS.

Re:Why?

[Anonymous Coward]

I would like my webapp to be able to extract and maybe even create zipfiles. Javascript unzippers are not fast enough to work with the filesizes I need. So I have to tell my users to unzip their files before they can be used. We need to replace Java with something right?

Re:Why?

[SB9876]

Browsers have been slowly becoming self-contained OSs for a decade now.

Re: Why?

[ewanm89]

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:Why?

[bickerdyke]

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: Why?

[K. S. Kyosuke]

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:Why?

[K. S. Kyosuke]

Which is a symptom of OSes not doing their work properly. Of course, the demand for network-distributed, compound documents with extensible and replaceable components has been here ever since the 1970s. Since the OSes currently in use don't implement any of it, many people have logically resorted to trying to do that in the closest thing they new: the web. I wouldn't blame them, it's not their fault.

Re:Why?

[VortexCortex]

Perhaps 'vulnerable' is more your taste? Ask a native American about their insecure imigration policy.

Re:Why?

[mcgrew]

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.

What?

[brunes69]

"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:What?

[Anonymous Coward]

well Java defines a JVM.

This thing... does it define a NaClVM?

Re:What?

[brunes69]

It's using LLVM, so yes.

Re:What?

[bensyverson]

Ugh, exactly—except Java runs in more browsers. 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.

Re:What?

[Anonymous Coward]

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 difficult or impossible.

Re:What?

[Anonymous Coward]

Both Java and .NET are stack based, you fucking moron.

Re:What?

[Anonymous Coward]

And like Silverlight, and like Flash

Re:What?

[DrXym]

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 that has to be loaded, parsed, recompiled again and run over a JS engine with the performance and memory overhead that this implies. I would rather than browsers adopt a LLVM based runtime framework like PNaCl so few of the overheads of using JS are necessary.

Re:What?

[brunes69]

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:What?

[jfengel]

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 into native code and kicked off. Only a very naive JVM implementation would actually manifest the stack as a stack.

That sounds familiar.

[Anonymous Coward]

That approach sounds familiar. What's to stop this being Just Another Vulnerability Apparatus?

Re:That sounds familiar.

[Anonymous Coward]

Nothing! Release the Fuzzer!

Re:That sounds familiar.

[jthill]

They've got a sandbox that works. It's BSD-licensed, it's been public for years, it's drop-dead simple.

Re: That sounds familiar.

[Anonymous Coward]

Popularity.

PNaCl

[OhSoLaMeow]

Why would chrome even need phosphoric sodium chloride? Seems like Ferro-Cesium Sulfate is more appropriate.

ActiveX was such a good idea after all....

[Anonymous Coward]

Oh but its Google and they're the prince geniuses of the Internet so.

Re:ActiveX was such a good idea after all....

[aztracker1]

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.

Re:ActiveX was such a good idea after all....

[Anonymous Coward]

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:ActiveX was such a good idea after all....

[epyT-R]

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:ActiveX was such a good idea after all....

[Anonymous Coward]

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 installs a "safe for scripting" component, you might get owned by a webpage. Consequentially, IE ships with a huge ActiveX blacklist ... it would have made much more sense to whitelist things instead. (Firefox plugins avoid this problem because at least the programmer knows they're developing a browser component.)

Re:ActiveX was such a good idea after all....

[dutchwhizzman]

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 see a whole plethora of problems with this, one of them being Google being in control of the "operating system" that the Chrome browser is becoming this way, but purely from a technological stand point, ActiveX is far worse than NaCl.

Re:ActiveX was such a good idea after all....

[DrXym]

An ActiveX control is fundamentally no difference from a Netscape plugin. They are both native DLLs running with the full privilege and power of the process they are hosted by. Plugins could even be scripted like ActiveX controls through LiveConnect and later through XPConnect.

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 it. Scripting a control was easy too thanks to OLE automation and IDispatch interface. Worse, even if I didn't have BadlyWrittenControl installed, the website could still reference the CAB file that contained it and IE would facilitate the automatic download and installation of it.

Conversely installing a plugin was a pain in the ass. Even if a page said it needed a plugin and provided the url to it, the user still had to manually go off and install it. Therefore by default plugins had a level of safety which IE did not have. And it was also a pain for developers to write a scripting API for a plugin, so many plugins didn't bother or offered only minimal scripting. I don't think this was intentional security, just the general craptitude of LiveConnect provided better security as a side effect.

Anyway, I don't see PNaCl as being unsafe per se but it should be something that is disabled by default, and even when it is enabled, users should be alerted and given the option of blocking execution of apps on a per site basis.

Re:ActiveX was such a good idea after all....

[AmiMoJo]

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:ActiveX was such a good idea after all....

[Anonymous Coward]

Well then, run with noscript, only use websites that work without scripting, and stop whinging. Any no, you're not entitled to force people to produce websites that work without scripting just for you.

Re:ActiveX was such a good idea after all....

[Anonymous Coward]

> If you want an interactive application, build executables for the target
And how this approach would be more secure?

Re:ActiveX was such a good idea after all....

[spongman]

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. it would be nice to have a unified language that was easy to learn and suited just for the task, in fact, why not just compile it on the client then you don't need to store different versions of the binary.

oh look... a browser!

fool.

Re:ActiveX was such a good idea after all....

[Kalriath]

You should probably stop posting on the interactive application known as Slashdot then.

I am hereby calling for a boycott of active-x v2

[Anonymous Coward]

We tried this with java, we tried this with active-x, and we tried this with adobe flash...

Ick. End it already. It leaves us with nothing but messes all around and gaping security holes.

Not to mention it forces non-free code down our throats that is as intrusive as hell and destructive to our freedoms.

Browsers

[Anonymous Coward]

Should only display text and images........ that's it. I shouldn't even be able to type this comment.

It has come to this...

[sinij]

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:It has come to this...

[Anonymous Coward]

> Browser should do one, and only one thing well - render web pages

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!

Re:It has come to this...

[asmkm22]

> 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:It has come to this...

[binarylarry]

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.

Re:It has come to this...

[binarylarry]

Back in my day we had Gopher and we liked it that way.

Damn kids, get off my lawn!

Re:It has come to this...

[Anonymous Coward]

I disagree, Browsers should do much more than just render web pages. If that was their goal, they should have stopped development back in 1990's.

These days, browsers need to render rich applications, whose complexity, demand and scope are ever increasing. The web has become an application development platform, and has been on that course since XHR took off in circa 2006.

In order to further this platform, we need access to more and better API's (https://developer.mozilla.org/en-US/docs/Web/Reference/API). Yes, unfortunately this can add bloat. However, as long as performance remains a priority, I don't think it will be a major issue. And FWIW, both Google and Mozilla seem to be staying on top of that from my experience.

Re:It has come to this...

[Anonymous Coward]

And we heard the exact same thing about all the other "strategic" technologies like Java Applets, ActiveX, Flash/Flex, Silverlight, and so on. HTML owns your face, bitches. The web always wins.

Re:It has come to this...

[sinij]

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 cellphone because they need to call on the road, because most smartphones actually suck at calling part and require mic-headphones plug-in addon to be any good at it.

FeCsSO3

[tepples]

Seems like Ferro-Cesium Sulfate is more appropriate

What about FeCsSO3 makes it better?

ANOTHER Notifications tool

[felixrising]

Instead of using the native OSX notifications, they added their own spammer to the menu bar... complete fail.

did you mean SO4?

[Anonymous Coward]

SO3 is sulfite. SO4 is sulfate.

Re:did you mean SO4?

[OhSoLaMeow]

Argh. Stupid typo. I meant Ferro-Cerium Sulfur.

The browser recommended by Section 31.

[sconeu]

n/t

Hmmm...

[Anonymous Coward]

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.

I'm sure Sun came up with a very similar technology. I seem to recall Apple and Microsoft weren't wildly thrilled about it.
I won't be holding my breath for PNaCl to be allowed to compete with Apple's or Microsoft's app store. I'm sure it will happen right around the time WebGL or Java Applets are implemented in iOS Safari.

Re: Potato exploit

[Anonymous Coward]

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.

Keep pushing your tech on us, Google

[Anonymous Coward]

Google has been pushing their own tech a lot over the past few years: their own image format, their own video format, their own runtime, their own plugin api, their own networking protocol, etc. Pretty funny, given how they got the clout to do this by using other people's open web tech, and now that they managed to convince a lot of people that Chrome *is* the Internet, they're convinced that they can do whatever the hell they want. And the scary thing is that all the young kiddies are happily letting them. Reminds me of Microsoft's day in the sun when they did the same thing with Internet Explorer. I wonder if there will be a Mozilla this time to save us from a company who slyly hides behind the illusion that all of their proprietary tech is "open", rather than just some big chunk of sourcecode to be dropped into another project that's under Google's control.

Re:Keep pushing your tech on us, Google

[binarylarry]

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:Keep pushing your tech on us, Google

[0ld_d0g]

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 misplaced. That works for tiny 'hello world' type open source projects. Once OSS projects get to be complex you cannot just fork them without major $ resources. Without the money all you can do is complain on online forums.

Also, One could say a similar thing to you. If you don't like the comment, ignore it :)

Re:Keep pushing your tech on us, Google

[Anonymous Coward]

Seriously? You claim I'm a paid shill and then go on to defend Google with such a flimsy, self-serving argument? No, fuck you. Google's been pushing their own tech so fast that no one can keep up. They clearly don't care about that, either. What goes in their codebase may be their choice, but they're in a position to dictate how the web advances. If you're that blind and ignorant and don't care that one company is trying to steer the web as they see fit, then you need a reality check.

When will chrome support 64 bit java?

[goombah99]

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:When will chrome support 64 bit java?

[AlphaWolf_HK]

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:When will chrome support 64 bit java?

[MachineShedFred]

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.

Re:When will chrome support 64 bit java?

[Anonymous Coward]

Hopefully, NEVER.

R

I for one welcome the new activex

[Anonymous Coward]

What I like is how it will never, ever be abused and allow access to the file system.

Re:I need help?

[AlphaWolf_HK]

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

Exciting, but...

[thatpythonguy]

I like the idea of running native code in the browser, but I will be really excited when (if?) this becomes a standard. Ever since the now-defunct NPAPI stopped being the cross-browser solution of choice, we've been in dire need of something that is both native (i.e., not Javascript) and standard (i.e., not Chrome NaCl). Interesting nonetheless!

Just when I thought I'd never go back to FF

[gnoshi]

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

Summarized

[dutchwhizzman]

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 agree with the conclusion that Java is a steaming pile when it comes to security, having Google replace it with something marginally less steaming doesn't seem like a good idea to me.

Re:Summarized

[Anonymous Coward]

Does seem so to google, though. For their own reasons, of course.

Re:Summarized

[Anonymous Coward]

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.

Viability

[dutchwhizzman]

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

[swillden]

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:Viability

[Anonymous Coward]

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? Is Google going to consult apple, mozilla, opera, microsoft, etc before deciding on features to NaCl? Or will the competition just be left playing catchup while google develops NaCl and dumps source onto a server once the next chrome is released?

The "fork" idea is irrelevant. You're talking about the implementation, which nobody cares about because controlling the spec of a platform standard is much more relevant. Once enough apps are written using google's NaCL spec, no alternate spec or implementation will survive. Google will ofcource attempt to strongarm or as the word was in the leaked memo "sweettalk" people into writing applications for NaCl exclusively. And ofcource just like with Android (e.g. Acer forced to cancel their "non compatible" android fork) they will use legal means to exercise control over the 'nacl' trademark, so even if someone else develops an alternate store for nacl apps, they wont be able to advertise it as such because google will not allow it. And since google controls online advertising to such an alarming extent, most people will find it difficult to compete because they cant even advertise it. Even web search results will as usual be biased to googles own products.

Google has already been facing anti-trust investigations, and has largely beaten them all precisely because Google is careful not to lock users in.

Google locks in its paying customers, not users. The users are just fodder to be mined and exploited.

As soon as they did, forks would spring up to compete.

No, they wont. When a codebase crosses a million lines of code, it is practically impossible for a completely new team to even fully comprehend the codebase, much less begin to modify it in any important way. Its much easier to begin afresh - which never happens and would take years of additional work.

(ObDisclaimer: I work for Google, but I don't speak for Google.)

Too bad. I view most advertising companies as slime. They don't care about anything except extract the last drop of money exploiting whatever resource they can get their hands on.

All you google engineers love to pretend like engineers run the place, but to the outside world its obvious that the asshole MBA types run it. The forced google+ "adoption" and all the real name bullshit is something no self-respecting engineer will force onto people who don't want to use it.

Re:Viability

[swillden]

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 no legal repercussions. Google just wouldn't have treated them as a member of the club. Amazon has gone very incompatible with their fork and not only is there nothing Google can do about it, I don't think there's even any interest in stopping them.

Google locks in its paying customers, not users. The users are just fodder to be mined and exploited.

Google views both as customers. And Google doesn't lock in its paying customers, either.

As soon as they did, forks would spring up to compete.

No, they wont. When a codebase crosses a million lines of code, it is practically impossible for a completely new team to even fully comprehend the codebase, much less begin to modify it in any important way. Its much easier to begin afresh - which never happens and would take years of additional work.

Nonsense on the "easier to begin afresh" point. That's a common fallacy among software engineers; starting over is almost never cheaper/easier unless you're also redesigning, and often not even then. As for the rest, there are plenty of counterexamples.

Re:Viability

[Anonymous Coward]

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.

Well Google certainly is trying. You guys are bundling chrome and your crappy toolbar (another Google MBA invention to capture user data BTW.. no engineer would ever think that creating a browser toolbar for IE is a good idea) with all sorts of random installers, not to mention paying OEMs to install chrome.

Google just wouldn't have treated them as a member of the club.

Ah.. the truth comes out. "Hey OEM guy, you can choose not to bundle IE with the PC, except you'd lose access to the cheap windows license club".

Since he owns the trademark, imagine if Linus was evil he could say only RedHat can call its product Linux. The rest of you are "incompatible". Sure you can fork it or do whatever you want, you cant call yourself a Linux distro. That kills the remaining distros completely.

Google views both as customers. And Google doesn't lock in its paying customers, either.

Once you setup an adwords campaign AFAIK you cannot extract the associated data. Well one reason could be that there is no standard data migration path from one ad network to another, and that is not googles fault.

 

Nonsense on the "easier to begin afresh" point. That's a common fallacy among software engineers; starting over is almost never cheaper/easier unless you're also redesigning, and often not even then.

Thanks for twisting my words. Classy.

As for the rest, there are plenty of counterexamples.

Oh really? "plenty" you say..

Which are the plenty of tens of millions of lines codebases which have been successfully forked by a team which was not part of the original work?

The Web is no longer about pages

[coder111]

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

No more "plugins" please

[peppepz]

The worst thing about Flash weren't its security implications. The problem was that Flash put islands of non-HTML in the middle of HTML pages, complicating their description, their development, their deployment, and therefore complicating the software implementations required to render them; also, increasing the time required to train people into writing web pages, and introducing the conflicts between two standards that are planned and evolve independently, yet have to intercommunicate. Often only to obtain similar results to plain HTML - especially in the post-HTML5 world.

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.

Chrome still sucks

[Anonymous Coward]

...because side tabs are still gone and they won't let mod authors write addons to replicate the behavior.

Re:I need help?

[geminidomino]

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.

I dont like where Google is heading

[Anonymous Coward]

so i switched back to firefox. I don't want a browser that more and more enforces you to use Google Services all the time.

Re:I need help?

[Anonymous Coward]

Mods, the above posts are all offtopic. Whoever modded that offtopic post up, LEAVE A COMMENT TO UNDO THAT IDIOTIC MODERATION. I swear, the only thing wrong with slashdot these days (besides dupes and typos in the summaries) is the non-nerd idiots that have swarmed in here from reddit and 4chan. IF YOU'RE NOT A NERD, DO NOT COMMENT. If you're commenting, stay on topic. If you're moderating, MOD OFFTOPIC COMMENTS DOWN.

God damn it, stop fucking up my slashdot, punks. GTFO.

GOOG: Cookie monster epitaph

[ElitistWhiner]

Chrome now operates as an unregistered vehicle transporting executable code handing off to server farms who knows what...surely not - YOU

Re:I need help?

[AlphaWolf_HK]

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 seems to be doing fine with it.

Re:I need help?

[geminidomino]

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?"