Google Native Client: The web of the future - or the past?

Chad Austin believes in Google's Native Client because he believes in the web. He sees the web as the ultimate programming platform – something that spans not only disparate devices but the competing interests of the world's corporate tech giants – and he sees Native Client as a way of bringing most any language to the …

[Destroy All Monsters]

Sink the Bismarck!

This article is somewhat "fair and balanced" as the USerricans say.

That is, it compares something that may be rather dubious proposition [like torture and the surveillance state] to something that is known to work [e.g. defending civil liberties and keeping state out of your pants] by putting both sides on the same level and explaining away differences by "religious attitudes".

I can empathize with the developers of this thing but can I have some marmalade with this buttery slatherfest of complexity, please?

Clearly a torpedo aimed at the steaming-in-circles Wintel platform. I expect Microsoft to line up the lawyers at some point in the future complaining about various IP violations regarding use of its DLLs.

[Anonymous Coward]

poo

What a bunch of poo this is! Let me see, they'll have to drop back to bytecode else are google going to support write many times run manywhere? Or is it google.net? Now this is a joke? Native web, isn't that like when I host the browser control in my app or something and call window.external hahahah. What are they playing at!! What are they trying to solve!

Stick to search. You're good at it. Chrome is just a pretty lame application really compared to even something as simple as textpad.

[Anonymous Coward]

Do not want.

Sounds like ActiveX. From Google.

[DrXym]

It's not activex but it is proprietary

ActiveX has no safeguards in place. Once you run an ActiveX control it has complete power to do anything that the browser itself could do. So if you run your browser as administrator then the control is also administrator. If you run your browser in safe mode, then the control is also in safemode. So basically there is no sandbox beyond what the browser is running in.

ActiveX is fine when you trust your content. So it's okay that programs use ActiveX controls that you explicitly installed. The problem was when they went onto the Internet. Microsoft's security model was a joke. Random websites could invoke any "safe for scripting" control. It soon turned out that not many controls were safe, even those which said they were such as the ones that shipped with MS Office. So MS added a blacklist of bad controls. Then they flipped to a whitelist for the popular controls (e.g. Flash, Acrobat) and disabled other ones.

I'd note also that NPAPI plugins are not sandboxed and can do anything they like too. NPAPI has been luckier because it's a pain in the backside to write NPAPI plugins and Firefox uses a whitelist so only a few "blessed" plugins can be auto installed.

So NaCl does not suffer some of these issues. It is (allegedly) sandboxed, and I assume it has a some kind of same domain policy so your apps must execute and reside from the site they're hosted by.

Problem is that sandboxes have a tendency to leak. A more serious issue is introducing a technology which is restricted to one architecture and one browser is plain stupid. One has to wonder what Google are thinking here. It's not even in their interests to have an x86 only technology when half the devices they want to target are ARM. Do they really think devs like compiling twice?

If I were Google I would take a step back. Recognize that NaCl is a dumb idea and focus on PNaCl. Open up the APIs, tools and development and offer it on open terms and peer review so other browsers can implement the tech, Other browsers might be more favourable to such an approach.

[Christian Berger]

But what about the sourcecode problem?

Native Client doesn't deliver the source code, so you cannot change it easily which makes it a lot harder for the user of web applications.

BTW, what if there's yet another CPU bug which can halt the CPU or cause privilege escalation?

[Ru]

What sourcecode problem?

I'm not entirely sure ywho you're thinking about when you say "[this] makes it a lot harder for the user of web applications". Web app users don't care about the source. They probably don't care about the platform, or the company badge on it either. They just want it to work and get out of their way.

Rewriting chunks of it is about as far removed from this ideal as physically possible.

[Brewster's Angle Grinder]

Acutally, it fixes the source code problem...

One of the hurdles I'm having convincing management that our app should be converted into javascript is the problem of lusers getting at the source. This might allow me to do less sensitive bits in javascript and keep the more valuable C++ in a plugin.

Where's the "have cake and eat it" icon?

[Pperson]

The "why bother" isn't very clear...

... and usually that means other unspoken agendas are busy. There's a few things I just don't get about Native Client:

- If its security model is working on x86 instructions, how is that portable to non-x86 machines?

- Given how new the verifying-instructions approach is, how can one claim it is secure? It's not been sitting there getting attacked yet - who knows whether there is a glaring hole that the researchers hadn't thought of? Only time will tell.

- The only thing I personally see as a bonus is that you can use a compile-checked and statically-typed language, something that I like better than the dynamic typing and loose OO of JavaScript. But you don't need to support native code to do this. You just need a different language, or simply get stricter with JavaScript, exactly like HTML5+CSS does to old-style HTML. The reasoning of "eases porting existing C code to the Web" isn't exactly inspiring.

On the surface, Native Client fills the same role as Java applets (speed + compiled code). However, it seems more likely to me that Google wants more speed to do things with their Web toys to make them more desirable than the competition's, and their tweaks of their JavaScript engine isn't giving it to them. Hence the Native Client idea.

[Windrose]

You mean XHTML, surely

"You just need a different language, or simply get stricter with JavaScript, exactly like HTML5+CSS does to old-style HTML."

HTML 5 has not gotten stricter, no. That's XHTML for you. What HTML5 is, today, is a loose, shaky, half-baked set of specifications that include how to parse CRAP code. No, XHTML as XHTML doesn't do much good for the end user either, but HTML 5 isn't strict in ANY sense of the word.

You want strict? You need to upgrade the so-called "developers".

[David Hicks]

It is mentioned but I'm going to bring it up again

Isn't this likely to be a security nightmare?

There's enough harm can be done with Javascript, which the guy seems to hold up as a paragon of secure computing, but starting a cat and mouse game with native code hackers seems like a really bad idea.

[Anonymous Coward]

This is actually googles attempt at giving you a boot up browser based os. they needs native apps for this to be effective as no one can write a decent word processor or spreadsheet in javascript. They look good but can't really work well with big documents, insert charts, and manipulate on the fly all that lovely stuff we are so used to with excel.

They don't want to be another .net or java but they will attempt that old pony too.

Flogging a dead horse too. Or maybe its horseplay? Its all rather equine, I don't like this hoofing around at all. stick to search.

[Pete Spicer]

At least in the Chrome beta you can turn it off. I'm not sure that will remain the order of the day in the future - just as once, JavaScript could be turned off without breaking most of the Internet.

As a web developer I really don't like this idea. Not because it puts my skills out (which it doesn't, I primarily program on the server side, not the client side) but because the so-called sandbox really isn't that secure.

[jake]

::yawns::

I already have access to programming languages and interfaces that allow me to set up "world readable" Internet sites.

What's the point of this new kit?

Don't bother answering ... I already know. It's about marketing ...

[bazza]

Sorry, but quite long...

Good article, thank you.

There’s a whole lot of horse shit being spouted all over by the various people quoted in the article. For instance:

"While JavaScript is a fabulous language and it just keeps getting better, there is a lot of great software that isn't written in JavaScript, and there are a lot of software developers that are brilliant, but they would rather work in a different language,"

Entirely wrong. JavaScript is merely an adequate language for certain purposes. Programmers use other languages for sound technical reasons (performance, libraries, etc), not just because they’d rather not use JavaScript. If Brad Chen thinks that all programmers should somehow want to use JavaScript (or maybe some other single language) then he’s starting off on the wrong foot.

And just who is Linus Upson trying to kid:

"One of the key features of the web is that it's safe to click on any link. You can fetch code from some unknown server on the internet,"

So Google have never got stung by a dodgy web link then? There have never been holes in JavaScript interpreters have there?

"Before, when you downloaded a native application, you had to install it and you had to trust it. With Native Client, you can now download native code, just like you download JavaScript and run it, and it's every bit as safe."

That maybe true but they’re carefully chosen words. “Every bit as safe” doesn’t mean perfectly safe.

And how about this little gem:

"You've added this arithmetic to make sure the jumps are in range. But the real issue is that if it's really clever, a program will arrange for a jump to jump past that arithmetic," says Morrisett. "You might protect one jump but not the next one."

So Morrisett is saying that someone might just do a little manual hacking to insert op codes in order to achieve something nefarious? It depends on where the verification is performed. If it’s done on the client as the code is running, then this whole NaCl sandbox idea will fall to the oldest hacking trick in the book. And using x86’s segment registers is mad. In today’s world of virtualisation there are many fine instructions on x86 from Intel and AMD to make strong sandboxing realistic, yet Google are choosing to ignore all that in favour of an archaic monstrosity from the dark ages of computer architecture history?

And Google haven’t done an ARM version yet. Haven’t they seen the mobile revolution happening just down the corridor in the Android department, in Apple’s shack, at Microsoft and literally everywhere else? Not having an ARM version is soon going to look pretty stupid if it doesn’t look stupid already… And isn’t PNaCl just mimicking Microsoft’s .NET and Sun’s Java? Does the world really need another one?

“Chrome will only accept Native Client applications distributed through the Chrome Web Store, and Google will only allow Native Client apps into the store if they're available for both 32-bit x86 and 64-bit x86”

So NaCl won’t be the web then. Users won’t be able to click on any link out there in the Web and get a NaCl app because they’ll have to visit a Google run store? That sounds *very* inconsistent with what Linus Upson was saying earlier.

But hang on, Chris Blizzard is talking junk as well:

“Once you download the native code, there's no opportunity for browser optimizations.”

Err, isn’t that the whole point of native code? Isn’t it supposed to be fully optimised already, no room for improvement without a hardware upgrade? No amount of software re-jigging inside a browser is ever going to make a properly written decently compiled piece of native code run any quicker than it already does?

“A source code–based world means that we can optimize things that the user hasn't even thought of, and we can deliver that into their hands without you, the developer, doing anything.”

Hmmm. I wonder how many web site authors, plug in developers and the like have spent feverish hours in the middle of the night trying to fix a web site or plug in to cope with Mozilla changing something YET AGAIN. Hasn’t Blizzard heard about the debacle over Firefox version numbers? His statement is correct only if the ‘optimisations’ don’t effect the standard, but Mozilla (and everyone else I guess) hasn’t exactly agreed what the standard is nor kept to it:

"What are you going to do about version compatibility? What are you going to do about DLL hell?”

Indeed. What are you going to do about plug in hell?

And this is a real beauty:

“Chen and Upson also point to efforts like the Emscripten project, which seeks to convert LLVM bit code to JavaScript. Even if Native Client isn't available in other browsers, Upson says, this would allow all Native Client applications to span the web.”

So we’re going to write in C++. That’ll get compiled to LLVM. Ordinarily that would get executed in some sort of VM, just like .NET and Java, in which case I might have chosen to use C# or Java in the first place. But just in case that VM is missing, the LLVM will get re-compiled to JavaScript, which in turn will get interpreted to x86 op codes. IN THE NAME OF HOLY REASON HOW IS THAT SUPPOSED TO BE A GOOD IDEA? Sorry for the shouty shouty, and I’m not religious in anyway either, but sometimes things make me snap. It’s not April 1st is it? No, good; I thought I’d better check.

Right, enough of the rant. Web apps (Java, JavaScript, whatever) are Web apps. Native apps are native apps. They serve different purposes. NaCl is another Google effort to corner more on line advertising revenue by means of setting up another app store eco system that doesn’t actually deliver any tangible benefit to the end user. All this talk of ‘trust’ doesn’t matter two hoots. In both models you have to trust either the app developer or Google. Why is trusting the app developer worse than trusting Google? You could even argue that a Single Point of Trust is worse - just look at the problems we've had when a single CA (Diginotar) gets hacked.

Unless they pull their fingers out very quickly NaCl is going to wither and die as the consumer world transitions wholesale to ARM. This transition is likely going to be driven like we’ve never seen before by Microsoft bringing out Win8/ARM.

On the face of it Linux (well, Android), Apple’s and Microsoft’s propositions are far more sensible (though Oracle might do for Android yet in the law courts). Java and .NET do a decent enough job. Microsoft will also have to do a decent job of making the x86 / ARM choice a non-issue to native developers (and the word is that they’re doing quite well on that front). Apple has made it relatively simple for developers of native apps to target the whole Apple eco system.

Battery life is going to be king for many years to come, and NaCl looks like a very bad way of extending battery life to me, not least because it’s currently stuck in the land of x86. If Win8/ARM machines start issuing forth in large numbers and last whole days on a single charge, who’s going to want a power hungry x86 machine running anything, least of all Chrome and NaCl?

[DZ-Jay]

@bazza

Very good and insightful post. However, I do find one fault:

>>>>>>

Err, isn’t that the whole point of native code? Isn’t it supposed to be fully optimised already, no room for improvement without a hardware upgrade? No amount of software re-jigging inside a browser is ever going to make a properly written decently compiled piece of native code run any quicker than it already does?

<<<<<<

I believe that was exactly Blizzard's point, especially considering that not every single native application is a "properly written, decently compiled piece of native code."

-dZ.

[bazza]

@DZ-Jay

"Very good and insightful post."

Thank you very much :-)

>>>>

I believe that was exactly Blizzard's point, especially considering that not every single native application is a "properly written, decently compiled piece of native code."

<<<<

Well, maybe. Blizzard is right in that a piece of JavaScript can be run better by having a better interpreter as well as the developer actually improving the source code's own efficiency. But I suspect that Blizzard is being rather optimistic if he thinks that an interpreter can make JavaScript better than ordinary native code.

For example, imagine that they were to develop a Javascript engine that automatically spots opportunities for parallelisation in the source code. Fantastic!!! That can all be vectored up, maybe executed on a GPU if its big enough to warrant it, amazing!

However, all those tricks will also exist in the native application world too. Many already do (loop unrolling, etc. The native C/C++ compiler writers have been trying pretty hard over recent years, especially Intel). All you have to do is set the right comiler switches to tell it to do what it can, et voila, a faster application is produced. And ATI and Nvidia are trying very hard to make useful APIs (OpenCL and CUDA) available to developers to simplify the task of doing really big number crunching.

So there's nothing special about JavaScript that means that there are some magical optimisations that can automatically be applied that couldn't also be applied to C, C++ or indeed any other language. And if they are applied to a native application at compile time that's likely always to be better than suffering the overhead of an interpreter. Concievably one might run the interpreter in a separate thread on a different CPU core to get round this. But that is consuming a core's runtime which might otherwise be dedicated to executing application code.

Similarly I think Google are crazy if they think they can successfully and usefully abstract all the fancy high performance computing APIs that are currently available to native application developers. For instance, will they make NVidia's CUDA or ATI's OpenCL available as a standard part of the NaCl environment? If not then already they're way behind the curve. It will likely always be the case that as APIs for high performance come along (like CUDA and OpenCL) NaCl will always be playing catch up, won't be able to support them on all platforms, or will just not bother.

The only way to achieve better performance on given hardware than is achievable through compilers / interpreters spotting the obvious or off-loading this 'n' that to a GPU is to have explicit parallelisation in the original source code. This has traditionally been perceived as very difficult, so most people and indeed almost the entire computing industry has tried to avoid tackling this head on.

There is some progress though. SCALA (for those who've not heard of it that's a superset of Java) is a language that brings the old fashioned Communicating Sequential Processes paradigm from 1978 (!!!) back to life. This simplifies the business of developing applications that are inherently parallel. It takes a big shift in how one goes about designing a computer programme, but trust me it's worth it. This is (currently) a much better starting point than trying to get a compiler or interpreter to work it out for itself. Likewise OpenCL and the like are making it easier to exploit the mass parallelisation available in a GPU.

[stuff and nonesense]

"Right, enough of the rant. Web apps (Java, JavaScript, whatever) are Web apps. Native apps are native apps. They serve different purposes. NaCl is another Google effort to corner more on line advertising revenue by means of setting up another app store eco system that doesn’t actually deliver any tangible benefit to the end user." -- Completely agree

NaCL distributes binaries, why bother, I can download a binary (.exe), install and run it.. my trust is in my virus scanner..

Java distribures web applications, these are self contained.. maybe a little slower than NaCL but browsers improve.

JavaScript is text, read and interpreted/compiled on the fly (if I'm wrong let me know but no flames needed)..

The comparisons are between NaCL and Java from what I can see, JavaScript is a herring rouge.

To be honest, I won't be using NaCL, it is another tool for Google to harvest data to enable them to "better serve" us advertisements.

To all Americans, it is "different from", an infinitive, never is it "different than" or "different to".....

[Eric Van Haesendonck]

A good idea

I am one of the only one who seems to think that native client is not only a good idea but something that is needed by the web?

What most seem to forget is that for a lot of things web apps have failed miserably.

- Gaming is one of them: why do web games look like some 2D thing out of the 90' ? Why can't I play battlefield 3 or Skyrim from my browser if my computer has the 3d hardware to do so? The only thing that currently looks like a decent "console quality games on the web" is OnLive and that's because all the processing happens on the server (and it needs a plugin anyway)!

- Video is only remotely good with the flash plug-in. Youtube exists for years now but the only way to get decent (meaning hardware accelerated) web video on desktop and mobiles is still flash with no useable standard in sight. and don't get me started with video editing in the browser.

- Mobile web apps are also a failure. Initially the iPhone was supposed to support only web apps, no app store. Have you seen how well that turned out: developers are fighting to get into the app store and the Android marketplace!

The fact is that current web apps and Javascript are OK for apps that mostly display data or do some limited data manipulation such as email, word processing or spreadsheet, but as soon as you want something more consistent there is not much. Where my web base GIMP (with all its filters and plugins)? where's my web based Audacity? Where is my web based premiere? where's my web base PowerDVD?

If you think current web technologies are good enough try to use a browser without plugins for a month to perform all you do with you computer (and that means watching DVDs and Blu-ray, video gaming, office work, watching video etc...) and tell me how you fare. End users expect web apps to deliver the same level of functionality and processing as native apps, can Javascript deliver that?

[Mike Pellatt]

"Where my web based <name any app you fancy>"

To which my only response is "Why would you want that ??"

[DZ-Jay]

A bad idea

>> What most seem to forget is that for a lot of things web apps have failed miserably.

What you seem to miss is that your comment completely undermines your point. Web apps *have* failed miserably in certain respect *precisely* because they are not part of the core strengths of the Web.

Your post starts acknowledging this and then rams into a wall of bad logic. It all starts with your definition of what the "Web" is. Just like Google, you seem to define "Web" as "Browser." It doesn't matter if it is portable, or consistent across platforms, or distributed, or completely open; as long as it executes within a browser it is "Web."

Right-o.

I'll tell you what, take the executable of Battlefield 3 and rename it "iexpore.exe," et voila! it's now "the Web."

-dZ.

[sparso]

"The only thing that currently looks like a decent "console quality games on the web" is OnLive and that's because all the processing happens on the server"

Personally I think this is the long-term future for graphics/cpu intensive applications. As internet connection speeds and latency improve over time "cloud gaming" would mean you no longer have to upgrade your hardware to play the latest games, install patches or buy a new console. And there's no need to run native code in the browser.

[TonyHoyle]

.....

"One of the key features of the web is that it's safe to click on any link. You can fetch code from some unknown server on the internet,"

hahahahahahahahahahahahah

[DrXym]

NaCl waste of time, PNaCl not a waste of time

NaCl uses processor hacks to enable a browser to execute native code within a sandbox. The theory being that the sandbox stops the code from doing anything it shouldn't. Even assuming the sandbox is secure, the fact that the code is processor dependent makes it a really dumb idea. People don't like having to write the same code for multiple architectures.

PNaCl on the other hand is a good idea. It uses LLVM to virtualize the environment so devs can build one app and in theory it will run anywhere. Also, because the instruction set is virtualized it means there less chance of the sandbox being exploitable, or if it is of fixing the issue.

Without or without PNaCl, people are already trying to produce native client code. LLVM bytecode can be turned into Javascript via Emscripten, and x86 emulators have even been written for JS. So we've see various C++ apps appear from Doom to even a Linux kernel all running in JS. But performance is all over the place. With PNaCl, Emscripten wouldn't be necessary and apps could benefit from near native execution speeds.

[nyelvmark]

x86 emulators have even been written for JS.

Seriously?

Some people just have too much time on their hands.

[DrXym]

Fabrice Bellard

He's the author of QEMU and he wrote a JS emulator for x86. You can even run Linux on it:

http://bellard.org/jslinux/

It's not working for me at the moment, don't know if its an issue with the site or my browser but I have played around with it and it's a little Linux dist and shell.

The obvious problem with JS is it's not memory mapped so everything has to be faked out in a clunky and non-optimal manner. The emulator uses typed arrays for example which are basically byte buffers to simulate memory.

[nyelvmark]

Fabrice Bellard

Thanks. Yes, I already found it. I couldn't do much with it because it seems to require a US keyboard, but it's amusing. rm -rf / has the expected catastrophic effect on the Linux user account.

>> The obvious problem with JS is it's not memory mapped so...

You mean, apart from the more obvious problem that it's like building a Mercedes with a hamster running in a wheel as the power source?

[bazza]

@DrXym

>>>>

Even assuming the sandbox is secure, the fact that the code is processor dependent makes it a really dumb idea.

<<<<

Well, except that currently that's what you have to do to get ultimate performance. Until either x86 (eek!) or ARM or PowerPC or SPARC or MIPS (all much nicer) achieve a complete world wide instruction set monopoly we're stuck with that. And if ultimate performance isn't needed then you'd probably use Java, JavaScript, etc.

In effect Google are trying to provide a completely standardised API for native app developers on all platforms so that apps are write-once-compile-many-debug-once. History is shown that such things tend to fall to the lowest common denominator, which is a sure fire way of not being able to exploit the maximum potential of any given hardware platform which rather defeats the whole point. I wouldn't be surprised if they couldn't make that out perform a really well written .NET or Java (dare I say even Javascript? On second thought's, meh) virtual machine *and* keep it truly platform independent.

>>>>

With PNaCl, Emscripten wouldn't be necessary and apps could benefit from near native execution speeds"

<<<<

Yes, but PNaCl on top of LLVM gets away from the main thrust of NaCl which is to be purely native on the client. If PNaCl becomes their main effort then really they're just trying to compete with any other VM based cross platform ecosystem like .NET, Java, etc. Why bother doing that when they're years behind all of those?

[DrXym]

Ultimate performance

"Well, except that currently that's what you have to do to get ultimate performance. Until either x86 (eek!) or ARM or PowerPC or SPARC or MIPS (all much nicer) achieve a complete world wide instruction set monopoly we're stuck with that. And if ultimate performance isn't needed then you'd probably use Java, JavaScript, etc."

Not really. They could generate native code from LLVM bitcode upon first invocation and cache it somewhere. Then it would run natively thereafter at native speeds. Or they could choose to execute LLVM bitcode through a JIT / interpretter. I assume they'd compile most of the time but on small devices they might prefer JIT.

The advantage is that developers write once and run anywhere, rather than pick and choose which architectures to support.

"Yes, but PNaCl on top of LLVM gets away from the main thrust of NaCl which is to be purely native on the client. "

I don't see why. As I said, LLVM bitcode can be compiled to native code. The performance impact from this is minimal. That's the whole point of LLVM. Benchmarks from gcc vs gcc-llvm / clang suggest the performance gap is quite small and closing.

[John Miles 1]

Provide vector and matrix types in javascript

There really is something attractive in the speed-up from using just one or two machine operations to perform a single source code operation e.g. x = x + 1 (rather than many arising from interpreted steps).

But if one of the objectives of Native Client is to speed up vector and matrix operations, then why not add fundamental (i.e. native) vector and matrix types to javascript, in which case the interpreted overhead would occur only on the single expression involving vectors e.g. vec_a = vec_b + vec_c. The repeated underlying addition and indexing operations would occur at 'native' speed. If the vectors have more than 10 elements such code would excute at close to native speed.

[bazza]

@John Miles 1

Careful - you'll be turning JavaScript in to MatLab, and you reeeeeeeeeeeeeeeally don't want to do that it you want high performance!

Other languages have done just that. Motorola extended C (and hence C++) on PowerPC with new types like "vector float" and "vector int". If you wanted to add four floating point values to another set of four values then it is a simple operation along the lines of ans_vec = vec_add(vec1,vec2), guaranteed to complete in a single clock cycle. A very good way to easily get stunning performance out of quite slow clock rate PowerPCs (equivalent to a x4 on the clock rate if you were really good).

I think that deeeeeep down in the Intel C compilers there's a very similar idea hidden away from view but still accessible if you go looking. Intel seem much more focused on providing complete libraries of useful routines that hopefully mean you as the programmer doesn't have to get that low level. But the low level stuff is still there somewhere.

[Anonymous Coward]

Agreed - Chrome OS might be a pretty neat idea, but it can't play anything other than Flash games (although Flash 11 will have native 3D support).

If Google want to sell bucket loads of web-only PCs, then also being able to play proper games is important to them. It could then be more than a simple web and email only computer that seems a little pointless.

[bazza]

@Def

"The world+dog is moving away from languages like C and C++ for a reason."

Not entirely correct. Those who really want the ultimate in performance are using them in a big way. Many datacentre people are wondering if C/C++ are a better bet than PHP, etc. from the point of view of electricity bills. And a surprisingly large fraction of the HPC community are still using Fortran. Almost all OSes are in C / C++ one way or another. Big applications like database engines, CAD packages, CFD modellers, etc. are not written in Javascript.

[Ben Liddicott]

Again... Great! A new way for malware to exploit our browsers!

If they can't sandbox Java, which is a BYTECODE interpreted language FFS, how the heck are they going to sandbox Intel machine code?

They aren't, obviously.

Just as this:

WebGL: Interwebs 3D tech emerges from puberty

http://www.theregister.co.uk/2011/03/03/webgl_one_dot_o_released/

Became this:

New graphics engine imperils users of Firefox and Chrome

http://www.theregister.co.uk/2011/05/11/chrome_firefox_security_threat/

This will become something bad too.

[Ken Hagan]

What's the point?

Technically, this is pointless. It will fail in the market, just like it did last time.

1) If you want to sandbox native code, use the facilities in your OS. I'm fed up with web browsers trying to re-invent security models and sandboxing techniques that were developed by OS designers in the 60s and that are implemented in every desktop OS that these browsers run on. You can run IE6 in the "Safer" sandbox provided by Windows and it is more secure than the latest version of your-browser-here running normally. The OS people are *much* better at this game than the Web people.

2) If you want an app that has the speed of native code and the connectivity of a web page, find a sockets library and implement the web bit on native code rather than the native code bit on the web. The latter is about as sane as that guy who wrote an x86 virtualisation engine in Javascript. Alan Turing would be completely proud, but you are still a dick.

3) If you want something portable, try shopping for a decent implementation of a language that has an ISO standard behind it, rather than settling for the sole implementation of a language where the owner bought the standard. I won't recommend one, because there are several languages out there with decades of practice, extensive supporting libraries and standards specified to a level of detail and precision that would make a Web 2.0 programmer's eyes water. If you can't handle the choice, find a new career.

So if standardised and fully portable languages for general purpose programming already exist, and the capability to sandbox them already exists, and if they have all the connectivity of the web already, why are Google (and others) constantly trying to re-invent the wheel?

My guess is that these projects are driven by people who enjoy programming but have rather less idea about marketing. Ironically, the problem with these languages is that they behave the same way on every platform and therefore fail to integrate really well with any of them. Given the choice, most commercial developers choose to use non-portable features (or languages) to produce a better product for a smaller market. As long as the academics and hobbyists fail to understand this point, we'll see a constant re-invention of this particular wheel.

Off topic, but an example of the same broken mind-set, application designers and technology evangelists should note that Real People also "don't want" the same application UI on their mobile phone (touch screen, just several inches across) as they do on a desktop device (mouse and keyboard, screen several feet across). They don't want that any more than they want their bodily appendages to be re-scaled by an order of magnitude.

[Anonymous Coward]

One correction...

"They don't want that any more than they want their bodily appendages to be re-scaled by an order of magnitude."

Some might to some of them. Just saying.

[TeeCee]

".....just like you download JavaScript and run it, and it's every bit as safe."

Says it all really.

Any statement on security that uses the words "Javascript" and "safe" in the same sentance without a negative qualifier has an inherent flaw.

[Ru]

Hmm, sounds familiar.

Program in whatever high-level language you like, compile it to portable bytecode, have it run on a suitable interpreter written for a target architecture in a nice sandboxed environment. Add some open-source, standards-enthusing whitewash to complete the picture.

You could do that with silverlight, if you wanted.

That's been an absolute runaway success for Microsoft, hasn't it?

Frankly, I'm more interested in their ability to support sandboxing of actual native applications in general; that sounds like a massively useful feature for any OS.

[lostinspace]

I'm confused, wasn't this invented years ago by Sun and called "Java"? Or have I missed something?

[Thomas Wolf]

yes you are confused

Java is not a "native" client. Java programs are turned into a single "byte code" used on every platform.

[Christopher Edwards]

Erm...

Which is exactly what Google are planning to do eventually according to this article!

[bazza]

@Thomas Wolf

Almost right.

A lot of ARM devices implement Jazelle, which is ARM's Java byte code execution engine alongside the ARM instruction set. In essence you can execute Java byte code natively alongside ARM instructions. There's an ARM op code that says that the next instruction to load from memory will actually be Java byte code; it's as seamless as that.

All of a sudden Java doesn't seem so stupid in the mobile platform, does it? Though I don't know if any of the the Java ME environments out there or Android's Dalvik use it.

[bazza]

@Thomas Wolf, encore

I've done a bit more digging.

Jazelle exists, but isn't widely used. Japanese phones seem to use it a fair bit, but that would appear to be that. Seems a shame. I tried to find out whether Blackberries use it with no success. Given their pretty good battery life, perhaps they do.

Hardware acceleration has made everything else on ARM pretty good - video/audio codecs, GPUs with adequate grunt, etc. etc. So why not Java?

If the chip manufacturers (TI/OMAP, Qualcomm/Snapdragone, etc) don't put it on then no one can use it. And given that a large fraction of the mobile market (Android & iOS) don't support Java anyway, why bother to put down silicon that's not going to be used?

Seems a shame - hardware accelerated Java could provide a really nice solution to the problem of write once run anywhere in the mobile space, but I guess there's too many vested interests to prevent it ever taking off. There's Apple with the iTunes store and Google with the Android store for a start; and neither of those parties want to open up their platforms to apps from just anywhere...

[P. Lee]

What are you canabalising?

It depends what ends up happening...

If you end up moving desktop apps (which otherwise wouldn't move) to the browser then that's nice - a far better distribution model than currently exists.

If you end up moving what could be a web app to compiled C++ in NaCl then you're going the wrong way.

You might reduce the impetus to move to pure web apps, but then, that might not happen anyway.

Personally, I'd love to see LibreOffice in NaCl because it would be a great way to roll it out and I

don't think we'd see it performing well if it was re-written in pure JS. Of course, a pure web version would be great but I don't think we have the cpu horsepower for it yet.

I'd see NaCl as another architecture, not really a replacement for the true web. Currently we have x86 windows apps, x86 linux apps so there's no reason not to have x86 NaCl apps.

As for Pinnacle, I think a bit of competition for Java from a company slightly less evil than Oracle would be a good thing.

[Paul Ireland]

Unity and Flash 11 Molehill

"Unity Technologies has long offered a plug-in for running 3D games in the browser at its Unity platform, but the San Francisco-based outfit is now porting the game platform to run as a Native Client application. This means that developers can deliver their Unity-based games to Chrome without asking the user to install the plug-in – and at the same time, they can take advantage of the Native Client sandbox."

Unity are also looking into porting their engine to Adobe Flash 11 molehill technology (with its 3D hardware acceleration):

http://blogs.unity3d.com/2011/02/27/unity-flash-3d-on-the-web/

[1Rafayal]

"Native Client democratizes web technology"

I stopped reading at this point...

[cyborg]

What are you - a commie? If you don't love NaCL the Russians will win!

[Andrew Hodgkinson]

Facepalm quotes galore

"...the same excellent level of portability and safety that JavaScript provides on the web today..."

Clearly, Mr.Chen has never written JS for more than one browser and has presumably not read any of the numerous articles about JS based exploits.

"One of the key features of the web is that it's safe to click on any link..."

Meanwhile, Mr.Upson is apparently talking about a different 'web' on some planet other than Earth.

"Before, when you downloaded a native application, you had to install it and you had to trust it"

How would providing a sandbox at the OS level be any better or worse than providing a sandbox built into the browser? Are Google completely unaware of all the code signing and sandbox technology that's been going into the mainstream operating systems for the last few years?

So this isn't about safety...

"Native Client doesn't add any new capabilities that aren't actually in JavaScript and HTML5. It just makes them available to C and C++ programmers"

...it's about providing the legendary ease of development, easy of debugging and stability of C and C++ combined with the legendary reliability and security of the cross-platform seamless environment that is the web browser. After all, HTML and CSS are just *the* best thing in the word for making application-like user interfaces, yes?

Good grief.

Just a handful of quotes in the article have managed to give me stronger reasons to avoid Native Client than any number of comp.risks digests might have done! :-)

[Luke McCarthy]

Not the worst idea

I don't like the idea of distributing native code directly with NaCl, but using LLVM is a good idea since it doesn't lock the web to a set of supported ISAs (at worst you need to implement a new backend code generator for LLVM). It's like Java bytecode, but better since you can use a much wider range of languages.

JavaScript has been stretched way beyond what it should have and it's time for real programming languages to pick up the slack. Many design flaws of JS make it very hard/impossible to optimize it like you can other languages (despite the heroic efforts of V8, TraceMonkey, etc.), so it makes a very poor choice as the "assembly language of the web".

[Thomas Wolf]

Javascript secure? Really?

The author appears to lack a certain understanding of the the underlying technologies/languages he's writing about. It is most evident in this one statement:

"JavaScript is an interpreted, dynamically-typed language, and it was specifically designed to protect netizens from malicious and buggy code".

Javascript, when it originally came out, was nothing more than a hack Netscape came up with to allow scripting in the browser. There wasn't much design to begin with - and even less (I'd say zero) consideration to "protect netizens from malicious and buggy code". Perhaps the author confused Javascript with Java (a confusion Netscape no doubt counted on for publicity when it re-labeled the language from Livescript to Javascript). *Java* was designed with a strong security model built-in.

[Stephen Channell]

NaCl && PNaCl

Both are a bit-show for browser functionality because HTML5 is already too far through the adoption cycle too tempt developers of any new application.

Where it will be neat is for hosting existing code within the browser.. LibreOffice, some games, Flash/Moonlight && terminal/remote access software ..

The real potential though is for the Google AppEngine... once the sucks have tested the security to death in the Browser... the user is another sandbox

[Captain TickTock]

Different Than...

It's different "from"...

You may as well ask what's the difference between a duck.

[Boris the Cockroach]

Java script great?

safe?

excuse the noise , that was me falling off my perch laughing

I had some loverly safe fun javascript delivered to my browser last year

It included a fekking nasty virus that drove straight through the 'security' and trashed my operating system.. only solved by a live copy of Gparted wiping the entire partion

And now , google want to introduce more native crap that can only run in the browser sandbox... I say no.

If you want apps in the browser, use Java ...... although that involves paying money to Oracle and it leaks like a sieve anyway

[Ben Liddicott]

'Cept Java leaks like a sieve too...

Most recent newsworthy one here:

http://www.theregister.co.uk/2011/06/08/java_security_update/

[Brian Miller]

Write once, run anywhere -- really?

Whatever happened to the "write once, run anywhere" goal? First NaCl makes a goofy x86 pseudo-sandbox, then turns to LLVM. Is LLVM better than .NET MSIL or Java JVM bytecode? Or is it just that its open source? Are there benchmarks for native code derived from each?

This really doesn't look anything at all like the original goal of web applications. For enterprise software requiring performance, the solution might as well be ActiveX plugins. Otherwise, just load up a game and be done with it.

[Infernoz]

Worse security than JVM!

Google must not understand security very well; Chrome is already less secure than Mozilla Firefox because all of its extensions are in machine code, which is stupid and non-portable; worse this new project will have a joke of a sandbox which thinks you only have to protect CPU RAM using a kludge; wrong! The default security in Android is also inadequate, so you have to add extra apps to provide finer grained resource permissions control than the install/don't install with all requested permissions 'option'.

A proper sand box for this native code would need to control access to: GPU RAM (to stop image scraping or GPU malware), network resources, browser components, system components, allocated and passed RAM, and various other vulnerable system resources, otherwise your native app could turn out to be a trojan or a trojan proxy!

Java already provides an extensible security model which makes the Google sandbox sound pitiful and already has serious networking, database and media support (e.g. fast 3D Graphics (via DirectX and OpenGL) , video, sound etc.), but some people are too lazy to use these facilities so mistakenly think that Java can't do fast flashy apps!

To those who think that a Java JVM can only run Java, look here:

https://secure.wikimedia.org/wikipedia/en/wiki/List_of_JVM_languages

Google have already proven that a Java like VM (Davik) can run fast and powerful apps with Android, so why not roll-out Davik to laptops and desktops or provide enhanced plugin support for Java beyond mere Java Applets i.e. multi-threaded code and a better bridge to the browser APIs.

.. or are Google really evil, and want to lock suckers in!

[Werner McGoole]

Just sounds like Java to me

Well, not exactly like Java, obviously. But if the portable version was implemented its goals seem pretty close to what Java* was originally trying to achieve rather a lot of years ago now. That's especially so if you recall that Java turns a lot of its critical byte code into native code at run time for faster execution.

So if this is to have more success than Java it needs to have something extra to offer and I just can't see what it is.

*Not Javascript - thats something different.

[Crazy Operations Guy]

Google is the new Microsoft, only worse

They are up to the same tricks of Microsoft:

1) Reinvent an old technology and make sure to lock people into it. Especially how they force you distribute native code via their own store

2) Release as much FUD as possible. This is seen mostly in how they compare everything to JavaScript, like its only scripting language you can use.

3) Attempting to add non-standard features to standards to force users onto their platform

4) Offering things for free than taking them away once they are adopted (Especially true with the closing of the Android Source code)

5) And what makes them worse than Microsoft could ever be: they are trying to control every part of the web, everything from the base hardware all the way up to the highest layers. And with every one going crazy over Chrome OS, it seems that such control will become reality

[FrankAlphaXII]

Yet another reason not to go anywhere near Chrome.

I think ill add this to my ever growing list of why I wont go anywhere near chrome with any machine I have any modicum of control over. It seems to grow daily.

And using JavaScript as an example of some sort security paragon displays either a complete lack of understanding of JS security issues or simply general ignorance.

[Henry Wertz 1]

Not a browser technology

Tim Berners-Lee is right on this one. The possibility for security holes is real. But, this is not even the real issue. The real issue is that it is NOT CROSS PLATFORM. Compiling for a few main chips that are on the market now is really not a solution. PowerPC? Alpha? PA-RISC? Some new chip like the CRIS, or one of these MIPS that some cheap tablets are using? Shit out of luck. As something in the browser, this is objectionable by it's very design quite honestly.

PNaCL *could* solve this. But, the way it's described, having binaries shipped native x86, then for non-x86 coverted to llvm, then compiled for the native CPU? Fail. Have the apps shipped in llvm bytecode. This also enables the possibility of optimizer improvements down the road in the llvm->x86 transformation, which would not occur if PNaCL insisted on natively running the x86 code on x86 platforms. Down the road, if PNaCL did gain llvm->x86 optimizations, you'd likely end up having it do x86->llvm->x86 transformations anyway, just wasting time over shipping in llvm form to begin with.

If PNaCL comes out, uses llvm rather than x86, then I'd have to see how it works out.

I'm also curious on how flexible the (already existing, already portable, and already having just-in-time compilation) Java VM is. Is it designed to just support Java-like programming languages, or could it support C? If it can support C and C++ reasonable, then problem solved.

[Hoagiebot]

Yet another possibility for why Google could be pushing NaCl

I am in general agreement with many of the sentiments that were posted here about what Google's purpose was for creating and pushing NaCl. Ideas such as Google creating NaCl to create another app store ecosystem for non-mobile devices, that this was a way to add the ability to run native code on their ChromeOS-powered Chromebooks to make the things more capable, or even that Google was trying to do what Netscape and Microsoft did back in the 1990's by trying to create new proprietary add-ons to the Chrome browser to give it more amazing and flashy features than the competition in an attempt to increase market share and lock-in are all very possible and likely also very probable.

With that said, I believe that I may have thought of yet another reason for why Google may be pushing the development and adoption of NaCl: to help save their core business and revenue stream based on their web offerings, such as the Google.com search engine and AdWords. To explain what I mean, last year I read an article in Wired magazine called "The Web is Dead. Long Live the Internet." You can read this article for yourself online here:

http://www.wired.com/magazine/2010/08/ff_webrip/all/1

The article explained that while the use of the overall Internet is booming, the use of the web itself is in decline. The reason for this is because consumers are ditching the wide-open web for the consumption of much of their content and instead turning to simpler semi-closed platforms (a.k.a. "apps") to consume their content instead. Think of how much you use apps to get your Internet content in this day and age instead of your browser, especially on your smartphone. Pandora, Skype, instant messengers, Netflix-- those are all apps that use the Internet while not using the web. And there are many things that you used to use the web for that you can now do with apps, such as using Facebook apps, Twitter apps, webmail apps, weather-checking apps, heck you can even download apps for newspapers such as the New York Times to read their articles with if you feel too lazy to load up your browser and type "www.nytimes.com".

Every time you use one of those apps to access a service directly you are not using Google's search engine to find that service's website, and you are not seeing any AdWords advertisements displayed on webpages. In fact, I would go as far as to say that the only reason why smartphones contain web browsers at all is as a courtesy to provide a throwback solution to allow you to view those last few services and sites on the web that haven't developed their own app yet. Everyday the web is becoming less and less relevant, and as a result Google's primary web-based advertising business is slowly becoming less and less relevant. Recently Facebook became the most visited website on the web actually usurping Google.com, and you don't actually need to visit Facebook on the web at all because hey, there's an app for that! Google may still be king of the non-Facebook web, but being king of the web is being the king of a dying kingdom. As a result, Google needed to find a way to ensure their relevance for the future, and I think that they are doing this through three different (and sometimes self-competing) fronts.

First of all there is Google's attempt to embrace the whole non-web app movement-- Android, which is Google's attempt to have some control and make some money off of the smartphone and app revolution that is slowly cannibalizing its web business. This would probably be working out great for them if companies such as Baidu, Alibaba, and QQ weren't forking Android, stripping out all of the Google parts, and then selling the Google-less version to massive markets like China.

Then there are Google's attempts to actively combat this whole browserless app trend by instead improving web application technologies in an attempt to make the web into a top-notch application-hosting platform (in combination with their Chrome browser, of course). NaCl, like Google Gears before it, falls into this category. Google doesn't want you to use Facebook, or read the New York Times, or watch movies, or do anything else through a direct app that cuts out the middlemen of their search engine, their advertisements, and the web in general. Instead they want to drive user traffic back to the web where they can make money off of it, and they are trying to do this by turning the *web browser*, on the desktop at least, into a competitor of iOS and Android for hosting and running apps. If Google succeeds and turns the web browser into the primary way of running apps it would make their Chrome browser more relevant, it would keep their core search engine and AdWords business relevant, and it would suddenly make their ChromeOS actually relevant. And for mobile devices where using the web browser is not ideal Google still has Android to help hedge their bets in that market too.

So while I definitely think that NaCl presents an opportunity for Google to create a new app store ecosystem, improve the capability of ChromeOS, make the Chrome browser more attractive than competing browsers through proprietary features, etc, I also think that this is a play by Google to make the web a more competitive application platform and stop the drain of people leaving the Google AdWords-dominated web to use simple single-purpose apps to directly access Internet content.

[Eric Van Haesendonck]

A good idea

What you seem to miss is that your comment completely undermines your point. Web apps *have* failed miserably in certain respect *precisely* because they are not part of the core strengths of the Web.

Your post starts acknowledging this and then rams into a wall of bad logic. It all starts with your definition of what the "Web" is. Just like Google, you seem to define "Web" as "Browser." It doesn't matter if it is portable, or consistent across platforms, or distributed, or completely open; as long as it executes within a browser it is "Web."

=> Indeed this is the whole idea: that everything should run in the browser and everything should have a certain amount of portability. If the point of project like Chrome is to remove all local apps except the browser then browser technologies need to be secure and have enough performance to perform within the browser all the tasks that are currently performed outside the browser, and currently Javascript is not up to that.

[Jeff 11]

"Native Client democratizes web technology"...

"...but only if you use Chrome, the Chrome app store, and we approve of it."

Democracy, indeed.

[Anonymous Coward]

How long before the NoScript devs get busy...

...and release NoNative.