Native Client in Chrome Beta

[Marco Leise]

Am 14.08.2011, 22:00 Uhr, schrieb Andrew Wiley <wiley.andrew.j at gmail.com>:

> On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise <Marco.Leise at gmx.de> wrote:
>
>> Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley  
>> <wiley.andrew.j at gmail.com>:
>>
>>  On Sat, Aug 13, 2011 at 5:10 AM, bearophile  
>> <bearophileHUGS at lycos.com>**
>>> wrote:
>>>
>>>  Found though Reddit. It seems Chrome is starting to warm up to the  
>>> Native
>>>> Client (NaCl) idea, the Chrome Beta now has a working NaCl:
>>>>
>>>> http://chrome.blogspot.com/**2011/08/building-better-web-**
>>>> apps-with-new.html<http://chrome.blogspot.com/2011/08/building-better-web-apps-with-new.html>
>>>>
>>>>
>>>> http://channel9.msdn.com/**Shows/C9-GoingNative/**
>>>> GoingNative-0-Help-us-fly-**this-plane-Some-modern-C-Meet-**Ale-Contenti<http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti>
>>>>
>>>> It's one (the only?) chance to use D in the browser.
>>>>
>>>> Bye,
>>>> bearophile
>>>>
>>>>
>>> Just thought I'd point out that the previous discussions on NaCl seem  
>>> to
>>> have missed this part of the overview:
>>> "The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is
>>> included in the Native Client SDK. This library is written in C, and  
>>> the
>>> SDK
>>> also provides a set of C++ bindings for it. Native Client modules use  
>>> the
>>> Pepper API to communicate with the browser's JavaScript, the DOM, and
>>> other
>>> resources managed by the browser. The Pepper Library also provides a
>>> platform-independent multimedia API that Native Client modules can use  
>>> for
>>> audio, video, and 2D graphics."
>>>
>>> So yes, this is somewhat geared toward multimedia, but it looks like it
>>> can
>>> also replace javascript in web apps.
>>>
>>
>> Is this basically the same as the Java applet interface to the browser
>> without the "compile once, run everywhere", but with better API?
>>
>
> I haven't ever dealt with the applet interface, but that quote came from
> http://code.google.com/chrome/nativeclient/docs/technical_overview.html  
> if
> you want to take a closer look. The Pepper API docs are there as well.

It doesn't convince me. The driving force seems to be moving desktop  
applications into the browser. That's understandable since a lot of people  
at Google use their web services where possible. I personally don't like  
that centralization on the browser. It adds up on complexity and bugs,  
trying to be an operating system that manages running applications. How do  
they make sure the code is safer than what we know from ActiveX? Even the  
WebGL standard was in the critics, because it was obviously accessing the  
gfx card and a malicious texture upload in a buggy driver could become a  
security risk.
Maybe it finds a way through good advertising or real-time games which run  
faster with native code instead of JavaScript, but there will always be  
some bad memories from http://www.adoko.com/activex.html
At least they take the issue serious :)  
http://www.zdnet.com/blog/security/google-wants-to-buy-native-client-security-flaws/2702