

Native Client: A Technology for Running Native Code on the Web - bdfh42
http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html

======
andreyf
A coworker: "Yay! Google is re-imlementing ActiveX!"

~~~
tptacek
Your coworker doesn't really understand ActiveX; ActiveX controls execute
_unchecked_ native x86 code with _full access_ to the system call table. NaCL
falls somewhere in between VMWare and the Java Bytecode Verifier.

~~~
tlrobinson
I like your abbreviation for it, but that's not an official name, right? Are
you just hoping it will catch on?

I'll join you in calling it NaCl.

~~~
tptacek
They used it in the paper.

------
frogger
Yahoo! has already released a very similar "BrowserPlus" ...
<http://browserplus.yahoo.com/>

~~~
wmf
They don't look that similar, since BrowserPlus doesn't appear to run
arbitrary untrusted native code.

~~~
tptacek
NaCL doesn't run "arbitrary" native code; it runs a strictly controlled subset
of x86, with all bblock edges verified, in a per-process environment that uses
segment access controls to prevent code from overwriting code, and without
access to the full system call table. It is basically a faster version of the
Java applet sandbox.

~~~
wmf
Maybe "arbitrary" wasn't the right word; my point is that it looks like
BrowserPlus lets you run a small selection of native things approved by Yahoo,
while NaCl lets you run whatever you want in a sandbox. Most of the
restrictions of NaCl are inconsequential since they only block things that
well-behaved code doesn't do anyway.

~~~
tlrobinson
I believe BrowserPlus will allow 3rd party plugins, though I'm not sure if
they will require Yahoo approval.

Also, there's already a "RubyInterpreter" plugin, though assuming it's
sandboxed there's not much advantage over JavaScript, unless you prefer Ruby
(JS appears to be faster than Ruby, in most cases:
[http://shootout.alioth.debian.org/debian/benchmark.php?test=...](http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=javascript&lang2=ruby))

------
pierrefar
It's game over for Microsoft. The OS will become even more irrelvant. Adobe
should be really worried too - they both just might disappear into a silvery
lit air :)

Let's just hope Google doesn't mess this opportunity up. This is the silver
bullet and they get to shoot it only once and they must not miss. No beta
tags.

~~~
tptacek
It was game over long before NaCL, which is why I'm not bullish on this
particular browser plugin: very, very few information problems people need
solved require native code, and those few problems are already pretty well
represented. If this was a killer problem, the JVM applet plugin would have
evolved faster.

~~~
stcredzero
This could be a huge boon to casual multiplayer gaming. You may be able to
implement games that are as fast as desktop clients, but which require zero
installation. (Once the plugin is installed the first time, of course.)

The same benefits would also be a huge boon to browser office apps.

Actually, _this_ is the architecture that should be used to distribute
plugins, period.

~~~
tptacek
You say that as if you knew it to be true. But we don't really even know if
it's going to work; it's a new x86 verification scheme, and if it's somehow
broken, it won't work _at all_.

I see how a near-native-performance plugin interface is valuable, but it's
still just not clear to me why, if this was that important, it wouldn't be in
the Java applet plugin's bailiwick. The same CS disciplines that make NaCL
possible can also drastically accelerate the JVM.

It's also not totally clear that, when NaCL is actually fielded, the end user
experience will be that much better than the applet plugin. NaCL forks off a
seperate process and sets up a special runtime with a sidecar debug monitor;
once it's up in steady state, I'm sure it's faster than Java, but the big
issue with Java is setup time.

~~~
stcredzero
Your referents are a bit vague: "You say that as if you knew it to be true."

Are you referring to my first paragraph, where I say _could_?

Are you referring to my second, where I say _would_? (Would if it works like
it's supposed to.)

As for my last paragraph, this is an opinion based on personal experience with
the "security" of ActiveX and other plugins I've run into in my professional
life. Web plugins and other downloaded executables should be sandboxed for
security.

Also, the fact that it's not a virtual machine, but virtualized machine code
will help with setup: the X86 ISA seems to change much less often than the
JRE.

~~~
tptacek
When I said "that", I think I meant, "all of it". ;)

ActiveX vs. NaCL is a false comparison, obviously. You can't do worse than
ActiveX, and nobody promotes it.

I don't understand your last paragraph; setup time isn't going to be based on
the X86 ISA, but rather the time it takes to fork a process, monitor it in a
debugger, set up the system call interface, and then do whatever UI goop NaCL
wants to do to give native code a window context. It could be faster than the
Java applet plugin. It could be slower. And applets could get faster.

~~~
stcredzero
So your "that" referent consisted of two hypothetical parts and a 3rd
statement that you agree is trivially true.

I meant setup from a user standpoint. I suspect that once such sandbox
software was stable, updates would be less frequent than updates to the Java
plugin. You meant setup time in terms of getting code JITed and actual
execution.

------
socksandsandals
History will judge this to be our day's version of VBA.

------
tocomment
Could you run a Python interpreter in this, or Perl?

~~~
andr
Better yet, you can run a JavaScript interpreter in there. Firefox, even.

------
tlrobinson
It seems like NaCl should be part of Gears, no?

------
andr
I guess metaprogramming is out of the question.

~~~
wmf
Not necessarily, although you won't be doing any JIT.

