Google x86 Native Browser Client Maybe Not So Crazy After All

GMGruman writes "Google's experimental technology to run native x86 binaries in the browser shows lots of potential, writes Neil McAllister. He's previously said it was a crazy idea, but a new version of Native Client (NaCl) caused McAllister to take a fresh look, which has led him to conclude the technology is crazy like a fox. McAllister explains what NaCl is useful for, how to use it, and why it's not a Java or a Flash or a JavaScript replacement, but something else."

Comments

Not Java, more like Active X

[Anonymous Coward]

Hopefully Google will make this more secure than ActiveX.

If Android is any indication of Google's commitment to security, a free wallpaper application will be able to read all your text messages and track your location in real-time.

Re:Not Java, more like Active X

[WrongSizeGlass]

Now all they need to do is give it full access to the Windows Registry and we'll be right back to where we started.

Re:Not Java, more like Active X

[Dunbal]

I don't see how it could be made secure at all, unless it's a virtual machine - you are giving it execute privileges. That means at least full read access to all hardware, including the hard disk. While some OSes are picky about who gets to write where, this means your whole HD can be scanned. This is an absolutely horrible idea - from the user's perspective. But in Corporate America, program uses you!

Re:Not Java, more like Active X

[Enderandrew]

Chrome is extremely sandboxed. Scripts running in Chrome don't have permission to randomly alter files, install software, etc. like ActiveX did.

I imagine they'll keep NaCl in a similar sandbox.

Re:Not Java, more like Active X

[ByOhTek]

There's a difference between sandboxing scripts which you facilitate the execution of/interperate yourself (Javascript, to a lesser extent Flash and Java) and native code.

Re:Not Java, more like Active X

[ewibble]

I assume have to go through some interface to make system calls, (it is os independant) but how you stop these calls hard to say, maybe check the code for specific instructions, however it seem like you could calculate some code then execute it.

Re:Not Java, more like Active X

[AlecC]

No, you are still running in User mode rather than Kernel mode. The OS still gets to trap and inspect all your accesses, so that you can only look at the HD in the same way as any user program can.

Re:Not Java, more like Active X

[toastar]

I imagine they'll keep NaCl in a similar sandbox.

I prefer to keep SiO2 in my sandbox, But whatever flips your switch.

Re:Not Java, more like Active X

[Tubal-Cain]

Chrome is extremely sandboxed. Scripts running in Chrome don't have permission to randomly alter files, install software, etc. like ActiveX did.

Chrome extensions are even limited in the ability to alter their own files. Or at least that's seems to be the reason NotScripts needs you to edit one of its files by hand after you install it.

Re:Not Java, more like Active X

[Anonymous Coward]

There have been bugs in the OS or CPUs that allow privilege escalation.

Re:Not Java, more like Active X

[Trufagus]

Java, Flash, Silverlight, etc. all replace web technologies in your browser.

NaCl is designed to be used with HTML, CSS, Javascript, and all the other HTML5 technologies. It essentially lets you pre-optimize pieces of performance critical pieces of Javascript such as codecs.

Re:Not Java, more like Active X

[AlecC]

That is always true, and NaCl makes little difference to this. Of course, the more different ways you use an OS, the more different places you get to probe for bugs. If you never try anything new, you will not find new bugs, but you will not get the benefit of new capabilities. Take this to an extreme, and you end up Amish: they have decided not to take up new technology because it brings new risks.

Re:Not Java, more like Active X

[Trufagus]

"If Android is any indication of Google's commitment to security, a free wallpaper application will be able to read all your text messages and track your location in real-time."

Only if you explicitly give the app permission to do those things.

And, what is wrong with that. There is a Google Maps live wallpaper that does just that - requests and uses my real-time location.

It's a bit different then the iPhone where Apple is tracking your location whether you like it or not (permission is buried in the iTunes terms). On Android, nothing gets your location, not even Google, unless you explicitly permit it.

Re:Not Java, more like Active X

[harrkev]

Well, this thing is supposed to be platform-independent, so you would HAVE to go through a Google API to get any access to the hard drive. I would imagine that they would but blocks in that could stop nefarious actions. They will most likely NOT allow access to operating system calls, since the code is supposed to be able to run on any operating system.

Re:Not Java, more like Active X

[GooberToo]

If Android is any indication of Google's commitment to security, a free wallpaper application will be able to read all your text messages and track your location in real-time.

Only true in the most vague of the meaning. As most people will read that statement, its implications are completely untrue. Android is extremely secure and has the best security model of all mobile OSs.

A wallpaper may read contacts and track your location but only, and I mean ONLY, if the user specifically accepts the associated permissions which very clearly say the application has such capabilities. To blame Android for user stupidity, it say you're not trolling.

Simply put, when you install an Android application it forces you to review the list of permissions the application is requesting. It can't, however, force the user to actually read them. If a user is dumb enough to install a wallpaper which requires access to the Internet and your contacts as well as the GPS, well, that's strictly on the user. Faulting Android for user stupidity is stupidity in of itself.

Not hard to see why you're trolling anonymously.

Re:Not Java, more like Active X

[Goaway]

I don't see how it could be made secure at all

This may have something to do with you not making any effort whatsoever to read up on what NaCl actually does.

Re:Not Java, more like Active X

[Goaway]

Chrome sandboxes its own native executable code, not just Javascript.

Also, NaCl is even more strictly controlled than just a sandbox.

Re:Not Java, more like Active X

[abigor]

Well, some of us treasure our time in our lovely saltboxes.

Re:Not Java, more like Active X

[MrEricSir]

It uses something called Newlib, but there's also a port of libc. And of course no OS calls are allowed.
http://en.wikipedia.org/wiki/Google_Native_Client

Re:Not Java, more like Active X

[MrEricSir]

To be fair, ActiveX applications also have full, elevated access to your filesystem during the install.

Re:Not Java, more like Active X

[guyminuslife]

And prohibiting self-modifying code. And probably some other stuff that I haven't even considered yet (and they probably haven't, either).

There are enough security vulnerabilities on the Internet already. Java is fast enough for anything you'd conceivably need to do on the Web, and more importantly it's had 15 years of real-world testing in exactly this environment. If you really need to juice out those extra cycles (and I'm not saying that you don't), then you don't need to use a browser.

Re:Not Java, more like Active X

[Asm-Coder]

I can still cause plenty of trouble in user mode. I can delete user files (which are usually the ones that can't be replaced, so you have to revert to your las backup), access the network, change the $PATH or user startup scripts, and potentially screw with any of the other applications running in the same user session. If I knew what I was doing, I could download a hacked sudo binary, and change the $PATH to include it. The next time the user doesn't use the full path to sudo to get elevated privileges, I can store the password, and can now gain elevated privileges at any time I choose.

This will only work if the account can sudo, but I expect most home users are working with an account that can do so, and I can do the same for su, which doesn't have that problem. If the user never elevates their privileges, I just wasted my time, but I expect the process would be automated, and it only has to work once on each machine.

So yeah, I'm only running in user mode, but for most purposes, user mode is 'good enough'.

Re:Not Java, more like Active X

[Goaway]

NaCl can't do any of those things, though.

Re:Not Java, more like Active X

[Anonymous Coward]

Take this to an extreme, and you end up Amish: they have decided not to take up new technology because it brings new risks.

That isn't the purpose.

Re:Not Java, more like Active X

[Asm-Coder]

Yeah I got that from reading the comments, but there wasn't any mention of any limitations as to what the applications could do in the article, just a limitation on how you could run them. In reality, the applications are sandboxed, so they aren't running in full user mode. If they can break out of the sandbox however, all of the possibilities in my above comment are available.

Re:Not Java, more like Active X

[syockit]

But you don't necessarily have to use the former 3 in a way that they replace web technologies. You can use them purely for perfromance optimization as well.

Re:Not Java, more like Active X

[Goaway]

They are actually both sandboxed and statically analyzed for safety. Of course there can still be holes in all that, but there's been a lot of effort put into breaking and fixing it already.

Re:Not Java, more like Active X

[Daniel Phillips]

And to be even more fair, the word "security" does not even appear once in the article which makes the author a clueless idiot who flatters himself to believe he understands anything remotely resembling the internal details of this stupid idea.

Re:Not Java, more like Active X

[c0lo]

Wait 'til your desktop metaphor will be supported by a browser and... that's the next good thing, right?.. you will be allowed to use the NaCl applications even when offline.

Re:Not Java, more like Active X

[c0lo]

No, you are still running in User mode rather than Kernel mode. The OS still gets to trap and inspect all your accesses, so that you can only look at the HD in the same way as any user program can.

This is until the "consumers" will use mainly your technology and have all their data saved in the sandbox. At that point, it won't matter if the HDD contains something else, because chances are that it won't.

Re:Not Java, more like Active X

[c0lo]

I imagine they'll keep NaCl in a similar sandbox.

Until the data you keep in the sandbox will make your main corpus of your data.

Re:Not Java, more like Active X

[Anonymous Coward]

If Android is any indication of Google's commitment to security, a free wallpaper application will be able to read all your text messages and track your location in real-time.

Only true in the most vague of the meaning. As most people will read that statement, its implications are completely untrue. Android is extremely secure and has the best security model of all mobile OSs.

A wallpaper may read contacts and track your location but only, and I mean ONLY, if the user specifically accepts the associated permissions which very clearly say the application has such capabilities. To blame Android for user stupidity, it say you're not trolling.

Simply put, when you install an Android application it forces you to review the list of permissions the application is requesting. It can't, however, force the user to actually read them. If a user is dumb enough to install a wallpaper which requires access to the Internet and your contacts as well as the GPS, well, that's strictly on the user. Faulting Android for user stupidity is stupidity in of itself.

Not hard to see why you're trolling anonymously.

whilst I agree with you, and I have an android phone and have written several live wallpapers and android apps, I can still see ways to get malicious apps out there.

For example, its easy to think up an idea for a wallpaper that needs full internet access to do what it does. It might also want access to your contacts for a seemingly unrelated feature. With the right accompanying description, the permissions probably seem reasonable.

The thing is, if I were to do that on Android market, Google would find out sooner or later, probably sooner, and ban me from everything Google. Sure, some people can set up fake google accounts and everything, but it seems no one has done that yet. All known exploits have landed on alternative app stores not controlled by Google.

I'm guessing if anyone targetted Google's Android Market directly, it would be difficult for them to remain completely anonymous...

I wonder if Google employ automated testing on android apps to see what the app sends and receives from the internet...etc.

Re:Not Java, more like Active X

[fractoid]

I don't see how it could be made secure at all, unless it's a virtual machine - you are giving it execute privileges. That means at least full read access to all hardware, including the hard disk

Does having execute privileges give you 'full read access to all hardware including the hard disk', though? I don't think it does - for instance, try reading another user's files in Linux. If the permissions are set properly, the OS will stop you from reading them. If a user (who can run programs) can be locked down like this, why not a program?

Re:Not Java, more like Active X

[Anonymous Coward]

Come on you fags.. This is funny.

Re:Not Java, more like Active X

[LordLimecat]

Android is extremely secure and has the best security model of all mobile OSs

If you mean exactly identical to Blackberry's model, then yes. Before google maps can make calls, it must request permissions to do so. If an app recommends security permissions at installation, the user must review them before they can accept them.

This isnt anything new, Blackberry has been doing this since I started using them 5 years ago.

Re:Not Java, more like Active X

[!eopard]

I had an idea for an application where many people would "sensibly" allow access to a whole bunch of things on their phone - including the functionality mentioned above - then realised I don't want that visible here for a number of reasons:

1) someone might code it :/

2) *I* might want someone to code it for me (I'm not a developer) and so I don't want the idea 'stolen'

*sigh*

Re:Not Java, more like Active X

[dreamchaser]

And to be even more fair, the word "security" does not even appear once in the article which makes the author a clueless idiot who flatters himself to believe he understands anything remotely resembling the internal details of this stupid idea.

Be careful when you call someone an idiot lest you look like one yourself. Page 2:

To see NaCl apps in action, you need a browser that supports Native Client. For now, that means Chrome 10 or later, and you need to explicitly enable NaCl, either with a command-line option or through Chrome's experimental features panel. Once NaCl is enabled, Chrome warns you that security and stability will suffer -- don't try this at home, kids.

Re:Not Java, more like Active X

[perryizgr8]

ohh! just like my native programs! then i'll be able to download programs and run them on my OWN computer!!!11

Re:Not Java, more like Active X

[Goaway]

They have thought a lot longer and harder about this than you. Assuming they are as ignorant on the topic as you is pretty arrogant.

Before you start going on about how little they know, maybe you should actually go read the papers they've published on the topic.

Re:Not Java, more like Active X

[GooberToo]

There's more to a security model than asking the user to confirm application privileges.

Re:Not Java, more like Active X

[Daniel Phillips]

Indeed, got me, but in no way did you contradict my point: author in fact had nothing to say about anything "inside" this stupid idea, and commented only indirectly on security. For your part, you might consider your own advice.

Re:Not Java, more like Active X

[GooberToo]

The point that legitimate applications may have such requirements; rather the issue is, if you accept such permissions, you do so at your own risk. You can't blame Android for the user accepting such risk.

Personally, any application which requires access to contacts and has internet access is extremely unlikely to be installed on my devices. There is rarely such a legitimate need. Furthermore, Android has enough flexibility which allows for additional features to be added as plugins which all too often means the need for applications which require massive privileges are truly few and far between.

As for your second part...I can't tell you how man completely obvious and yet supposedly unique and wonderful application ideas I've had pitched to me. All too often, they are already on my wish list, impossible, not practical, require a million dollar budget (to which the pitcher wants to seed none and receive 60% of gross), or is just a plain 'old bad idea; or some combination.

Its pretty easy to understand why movie producers get pitches all the time and why they are almost always completely useless; much to the surprise of the person pitching.

Re:Not Java, more like Active X

[DaVince21]

Apparently they verify the code before it's run, and the compiler is made in such a way that it can only create verifiable code.

Like ActiveX?

[Anonymous Coward]

This sounds suspiciously like Microsoft's foray into native binaries with ActiveX technology and COM.

Re:Like ActiveX?

[The MAZZTer]

Except it's properly sandboxed so web code doesn't have admin-level access to your entire system.

Re:Like ActiveX?

[jlechem]

The problem is so was java and as I recall there was a recent attack vector against that fairly recently in windows. I love plugins but they introduce so many new security issues it's hard to overcome them all.

Re:Like ActiveX?

[Dunbal]

properly sandboxed

I read that as in "until someone finds a way around it". I give it a week.

Re:Like ActiveX?

[drspliff]

The Java sandbox was at the interpreter level and did not provide protection at the OS level. The google native client stuff sandboxes it at the OS level and only allows for communication via RPC calls to the parent app (e.g. drawing on a canvas), much like the seccomp approach for Linux which is a true sandbox

Re:Like ActiveX?

[Anonymous Coward]

Wasn't also ActiveX supposed to be sandboxed?

Re:Like ActiveX?

[James_Duncan8181]

I read that as in "until someone finds a way around it". I give it a week.

Fancy a wager? I'll offer you even odds on a month for any sum up to $500.

Re:Like ActiveX?

[Goaway]

It's been around for years already.

Re:Like ActiveX?

[Anonymous Coward]

So you mean just like IE since IE 7 on Vista? Which doesn't allow access to much of the file system at all and runs as "low integrity" (regular user processes run as "medium integrity". But then you obviously were talking about Windows XP which is obsolete.

Re:Like ActiveX?

[shog9]

No. Hence its sterling reputation...

Re:Like ActiveX?

[Anonymous Coward]

RPC calls

IPC.

NaCl

[allo]

what will Daniel J. Bernstein say to the name?

Re:NaCl

[blair1q]

Yeah, you wouldn't want to confuse anyone by saying "I'm running my Windows code in a browser window on my Apple".

They'd think you're mad, talking about windows that run inside apples.

Re:NaCl

[Megane]

You talk like this is the first time that Google has done this. Remember a few months back when they came up with a programming language that was a common 2-letter word, and the name of an existing board game? I wonder what tweaking to their search algorithms they had to do to make it come up as high as #3 on that search, or even on the first page at all.

Re:NaCl

[Salvo]

The first exploit using this technology should be called "corrosion".

Re:NaCl

[Attila Dimedici]

Except that this will never be as widely referred to as either MS Windows or Apple computers.

Re:NaCl

[Attila Dimedici]

And as you might remember, that programming language was almost dead on arrival.

Re:NaCl

[blair1q]

I don't know if I've heard anyone since high school chemistry refer to salt as "NaCl". It's "salt" or "sodium chloride".

Re:NaCl

[Attila Dimedici]

I say "sodium chloride", but I usually write NaCl. Of course, that is when I don't simply say or write "salt".

Re:NaCl

[shutdown -p now]

It's called "Native Client". "NaCl" is just an abbreviation (and a pun attempt).

Re:NaCl

[c0lo]

The first exploit using this technology should be called "corrosion".

And the protection against the exploits? "Paint Symantec Antivirus" or "Intel Electro-plating Suite"?

NaCl?

[Anonymous Coward]

is theproject named "Salt"?

Re:NaCl?

[Tr3vin]

Yes. The media framework (audio, OpenGL, etc) is called Pepper.

Re:NaCl?

[alostpacket]

Well, it is for pouring on the wounds of browser security

Re:NaCl?

[Tr3vin]

While I appreciate the funny mod, it wasn't meant as a joke. http://code.google.com/chrome/nativeclient/docs/reference/pepperc/index.html

Re:NaCl?

[QRDeNameland]

Maybe they were laughing about all the PP references in the Pepper API?

Re:NaCl?

[Anonymous Coward]

About all those PP references:

The C API is divided into three sub-groupings, indicated by the prefixes PP, PPB, and PPP.
. . .
The prefix "PP," used to help prevent naming collisions, stands for "Pepper Plugin"
. . .
Interfaces implemented by the browser are prefixed by "PPB" where "B" stands for browser.
. . .
Interfaces implemented by the Native Client module (Plugin) are prefixed by "PPP" where "P" stands for plugin.

So PPP stands for "Pepper Plugin plugin"? LOL. No that's not confusing at all.

New vector for web-based asalt!

[rwa2]

Oops, sorry for spelling "assault" wrong. Sodium Chloride indeed. nyuk nyuk

NaCl + GAE

[rumith]

Can't wait for this thing to get hooked to App Engine once they are both stable enough. The results will likely be breathtaking, to say the least.

this is a terrible idea

[digitalsushi]

I am qualified to comment because I have skimmed the article summary. Furthermore, I know perfectly well that any time a browser allows for new features, it's a way to get hacked by eastern bloc countries. Finally, I can't remember why I was angry in the first place, but I can guarantee you that if whatever it was is also the reason the honeybees have been dying off. I am getting so sick of this stuff!

Re:this is a terrible idea

[Anonymous Coward]

Damn Bulgarians!

Re:this is a terrible idea

[sunderland56]

Maybe you're angry because you're reading this on an iPad. Or most other tablets. Or an iPhone. Or an Android phone. Or an older Mac.

...sent from my SparcStation

Re:this is a terrible idea

[Anonymous Coward]

I am qualified to comment because I have skimmed the article summary.

I would have said over-qualified.

ActiveX revisited?

[H0p313ss]

So a proprietary, but open SDK to run native binaries on one vendors browser. What could possibly go wrong?

I hope Google put a heck of a lot more effort into security/sandbox issues than Microsoft did or I'm going to have to start telling people to never install Chrome. ActiveX was the best attack vector for Windows for the longest time, and as far as I know it's still pretty effective against the great unwashed who will click anything to make a dialog go away.

Re:ActiveX revisited?

[TheRealMindChild]

That is because ActiveX is just a DLL. Loading an ActiveX library is just loading a DLL. It isn't ActiveX that is the problem, but the fact that you are allowing any site to install and run a DLL. You don't even need to load your own anymore. Just have a handy exploit for Adobe Flash, load random flash object to make sure the browsing party has the DLL(s) installed and loaded, then exploit Flash. Same goes for Java. And that zynga "helper" you have from Facebook...

Re:ActiveX revisited?

[morcego]

Shouldn't we ask a different quest ? Like: is it possible to put ENOUGH effort into it to make it secure ? Remember that, not only they need to avoid exploitation of the plugin (whatever) itself, they need to avoid exploitation of the browser, Windows API etc.

Re:ActiveX revisited?

[H0p313ss]

Shouldn't we ask a different quest ? Like: is it possible to put ENOUGH effort into it to make it secure ?

Good question. I do not believe it is possible to make a native binary safe, but then I'm just a computer geek with a degree in the subject and a decade of professional experience. Who am I to question the great Google.

Re:ActiveX revisited?

[Anonymous Coward]

If you follow up on what this actually means in practice, the way these native modules are loaded is in a sandboxes process that disables all access to system calls (file read write, dll hooks, new process execution, etc). The modules interact through a "simple IPC" mechanism that is allegedly easy(er) to secure than arbitrarily complicated code.

ActiveX had no such sand boxing restrictions. ActiveX was closer to browser plugins in that they have complete, pretty much unrestricted access to the system.

Start here on the sandbox process:
          - http://www.chromium.org/developers/design-documents/sandbox
          - http://www.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ

If this works as advertised (is actually safe), I would expect the general architecture to be adopted across any piece of software that speaks on the network (i.e. complex protocol parsers and validators in a sandbox).

Re:ActiveX revisited?

[Anonymous Coward]

Well I don't think you need to worry about people installing Chrome because the Native Client stuff is not enabled by default in Chrome.

I'm not sure what the point of this is though, if you're delivering native binaries you might as well just install the application locally. Consider (as the article mentions) a NaCl version of Photoshop. Well, you would have to download the entire app every time you use it? Why not just install Photoshop?

Re:ActiveX revisited?

[Dunbal]

Why make it secure, when there is money to be made by having it INsecure. Trust Google...

Re:ActiveX revisited?

[H0p313ss]

I'm not sure what the point of this is though, if you're delivering native binaries you might as well just install the application locally. Consider (as the article mentions) a NaCl version of Photoshop. Well, you would have to download the entire app every time you use it? Why not just install Photoshop?

I suspect it's perceived to be easier to users manage and maintain. The road to hell is paved with good intentions.

I had to point out to my management years ago that any kind of software install is effectively a violation of security. As a vendor it is not a question of IF you violate security, it's a question of HOW.

I suspect that the corporate IT world will come down on end-users who use Chrome like a ton of bricks if this gets any traction.

Re:ActiveX revisited?

[H0p313ss]

Why make it secure, when there is money to be made by having it INsecure. Trust Google...

Do not attribute to malice that which is more adequately explained by stupidity.

Re:ActiveX revisited?

[suy]

You probably should start reading about it first, please. The browser doesn't allow you to run native binaries of the system, or native code in general. It allows you to run very constrained routines in assembler code, but a very limited set of instructions, only the ones that can be secured enough. That's why you need an specialized SDK: the generated binaries have to use a very reduced set of machine instructions.

The great benefit of this, is that the generated ".nexe" files are portable accross operating systems. Basically, is a way to run heavy routines in C/C++ instead of JavaScript. The API is limited too.

It's pretty cool in the sense that you could do fancy graphics or UIs without Flash or Silverlight. You could write them in Qt or GTK+ or SDL, and the generated executable works on every OS (you'll need a recompile for ARM phones though).

If it can be refactored to a plugin for every browser, this will be the best Flash/Silverlight killer ever.

Re:ActiveX revisited?

[gstrickler]

So a proprietary, but open SDK to run native binaries on one vendors browser. What could possibly go wrong?

Good questions. I'm not saying that I think it's a good idea, but there are significant differences from ActiveX. First off, it's sandboxed, it doesn't have native access to the OS, only native access to the CPU and only in ring 3. Second, it's single browser, but cross platform (Runs on Chrome on Linux, Windows, and Mac OS).

Of course, the fact that 32-bit code won't run on a 64-bit system and vise-verse is a (possibly minor) disaster waiting to happen. Add ARM on Android smartphones and you've definitely created a monster. Unless it becomes available in other browsers, it just further segments the market for minimal benefit.

Re:ActiveX revisited?

[VGPowerlord]

Why make it secure, when there is money to be made by having it INsecure. Trust Google...

Do not attribute to malice that which is more adequately explained by stupidity.

Do not attribute to stupidity that which is more adequately explained by greed.
-- Enron's razor

Re:ActiveX revisited?

[Anonymous Coward]

Really? Because a little-known piece of computer software called an OPERATING SYSTEM makes native binaries safe THE WHOLE TIME.

Hand your degree back and get it exchanged for a diploma in knee-jerk reactionism.

Re:ActiveX revisited?

[Anonymous Coward]

It depends on how you define "native". On x86 since 286, you can use the vm86 features to run app code natively but with privileged instructions trapped for handling by the parent; only some esoteric instructions could not be virtualized effectively (and they failed safe), so a modern compiler could just avoid them. I would also be interested to see what someone could do by adapting the newer virtualization support features for running small applications rather than an entire guest OS image.

People put too much faith in "interpreted" virtual machines or "trusted computing" which eventually roots trust in industry or in naive users. They do not magically provide security any better than hardware virtual machines. All of them can be rendered pointless by developers trying to cram in too many nice, convenient features for the kinds of apps people want. Those features inevitably lead to escalation/circumvention.

The hardest part of this is not the VM container itself, but the policy management of the container to provide the right least-privilege rights to each sandboxed application. I personally do not trust browser vendors to do this right, and Google has demonstrated with Android that they don't get it either. (For example, they place the desire to serve ads and perform analytics at greater importance than my desire to block pointless traffic or privacy-infringing tracking features. I should be able to amend and further restrict policies on my devices.)

Re:ActiveX revisited?

[SuperSlacker64]

Have you ever heard of caching? In theory, if the binary code hasn't changed, then if the NaCl module is cached properly, you'd only have to download it the first time. Of course, you'd have to redownload it anytime it changes on the server, but look at it this way - you get instant access to updates.

And if you read the article, Google's purpose in this is not to create huge, full applications in native code and then run them through the browser, but combine this native calculations with the cloud. In Photoshop, that might mean your computer's GPU handles all the image processing, but all the data to save and export to different formats is sent to the cloud for processing. Or, Google Docs' spreadsheets could offload all the cell formula calculations in native code, rather than sending a request back to the server. The point of this native code is to speed up lots of little actions, not build entire applications.

Re:ActiveX revisited?

[H0p313ss]

Really? Because a little-known piece of computer software called an OPERATING SYSTEM makes native binaries safe THE WHOLE TIME.

ORLY?

Re:ActiveX revisited?

[thePowerOfGrayskull]

The ability to run these binaries must be explicitly enabled by the user, so no reason to avoid Chrome just yet ;)

Re:ActiveX revisited?

[Anonymous Coward]

"Why make it secure, when there is money to be made by having it INsecure. Trust Google...

Do not attribute to malice that which is more adequately explained by stupidity.

Do not attribute to stupidity that which is more adequately explained by greed.
-- Enron's razor"

Bud: At least one of these options is worse, now I need to figure out which one.

Bud's friend: Well since there's lots of all three, what difference does it make as they're all bad, just kill them already.

Re:ActiveX revisited?

[moonbender]

I don't see why the multiple architectures would be a problem. I don't understand why they don't run 32-bit code on downwards-compatible 64bit machines... But I guess for people developing NaCl code, it'll just be normal to compile their code for multiple architectures including ARM.

Re:ActiveX revisited?

[swilly]

According to Wikipedia, they are planning to support LLVM to provide platform independence. Since the technology is still being developed, it's possible that native x86 instructions may just be a bootstrapping step and not a final feature, though I haven't seen anything from Google that suggests this.

Re:ActiveX revisited?

[sexconker]

Why make it secure, when there is money to be made by having it INsecure. Trust Google...

Do not attribute to malice that which is more adequately explained by stupidity.

Do not attribute to stupidity that which is more adequately explained by greed.
-- Enron's razor

You can never have too many razors.
--Gillette's Razor

Re:ActiveX revisited?

[Asm-Coder]

Wait, Windows 7 is an OS right? Sweet I'm safe from viruses! Let me just uninstal my anti-virus....

Win7: Would you like to run "Please_send_my_passwords_to_hackers_in_Russia.exe"?
Me: Sure why not, my OS wouldn't let a native binary do anything unsafe...

Re:ActiveX revisited?

[Anonymous Coward]

Imagine if all you could do is run ring 3 code with no in/out - imagine if there was no IO mapped into your address space.
Now you can write any code you like that does ABSOLUTELY NOTHING AT ALL. No screen, no network card, no mouse, no keyboard, ABSOLUTELY NOTHING.

I'd imagine it's pretty easy to secure a machine in that case.

Re:ActiveX revisited?

[shutdown -p now]

Good question. I do not believe it is possible to make a native binary safe

I highly recommend that you actually read what NaCl is all about. The idea is to use various tricks about x86, such as memory segmentation, to produce a subset of opcodes which can be statically verified to be memory-safe, or otherwise easily intercepted by the sandbox. The subset is still large enough that you can compile C code efficiently into it, but you can't just take any random binary and run it in NaCl - you need to use their own toolchain.

(I've no idea what tricks they have used on ARM)

Re:ActiveX revisited?

[H0p313ss]

Imagine if all you could do is run ring 3 code with no in/out - imagine if there was no IO mapped into your address space.
Now you can write any code you like that does ABSOLUTELY NOTHING AT ALL. No screen, no network card, no mouse, no keyboard, ABSOLUTELY NOTHING.

I'd imagine it's pretty easy to secure a machine in that case.

Indeed, back when I did my intelligence indoctrination it was drilled into me that the only way to secure a computer was to put it in a locked room with tempest level isolation. The next step is to remove the power supply and throw away the key.

Re:ActiveX revisited?

[H0p313ss]

The ability to run these binaries must be explicitly enabled by the user, so no reason to avoid Chrome just yet ;)

Thats true of lots of the most effective attack vectors, the problem is the users.

Re:ActiveX revisited?

[Kalriath]

So basically, they're reimplementing .NET ClickOnce? Yeah, because that went well.

Re:ActiveX revisited?

[Anonymous Coward]

A lot of 32-bit code will run on a lot of 64-bit systems, Solaris and Linux included - I do it a lot, and so does my employer on their Solaris servers. The other way around would not work though, so you got that half right.

Re:ActiveX revisited?

[Anonymous Coward]

If it can be refactored to a plugin for every browser, this will be the best Flash/Silverlight killer ever.

Not that this isn't a very cool technology, but you forget how much easier it is to code for Flash/Silverlight than C++. This is not going to "kill" anything until the legions of web developers and programmers brought up on a diet of high-level languages suddenly embrace native coding. Sure, you could port a VM to run inside NaCl and execute a high-level language, but then what's the point?

Re:ActiveX revisited?

[Daniel Phillips]

It isn't ActiveX that is the problem, but the fact that you are allowing any site to install and run a DLL.

Your comment should be rated -5, clueless. The problem is what the native code is able to do, which only incidentally includes loading DLL's. Hostile name code running with any privilege at all on your system is a recipe for rooting, particularly if that system is a Windows box but not only.

Re:ActiveX revisited?

[Anonymous Coward]

... in assembler code, but a

Fag, I think you meant assembly code.

that you could do fancy graphics or UIs without Flash or Silverlight. You could write them in Qt or GTK+ or SDL, and the

Anything written with those will be complete kludges of shit. They will not be fancy.

Re:ActiveX revisited?

[suy]

That's exactly the point for Google. One of the demos is Quake inside the browser, and in one Google I/O conference (IIRC the last one), they showed the Lego Star Wars game. They wish they can sell you all sorts of games through the Chrome Store (replace games with video edit apps, or any kind of software that requires heavy use of the CPU).

Re:ActiveX revisited?

[thePowerOfGrayskull]

Well - the impression left by TFA is that the user isn't even told or prompted about it - if it's not enabled, it just won't work. No banner or popup requesting permission to enable.

Re:ActiveX revisited?

[H0p313ss]

That's not so bad, but still leaves open the case of there being multiple users sharing a login, one being aware of the setting and the other not. Scarily common.

Re:ActiveX revisited?

[russotto]

Good question. I do not believe it is possible to make a native binary safe, but then I'm just a computer geek with a degree in the subject and a decade of professional experience. Who am I to question the great Google.

It's certainly possible to make a native binary safe; full virtualization will do it. Given that, I find it hard to believe that it's possible to decide a priori that it is impossible to do it with anything less.

Re:ActiveX revisited?

[Rich0]

So a proprietary, but open SDK to run native binaries on one vendors browser.

Actually, more like: So a proprietary, but open SDK to run native binaries on one vendors browser on a subset of platforms.

How will this work for 64-bit users, how will this work for people running arm (you know, anybody with a phone, etc), and so on?

I don't have a big problem with the principle, but I'd prefer something that works on any platform. Otherwise I can look forward to another whole wave of new IE6-only websites, except now it is Chrome/Win32-only, or whatever.

Light on details

[pclminion]

The article is light on details, but they do say that the executables are contained in .nexe files which are apparently NOT your run-of-the-mill PE format, so they can't just execute from a double click. And they do say that there's this annoying multi-second lag as the thing fires up. From this, I assume they are doing dynamic code instrumentation to implement whatever security measures they have in place.

If done correctly, this can be secure. I've been working with Intel's Pin library a lot lately, mostly for security-related projects. With these sorts of things you can intercept all memory accesses, function calls, system calls, instrument and analyze arbitrary instructions in arbitrary ways, etc. Again, if done correctly a dynamic instrumentation approach could make this idea viable. But you'd need a very skilled team to do it right.

Re:Light on details

[JackDW]

Sounds likely, but if that's the approach, then why use native code at all? If you are going to effectively do JIT compilation on x86 code, turning it into more x86 code with extra safety checks, then why not instead do the JIT compilation on something intended to be JIT-compiled? For instance you could serve up some intermediate representation of the program, like LLVM bitcode. But that just sounds like Java or C#...

Re:Light on details

[slart42]

NaCl in it's current implementation is not JIT compiled. It is actual compiled native x86 (or x64 or arm) code running in a secure sandbox. What causes a delay is the Validation of the code, ie, the code has to meet certain requirements to be secure. That said, Google has plans for PNaCl, "portable" nacl, which indeed uses LLVM bytecode, making it a JIT implementation. Why not just use JavaScript? Having access to a lower level language and to being able to reuse tons of existing code is a big plus. Think porting existing game engines to the web.

Re:Light on details

[pclminion]

It's not a huge investment. x86-to-x86 translators have existed for a while. Being able to use pre-existing native code is an enormously attractive possibility. This gives developers the ability to take pre-existing software and directly target it to Chrome without porting to another language or even recompiling it (I presume there will be a utility which converts .exes and .dlls into .nexe format)

Re:Light on details

[larry bagina]

Maybe google engineers want to show off how smart they are by validating x86 code. And x64 code. And ARM code. Or maybe it's a poorly thought out research idea. At least they are working in PNaCl, which uses llvm bytecode instead of x86/x64/arm/mips/???.

Re:Light on details

[pclminion]

How well does the validation engine cope with code that's deliberately obfuscated? I don't know for sure, but I suspect that proving code is safe using static analysis is probably NP-complete. Dynamic instrumentation would make it much easier to implement sandboxing -- all operations which aren't explicitly permitted are forbidden, and you simply stop the code when it tries to do one of those forbidden things.

Re:Light on details

[JackDW]

Thanks, that's very informative. I wonder what is involved in validation, and what restrictions are imposed to ensure the code is actually safe? Sounds like a tricky problem - difficult enough that it's previously only been solved by (1) restricted languages like Java and C#, or (2) in hardware, with protected memory and access to the OS only via system calls. To do it with arbitrary x86 code is certainly interesting. I wonder if this could be useful not just for browsers, but even entire OSes where memory protection is not necessary because all incoming code is fully validated.

Re:Light on details

[Trepidity]

Doing it optimally probably isn't possible, but you can statically transform code so it's guaranteed safe by doing somewhat pessimistic transformations, things like replacing every store instruction with a sequence of "safely store" instructions. As long as the analysis and transformations are at the assembly level and don't require recognizing higher-level patterns, obfuscated code isn't really an issue; the main issue is making sure you correctly analyze what safe and unsafe asm instructions are, and what transformations are guaranteed to result in safe code.

There's a nice writeup here of how they do the transformations on ARM.

Re:Light on details

[Anonymous Coward]

But you'd need a very skilled team to do it right.

Or a million monkeys on a million typewriters for a million years.

Re:Light on details

[EvanED]

Proving general code safe using static analysis is undecidable (that whole halting problem/Rice's theorem thing).

However, that doesn't mean you can't do something like what the JVM does: impose extra requirements that go beyond safety. That is, reject huge swaths of safe programs because they are too hard to prove safe, and just make it so that your SDK doesn't generate code like that.

Re:Light on details

[ewibble]

It is impossible to completely analyse code, maybe you can determine if it is malicious I don't know but you can't even tell if it terminates

Proof by contradiction:

Assume A is a program that returns true if the parameter P terminates and false if it does not

Write a program B

if A(B) then while 1

since B does not terminate if A says it does and does if A says it doesn't that program cannot exist

Re:Light on details

[pclminion]

I think most of us are familiar with the proof of the Halting Problem. However, all it proves is that there exists a program which can't be shown to halt or not halt. It doesn't prove that there is a great class of such programs. It could be that all realistic programs can be proven to halt. I think we shouldn't use the Halting Problem as an excuse not to research the topic.

Re:Light on details

[Carewolf]

Instrumented binaries are not currently faster than interpreters, they are useful for debugging and auditing, but they are not quite native in performance. With CPU having virtual machine extensions these days, virtual machines have performance similar to non-virtual machines, and would in my mind make more sense. Then again I am not sure what Google are doing. It sounds like they are just OS sandboxing it, like running the browser in chroot as the nobody user.

Re:Light on details

[Goaway]

How well does the validation engine cope with code that's deliberately obfuscated?

It rejects code it cannot analyze. In practice, this means many instructions are forbidden. You use a specific compiler tuned to only output legal code when you build for it.

Re:Light on details

[Goaway]

The first step is learning about the halting problem.

The second step is realizing that it is completely irrelevant in the real world.

Re:Light on details

[Anonymous Coward]

If done correctly, this can be secure.

facepalm.

Re:Light on details

[jthill]

See for yourself. Basically, if your code is simple enough that their static analyzer can completely comprehend it, you're good to go.

Looks to me like they know what they're doing:

Our validator implementation requires less than 600 C statements (semicolons), including an x86 decoder and cpuid decoding.

. which I figure is simple enough to tempt lots of smart people into trying to break it for kudos.

A link I didn't save says the implemented safe subset is complete enough that porting even many substantial libraries to the NaCl runtime takes no more than a recompile.

Re:Light on details

[ewibble]

It is not irrelevant the principle is the same you are trying figure out what a program is doing. You write your program and say here you go see if you can write something that breaks it.

It makes sense when you don't have a malicious force trying to break the program, since static analysis can pick up a lot of bugs, but it also picks up a lot of complete nonsense as well.

To write a program that detect if another program is malicious is very very hard (not in terms of computational complexity) otherwise why do we keep getting virus scanner updates. Its a circular battle, just like the halting problem no matter what you get someone will always be examine the code generate some sequence instructions that your program does not check.

Checking instructions as they are executed is a much simpler proposition. And when it comes to security simple is by far the best its hard enough get an interpreter checking the instructions at runtime.

It is not the Halting problem but it is similar in nature.

I am not even sure this is how the code is checked, the article glossed over the how security was ensured.

Re:Light on details

[Goaway]

You could actually try going to the NaCl homepage and reading their papers on what they are actually doing before you start making long arguments about it.

Also, you still haven't mastered that second step, it seems.

Re:Light on details

[EvanED]

It most definitely isn't irrelevant (at least once you extend it to Rice's theorem) in the real world. It may not be particularly relevant to NaCl, but that's not the only thing out there.

You can argue that some other things are more relevant in program analysis (e.g. the fact that language inclusion even between nondeterministic finite automata is PSPACE-complete, or that language inclusion between context-free languages is undecidable) than that you can't talk about arbitrary programs, but it's still important.

Re:Light on details

[shutdown -p now]

I don't know for sure, but I suspect that proving code is safe using static analysis is probably NP-complete

This is dealt with by proving that code is not unsafe instead (which is a different problem, as this allows for false positives). Which is precisely what any sandboxed VM out there, like Java or .NET, have been doing for ages. You usually start by throwing out all instructions that aren't easily verifiable.

Re:Light on details

[Anonymous Coward]

Hopefully reject it.

Remember, proving that code is safe or unsafe is only NP complete when you accept no false negatives. A test "Is this precisely Hello, World?" obviously is non-NP complete, and has no false positives. It just has a shitload of false negatives. A saner validation would expand on the number of allowed programs.

Re:Light on details

[ayvee]

I suspect that proving code is safe using static analysis is probably NP-complete.

I believe it's undecidable. Rice's theorem.

Re:Light on details

[Anonymous Coward]

But on an actual machine there are only a finite number of bits of state available. You just simulate the execution of the code over all possible inputs and check every state. It may take a long time, but it can be done.

In the same way, the halting problem is decidable on an actual machine. You just execute the thing until it either halts or enters a state it has previously been in, in which case you know it never halts. Because there are a finite number of possible states this can be done in finite time.

Re:Light on details

[c0lo]

then why not instead do the JIT compilation on something intended to be JIT-compiled? For instance you could serve up some intermediate representation of the program, like LLVM bitcode. But that just sounds like Java or C#...

Exactly... uh... the patent suites with Oracle.

Re:Light on details

[bucky0]

I read another article, and it's actually pretty slick, I'll quote it so I don't screw it up:

  Native Client sets up x86 segments to restrict the memory range that the sandboxed code can access. It uses a code verifier to prevent use of unsafe instructions such as instructions that perform system calls. In order to prevent the code from jumping to an unsafe instruction hidden in the middle of a safe instruction, Native Client requires that all indirect jumps be jumps to the start of 32-byte-aligned blocks, and instructions are not allowed to straddle these blocks.

Re:Light on details

[kyz]

How well does the validation engine cope with code that's deliberately obfuscated?

Very well. It rejects it outright.

Disassemble the binary blob. Reject it if you see any instructions you don't allow or don't know how to handle. Reject if it jumps into the middle of any other instructions, or outside its area. Reject if it tries to modify the segment registers. Reject if you find unreachable code.

I'm going to go out on a limb and say that it's very unlikely that you'll be able to break out of the sandbox. The most likely vector of attack is a carefully formatted IPC message between the sandbox and the browser to exploit a bug in the browser, or get the browser to unwittingly inject code into the sandbox, because the sandboxed code is verified that it can't do that itself.

Re:Light on details

[russotto]

Our validator implementation requires less than 600 C statements (semicolons), including an x86 decoder and cpuid decoding.

Haha, abuse of the comma operator FTW!

Re:Light on details

[Anonymous Coward]

Don't be helpless -- read the paper and find out for yourself: http://nativeclient.googlecode.com/svn/trunk/src/native_client/documentation/nacl_paper.pdf

Re:Give it the registry.

[TaoPhoenix]

That might take 10,000 lines of code. What are the chances of an error in that?

Why????

[Thoreauly Nuts]

What is with this urge over the last decade to make the browser an OS?

I already have an OS. It plays movies, games, and anything else I throw at it. I don't need to run a 2nd OS on top of it to replicate the functions of the original.

Maybe we can come up with something to replace the browser that runs inside our current browser and then replicate everything again. If we can replicate functions twice, why not three or more times?

Re:Why????

[Ancantus]

If you havn't noticed, one of Google's intents is to make the browser you go-to place for all your needs (kinda makes sense with their business plan). And honestly i think that it is a worthy goal. This way people can make cross-platform applications and a way to distribute them all on one platform.

Re:Why????

[Anonymous Coward]

Maybe we can come up with something to replace the browser that runs inside our current browser and then replicate everything again. If we can replicate functions twice, why not three or more times?

Done.

Re:Why????

[gstoddart]

Maybe we can come up with something to replace the browser that runs inside our current browser and then replicate everything again.

Yo Dawg, I hear you liked to browse ... so I put a browser in your browser, so now you can browse while you're browsing.

Re:Why????

[dave420]

So you can turn *any* computer into your own simply by logging in to it. It's like roaming profiles, but even more useful. Not everyone sits in front of the same hardware all the time as you seem to.

Re:Why????

[DataDiddler]

Except there's already VNC, ssh, and bootable USB drives. This tech seems excessively redundant and, as has been pointed out, dangerous if not handled with the utmost (idiot-proof) care.

Re:Why????

[Anonymous Coward]

You're completely missing the point. The goal is total cross-platform software development, using the ultimate software distribution system, the world wide web. As it stands, if you want to build something like Photoshop and offer it to as many people as possible, you have to write a Windows version, a Mac version, a Linux version, possible versions that run on tablets such as Honeycomb or iPad, and then there's various mobile devices. With this tech, you build one version that works on EVERYTHING.

However, this is all theory, and the goal of true cross platform software development is still along way away.

Re:Why????

[Tubal-Cain]

I already have an OS. It plays movies, games, and anything else I throw at it. I don't need to run a 2nd OS on top of it to replicate the functions of the original.

ChromeOS. This will allow it to have real applications. Correct me if I'm wrong, but doesn't Native Client in Chromium imply that a ChromeOS app can be written once and run on any platform with Chromium? The ability to support 4 or 5 platforms, without any effort put into porting...certainly not something to be dismissed lightly.

Re:Why????

[Jon Stone]

The "OS" is less and less an OS. It is increasingly becoming an application that runs on top of another OS (VMWare/Xen/etc). It's the VM layer that handles all the things OS's traditionally handled, like the hardware device drivers and resource management.

Re:Why????

[Hatta]

Which is a great way to nullify all the benefits of being able to choose your own platform.

Re:Why????

[Anonymous Coward]

Microsoft solved that problem 15 years ago.

Re:Why????

[c0lo]

What is with this urge over the last decade to make the browser an OS?

Because the use of the cloud grew beyond what's economically viable to maintain. Therefore, there is a need to use the CPU-es of the local machine to off-load some... well... load from the cloud but still keep you captive in the "fog" of the cloud.

Re:Why????

[c0lo]

Except there's already VNC, ssh, and bootable USB drives..

Except that these technologies have the following disadvantages:
a. use something else than HTTP - so they cannot be that easily tracked and logged by your ISP at the request of the govt. This is a situation the govts start hating and should be stopped, together with the use of encryption
b. these technologies don't keep you prisoner in the cloud - this is a situation the cloud owner hates.

NaCl is very useful...

[coolmoose25]

I use it all the time... I put it on french fries. I spread a lot of it on my driveway and sidewalk this year. The only real drawback is the high blood pressure that can result if you consume too much of it.

Re:NaCl is very useful...

[Dunbal]

Yeah and too much of it can kill you...

Re:NaCl is very useful...

[H0p313ss]

Yeah and too much of it can kill you...

Of course that's also true of O2 and H2O.

Re:NaCl is very useful...

[Anonymous Coward]

yeah I had a buddy that thought inhaling some h2o was a good idea...needless to say he is now 6 feet under

Re:NaCl is very useful...

[Anonymous Coward]

Yeah, I even hear Angelina Jolie worked on it or something...

Re:NaCl is very useful...

[Anonymous Coward]

How long did it take to come up with that zinger?

Re:NaCl is very useful...

[Anonymous Coward]

Hopefully you actually put iodized NaCl on your french fries, not rock salt. Otherwise those are french fries of doom, and high blood pressure is nothing compared to your hypothalamus failing to leak good stuff (technically).

Re:NaCl is very useful...

[rcamans]

You are supposed to use the supplied blood thinner with it. It's called Vodka.

Re:NaCl is very useful...

[NaCl]

I know!

Re:this is *not* a terrible idea

[djbckr]

I too am qualified to comment. I'm not fully convinced it's a great idea, but I like the idea of running "next to the hardware" code in a sandbox (the browser). It's sort-of the best of virtualization (sandbox, controlled by the browser) and C-style performance.
I don't see this as something that would be extensively used on a lot of web sites, and there are potential security issues that need to be scrutinized, but it's another tool available to developers. I like it.

When Microsoft thought of it...

[Anonymous Coward]

When Microsoft thought of this (ActiveX) everyone thought it was stupid! When Google thinks of it, people are open to it. We'll have to wait for Apple to invent it for it to be wonderful!

Re:When Microsoft thought of it...

[Anonymous Coward]

We'll have to wait for Apple to invent it for it to be wonderful!

I think you mean magical.

Re:When Microsoft thought of it...

[c0lo]

When Microsoft thought of this (ActiveX) everyone thought it was stupid! When Google thinks of it, people are open to it. We'll have to wait for Apple to invent it for it to be wonderful!

Apple won't... at least not until it will own a cloud.

lol

[Anonymous Coward]

I personally wager my karma on this:

LOL! STFU AC FGT

Crazy smart? No, just crazy

[mrjb]

Basically this technology turns the browser from a platform-independent, architecture-independent development platform into an architecture-dependent one. That is, if somebody developed their little app for Intel and I'm on a Mac or Arm, the app won't work for me.

From where I stand, that's no better than being forced to VNC into a Windows box just so that I can access an ActiveX based site which will only run on Explorer.

ActiveX also is a nice case study to show what the tech would be used for- which is, about 50% of the time to exploit security holes, and 49% of the time, to do stuff that could just as well have been accomplished through W3C standards or (much more portable) Java.

Bad idea. *flush*

Re:Crazy smart? No, just crazy

[VolciMaster]

Basically this technology turns the browser from a platform-independent, architecture-independent development platform into an architecture-dependent one. That is, if somebody developed their little app for Intel and I'm on a Mac or Arm, the app won't work for me.

Macs for the past several years have been running Intel CPUs.

Re:Crazy smart? No, just crazy

[suy]

That is, if somebody developed their little app for Intel and I'm on a Mac or Arm, the app won't work for me.

Wrong. The NEXE files are OS independent. You will need a recompile for ARM though. Why don't you at least read the FAQ?

Re:Crazy smart? No, just crazy

[slart42]

Basically this technology turns the browser from a platform-independent, architecture-independent development platform into an architecture-dependent one. That is, if somebody developed their little app for Intel and I'm on a Mac or Arm, the app won't work for me.

While it may look like this short term, fragmentation is not the goal. Currently, NaCl has compilers for x86, x64 and arm, and in most cases code working on one should compile and work on the others without changes. Long term, the idea is to use LLVM bytecode to solve this problem for all architectures. As for browser compatibility, Google is actively encouraging other browser makers to pick up the tech, which is all open source.

While JavaScript may have it's use, it's going to be a while before the next high performance killer app/game/whatever is written in it. Since Chrome OS will be browser only, they need some lower level tech to run apps on it.

Re:Crazy smart? No, just crazy

[Anonymous Coward]

yeah, I don't understand it either.

Re:Crazy smart? No, just crazy

[c0lo]

From where I stand, that's no better than being forced to VNC into a Windows box just so that I can access an ActiveX based site which will only run on Explorer.

From where google stands, it's wonderful: keep you tied to thier clud but offload the CPU load on your personal machine - less carbon tax to pay, less CPU-es to add, cheaper for them. Doesn't it make sense now?

Re:Crazy smart? No, just crazy

[Sureshot324]

Technically Java isn't platform independent either. It only runs on whatever platforms Sun has released a JRE for, which is most of them. If the SDK for NaCl generates 32bit and 64bit executables for both x86 and ARM, they have at least 99% of the market covered.

Re:Crazy smart? No, just crazy

[mrjb]

Basically this technology turns the browser from a platform-independent, architecture-independent development platform into an architecture-dependent one.

Wrong. The NEXE files are OS independent. You will need a recompile for ARM though. Why don't you at least read the FAQ [google.com]?

Before shouting "Wrong" to people maybe you should read what they've written first? NEXE may be OS independent, but not architecture independent. Native client is x86 only. So unless your browser runs on a machine with an Intel-compatible CPU, NEXE won't run. All the hard-won abstraction layers of hardware just go *whooosh* down the drain. Bad idea.

Re:Crazy smart? No, just crazy

[suy]

Native Client requires an implementation for each architecture, true, exactly the same thing that happens with native compilers. Since the project is still young, they started with x86 and it might be the more mature implementation, but there are versions for x86-64 and ARM. You only need a recompile to target different architectures. The API is cross-platform.

For the purpose of NaCl, all the abstraction layers of hardware are the problem, not the solution. Sometimes you just need the extra performance (or the possibility of using C/C++ code for a web tool).

Re:Crazy smart? No, just crazy

[Anonymous Coward]

Umm, I think the compiler chain will just cross-compile binaries for a bunch of different architectures.

TL;DR

[Anonymous Coward]

I think Google is doing a poor job of communicating the true niche for this: simple "snippets" that augment a mostly HTML-based app. I just see it as a native-speed canvas element. The article sort of mentions that, but only at the end.

but...

[advocate_one]

I'm NOT running an x86 capable processor...

Re:but...

[Baloo Uriza]

Yeah, I was wondering if anybody was going to bring that up. Seems really quite silly and stupid unless this is architecture-independent.

Re:but...

[VolciMaster]

I'm NOT running an x86 capable processor...

You have an Itanium, too?

Re:but...

[3vi1]

Cell phones and tablets are mostly ARM. NaCl is mostly useless unless you want to prop up power-sucking Intel CPUs and their x86 monopoly.

Re:but...

[simula]

Please do the smallest amount of research before posting with such conviction.

Re:but...

[Anonymous Coward]

PNaCl runs on arm using LLVM.. NaCl is just a stepping stone on the roadmap to supporting a variety of CPU architectures..

Re:but...

[blair1q]

No, a Phenom.

Re:but...

[Anonymous Coward]

No, actually they have ARM compilers, intel 64 bit compilers, and they're working on an llvm implementation.

Re:but...

[Xtifr]

Sparc, but thanks for asking. :)

Re:but...

[DaVince21]

RTFA. The compiler will be able to compile to other architectures, and the browser will detect this and use appropriately compiled .nexe file.

Re:but...

[Anonymous Coward]

Please keep your comments rextricted to the artificial reality imposed by the article summary as not everyone has all day to read the internet.

Static analysis

[Anonymous Coward]

Static analysis can make this safe, but only if the API is limited to a browser specific API which implements all the necessary access restrictions. The problem with ActiveX was that it allowed access to the entire Windows API, not that it ran native code. Of course then you have to perform the static analysis instead of the just-in-time compilation of Javascript, and the limited API means you can't reuse existing code. So given the platform dependency, I don't think it's going to be that great. I've kinda gotten used to not caring about underlying processor architectures.

JavaScript

[neoform]

Why not just work on making JS more efficient, and if needed, give it more capability?

Applets were explored in the past and died because they were not what people wanted..

Re:JavaScript

[shutdown -p now]

JS is inherently hard to make more efficient due to the dynamic, weakly typed nature of the language. There is already some very advanced predictive type analysis done in the likes of V8 to make it run as fast as it does, but, ultimately, it's much easier to do on a more low-level language where all types are explicit. This thing is basically about taking that approach to the extreme.

Re:JavaScript

[DaVince21]

Because apparently making JS more efficient isn't sufficient. I mean, they've been doing that for quite a while and are apparently reaching some limits.

Project Codename?

[Anonymous Coward]

Does this x86 Native Client project have a double naught spy secret code name? If not, I propose to give NaCl the code name "Salt". I know, you are sitting there reading this and thinking Wha? , but I really think if you really tried, you could somehow in some chemical way associate NaCl with Salt.

Re:Dawg

[TaoPhoenix]

Bowser! Come here boy!
Oh wait...

Like Java, without the JVM

[Animats]

That's been around for a while. x86 machine code has to be written in a special way which prevents certain problems, such as buffer overflows into return addresses. Google has a modified GCC for this. Read the research paper. It uses the rarely-used segmentation protection features of x86 CPUs to help provide an inner section of sandboxing. That's not enough, though; static analysis of the code, to check that all branches go to valid instructions, is necessary. This works much like the Java byte code verifier, the checker that runs as Java code loads. All returns and calls have to go through some extra code to insure that control goes where it is supposed to.

The 64-bit extensions to the x86 instruction set don't have the segmentation machinery. The AMD designer of that mode once told me "nobody uses that". So this approach doesn't translate well to 64-bit code, and all code under this system runs in 32 bit mode.

This comes with an API and an OS shim. Executable modules can make about a hundred system calls, which are portable across Windows and Linux. In the original version, you couldn't get at the graphics hardware, so it wasn't a suitable delivery mechanism for games. But now, Google has a connection to OpenGL in the thing. That makes it more useful. Games with full system performance could be delivered through this approach, while appearing to run within the browser. The performance is about 90 to 98% of unprotected code.

It's very clever, and a good idea from a security standpoint. Untrusted processes communicating through narrow interfaces are always a good thing from a security perspective. The problem is that it doesn't solve a problem that anybody really seems to have - there's little demand for higher performance apps in the browser.

Re:Like Java, without the JVM

[gmaslov]

The problem is that it doesn't solve a problem that anybody really seems to have - there's little demand for higher performance apps in the browser.

I like the rest of your post, but this sentence is a little short-sighted. If there's anything that the march of progress in computing has taught us, it's that if the capability is there, someone will invent a useful demand.

Re:Like Java, without the JVM

[H0p313ss]

there's little demand for higher performance apps in the browser

As much as I hate the idea of a browser that is able to run downloaded native binaries, I have to disagree here. In the corporate enterprise world there is a HUGE demand for this since it centralizes and simplifies the software distribution problem.

Re:Like Java, without the JVM

[pclminion]

The problem is that it doesn't solve a problem that anybody really seems to have - there's little demand for higher performance apps in the browser.

It has very little to do with performance and a whole lot to do with being able to use pre-existing binary-only code safely.

Re:Like Java, without the JVM

[Metabolife]

I imagine a Photoshop app where rendering is done server side and client side in parallel. This can also lead to cloud vendor using your computer to perform calculations for others. Can you say distributed, decentralized, cloud computing?

Re:Like Java, without the JVM

[Animats]

It has very little to do with performance and a whole lot to do with being able to use pre-existing binary-only code safely.

No. The code has to be recompiled with a modified compiler, and has to use the special cross-platform API. Porting isn't a big job, but you do need the source code. Read the tech paper.

Re:Like Java, without the JVM

[John Hasler]

This can also lead to cloud vendor using your computer to perform calculations for others.

We already have this. It's called a botnet.

Re:Like Java, without the JVM

[daboochmeister]

there's little demand for higher performance apps in the browser.

Tell that to my poor Pentium4 struggling with the new SlashDot interface!

Re:Like Java, without the JVM

[rrohbeck]

So what prevents people from modifying their gcc to allow malicious code?

Re:Like Java, without the JVM

[Anonymous Coward]

Honestly, it's taking the Java design model and applying VMware to the solution.

Not bad afterall.

Re:Like Java, without the JVM

[Anonymous Coward]

The problem is that it doesn't solve a problem that anybody really seems to have - there's little demand for higher performance apps in the browser.

Video games that don't require Windows. I could see Google trying to convince some studios to develop in this manner. It helps them as much as it hurts Microsoft.

Re:Like Java, without the JVM

[lewiscr]

there's little demand for higher performance apps in the browser.

That's what everybody said before Chrome improved JS performance. Now there's an arms race to get better performance from apps in the browser. Where have you been?

Re:Like Java, without the JVM

[slapys]

The problem is that it doesn't solve a problem that anybody really seems to have - there's little demand for higher performance apps in the browser.

I think the coolest potential for this idea is to recompile existing well-written native applications (e.g. photo editors, IDEs) so that they run from the browser with exactly the same appearance as their native counterparts. This would bring the idea of a thin client laptop computer that runs a web browser only closer to reality.

Re:Like Java, without the JVM

[Anonymous Coward]

The problem is that it doesn't solve a problem that anybody really seems to have - there's little demand for higher performance apps in the browser.

Unless you're google, and you want *everything* to be able to be done in the browser. This is just one step closer to making your OS irrelevant. Not to mention the fact that I'm sure the creative people of the internet will come up with a use for their newfound power.

Re:Like Java, without the JVM

[Jeremi]

So what prevents people from modifying their gcc to allow malicious code?

Nothing... but it wouldn't do them much good, since the NaCL client would detect the non-compliant instructions in the downloaded binary, and refuse to run it.

Re:Like Java, without the JVM

[bucky0]

Read the paper, but to ruin it for you, the code is compiled in a way that the client can verify quickly and accurately the safety of the code. Bad binaries can be detected on load by the client.

Re:Like Java, without the JVM

[drfreak]

there's little demand for higher performance apps in the browser

I beg to differ. There are a ton of typical client apps which have been re-worked to run as a browser app. I won't name names, but just about every one of this class of "convert" apps has the issue of performance when used in a browser vs. a fat client app everyone is trying to avoid nowadays but actually runs much faster.

If a browser-based GUI app can run with comparable performance to its executable-native-client counterpart, then web 2.0 is official. Until then, all apps in that class are really what I'd call web 1.0.1.

Re:Like Java, without the JVM

[Animats]

I have to disagree here. In the corporate enterprise world there is a HUGE demand for this since it centralizes and simplifies the software distribution problem.

Yet Java applets, which have many of the same properties as programs run in this sandbox system, have almost disappeared. The killer seems to be that you can't start execution until all the code is loaded. That's why Javascript and Flash won out over Java and Shockwave. The latter two are far more powerful than the first two, but you have to wait for loading.

Re:Like Java, without the JVM

[laddiebuck]

I've RTFA, though not the research paper. I don't understand what prevents someone from compiling some C with a malicious nacl compiler (one that makes no bones about, say, jumping to evil memory locations) and serving it up?

Regardless, what worries me about the transition from a VM to native code is that every implementor has to get it really right. Securing interpreted code is really easy: you can just restrict the API. Securing a VM is harder (witness Flash) but still doable (witness Java). But securing native code means you have to have a really good team and be really careful, and almost certainly at some point some bug will slip through (witness the remote root in OpenBSD of all things). I like the stupid solution because it's reliable and secure and they can do wonders with optimising it these days anyway...

Re:Like Java, without the JVM

[FrangoAssado]

I've RTFA, though not the research paper. I don't understand what prevents someone from compiling some C with a malicious nacl compiler (one that makes no bones about, say, jumping to evil memory locations) and serving it up?

You should really read the paper, they address this concern and many others. Basically, they have a way to validate the binary (regardless of where it came from) that ensures it can't break out of the sandbox. The validator allows only a limited subset of instructions ("ret" is not allowed, and jumps are severely restricted, for example). It's simple enough (600 lines of code) to be easily checkable by hand by many different people, so we can be reasonably sure it contains no nasty bugs.

Just use a less privileged user

[subanark]

The OS can protect your system by having users that don't have full access to your system. Just apply that concept to these processes. You can remove all the safety overhead that Java and Flash provide while still preventing the process from harming any process except itself. By allowing use of C, you allow people to leverage a lot of existing libraries, which avoids the problem of introducing a new language. However, I really have doubts about being cross platform. Flash and Java do this fine (as long as you do all your own painting, instead of relying on a smart GUI that matches the platform).

Re:Just use a less privileged user

[c0lo]

The OS can protect your system by having users that don't have full access to your system. Just apply that concept to these processes. You can remove all the safety overhead that Java and Flash provide while still preventing the process from harming any process except itself. By allowing use of C, you allow people to leverage a lot of existing libraries, which avoids the problem of introducing a new language. However, I really have doubts about being cross platform. Flash and Java do this fine (as long as you do all your own painting, instead of relying on a smart GUI that matches the platform).

Well, yes... but... if you apply common-sense, how can google keep you captive to the cloud?

Re:Just use a less privileged user

[kaffiene]

What's nuts, is if they had produced this... 15 years ago, it'd be amazing. Java promised this kind of functionality but was way too slow. These days, Java has all the safety, portability etc but the performance issues are gone. I don't see what problem Google are solving.

Re:label yourself a "computer scientist"?

[gmaslov]

Look at HTML, look at Javascript, look at all that: what have webprogrammers been doing for the last decade? Yes, a browser is ALREADY A VIRTUAL MACHINE RUNNING YOUR APP. That is where this was all going! HTML+JS was just ONE instance of that, but you could allow any kind of bytecode/machine code/whateverexecutablething for the same effect.

Yes, this is a good generalization and an interesting idea. But I would argue that HTML+JS, or even Java, is still better than using native machine code. My main beef with this NaCl system has to do with the fact that x86 isn't the only platform out there. FTFA, every NaCl app already has to be compiled twice -- once for x86-32, once for x86-64. How many web developers will bother to also recompile their app for ARMv7, PowerPC, Itanium? When we all migrate to the latest and greatest ISA for our mobile devices in 2025, all the closed-source apps from 2015 that their maintainers have abandoned will be unusable. JavaScript and Java don't have this problem. The best you could do would be to package some sort of dynamic recompilation engine with NaCl to translate between machine languages... but that seems a rather roundabout way of arriving at the JVM, doesn't it?

Mod Parent Nonsense

[Anonymous Coward]

I don't see how this comment makes any sense. App Engine is a platform for creating webapps. This would let you run binaries in a browser. It's quite a stretch to see any synergy between the two.

NaCl

[Attila Dimedici]

I'm sorry, but calling it NaCl is just asking for people to be confused when it comes up in discussion. We already have enough problems with people using the intials of something where by pure happenstance those initials are the same as some more common reference. Now we have Google intentionally using the chemical abreviation for salt for this new initiative of theirs. If this was something that endusers could add to any software to amplify some aspect of the software (not that I can imagine how that could be done), then I would see comparing it to salt to be a potentially usefull comparison. However, this just doesn't work. I can't see how this is in anyway like salt.

I really wish...

[Spazmania]

I really wish folks wouldn't intermix this crap with a web browser. I'm all for having some kind of a cloud browser for accessing Internet-based applications with the client running java or nacl or whatever. But when I'm surfing the web looking at untrusted sites, I don't want ANYTHING running browser-side. Not even javascript.

Re:I really wish...

[blair1q]

Too late for that. Ask for a checkbox to disable it and you'll get the same effect you get with JavaScript now.

Re:label yourself a "computer scientist"?

[GameboyRMH]

Apart from the security catastrophe this would surely cause, it's a bad idea because it's architecture-specific. Name one other web technology that is, apart from shitty ActiveX that nobody uses (and is also OS-specific and browser-specific). Go on. I'll wait.

You can talk to anyone with a PhD in computer science and they'll tell you the same thing. You can call them all short-sighted idiots too if you like.

The REAL Chrome OS

[Yuioup]

Gentlemen, let me present to you the REAL Chrome OS. Run native apps directly in your browser, straight down to a hypervisor. Windows and Linux need not apply.

Re:The REAL Chrome OS

[Enderandrew]

That is what I've been saying ever since ChromeOS has been announced. Everyone said it was crazy to ship an OS that was only a browser, and basically couldn't run anything.

Consider now that the entire OS is locked down and fairly secure. Consider how the browser also keeps NaCl in a sandbox. And now you have perhaps a very simple and secure way to run all kinds of apps with the OS that no one was taking seriously.

Re:The REAL Chrome OS

[blair1q]

Everyone said it was crazy to ship an OS that was only a browser, and basically couldn't run anything.

Not everyone. I distinctly remember reports that Bill Gates openly discissed his fear that computers would become entirely browser-based and make operating-system user interfaces obsolete, killing his company. IIRC, it was one of the things that justified developing .NET.

Re:The REAL Chrome OS

[Anonymous Coward]

Consider how the browser also keeps NaCl in a sandbox.

Wouldn't it be better to keep NaCl in a salt shaker?

Re:The REAL Chrome OS

[Anonymous Coward]

+1
Hurrah, all the way down here before somebody said it! Absolutely spot on IMHO

Re:The REAL Chrome OS

[c0lo]

And now you have perhaps a very simple and secure way to run all kinds of apps with the OS that no one was taking seriously.

Huh? But it was taken seriously long ago... started with emacs!!

Inner Platform Effect?

[Draaglom]

http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx

+1 Parent

[Anonymous Coward]

The idea is web servers running your native code (or within 5% of its speed) securely on Google's servers. Even DOTNET vm running on AppEngine! (Not that i'd want taht, quick to add before i get stoned)

Re:+1 Parent

[burnstone]

The idea is web servers running your native code (or within 5% of its speed) securely on Google's servers. Even DOTNET vm running on AppEngine! (Not that i'd want taht, quick to add before i get stoned)

You know, reading the name of the project, I'd assume it runs on the client. As in, in the browser.

How exactly would you run a browser on AppEngine?

Re:+1 Parent

[Korin43]

Yeah I really wish there was a way to run native code on a web server.

Re:+1 Parent

[Goaway]

There's nothing browser specific about the base technology. It's just that their main use case for it is in the browser. They could fairly easily adapt it for running code on the app engine, if they wanted.

Re:Give it the registry.

[ciderbrew]

about 10,000 chances

Missed the obvious motive.

[140Mandak262Jamuna]

Most obvious motive for doing this is to allow corporations that are stuck with old unmaintainable "applications" a way to get it running under Linux/ChromeOS/Android eventually. An escape hatch from the MS. Suddenly all those "apps" are ported to Linux, upgraded to run on the latest hardware, protected by the latest sandboxes. They can technically run IE6 under NaCl in ChromeOS. This does not have to make any money for Google.

Google seems to have fully realized that as long as the Windows/Office monopoly is pumping billions of dollars into the coffers of Microsoft, it can simply wait out any competitor. Unless holes are poked in that firehose Google is just one stumble away from being vaporized. So it does what it can to make sure Microsoft plays defense.

Re:Missed the obvious motive.

[Anonymous Coward]

Under Chrome OS only (yes Chrome within Ubuntu and other select distros but how long will Chrome be on Linux? Probably discontinue it if Chrome OS becomes popular - Embrace, Extend, Extinguish). This isn't about Linux. Google has no commitment to Linux. In fact it has a vested interest in Linux's desktop marketshare not improving.

Re:Missed the obvious motive.

[Anonymous Coward]

Running in Chrome, nothing really to do with Linux. Google have a vested interest in Linux's desktop marketshare not increasing.

Re:Missed the obvious motive.

[Anonymous Coward]

Which is?

They have a vested interest in decreasing Microsoft's control which Microsoft achieve primarily through Windows and Office, if Google can decrease Windows market share, but the user can still use a Google browser they win. Now Google might not care what users switch to as an alternative to Windows so long as they use Google products, but I don't see why they have a vested interest in Linux desktop market share not increasing.

Browser as OS

[md65536]

This would run only "pure" native code, and not access any OS features of the main OS on the client's machine. Any OS features would be provided by the browser. In a sense the browser would implement a virtual machine and become an OS running on top of any other OS that Chrome runs on.

Google wants control of as much of "app space" as they can, as all the major players do... Not necessarily for dominance; it may simply be to get around the dominance of others. For maximum control, you control the OS (ideally, the processor as well, then you really can do whatever you want to iphone).

Google can create its own OS and try to get people to use that...
or it can just build an OS into its browser and say "who cares what OS you have underneath, I'mma ignore it."

Yes, different native binaries need to be compiled for each architecture supported, but they already do that for Android with NDK. It's not "that bad" because there aren't a lot of architectures that need to be supported, and one can compile for all of them on a single machine. However, it supports monopolization of architectures and suppresses alternatives.

Eventually, Google will be making its own processors. You'll run Chrome in whatever OS you have, and Chrome will encourage you to go fullscreen, and then it'll take your OS out back and beat it up, and you'll say to Chrome "Ok how do I switch back to other windows?" and it'll say "Windows? What's that?"

Re:Browser as OS

[blair1q]

Oh. So you've met Android.

Re:Browser as OS

[zero0ne]

So that means:

1) Write an OS within NaCl - creating an OS within a browser based OS within an OS within a VM on bare metal.
2) Place adverts on all levels
3) ....
4) Profit?

Re:Browser as OS

[c0lo]

So that means:

1) Write an OS within NaCl - creating an OS within a browser based OS within an OS within a VM on bare metal.
2) Place adverts on all levels. Keep the consumer's data on ransom in the cloud. Reduce the cloud's CPU cost by using as much as possible the CPU of the "consumer"
3) ....
4) Profit?

FTFY.

First step to being the OS

[JustNiz]

The blatant security issues of allowing websites to download and execute native code far outweigh any benefits. Even Google must know that.
So it seems that this is really just a first step to rid PC's of Windows OS entirely, such that the PC boots right into a browser.
As far as I'm concerned, even though the superficial concept sucks, separating the mainstream from its Microsoft addiction would be worth the price.

Re:First step to being the OS

[c0lo]

As far as I'm concerned, even though the superficial concept sucks, separating the mainstream from its Microsoft addiction would be worth the price.

Yes, I agree... getting rid of the heroine addiction using LSD... totally worth it, man!

Re:Give it the registry.

[lwriemen]

Lines not words. You need to multiply by at least two.

Crazy smart ISA portability

[simula]

Native Client was designed to easily allow portability across all popular current platforms using cross-compilation. On a single development machine you can currently build executables for x86-32, x86-64, and arm. There is currently support for Windows, Linux, and OSX. Here is an article on the generals.

Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture. Here is a pdf concerning that effort.

You are also significantly underestimating the effort that they have put into this BSD licensed project.

Re:Crazy smart ISA portability

[blincoln]

Because cross-compilation works so well for making it 100% seamless to compile regular C code across multiple architectures?

Even setting aside the potential security issues, and the potential "why isn't there support for my platform" issues, I'm pretty sure introducing the possibility of things like endianness problems into *web applications* makes this a terrible idea.

Seriously, this has got to have been invented by someone who wasn't around when the alleged benefit of migrating everything to web apps was platform-independence. If you want native code, write a traditional native client. Apple figured this out with iOS, and it seems to be working out pretty well for them.

Re:Crazy smart ISA portability

[shutdown -p now]

Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture.

So, how is that any different from, say, HotSpot JVM? And why didn't they start with this approach? Why even bother with all the tricks needed to ensure a secure sandbox for native code (which really are creative), if you then move onto a conventional JIT-compiler, anyway?

Re:Crazy smart ISA portability

[Anonymous Coward]

> across all popular current platforms

No matter how you call it that will be breaking what the web has been designed for: run everywhere even on the most exotic platform. It's no better than Flash, or any platform dependant extension.

Please google, don't break the web.

Re:Crazy smart ISA portability

[bucky0]

I honestly think you should read up on what they're doing. I had the same questions, read their pages and it makes 9x more sense

Re:Crazy smart ISA portability

[Anonymous Coward]

Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture. Here is a pdf concerning that effort.

Okay, this is a fine idea. Just one problem here, why the heck is this being based on ia32?! If you're going to design a bytecode, design it around a sane VM, such as perhaps Dalvik. Even for the modern AMD and Intel processors the "machine language" is merely a bytecode they translate in real time to the actual processor hardware. Given these factors, you want a bytecode optimized for size and ease in translation to real hardware, things not present in ia32.

Re:Crazy smart ISA portability

[Anonymous Coward]

Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture.

Ok, NOW we're talking. I've been proposing a similiar idea for years!

I may be suffering from buzzword syndrome

[pugugly]

But going from this (particularly the C/C++ friendliness), you could almost run a Unix/Linux implementation across the entire cloud, with each browser being a separate 'login'?

It almost seems designed with that as a goal.

Pug

DRM

[benob]

This technology is only intended for one thing : Digital Rights Management. Delivering binaries, that's what they want to do...

Time to dust off the old software

[ArhcAngel]

This is great news! Now I can pull up that copy of VisiCalc.

Re:Give it the registry.

[Anonymous Coward]

Optimist.

MOD PARENT DOWN.

[Anonymous Coward]

Jesus Christ, that was horrible, you feel very bad for that.

Re:MOD PARENT DOWN.

[rwa2]

lol, if I'm going down, I'm taking your Nerd Card with me! :-P

Re:label yourself a "computer scientist"?

[gtall]

It is a bad idea because of the architecture and OS specific part. It is not clear it is security problem though. It presumably runs in ring 3, so all OS traps, naughty memory traipses, etc. can be caught. What specific security problem do you expect it to cause?

I can only think of one, if there is a problem in the underlying OS....well, since we're probably talking MS here, multiple security problems in the underlying OS that can be accessed through OS traps that go to kernel mode or any that MS left out in user land.

Chrome + Salt = Rust

[mevets]

Seems google took more than the tech talent from the rotting corpse of Bell Labs. They seem to have captured the marketing folks as well.

Re:this is *not* a terrible idea

[blair1q]

pithy response either incorporating trending memes or exploiting unclosed double-entendres in parent post

RDA Pedantry

[Anonymous Coward]

Salt is bad if you already have hypertension, but does not cause it (that we've been able to prove so far).

Re:label yourself a "computer scientist"?

[GameboyRMH]

CPU microcode vulnerabilities could also be exploited, such as this one:

http://www.networkworld.com/community/node/39825

Um

[Anonymous Coward]

I don't get Google's motivation with Chrome Browser.

So I need to install an OS on a computer, install a browser, and then install native x86 apps in the browser.

I can understand Chrome OS motivations, but this is just ridiculous. How many layers of software between me and my hardware do I need to achieve the same results.

I am not sold on the idea of interacting with an OS that is just a tabbed browser environment, and I think Google better start rethinking their whole Chrome OS strategy because I have not seen a lot of positive comments about Chrome OS as a whole. Android is headed in the right direction as a great mobile OS platform, but I will never want to use a browser based OS, ever.

We have tried this with Java, Flash, Silverlight, etc, running "applications" with a software layer between the platform OS and the user, how many times are we going to have to repeat this mistake?

Don't get me wrong, at least Google is coming up with new innovations and concepts, but I think they have to move out of the browser if they want to be a serious competitor to Windows or any other "traditional" OS.

Re:Um

[c0lo]

How many layers of software between me and my hardware do I need to achieve the same results.

Just enough to boost Google profits. Year-on-year.

NaCl Useful for

[jluzwick]

"McAllister explains what NaCl is useful for" Cookies, brownies, Tortilla chips... with guac.... mmmm

Re:NaCl Useful for

[Megane]

Don't forget keeping sidewalks and roads from getting iced up in the winter!

H2O poisoning

[Anonymous Coward]

Sadly, I can confirm that H2O poisoning is actually a serious issue. My mom worked in a mental health ward. A patient had the idea, "Water is good for me, more water must be better.' That patient ended up drowning in their own body tissue (basically, the lungs couldn't keep the water out). Mom says it was one of the worst things she has ever seen.

Only wish I were joking.

Re:H2O poisoning

[Anonymous Coward]

ROFFLE LAWL!

Won't work on 64-bit Windows

[Myria]

Unlike 32-bit Windows, 64-bit Windows does not provide user-mode programs the ability to create arbitrary selectors. NtSetLdtEntries returns STATUS_NOT_IMPLEMENTED in 64-bit Windows. In fact, in Vista 64 and XP 64, the kernel does "xor eax, eax \ lldt ax" and never touches LDTR again. This means that even drivers couldn't create selectors on behalf of user-mode programs, because the Windows scheduler does not save or restore LDTR during a task switch.

This is absolutely core functionality that is necessary in order for this to work - if user mode can't create selectors with shorter limits, Google's design plain doesn't work.

In contrast, even in 64-bit mode, Linux allows modify_ldt() and Mac OS allows i386_set_ldt(). In fact, this functionality is the only reason WINE is possible on these platforms.

Re:Won't work on 64-bit Windows

[Nimey]

Cite?

Re:Won't work on 64-bit Windows

[Shados]

Then explain how the guy in the article ran them in Windows 7 64 bit without any issue?

Re:Won't work on 64-bit Windows

[bsy_at_play]

see http://nativeclient.googlecode.com/svn/data/site/NaCl_SFI.pdf for the sandboxing schemes for x86-64 and arm.

Re:Won't work on 64-bit Windows

[Myria]

Cite?

.text:000000014007B8C0 ZwSetIoCompletionEx proc near
.text:000000014007B8C0 ...
.text:000000014007B8D4 mov eax, 164h
.text:000000014007B8D9 jmp KiServiceInternal
.text:000000014007B8D9 ZwSetIoCompletionEx endp

.text:000000014007B8E0 ZwSetLdtEntries proc near
.text:000000014007B8E0 ...
.text:000000014007B8F4 mov eax, 165h ; syscall of ZwSetIoCompletionEx plus one
.text:000000014007B8F9 jmp KiServiceInternal
.text:000000014007B8F9 ZwSetLdtEntries endp

.text:0000000140081300 KiServiceTable ...
.text:0000000140081E20 dq offset NtSetIoCompletionEx
.text:0000000140081E28 dq offset xKdSetupPciDeviceForDebugging ; symbol shared for many unimplemented syscalls

.text:0000000140105210 xKdSetupPciDeviceForDebugging proc near
.text:0000000140105210 mov eax, 0C0000002h ; STATUS_NOT_IMPLEMENTED
.text:0000000140105215 retn
.text:0000000140105215 xKdSetupPciDeviceForDebugging endp

Re:Won't work on 64-bit Windows

[Myria]

see http://nativeclient.googlecode.com/svn/data/site/NaCl_SFI.pdf for the sandboxing schemes for x86-64 and arm.

Interesting, and a pretty cool trick that I should try. However, that won't help 32-bit browsers running on 64-bit Windows. You'd either have to always use a 64-bit browser or come up with a segment-less sandbox implementation in 32-bit mode.

Re:Won't work on 64-bit Windows

[bsy_at_play]

32-bit browsers running on 64-bit windows can launch another 64-bit executable.

Re:Won't work on 64-bit Windows

[evilgrug]

You keep making all these comments without RTFA, which clearly states the author's 32-bit version of Chrome needed a 64-bit executable.

Re:Won't work on 64-bit Windows

[Anonymous Coward]

Yeah, we discovered this some time ago and it is exactly why NaCl also implements an x86-64 sandbox which doesn't rely on x86 segmentation.

Re:Won't work on 64-bit Windows

[Anonymous Coward]

umm I don't know what you're talking about but the article says you're wrong

Re:this is *not* a terrible idea

[Joe Snipe]

My parent's are unclosed double-entendres, you insensitive clod!

Re:label yourself a "computer scientist"?

[maxwell demon]

Just integrate Bochs into your browser. :-)

Erghhh, wryyyy

[Anonymous Coward]

This is a good idea for a few specific things that JAVA is already used for.

Games it is not useful for. Why waste the effort on making it run in the web browser when you can just make a native game client without the browser overhead?

Now the LLVM part which makes it portable between OS and Processor type is interesting, even for games. This does away with some of flash's shortcomings (mainly Adobe's lack of commitment to actually updating things in a reasonable timeframe, OpenVG, x64 and multicore, hello?)

However I'm assuming Google is actually going to release a SDK for this that gives access to OpenGL,OpenVG,OpenAL,OpenCL on the native hardware along with access to native video playback. All I really see this being used for is proprietary DRM schemes. Since the script kiddies are all gung ho about breaking or pirating everything that isn't nailed down, I don't see this as ever becoming anything mainstream, and in all likeliness is all about trying to get this technology into GoogleTV, Android, and PC's not being the real target at all. Forget Dalvik.

excuse me?

[Anonymous Coward]

WTF is Natrium Chloride doing in a browser? FAIL.

Salt!

[euxneks]

NaCl is salt isn't it?

Re:Salt!

[SpinyNorman]

Yep, and and Native Client (NaCl - salt) uses a browser plug-in interface called pepper. Tasty stuff!

Re:Salt!

[Anonymous Coward]

Thanks, Einstein.

Re:Give it the registry.

[dkleinsc]

At least 0.01% per line.

Re:this is *not* a terrible idea

[gman003]

Obligatory "I for one welcome our new memetic overlords".

Re:label yourself a "computer scientist"?

[jthill]

That's why they're going for PNaCl.

NaCl?

[Anonymous Coward]

NaCl? I think they should just call it salt like normal people.

Portable NaCl makes sense, other versions DON'T.

[pslam]

Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture. Here is a pdf [llvm.org] concerning that effort.

The LLVM version is the ONLY version which should exist. It's funny that the LLVM version is called Portable Native Client because that infers that the x86/arm version is the Non-Portable Native Client. Damn right.

So what happens if I'm not x86-32, x86-64 or arm? What if I'm MIPS, running on a set-top box? What about Itanium? What about one of the lesser known architectures out there? Do I add support to NaCl, then ask every web developer in the world to recompile?

That's NOT how the web is supposed to work. This is an abomination of a web tech - it simply should not be promoted. Portable NaCl, fine, because architecture support means adding LLVM support, and doesn't require a recompile.

It's not like I have to recompile my HTML every time someone invents a new CPU.

TO: PayPal - Courage To Resist and Bradley Manning

[Anonymous Coward]

RE: Courage To Resist and US Army Pfc. Bradley Manning

Due to PayPal's recent policy decision to suspend the the account of Courage to Resist, a non-profit raising defense funds for US Army Pfc. Bradley Manning, (and additionally, previous policy decisions regarding WikiLeaks, et all) PayPal will no longer enjoy my business, the business of people like me, nor, to the extent that my personal and professional influence allow, the business of my professional, personal and familial relations.

Until such time as this policy decision -- to which no legal authority has bound PayPal to implement -- is reversed, I personally will:

- No longer make purchases using paypal as a payment method.

- No longer accept paypal as a payment method for personal transactions.

- No longer accept paypal as a payment method for business transactions.
- No longer conduct business with entities (for example, ebay sellers, web stores) whose only payment method is PayPal and, when I find this to be the case, contact the seller to tell them that their strict alignment with PayPal is the cause of their lost business.
- No longer recommend the services of PayPal to friends, family or anyone else.
- In short, I will no longer conduct business with PayPal in any way.

Furthermore, to the extent that my influence allows, I will seek to discourage all others from conducting business with Paypal in any way, including but not limited to those outlined above, and encourage them to seek out competing payment providers for their transactions.

Finally, I will contact major online retailers who accept PayPal as a preferred means of payment to inform them that PayPal's policy decision is having a direct, negative consequence on their active user base from myself and others like me who view this decision as detestable, and contrary to the freedom of individuals in this and other countries.

All such consequences could have been avoided, had PayPal not made the decision to freeze the account of a non-profit organization collecting defense funds for an American Citizen and Service Member. All such consequences can still be avoided by reversing this decision and releasing due funds in full to Courage to Resist, but until such time as that happens I consider PayPal to be an enemy of Freedom, Due Process, and the Human Right to Conscientiously Object To, and Oppose, what they truly believe to be Unjust.

My PayPal account will remain active for a period of two weeks hence, after such time it will be closed unless PayPal takes action now to resolve this matter in favor of Courage to Resist and US Army Pfc. Bradley Manning, issues a public apology, and commits to never again blockade the monetary means (either by witholding funds, or by preventing the collection thereof) to the legal defense of any individual or entity.

With Resolve,

Michael Thompson

Re:this may or may not be a terrible idea

[Anonymous Coward]

I am too qualified to comment.

NaCl vs SIPs

[Anonymous Coward]

I wonder how closely or distantly related NaCl techniques are when compared to Microsoft Research's SIPs (Software Isolated Processes) that too run native code in a sandbox (software isolation)...

Re:Give it the registry.

[Antisyzygy]

Lines have characters, variables, operators and syntax in them. You need to multiply by ALOT more than 2 as another post suggested. One time by accident I made a 1 character bug that totally ruined an entire experiment we were doing and about 40 hours of someone else's time. Now everyone gives me shit for it.

Re:this is *not* a terrible idea

[linhares]

pithy response either incorporating trending memes or exploiting unclosed double-entendres in parent post

You really must be new here

Salt?

[Anonymous Coward]

NaCl = common table salt

I thought we should limit the salt intake

Re:Salt?

[c0lo]

NaCl = common table salt

I thought we should limit the salt intake

Naah... You can have it as much as your kidney manage to eliminate. Beer helps.

Re:Salt?

[larry bagina]

Drinking saltwater is a dumb idea, but salt isn't evil. Drink your piss sometime. Taste salty? That's right, your body is quite efficient at getting rid of excess salt, minerals, vitamins (water soluble ones, at least), etc.

But, but, but, I ate 3 bags of potato chips a day for 60 years and now I have health problems! It must be the salt, couldn't possibly involve my lifestyle.

Re:Give it the registry.

[HomelessInLaJolla]

I did that, too. Dr. Square was running a COSY experiment on a 200 MHz Varian NMR. The system appeared to be locked and I _really_ wanted to take a single pass (16 or 32 scan) spectrum on a single experiment. The user's manual seemed to indicate that the twelve hour experiment's data was being saved on disk as it was acquired and that it would be possible to cycle the power, run my experiment, and then resume his.

I read something wrong. It wasn't being saved to disk as it was being acquired. He was pissed.

They'll put NaCl in a shaker.

[Anonymous Coward]

nm

Google should sink this ship now

[Anonymous Coward]

It doesn't matter how technically brilliant or carefully thought out this is. Nearly everyone is missing the point, including the article's author.

You can look at the tech and be impressed, after all.. Google does that well. The problem is that this is a partial solution which is still looking for a problem. There are emerging standards for interfacing web based apps with hardware, and these standards will be implemented across all browsers.. eventually. Nacl isn't standard. Mozilla, IE, Safari.. none of them are going to implement this interface.

That means that it's a non-standard browser specific implementation. Sound familiar to any web developers out there? Normally that one sentence gives people headaches, but here we are with the best and brightest who are praising this fragmentation. I don't care if it has the potential for world peace and to cure cancer .. if it's not supported across all browsers, I'm not going near it. This is a fundamental principle of web software implementation. There are emerging standards for interfacing with 3D hardware, standards which will be supported across platforms and browsers.. use those, leave Nacl in the wake of the future.

Besides 3D graphics, what local resources would you want to use? I can speed up a web service by utilizing an 800Mhz ARM tablet processor? Rubbish to that. Who's going to download massive payloads from powerful central servers to process them locally in a sandbox on a piddly portable machine? There's very specific circumstances under which local processing of data via a web interface will be useful, but Google is exposing MILLIONS of users to a potentially vulnerable browser integrated binary interface for the benefit of an extremely small minority. Doesn't this sound familiar?

one that's well worth watching if you're interested in future directions for the Web

That just begs one question, where do you want to go today?

Re:this is *not* a terrible idea

[Anonymous Coward]

I too am qualified to comment. I'm not fully convinced it's a great idea, but I like the idea of running "next to the hardware" code in a sandbox (the browser). It's sort-of the best of virtualization (sandbox, controlled by the browser) and C-style performance.

The problem is, if you have a site that needs this sort of performance, you will need that performance on all devices. Instead of having your web-based VM based on ia32, base it on a sane bytecode/VM, Dalvik anybody?

Re:Give it the registry.

[monkyyy]

not more then that, 10% ish maybe up to 50% if its someones new to it

Micro-VM

[kakazpl]

It could be sandboxed within micro virtual machine running Windows compatible micro OS.

It is faster than current JIT compilers

[r6144]

Yes, the LLVM version would be quite similar to a JIT compiler, but it is more efficient than most of the JIT compilers currently available. Unlike e.g. the Java VM, there is no need to do much bounds checking and type checking; for example, on x86-64 the code can have all kinds of buffer overflow problems, but the compiled code is generated in a way that makes it possible to verify before running that all stores can only end up in a 4GB slice of the address space, so other code running in the same process remain unaffected. As a result, it is possible to compile the large body of existing C code to run on the NaCl virtual machine, and have it run at about 90-95% the speed of ordinary C code. This is not possible on the JVM.

Moreover, there remains the possibility of processor-specific optimization using e.g. SIMD instructions. For example, if we want to make the JVM support AVX instructions, we need quite a bit of additional code in the JIT compiler, and usually some kind of API must be introduced so that the application can use these instructions manually (compilers are not yet so smart). On NaCl it is only necessary to modify the verifier so that only valid uses of these instructions are allowed; actual generation of the instructions is left to the ahead-of-time compiler, which hardly has to be changed if the new instructions do not make verification difficult.

Security details of NaCL - nothing like ActiveX

[Ed Avis]

Check out some of the papers from Google about how they do the security validation for Native Client - the Wikipedia article might be a good place to start. It's pretty cool - they define a restricted subset of x86 instructions which can be statically checked to prove they are safe (don't access memory outside a certain range, don't make system calls, etc). Then once the code has been verified, you can execute it and let rip! Kind of like the opposite approach to Java or .NET - instead of defining a new virtual machine, why not take an existing instruction set and modify it slightly to make it sandboxable but still execute at native speed?

Irony?

[rJah]

So they're making a browser that can run native code, and an OS that can't?

Dumb Google Idea that Fools Fall in Love With(tm)

[terjeber]

This is absurd, insane and stupid. What on earth would this accomplish. Just create a better JIT will you, and develop in Java.

NaCl?

[Anonymous Coward]

I'll take that with a grain of salt.

NOT ActiveX

[veldon]

From TFA:

NaCl's intended niche is as a method of allowing Web applications to execute complex algorithms at native speed. Picture 3D modeling for scientific applications, for example, or running complex graphic transformations in a Web-based paint program.

It is raw C/C++. It is platform-independent. Its limitation is the processor architecture. Binaries must be compiled for each architecture. The only similarity between this and ActiveX is that you are running a compiled binary.

IMO it is a dead end unless other browsers follow suit and allow compatibility with these modules, or Chrome takes a larger market share, possibly in the mobile space. Otherwise it will be difficult to convince the execs, directors, managers, etc. that it makes economic sense to produce yet another browser plug-in.

On the other hand it could make Chrome more of a specialty browser used in certain communities where you can't get the same functionality from other browsers for performance reasons.

WHY

[Anonymous Coward]

Please remind me.. I want to use a browser built by an advertising agency.. and allow them to run code on my machine.. why, exactly?

No fine-grained permission UI on Android

[tepples]

If Android is any indication of Google's commitment to security, a free wallpaper application will be able to read all your text messages and track your location in real-time.

Only if you explicitly give the app permission to do those things.

So how do I explicitly give the app permission to do some but not all of those things? Neither Android Market nor the "Unknown sources" APK installer allows the user any options between "grant all permissions requested by the package" and "cancel installation".

Origin

[tepples]

This is until the "consumers" will use mainly your technology and have all their data saved in the sandbox.

Then why doesn't it make a separate sandbox for each origin? I haven't had a chance to read the spec yet, and the Wikipedia article about Google Native Client is still a stub, but I'd imagine that it draws at least some boundaries between origins.

Hobson's choice

[tepples]

when you install an Android application it forces you to review the list of permissions the application is requesting.

And it gives me a Hobson's choice as to which permissions to grant: all or nothing. I can't cherry pick from the list.

Re:Hobson's choice

[GooberToo]

Cherry picking would be dumb because many applications would simply not function or would be completely unsustainable for the developer. And that's completely ignoring the massive support headache it would create for the developers, not to mention the massive increase in the testing matrix.

Such a statement is nothing but stupidity. That seems to go hand in hand with your constant trolling.

Modeling realistic programs as LBAs

[tepples]

It could be that all realistic programs can be proven to halt.

And if one models "all realistic programs" as all linear bounded automata, then yes, all realistic programs do halt.

A bytecode that's a subset of x86

[tepples]

Sounds like a tricky problem - difficult enough that it's previously only been solved by (1) restricted languages like Java and C#

And that's exactly how NaCl works. It verifies the code as if it were a bytecode with semantics that are a subset of x86 semantics, and then it hands the code off to the CPU to execute.

Testing on other architectures

[tepples]

they started with x86 and it might be the more mature implementation, but there are versions for x86-64 and ARM. You only need a recompile to target different architectures

So how do I test a Native Client module that will be deployed to the public without buying an x86 machine, an x86-64 machine, and an ARM machine?

Re:Testing on other architectures

[suy]

I would test it the same way I would test JavaScript code. With JavaScript, you don't have the certainty that the V8 engine behaves the same and has the same bugs on x86 and ARM, but in general it does (for the majority of cases). With other interpreted code, or with NaCl the situation is the same.

Locked-down devices with MIPS CPUs

[tepples]

So what happens if I'm not x86-32, x86-64 or arm? What if I'm MIPS, running on a set-top box?

Then even your PNaCl module won't carry the digital signature of your set-top box's manufacturer and therefore won't run. As I understand it, development of applications for set-top boxes is even more tightly restricted than for smartphones.

What about Itanium?

Native Client, not Native Server, at the moment.

How does a site become trusted?

[tepples]

I'm all for having some kind of a cloud browser for accessing Internet-based applications with the client running java or nacl or whatever. But when I'm surfing the web looking at untrusted sites, I don't want ANYTHING running browser-side. Not even javascript.

Then how does a site get promoted from "untrusted sites" to "Internet-based applications"?

Re:How does a site become trusted?

[Spazmania]

It doesn't. A site is a site. A cloud app is a cloud app. If I want to run a cloud app, I fire up the app runner. And I don't have to worry about sandbox security because I've chosen to run the app, no different than if I'd downloaded and installed it.

a bad java replacement?

[kaffiene]

I see nothing that this can do that Java couldn't - but safer and with portability.

But what's the difference?

[tepples]

A site is a site. A cloud app is a cloud app. If I want to run a cloud app, I fire up the app runner.

What is the fundamental difference in implementation between a browser for sites and an app runner for cloud apps? How do you run a cloud app that you have learned about from a site? And would you consider an online store a "site" or an "app"?

And I don't have to worry about sandbox security because I've chosen to run the app, no different than if I'd downloaded and installed it.

Some people are paranoid enough to use a sandbox even on applications that have been "downloaded and installed", such as Sandboxie for Windows or the jail facility in FreeBSD.

Sodium obvious

[Anonymous Coward]

Wonder if they'll end up calling it "Salt" instead of NaCl.