
Next-Gen Web Apps: Google unleashes Native Client into Chrome - lobo_tuerto
http://techcrunch.com/2011/08/11/chrome-native-client/
======
Animus7
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?

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

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

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

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

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

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

~~~
nextparadigms
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>

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

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

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

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

~~~
nikcub
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

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

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

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

~~~
abarth
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...](http://code.google.com/chrome/nativeclient/docs/releasenotes.html)

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

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

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

~~~
tomjen3
No it is not, unless somebody has taken a trademark on "web app". A "Web app"
is whatever is generally understood when people say "Web App".

~~~
drgath
Feel free to peruse through WHATWG's specification for "Web Applications", or
"Web Apps" for short. There is a standardized, very explicit definition of
what that term means.

<http://www.whatwg.org/specs/web-apps/current-work/complete/>

~~~
magicalist
I've read it and I don't seem to recall any normative sections defining "Web
Application" :)

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

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

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

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

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

~~~
nknight
Mono isn't exactly at par either, there's always a fairly substantial lag
time, and only a subset of the .Net stack is standardized. ASP.NET and Windows
Forms are notably absent from ECMA standards, as well as from Microsoft's
"community promise" with regard to patents.

~~~
nxn
First of all, we're talking about the VM here, so why does not having ASP.NET
or Windows Forms make any difference? Better yet, would you even want your
browser to come with them? Also, although the VM bytecode does change with
time, it doesn't change as much as the .NET libraries. I'm saying this because
the 'lag time' argument isn't all that significant for this reason.

But outside of that, "substantial lag time"? In my opinion the mono team has
always been exceptionally fast when it comes to implementing new features in
the .NET world. Plus mono has its own tool sets and features that aren't in
the regular .NET framework and wont be any time soon.

I am not saying that Mono is the VM I'd like browsers to implement, but my
reasons are definitely not related to it not being able to come with the
ASP.NET framework.

------
chintan
GooactiveX

~~~
brunnsbe
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?

~~~
zobzu
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)

~~~
brunnsbe
One has to remember that when ActiveX was introduced in Internet Explorer 3.0
the focus on security was a lot lower than in today's browser development.

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

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

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

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

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

~~~
cageface
All the heavy lifting in apps like that is done in SIMD.

~~~
ootachi
Which doesn't require NaCl.
<https://bugzilla.mozilla.org/show_bug.cgi?id=644389>

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

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

------
andrewf
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
Looks like 14.0.835.35 is the correct version.

[http://googlechromereleases.blogspot.com/2011/08/chrome-
beta...](http://googlechromereleases.blogspot.com/2011/08/chrome-beta-channel-
update.html)

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

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

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

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

------
zobzu
Google unveils.. ActiveX

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

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

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

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

