Next-Gen Web Apps: Google unleashes Native Client into Chrome

http://techcrunch.com/2011/08/11/chrome-native-client/

by lobo_tuerto • 15 years ago

160 122 15 years ago

adelevie• 15 years ago

Is this analogous to using the Android NDK for Android apps?

mahmud• 15 years ago

Opposite. More like FFI/JNI to Bosch/Qemu. Android NDK, and other foreign-function interfaces are a way to de-secure & de-manage secure code: a controlled mechanism for stepping out of the sandbox. Google NaCL, like other virtualizers, is a way to contain inherently insecure code into a (well?) defined sandbox.

wmf2• 15 years ago

Yes, in the sense that NaCl allows JS to call C while the NDK allows Java to call C.

chintan• 15 years ago

GooactiveX

dstein• 15 years ago

That's a very succinct way of putting it. Google is smelling more like Microsoft every day.

pagekalisedown• 15 years ago

I would've gone with GactiveX, which is a bit more pronounceable. :)

brunnsbe2• 15 years ago

ActiveX was also the first thing that popped into my mind. However, the whole ActiveX-lesson learnt everyone, not just Microsoft, how bad things can go if the security issues isn't solved when releasing new technology and I think Google has spent a lot of resources on it. My main concern is how this is going to affect us developers in, let say, next five years. Are we going to need to write even more browser specific code when other browsers also will start to support these native clients?

zobzu2• 15 years ago

what you just said basically: if ms implemented it, its wrong etc we all know that

if google does the same, it must have been done better and therefore its ok

the point tho: the design is broken security wise. google, ms, apple, whoever else implements it, its going to be exploited, heavily specially as soon as chrome becomes n#1 browser (which will happen no matter what - certainly the no-opt-out install with a zillion of popular apps helps with that)

tiles• 15 years ago

This, along with Chrome Web Store, are the first major deviances from Chrome the HTML5 browser into Chrome the platform. It's exciting but also unfortunate that we're starting to see a divergence here, when other browsers are unlikely to pick up NaCl for some time (if at all) and the Chrome Web Store being entirely incompatible.

Edit: Mozilla Rejects Native Code Approach of Chrome's NaCl http://css.dzone.com/articles/mozilla-rejects-native-code

yid7• 15 years ago

I think they might also see NaCl as helping drive Chrome's growth, when suddenly a browser can do cool stuff that other browsers can't.

EDIT: I'm old enough to remember the browser wars, but I really like most of the trends that Google/Chrome have introduced, from auto-updates to revving the JS engine to fallback-capable SPDY.

yuvipanda3• 15 years ago

Let's hope this doesn't devolve into something similar to the madness that was ActiveX.

ramanujan• 15 years ago

ChromeOS should be added to your list too. When Chromebooks get VPN...will be seriously tempting for a lot of businesses.

Also: this is a dumb thought, perhaps, but was just thinking about why browser sandboxing is so important.

Obviously (on a non-Chromebook at least) people can download and run any app locally, with the download itself often occurring through a web browser.

So why is sandboxing important?

I guess the issue is that you are downloading and running a full app with each page request, and often this download/execute cycle can occur on a script tag that is never explicitly approved by the user, so the frequency and invisibility of executing foreign code is much greater.

This is doubly true if you're talking about a Chromebook, whose administration and security features rest upon the fact that someone can't install stuff locally.

Also, the model of "trust every NaCl executable before you run it" breaks down in this environment...because Google depends on the fact that people must be able to trust clicking links they've never seen before [i.e. that they just searched for].

So it's really extremely important to their bottom line that they nail any security issues with NaCl. This may be different from MS's perception of ActiveX security as a priority.

Just some musings.

aboodman3• 15 years ago

Sandboxing is important on normal desktop browsers because downloading native apps off the internet and running them is incredibly unsafe for normal users. The more that can run in the browser's sandbox, the better for users.

As for comparisons to ActiveX, they are completely different. ActiveX was not designed to place any restrictions on the downloaded code at all. In contrast NaCL is designed to completely restrict the downloaded code.

Yes, there can be implementation bugs, just as there are implementation bugs in browsers. But it's a really important difference to say that full local privileges in NaCL is a _bug_ that will be fixed. Whereas full local privileges in ActiveX is a _feature_ that will not be fixed.

ditojim• 15 years ago

chromebooks now support VPN :) http://www.pcmag.com/article2/0,2817,2390942,00.asp

yariang• 15 years ago

It is a bit unfortunate to see divergence only because it would mean the reversion of platform-independent development that browsers currently allow.

At the same time though, sacrificing progress for standardization's sake is most unwanted. It is inevitable that some companies will make some superior innovation, and other companies might not want to adapt that right away, or perhaps they'd like to build something even better. But that's okay.

This kind of leapfrog might be hard for developers because they will have to have different branches of their product, but it is a net win for users because the ones on the "superior" platforms get access to the best technology around and it therefore places pressure on the competition to adopt this new superior technology or move ahead with something better of their own.

magicalist2• 15 years ago

Is there really a divergence though? Or is this just another way to run a program?

Relatedly, I think others in this thread are forgetting why exactly ActiveX was not a good thing.

To me, this is more analogous to XUL: an open-specced, open-source way to do something new in a browser that no other browser vendor ever implements. XUL didn't hurt the web (though it certainly still gives Firefox addons a competitive advantage), and -- at least as long as native client isn't adopted by other vendors -- I don't really see this hurting the web either.

Meanwhile, I'm going to keep writing javascript.

gcv• 15 years ago

Could someone more familiar with the effort comment on whether Google realistically solved the security and trust problems inherent in the approach? I'm assuming that

    while(1) fork();

is somehow blocked, but native code is a bonanza of attack vectors.

krasin2• 15 years ago

fork is not available under NaCl http://code.google.com/p/nativeclient/issues/detail?id=1239

xtacy• 15 years ago

The Native Client paper[1] was published in 2009. The main reason it took so long to be officially released is that it underwent a lot of scrutiny by various security researchers[2], through the Google bounty program. In fact, NaCl has been shipping with Chrome all along; it just needed a flag to enable it (--enable-nacl).

You should read their research paper for interesting insights.

[1] http://www.chromium.org/nativeclient/reference/research-pape...

[2] http://code.google.com/contests/nativeclient-security/

consultutah• 15 years ago

This is actually really cool. It is essentially "safe" activex. I wish MS would have done something like this rather than silverlight.

calvin• 15 years ago

The fact that it's anything like ActiveX is what scares me. I'm not looking forward to further fragmentation of web browser capabilities.

yuvipanda3• 15 years ago

With Mozilla explicitly announcing they won't support it (and we all know how Microsoft will react) - I hope NaCl goes on to die a silent death.

Except perhaps in chromebooks. I could see how they'd be useful there.

nitrogen4• 15 years ago

.Net and Silverlight, were they open and unencumbered standards not exclusively implemented by Microsoft, would be better than NaCl because .net uses a platform-independent bytecode, which avoids leaking the processor type through the abstraction of the browser.

srdjanjovcic• 15 years ago

CLI and C# are standardized by ECMA (http://msdn.microsoft.com/en-us/netframework/aa569283). Besides Microsoft implementation, there open source one (http://www.mono-project.com/Main_Page).

There is also open source implementation of Silverlight, but not at par with Microsoft one: http://www.mono-project.com/moonlight

nxn2• 15 years ago

I was somewhat irritated when Microsoft was pulling stuff like this with IE. But on the other hand, if they ever do make PNaCl, I will gladly disregard every other browser and target all my personal projects specifically for Chrome. The unfortunate thing is that I haven't seen any news or heard of any progress being made on PNaCl in a long time.

yuvipanda3• 15 years ago

Indeed - having different compiled versions of your code go over the wire to the client simply because they're on a different architecture seems so... backward.

andrewf• 15 years ago

I just switched to the Chrome beta stream, and NaCl still seems to be disabled by default. Is this what others are seeing?

(Chrome 14.0.835.35 beta-m on Windows)

abraham• 15 years ago

Looks like 14.0.835.35 is the correct version.

http://googlechromereleases.blogspot.com/2011/08/chrome-beta...

njharman• 15 years ago

Meh, very few apps are cpu constrained. For vast majority targeting html5/javascript and it's mindboggingly huge installed base is a bigger win.

cageface3• 15 years ago

This could, at least in theory, make it possible to deliver on the web a serious competitor to Photoshop, for example. I don't see that happening any time soon in Javascript.

ootachi5• 15 years ago

You assume wrong. Modern tracing or type-inferring JITs are heavily optimized for the kinds of tight loops you see in image processing.

nitrogen4• 15 years ago

Meh, very few apps are cpu constrained.

One must be very careful making statements like this. The only reason you're not seeing CPU-constrained webapps is because they aren't being created, because they would be constrained by the CPU. For example, I'm writing an app that would be significantly better if I could do fast client-side processing of data. Eventually I plan to use WebGL shaders, but I don't know if GLSL shaders can actually do what I need to do.

Your second sentence, however, is reasonable.

leon_2• 15 years ago

> Meh, very few apps are cpu constrained.

Maybe on the server side. Client side is a different story. My machine is regularly hitting 100% usage when browsing some fancy JS-driven blogs.

asadotzler• 15 years ago

Native Client apps aren't "web apps" any more than Silverlight, Flash, and Java apps are "web apps".

wmf2• 15 years ago

Many people consider anything that appears in a browser window to be "the web"; if you want to convince us otherwise, at least give a reason.

drgath6• 15 years ago

I agree that people consider anything that appears in a web browser is a "web app", but that doesn't make it right. ActiveX, Java Applets, Silverlight, Flash, and NaCL are not "web apps." People also think "Internet" is analogous to "World Wide Web."

A "web app" is something that is built using open standards that has oversight by a standards committee that is either the W3C or WHATWG.

sid0• 15 years ago

> Many people consider anything that appears in a browser window to be "the web"; if you want to convince us otherwise, at least give a reason.

Surely you're more informed than the "many people" you refer to?

chaz• 15 years ago

The "web" isn't a technical specification. People will click, link, and share the same way they've always done.

leoc3• 15 years ago

What argument are you making here?

Is it a purely definitional argument about what constitutes a "web app"? That raises the question of what exactly "the web" is and who gets to decide, on what basis - but more importantly, who cares? Let's all adopt Native Client apps in the place of web apps and call them something else.

Is it a "standards" argument against NaCl adoption, ie. "Mr. SOCKWG says No!"?

Or is it an argument on technical merit against NaCl adoption? If so, you'll need to spell it out in more detail. Appealing to "Web = Good" is a fair enough starting point, because the Web is Good, but it's not enough here. NaCl advocates (or some of 'em) are presenting an argument about why the Web is good, and how it (or some Web' that isn't the Web - again, definitions in themselves are nothing) could be better. To simply repeat "Web = Good" in reply would be make of the Web a cargo cult - and, one can't help noticing, a cargo cult which just happens to operate very much in the interests of the shrine guardians.

chrisdes• 15 years ago

We need to use a specific version of NaCl SDK for each Chrome version. See http://http://code.google.com/chrome/nativeclient/docs/runni... Knowing how quickly the Chrome version changes and automatically most of the times, it will be very difficult to keep up.

abarth• 15 years ago

This is the first release with a stable ABI:

"Applications compiled with version 0.5 of the SDK will work in Chrome 14 and future versions of Chrome."

http://code.google.com/chrome/nativeclient/docs/releasenotes...

zmmmmm• 15 years ago

The danger here is that we'll see Google lessen its focus on the speed and efficiency of V8 and instead start falling back on NaCl in their own apps. We seem to be at a particularly dangerous juncture right now where all the major desktop OSes are running on x86 processors. Thus a scheme like NaCl can easily take off and then, once we are dependent on it, it can lock us in to specific processors and platforms instead of the dream of the web - running anything anywhere.

yid7• 15 years ago

Not a problem -- if NaCl exceeds V8 in development, we just compile Javascript directly to NaCl (using tools that will certainly be devised).

nitrogen4• 15 years ago

How would precompiled JavaScript help? NaCl provides a subset of the processor's capabilities. V8 has access to everything, and is already compiling Javascript to native code. The only way you could exceed V8's performance is by writing a better JavaScript compiler than V8 -- no small task. Anything you can do with JavaScript-[as-yet-unwritten compiler]-NaCl, Google can do with JavaScript-V8-native code.

cageface3• 15 years ago

Unlikely. First, thanks to mobile, x86 is far less dominant than it was even a few years ago.

Second, Google can't afford to deliver a second-class experience to users not using Chrome. They don't have the kind of market share it would take to get away with that.

nextparadigms• 15 years ago

NaCl is supposed to work on ARM chips, too. I think you need like just a line of code to enable it for ARM machines.

Google I/O 2011: Beyond JavaScript: Programming the Web with Native Client:

http://www.youtube.com/watch?v=WgbK0ztUkDM

ootachi5• 15 years ago

I don't know the particulars of how this is implemented, but you would either have to compile your code for ARM (adding an enormous burden to web development), or have all mobile browsers ship an x86 emulator (which is a massive step backwards).

bzbarsky7• 15 years ago

Google has in fact announced that they will more or less stop V8 optimization work... Which is too bad, because V8 is nowhere close to as fast as JS engined will get.

Animus72• 15 years ago

Without PNaCl, this feels nothing but regressive, for at least three reasons:

1) JS is awesome precisely because of the common denominator. But because Chrome said so, devs should go back to triple-testing everything and dusting off their assembly debugger toolchains?

2) With more and more happening on cloud servers, JS engines being mature, and clients just getting faster, the need for that ultimate level of performance feels ever more irrelevant.

3) ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. And even if Google manages to keep their implementation airtight and standards-conforming, what happens when NaCl takes off and Microsoft takes a crack at it?

yid7• 15 years ago

So what you're saying is that you want a JS-to-NaCl JIT compiler (presuming NaCl is faster than V8).

Animus72• 15 years ago

No, I don't see how JITting JS to NaCl would address any of those issues.

tomjen32• 15 years ago

1) Only if speeds matters. There are a lot of cases where it dosen't. You can now do this when it does. Also we are talking C/C++ (but really anything that can be compiled to binary code) which is not even close to assembly.

2) For the problems we have today you may be right, but you forget the class of problems that couldn't be done the old way. We can now do them.

3) People will learn not to use MS products? But in all seriousness that will be MS problem.

Anyway it is open source, I doubt Google has chosen a license which MS would object to.

abecedarius• 15 years ago

On point 3, it's not obvious to me that a high-performance Javascript engine can be expected to be safer than NaCl. Which is more complex?

leon_2• 15 years ago

> the need for that ultimate level of performance feels ever more irrelevant

Nah, I don't know. As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog.

> ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea.

It's not much different to downloading and running JS. Heap Spraying attacks are the simplest you can run against a JS vm. Then there's more advanced attacks that abuse the JITs nowadays found in VMs to generate malicious native code. And I bet not many JS VMs check their generated code for sanity - which NaCl on the other hand does.

davej2• 15 years ago

> Nah, I don't know. As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog.

That's due to shitty coding by the front-end developer of the blog. With power comes responsibility; writing in C is a lot of power but there are far more opportunities to write shitty code.

mike-cardwell• 15 years ago

"As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog"

You should try NoScript and/or RequestPolicy for that.

ootachi5• 15 years ago

You don't want JavaScript VMs to be running NaCl's verifier on all the code that they generate. That would be a significant performance loss. Remember that JavaScript engines are fundamentally built around self-modifying code, so the verifier would be running all the time.

aufreak3• 15 years ago

You don't _have_ to use NaCl just because it is available. If you find performance like an order of magnitude away from where you need it to be, NaCl could be one technology to consider. Demanding games come to mind, harvesting spare computing power is another possibility, I'm personally interested in high performance programmable audio (think Max/MSP/Jitter within the browser), etc.

Roritharr• 15 years ago

For gaming this is a big thing. One thing that limits cool 3D Games on the Web is the lack of good engine technology that can be used without plugins. Unity 3D has shown in cooperation with google that they could run without a plugin through NaCl.

I'm really looking forward to this possibility, making the Chrome Webstore as a sales platform even more interesting in the long run.

kayoone• 15 years ago

absolutely, we are working on a Unity browsergame and Native Client is a big thing for us as well.

cyrus_2• 15 years ago

This is a huge win for developer choice on one front -- choice of client language. Now you can use pretty much any language you want to write your client logic as long as a suitable binding to the DOM via the Pepper API has been developed. Not to mention the ability to write truly performant code (V8 is nice and all but you can't beat native code in tight loops -- media manipulation apps like Photoshop come to mind.)

Mono 2.10 already ships with support for NaCl, so you can already use a whole bunch of nice languages over the CLI that way. It'll be interesting to see where this takes the Moonlight project though, since it has similar goals. With Microsoft seemingly downplaying or abandoning Silverlight, so is this the end of the line?

hencq• 15 years ago

Mono with support for NaCL sounds interesting. Does that mean though the browser will have to download Mono every time it encounters a web app that's written in e.g. C#? Or will it only have to download the C# bytecode?

On a slight tangent, I've always wondered why Java (or other JVM languages) couldn't make a comeback on the client side. Instead of having Applets that run sort of isolated from the browser, you could just expose the DOM.

nikcub2• 15 years ago

You could host Mono once at a single URL and then include it. It will be cached by the browser just like any other resource.

Unlike javascript libraries, there will be more of an incentive to use a single CDN/hosting point, since the package is likely to be a bit larger

MatthewPhillips2• 15 years ago

Presumably it would be a stripped down version of Mono. The .NET Micro Framework is about 300k, for example.

cyrus_2• 15 years ago

On your second question, they've tried that with things like JavaFX Script. Not sure why there isn't uptake.

bzbarsky7• 15 years ago

> but you can't beat native code in tight loops

But you can. https://bugzilla.mozilla.org/show_bug.cgi?id=618692#c1 has a simple example where Java beats gcc -O3 by a factor of 1.5 or so on exactly such a loop. This is not an isolated case, and I fully expect JS JITs to get there for many situations. Unless browsers stop improving them, of course.

trueduke• 15 years ago

Mac OS already has its Native Client : the App Store...

tensor• 15 years ago

This is cross-platform and sandboxed. The App Store is just a publishing mechanism.

bzbarsky7• 15 years ago

NaCl isn't exactly cross-platform. At the moment it only works on 3 hardware architectures at most, and that only if you put in some special effort....

jamesu• 15 years ago

Personally i think this is great for running existing C codebases in the browser, the prime example being games. Good news for say... the chromebook.

ck2• 15 years ago

Wow one of the reasons for 3rd party browsers has now come full-circle (activex).

This combined with how Chrome like to hide things from users so they don't worry their little minds about it (status bar, url bar http, etc.) is a major disaster waiting to happen.

oemera• 15 years ago

I hope this trend will stop this instant. Why should we develop a Chrome App which only runs in Chrome (cross platform though) ? With existing technologies you can target way more people with all kind of browsers. (Ok there are browsers which are hard to optimize for)

I feel like we are going back from all these benefits the browserS gave us.

nikcub2• 15 years ago

Think of Chrome as just another OS platform target - in the same way iOS, Windows and OS X are.

there will be many more chrome-powered devices in the near future, it is already ~15% of the desktop

stanleydrew• 15 years ago

You don't have to use it. I am really confused by the sentiment in this thread. If you want your web app to be cross platform then don't use nacl. You will be no worse off than you were yesterday before having read this article.

zobzu2• 15 years ago

Google unveils.. ActiveX

StavrosK2• 15 years ago

Everything else aside, I love how the library to complement NaCl is called Pepper.

robgough• 15 years ago

Are there any examples around to take a look at? I can't seem to find any.

mikecaron• 15 years ago

I've got beta v 14.0.835.35 beta-m installed but the native client examples don't work for me. Is there something I have to do to enable the NC?

krasin2• 15 years ago

What does http://krasin.github.com/naclwtf/ say?

Hisoka• 15 years ago

Good news for consumers. Horrible news for developers. OK.. let's see, we gotta make an iPhone app, an Android app, a web app, one for the Blackberry, maybe one for Windows Phone, and ooh.. a Facebook app! Now a Chrome app..

grimen• 15 years ago

Ouch. I start to think of Microsoft and Apple. :( So far Google been outpacing my expectations on driving web technologies forward - all this for later go back to the "native client" approach Microsoft had in late 90s (thy stopp believing in HTML/JS). Does this mean MS was right back in '99? I'm really confused about Google's vision of how the web will work in 10 years from now. Anyone with insight in there?

Next-Gen Web Apps: Google unleashes Native Client into Chrome

Related Stories