Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google x86 Native Browser Client Maybe Not So Crazy After All

CmdrTaco posted more than 2 years ago | from the because-you-can dept.

Google 332

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

cancel ×

332 comments

Sorry! There are no comments related to the filter you selected.

Not Java, more like Active X (3, Informative)

Anonymous Coward | more than 2 years ago | (#35301694)

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 (5, Funny)

WrongSizeGlass (838941) | more than 2 years ago | (#35301712)

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:Give it the registry. (2)

TaoPhoenix (980487) | more than 2 years ago | (#35301822)

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

Re:Give it the registry. (1)

ciderbrew (1860166) | more than 2 years ago | (#35302226)

about 10,000 chances

Re:Give it the registry. (1)

lwriemen (763666) | more than 2 years ago | (#35302460)

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

Re:Not Java, more like Active X (1)

Dunbal (464142) | more than 2 years ago | (#35302056)

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

ewibble (1655195) | more than 2 years ago | (#35302452)

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

AlecC (512609) | more than 2 years ago | (#35302504)

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 (4, Informative)

Enderandrew (866215) | more than 2 years ago | (#35302190)

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

ByOhTek (1181381) | more than 2 years ago | (#35302368)

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

toastar (573882) | more than 2 years ago | (#35302560)

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

Tubal-Cain (1289912) | more than 2 years ago | (#35302652)

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.

Like ActiveX? (1)

Anonymous Coward | more than 2 years ago | (#35301696)

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

Re:Like ActiveX? (1)

The MAZZTer (911996) | more than 2 years ago | (#35301796)

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

Re:Like ActiveX? (2)

jlechem (613317) | more than 2 years ago | (#35301854)

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? (4, Informative)

drspliff (652992) | more than 2 years ago | (#35302168)

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 [lwn.net] approach for Linux which is a true sandbox

Re:Like ActiveX? (2)

Dunbal (464142) | more than 2 years ago | (#35302090)

properly sandboxed

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

NaCl (1)

allo (1728082) | more than 2 years ago | (#35301722)

what will Daniel J. Bernstein say to the name?

NaCl? (0)

Anonymous Coward | more than 2 years ago | (#35301724)

is theproject named "Salt"?

Re:NaCl? (4, Funny)

Tr3vin (1220548) | more than 2 years ago | (#35301836)

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

Re:NaCl? (1)

alostpacket (1972110) | more than 2 years ago | (#35302060)

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

New vector for web-based asalt! (0)

rwa2 (4391) | more than 2 years ago | (#35301732)

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

NaCl + GAE (3, Interesting)

rumith (983060) | more than 2 years ago | (#35301750)

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.

Mod Parent Nonsense (0)

Anonymous Coward | more than 2 years ago | (#35302144)

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.

+1 Parent (0)

Anonymous Coward | more than 2 years ago | (#35302206)

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

burnstone (769550) | more than 2 years ago | (#35302342)

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?

this is a terrible idea (5, Funny)

digitalsushi (137809) | more than 2 years ago | (#35301772)

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 *not* a terrible idea (3)

djbckr (673156) | more than 2 years ago | (#35301936)

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.

ActiveX revisited? (5, Insightful)

H0p313ss (811249) | more than 2 years ago | (#35301774)

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? (4, Informative)

TheRealMindChild (743925) | more than 2 years ago | (#35301874)

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? (2)

morcego (260031) | more than 2 years ago | (#35301898)

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? (2)

H0p313ss (811249) | more than 2 years ago | (#35302022)

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? (0)

Anonymous Coward | more than 2 years ago | (#35302410)

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? (1)

H0p313ss (811249) | more than 2 years ago | (#35302494)

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

ORLY?

Re:ActiveX revisited? (0)

Anonymous Coward | more than 2 years ago | (#35302436)

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? (1)

Dunbal (464142) | more than 2 years ago | (#35302134)

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

Re:ActiveX revisited? (1)

H0p313ss (811249) | more than 2 years ago | (#35302260)

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. [wikipedia.org]

Re:ActiveX revisited? (2)

VGPowerlord (621254) | more than 2 years ago | (#35302406)

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? (4, Informative)

Anonymous Coward | more than 2 years ago | (#35302050)

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? (0)

Anonymous Coward | more than 2 years ago | (#35302112)

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? (1)

H0p313ss (811249) | more than 2 years ago | (#35302210)

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? (2)

SuperSlacker64 (1918650) | more than 2 years ago | (#35302480)

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? (4, Interesting)

suy (1908306) | more than 2 years ago | (#35302340)

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? (2)

gstrickler (920733) | more than 2 years ago | (#35302360)

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.

Light on details (4, Informative)

pclminion (145572) | more than 2 years ago | (#35301782)

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 [pintool.org] 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 (2)

JackDW (904211) | more than 2 years ago | (#35301914)

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 (3, Interesting)

slart42 (694765) | more than 2 years ago | (#35302026)

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 (3, Interesting)

pclminion (145572) | more than 2 years ago | (#35302178)

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 (3, Informative)

Trepidity (597) | more than 2 years ago | (#35302346)

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 [chromium.org] of how they do the transformations on ARM.

Re:Light on details (1)

JackDW (904211) | more than 2 years ago | (#35302256)

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

pclminion (145572) | more than 2 years ago | (#35302120)

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

larry bagina (561269) | more than 2 years ago | (#35302152)

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

Anonymous Coward | more than 2 years ago | (#35302576)

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

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

Why???? (1)

Thoreauly Nuts (1701246) | more than 2 years ago | (#35301866)

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???? (5, Interesting)

Ancantus (1926920) | more than 2 years ago | (#35301960)

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???? (0)

Anonymous Coward | more than 2 years ago | (#35301996)

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. [zcubes.com]

Re:Why???? (1)

gstoddart (321705) | more than 2 years ago | (#35302006)

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:Dawg (1)

TaoPhoenix (980487) | more than 2 years ago | (#35302126)

Bowser! Come here boy!
Oh wait...

Re:Why???? (1)

dave420 (699308) | more than 2 years ago | (#35302084)

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???? (1)

DataDiddler (1994180) | more than 2 years ago | (#35302198)

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???? (1)

Anonymous Coward | more than 2 years ago | (#35302234)

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???? (1)

Tubal-Cain (1289912) | more than 2 years ago | (#35302544)

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???? (1)

Jon Stone (1961380) | more than 2 years ago | (#35302612)

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.

label yourself a "computer scientist"? (-1)

Anonymous Coward | more than 2 years ago | (#35301868)

Imo this was blatantly obvious for at least half a decade now, and I personally wager my karma on this: ANY single one of you that calls himself a "computer scientist", a "good programmer", or whatever smug along those lines, tell me this:

Do you think this is a good idea? If not: you lose, in my book. I would not hire you (perhaps that is why I am not hiring (yet) :)). I would not consider you a good computer scientist. In fact, I would label you a short-sighted idiot.

Do you think this is similar to ActiveX? It is (or might be, if you wish), but that does not make it bad. One mistake can make something beautiful fail. If you do not understand this, see above.

Do you think this is "novel"? "revolutionary"? "omgwtfbbq that's genius"? well... ok then.

Anyway, just to say, it frustrates me that people can be so fucking oblivious that they would not recognize a good theory if it violently did things to their hoohoo. This is obvious, this is good. 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.

If you do not get this, I really really do not like you. And I also probably do not care about your reply, but I would like if you replied anyway because maybe you can convince me I am wrong, in which case please do. But consider me skeptical.

Love/hate,

Anon.

lol (0)

Anonymous Coward | more than 2 years ago | (#35301948)

I personally wager my karma on this:

LOL! STFU AC FGT

Re:label yourself a "computer scientist"? (1)

gmaslov (1983830) | more than 2 years ago | (#35302140)

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?

Re:label yourself a "computer scientist"? (1)

GameboyRMH (1153867) | more than 2 years ago | (#35302160)

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.

NaCl is very useful... (3, Informative)

coolmoose25 (1057210) | more than 2 years ago | (#35301878)

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

Dunbal (464142) | more than 2 years ago | (#35302174)

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

Re:NaCl is very useful... (1)

H0p313ss (811249) | more than 2 years ago | (#35302298)

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

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

Who will be the first? (-1)

Anonymous Coward | more than 2 years ago | (#35301892)

To implement a new browser in this environment. Then we could do away with the unsecure Chrome browser and use that instead.

When Microsoft thought of it... (0)

Anonymous Coward | more than 2 years ago | (#35301946)

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!

Crazy smart? No, just crazy (2)

mrjb (547783) | more than 2 years ago | (#35301966)

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

VolciMaster (821873) | more than 2 years ago | (#35302086)

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

suy (1908306) | more than 2 years ago | (#35302466)

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 [google.com] ?

Crazy smart ISA portability (3, Informative)

simula (1032230) | more than 2 years ago | (#35302526)

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 [chromium.org] 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 [llvm.org] concerning that effort.

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

Re:Crazy smart? No, just crazy (2)

slart42 (694765) | more than 2 years ago | (#35302574)

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.

TL;DR (0)

Anonymous Coward | more than 2 years ago | (#35301968)

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

advocate_one (662832) | more than 2 years ago | (#35301970)

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

Re:but... (1)

Baloo Uriza (1582831) | more than 2 years ago | (#35302068)

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

VolciMaster (821873) | more than 2 years ago | (#35302110)

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

You have an Itanium, too?

Re:but... (2)

3vi1 (544505) | more than 2 years ago | (#35302156)

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.

Static analysis (0)

Anonymous Coward | more than 2 years ago | (#35301972)

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

neoform (551705) | more than 2 years ago | (#35302044)

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

Project Codename? (0)

Anonymous Coward | more than 2 years ago | (#35302092)

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.

Like Java, without the JVM (4, Informative)

Animats (122034) | more than 2 years ago | (#35302128)

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 [chromium.org] . 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 (1)

gmaslov (1983830) | more than 2 years ago | (#35302290)

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

H0p313ss (811249) | more than 2 years ago | (#35302362)

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

pclminion (145572) | more than 2 years ago | (#35302376)

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.

Just use a less privileged user (1)

subanark (937286) | more than 2 years ago | (#35302130)

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

NaCl (1)

Attila Dimedici (1036002) | more than 2 years ago | (#35302146)

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... (5, Insightful)

Spazmania (174582) | more than 2 years ago | (#35302150)

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.

The REAL Chrome OS (1)

Yuioup (452151) | more than 2 years ago | (#35302182)

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

Enderandrew (866215) | more than 2 years ago | (#35302230)

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.

Missed the obvious motive. (2)

140Mandak262Jamuna (970587) | more than 2 years ago | (#35302300)

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.

Browser as OS (1)

md65536 (670240) | more than 2 years ago | (#35302350)

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

First step to being the OS (1)

JustNiz (692889) | more than 2 years ago | (#35302380)

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.

I may be suffering from buzzword syndrome (1)

pugugly (152978) | more than 2 years ago | (#35302556)

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

benob (1390801) | more than 2 years ago | (#35302606)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>