Linked by Thom Holwerda on Wed 10th Dec 2008 19:49 UTC, submitted by BluenoseJake
Google Google has released an early version of Native Client, a framework designed to run portable x86 binaries inside a web browser - in a sandbox. Native Client also includes technologies that allow for easier communication between JavaScript and Native Client executables, which makes it possible for web applications to leverage native code when it comes to processor intensive tasks. This sounds eerily similar to Microsoft's ActiveX - one of the biggest security failures of the Windows operating system. Google insists, however, that Native Client is much, much more secure.
Order by: Score:
Hmm...
by mmebane on Wed 10th Dec 2008 20:10 UTC
mmebane
Member since:
2005-07-06

Native Client == NaCl == Sodium Chloride == table salt

Just a coincidence?

Or are they subtly trying to hint that someday this technology should be ubiquitous and bring extra flavor to every website?

Reply Score: 9

RE: Hmm...
by Adam S on Wed 10th Dec 2008 20:46 UTC in reply to "Hmm..."
Adam S Member since:
2005-04-01

My first thought too. I assume there is no connection other than the fact they probably think it's funny to call it NaCl and let just the few people "get it."

Reply Score: 2

RE: Hmm...
by tyrione on Wed 10th Dec 2008 22:12 UTC in reply to "Hmm..."
tyrione Member since:
2005-11-21

Native Client == NaCl == Sodium Chloride == table salt

Just a coincidence?

Or are they subtly trying to hint that someday this technology should be ubiquitous and bring extra flavor to every website?


And with this line of cryptogram the software will eventually stress out our systems and force us to get check ups and change our diets.

Reply Score: 3

RE[2]: Hmm...
by sbergman27 on Wed 10th Dec 2008 22:17 UTC in reply to "RE: Hmm..."
sbergman27 Member since:
2005-07-24

And with this line of cryptogram the software will eventually stress out our systems and force us to get check ups and change our diets.

Only a percentage of people are classified as "sodium sensitive". But none of us can do without salt entirely. Think about it:

http://tinyurl.com/5b7879

http://tinyurl.com/6n5jvn

Edited 2008-12-10 22:22 UTC

Reply Score: 2

RE[3]: Hmm...
by tyrione on Thu 11th Dec 2008 00:22 UTC in reply to "RE[2]: Hmm..."
tyrione Member since:
2005-11-21

"And with this line of cryptogram the software will eventually stress out our systems and force us to get check ups and change our diets.

Only a percentage of people are classified as "sodium sensitive". But none of us can do without salt entirely. Think about it:

http://tinyurl.com/5b7879

http://tinyurl.com/6n5jvn
"

Really? Duh. If you take my post seriously then you miss the point of it.

Reply Score: 3

RE: Hmm...
by Kokopelli on Wed 10th Dec 2008 22:15 UTC in reply to "Hmm..."
Kokopelli Member since:
2005-07-06

So Native Client raises our blood pressure if used too much?

Reply Score: 6

RE: Hmm...
by ari-free on Wed 10th Dec 2008 23:27 UTC in reply to "Hmm..."
ari-free Member since:
2007-01-22

I hope not. Otherwise, Mayor Nannystate Bloomberg would ban its use in NYC.

Reply Score: 3

kragil
Member since:
2006-01-04

.. not sure it will happen though.

I for one will be _VERY_ hesitant to run native code from some website.

Actually I might not even install the plugin ;P

Reply Score: 6

Delgarde Member since:
2008-08-19

I for one will be _VERY_ hesitant to run native code from some website.


Agreed. It's one thing to provide a sandbox for scripting code that requires an interpreter. It's another matter entirely to sandbox code that's running natively on the CPU. Without knowing more about the security they'd be putting in place, I'm not at all comfortable with this idea.

Reply Score: 3

sbergman27 Member since:
2005-07-24

I'm not even sure what the advantages of running native code are supposed to be. Poor implementations of non-JIT Java with horrid support for UIs back during the heyday of Java "applets" combined with more years of poor implementations of non-JIT javascript have given portable runtimes (and the letters 'j', 'a', and 'v') a bad name. Java is really only a little clunky these days, and Javascript engines are getting ready to not suck. We're finally mostly rid of the rid of the ActiveX terror. This is not the time to be pushing native code. It's finally time to start pushing client-side Java and Javascript.

Then again, the guys at Google are a lot smarter than I am. So there must be some uber-rarified reason for doing this.

Edited 2008-12-10 20:41 UTC

Reply Score: 9

kragil Member since:
2006-01-04

Agreed. Pushing and optimizing Java might be the better option IMHO.

Secretly I am hoping that open source and open standard will break the dominance of X86. It would be really nice to have a fast ARM Netbook in 2009 that can run nearly everything for a whole working day (8 to 10 hours).

100% working open source flash is the only thing I still really need.

And I don't think Google is smarter than I am ;) (Lively anyone?)

Reply Score: 5

james_parker Member since:
2005-06-29

I'm not even sure what the advantages of running native code are supposed to be. Poor implementations of non-JIT Java [...] combined with more years of poor implementations of non-JIT javascript have given portable runtimes a bad name.


The problem with "JIT" is that the results are simply thrown away after use. A much better approach would be "JITAR" (Just in Time And Retain), which would then amortize the translation of executable code across multiple invocations. Combined with efficient fine-grained dynamic linkin, a mechanism for finding and using common libraries (not necessarily maintained by a single source), and reliable version checking -- all to reduce the actual amount of compilation done across applications -- it could be extremely efficient.

Of course, given its relative ubiquity, x86 (or a reasonable subset) could be used as the intermediate language to even further reduce compilation for common cases.

Reply Score: 3

Michael Member since:
2005-07-01

Well, we know the guys at Google know how fast javascript can run. So either they've found it is too slow for something they want to do (what the heck would that be?) or this is just an experimental project with no major application in mind.

Reply Score: 4

JrezIN Member since:
2005-06-29

...they just want to bring more Quake to the world!

Reply Score: 5

sbergman27 Member since:
2005-07-24

...they just want to bring more Quake to the world!

Back in the day, I loved Quake 1. I wasn't a gamer. Not at all. But I downloaded the demo to my W95 box and played it. And I was completely hooked. We didn't call it Quake 1 back then. We just called it "Quake" because it was the only one. The demo shows E1M3 (episode 1, map 3). And that is interesting. Because I had the most notable dream about it some years ago. Years after Q1, or even Q2 was considered even remotely current.

I was on that very level. I just sort of found myself there. Except it wasn't a game. It was real. No monsters were present. No one at all, in fact. It was completely silent. It was like a Disneyland recreation but without the cars and without the other people. I walked from the cave, where you start out, into the hallway shown in the screenshot. (It's the first appearance of the grenade launcher.) The Ogre wasn't there, though. I walked around for a while, and was just amazed that I was really able to view what I was considering to be some sort of recreation even in the dream. The architecture was awesome, as Quake 1 architecture usually was. Then I guess I moved on to another dream or woke up. But to this day, I'm glad for the experience.

Edited 2008-12-10 23:37 UTC

Reply Score: 2

Wes Felter Member since:
2005-11-15

So there must be some uber-rarified reason for doing this.


Rewriting C code in Java is expensive.

Reply Score: 4

Delgarde Member since:
2008-08-19

Rewriting C code in Java is expensive.


It is, but that's relevant only if existing unmodified C code will run on this new platform. There's a question of libraries (both static and shared), of binary formats, of all sorts of things like that. If my code calls printf, for example, where will it find the function implementation, and how? The story doesn't answer any of those questions.

Reply Score: 2

tyrione Member since:
2005-11-21

"So there must be some uber-rarified reason for doing this.


Rewriting C code in Java is expensive.
"

Expensive? Relative to what? Google's expenses on marketing vaporware costs far more than that cost.

Reply Score: 1

But why
by Buck on Wed 10th Dec 2008 20:25 UTC
Buck
Member since:
2005-06-29

But why, Google, why? Why do we need to run x86 binaries in a browser which is itself an x86 binary? Can't we like have normal secure web standars and instead dive further into obscurity and incompatibility?

Reply Score: 3

RE: But why
by ebasconp on Wed 10th Dec 2008 21:14 UTC in reply to "But why"
ebasconp Member since:
2006-05-09

But why, Google, why? Why do we need to run x86 binaries in a browser which is itself an x86 binary? Can't we like have normal secure web standars and instead dive further into obscurity and incompatibility?


I think they want to compete directly with other managed environments [.net and Java] and their "bytecodes" are very similar to the x86 opcodes [I say "very similar", should I say "identical"?]. In this way, they can create a JIT compiler in a simpler way and they get normal x86 binaries running with no modification [or simple modifications] in their "vm".

Nice approach I think, though I see the possibilities surpass the web and the webbrowsing and invade the virtualization and process isolation arena.

Edited 2008-12-10 21:16 UTC

Reply Score: 4

hmm...
by poundsmack on Wed 10th Dec 2008 20:42 UTC
poundsmack
Member since:
2005-07-13

maybe i am missing hte bigger picture, but does anyone else think that google's time could have been btter spent on something else?

Reply Score: 3

RE: hmm...
by rexstuff on Wed 10th Dec 2008 21:37 UTC in reply to "hmm..."
rexstuff Member since:
2007-04-06

Maybe. But then again, a lot of major advancements in technology have come from companies investing in research that seems of questionable importance to their main business plan.

Xerox, anyone?

Reply Score: 5

Why native x86
by error32 on Wed 10th Dec 2008 21:24 UTC
error32
Member since:
2008-12-10

Seems a bit silly to build this with x86 in mind, especially since google wants have a piece of the action on the mobile market with Android. And I don't see any mobile x86 devices appearing any time soon...

Reply Score: 3

Comment by TQH !
by TQH ! on Wed 10th Dec 2008 21:43 UTC
TQH !
Member since:
2006-03-16

So, does Android compile on x86?

Reply Score: 2

v Good
by A.O.K. on Wed 10th Dec 2008 21:54 UTC
WTF
by Myrd on Wed 10th Dec 2008 22:10 UTC
Myrd
Member since:
2006-01-05

This must be one of the most backwards projects that Google has done. This is totally a step backward, not forward. There is no future for native code on the web.

Let's look at their example:

For example, imagine that you run a photo-sharing website and want to let your users touch up their photos without leaving your site. Today, you could provide this feature using a combination of JavaScript and server side processing. This approach, however, would cause huge amounts of image data to be transferred between browser and the server, leading to an experience that would probably be painfully slow for users who just want to make a few simple changes. With the ability to seamlessly run native code on the user's machine, you could instead perform the actual image processing on the desktop CPU, resulting in a much more responsive application by minimizing data transfer and latency.

Well, if you code your app poorly, then yes you will have tons of latency and data transfer back and forth. However, someone who knows what they're doing would do all the processing on the client-side anyway, with a rich client-side JavaScript framework like SproutCore. So the argument for "increased latency and bandwidth use" is irrelevant.

The only real argument is performance. But JavaScript engines (V8, SquirrelFish, TraceMonkey, etc) are becoming insanely fast. Sure, perhaps not quite as fast as running native code, but close.

And with native code the runtime has to do extra work like verifying the binaries which has an additional overhead. Not to mention the incompatibility between different architectures (I'd like to see that X86 code running on an iphone... and if it does using some kind of VM, to compare its performance to optimized JavaScript running on V8 or SquirrelFish), and the additional burden for the developer.

This is just yuck.

Edited 2008-12-10 22:13 UTC

Reply Score: 4

RE: WTF
by Delgarde on Wed 10th Dec 2008 23:13 UTC in reply to "WTF"
Delgarde Member since:
2008-08-19

The only real argument is performance. But JavaScript engines (V8, SquirrelFish, TraceMonkey, etc) are becoming insanely fast. Sure, perhaps not quite as fast as running native code, but close.


I think that's a bit of an exaggeration. The javascript engines are certainly becoming a lot faster, and for most purposes, are fast enough. But to say they're close to native speed is exaggerating more than a little. For heavy computation work, it's hard to beat true native code.

Reply Score: 4

RE: WTF
by galvanash on Wed 10th Dec 2008 23:16 UTC in reply to "WTF"
galvanash Member since:
2006-01-25

This must be one of the most backwards projects that Google has done. This is totally a step backward, not forward. There is no future for native code on the web.


I violently disagree. Try writing a full-featured postscript document viewer (i.e. Acrobat) or a timeline based vector/rastor graphics runtime with scripting support (i.e. flash) in javascript or java and see what the uptake on that would be. You cant do everything in Java - sometimes performance matters. I think people are missing the point because of the whole "it runs quake!" angle...

1. This is potentially a _safe_ and browser-neutral alternative for activeX and netscape plugins.
2. Neither of those 2 technologies is remotely secure or trustworthy - this promises to be.
3. If (I stress if) this can be made provably secure ,i.e. the runtime can guarantee that code running within it cannot perform certain operations this could be very very useful indeed.

I would argue that the real benefit of this is not so much to create a new development path for web applications, it is to replace an already existing, heavily utilized, but horribly broken one. Just because we are all used to the fact that plugins are plain ass insecure and untrustworthy doesnt mean we should accept it as a fact of life.

As things stand now, both acrobat and flash do massive amounts of system configuration, registry changes, file-type associations, writing executable images and libraries all over the place, etc. They do this simply because they can. A runtime that would permit these types of applications to be developed, but would inherently limit their ability to affect the underlying operating system and filesystem would imho be a very good thing.

Reply Score: 5

It's not secure
by fury on Wed 10th Dec 2008 22:18 UTC
fury
Member since:
2005-09-23

Correction to the OSNews summary: Google does not claim that Native Client is actually secure *at all*. In fact, they released it early as open source so it can even CLOSE to have a chance to be secure.

And as for Native Client itself, I think this idea is pretty ridiculous considering the gap between unmanaged and managed performance has only gotten considerably smaller over the last few years. Then there's the fact that developers would need to deploy multiple Native Client executables to support anything except stock PCs, and the fact that the performance gains of such a platform over Java, .NET/Silverlight, or Flash-based RIAs will not only be negligible, but it will continue to shrink as those systems gain more runtime performance enhancements. I just can't imagine a world where this would actually be beneficial to a normal web developer (although clearly this could be useful in medical and other latency-intensive/precise software).

Interesting project though and I'm glad they open sourced it right off.

Reply Score: 3

RE: It's not secure
by JrezIN on Wed 10th Dec 2008 23:15 UTC in reply to "It's not secure"
JrezIN Member since:
2005-06-29

don't forget it can be used not only on the web, but on the client-side too... plugins can use NaCl and solve some problems that plugins have in these days...

Reply Score: 2

ActiveX
by memson on Wed 10th Dec 2008 23:10 UTC
memson
Member since:
2006-01-01

Yay, the ActiveX it's cool for everyone to play with?!

Reply Score: 2

Not many ActiveX analogies...
by TBPrince on Thu 11th Dec 2008 00:12 UTC
TBPrince
Member since:
2005-07-06

Not many ActiveX analogies, apart from the fact that they run native code, of course. ActiveX is far more complex than NC could ever be.

But I doubt that Native Client can actually run native code because that would be highly risky, even when removing "dangerous instructions". To be secure, NC should be sandboxed and thus run inside a VM. If it runs inside a VM, NC basically is like Java applets, Flash or Silverlight. So Google created its own version of those frameworks, something which was highly probable in the past and now it's a reality.

If it doesn't compile into bytecode and it actually compiles to native code, it will be highly difficult to secure, even when stripping out dangerous code during compilation.

Whatever it is, as I stated in past, this is a confirmation from Google that Javascript+HTML model is not suitable for complex Web-based application. This is a *direct* confirmation that Flash/Silverlight/Java path is the right one. As it was expected ;-)

Reply Score: 3

RE: Not many ActiveX analogies...
by dvhh on Thu 11th Dec 2008 02:24 UTC in reply to "Not many ActiveX analogies..."
dvhh Member since:
2006-03-20

why do do we need all those complex web applications anyway, sure they are convenient but isn't that stretching the initial goal of the web.
Plus I don't think plugins/applets is the way to go, as it cut a significant share of the user (mobile, alternative OS,....) from the actual content.

Reply Score: 2

RE: Not many ActiveX analogies...
by snozzberry on Thu 11th Dec 2008 04:53 UTC in reply to "Not many ActiveX analogies..."
snozzberry Member since:
2005-11-14

I'm inclined to agree. I've written AJAX apps and while they work well, the overhead is ridiculous even with other people writing the frameworks. Web apps are exciting until you see what it takes to make them work.

Reply Score: 2

Photoshop in the browser?
by skypilot on Thu 11th Dec 2008 02:13 UTC
skypilot
Member since:
2008-12-11

I think Google is readying for Photoshop in the browser, or maybe it is time for games.

Reply Score: 1

ARM? Why no one has mention it.
by iwod on Thu 11th Dec 2008 02:39 UTC
iwod
Member since:
2006-05-02

Before anything else, Security, or usefulness,
Does NaCI runs on anything other then x86 is the most important question. Or will be it possible to run on other processors.

If it is x86 only then i will say it is a SERIOUS step backwards.

I could see the usefulness of Native Code. But being x86 only seriously hurt.

Reply Score: 3