Google Native Client : Un ActiveX-Like ?

Attention, cet article a été posté en 2008. Il est possible que les informations mentionnées ne soient plus d'actualité, ou que mon opinion ait évolué. Merci d'en tenir compte lors de votre lecture.

Depuis la naissance du web, de nombreuses technologies ont tenté de rendre les navigateurs plus interactifs. Nous pouvons notamment citer Javascript, les applets Java, Flash, Silverlight, ActiveX... Mais toutes ces technologies, à l'exception d'ActiveX, présentent un certain niveau de sécurité, pour protéger l'internautes des virus ou autres codes malveillants. Ainsi, certains types d'opération sont tout simplement bloqués.

En revanche, ActiveX n'impose aucune limite, et permet de faire absolument tout. À partir du moment où vous acceptez l'exécution d'un code ActiveX, ce dernier possède autant de privilèges qu'un programme directement installé sur votre machine. Accéder à vos documents, aux fichiers systèmes, ou agir directement sur les ressources de votre ordinateur. Malgré l'alerte affichée par Internet Explorer avant l'exécution d'un tel code, ActiveX a souvent été source de vulnérabilité, à cause du manque de vigilance des internautes.

Ainsi, pour des raisons de sécurité, la possibilité d'utiliser du code natif dans les navigateurs avait été écartée, privilégiant l'utilisation de Javascript, pourtant plus lent. Cependant, Google relance cette idée, en proposant Native Client, un nouveau projet opensource permettant d'exécuter du code x86 dans un navigateur web. Contrairement à ActiveX, cette technologie est conçue pour fonctionner sur toutes les plateformes (Linux, MacOS, Windows).

Google Native Client est prévu pour les gros traitements, généralement trop lourds pour Javascript. Par exemple, pour retoucher des images en ligne : actuellement, les applications en ligne proposant cela couple l'utilisation de Javascript avec un traitement serveur, ce qui nécessite de nombreux transferts de fichiers entre le navigateur et le serveur. Cette technologie permettra de faire travailler directement le processeur de votre machine, sans passer en permanence par le serveur. Vous gagnerez donc en intéractivité, et surtout en temps de réponse.

D'un point de vue sécurité, le problème est délicat. Lorsqu'un exécutable est chargé, Google Native Client le décompile pour s'assurer de la non-dangerosité du code. Cependant, Google admet qu'une telle sécurité n'est pas évidente à mettre en place, et ne peut détecter toutes les actions frauduleuses. En bref, pour peu que vous ayez quelques dons pour masquer votre code, vous arriverez à contourner ce système de sécurité sans trop de soucis. Pratique pour infecter un système.

Vos réflexions

Ça me fait penser à la techno BrowserPlus de Yahoo!
Dis comme ça, cette technologie ne m'enchante pas du tout ! Cependant, ce n'est certainement pas pire que les virus envoyés par mail, par exemple. Là aussi, la vigilance de l'utilisateur est mise à l'épreuve, car de nombreux virus arrivent à contourner les protections (antivirus, etc).
@jusled oui et non, le mail frauduleux reste assez facile à identifier. Mais admettons un avenir où GNC est installé sur tous les clients, quoi de plus facile de lancer une attaque massive via des serveurs DNS corrompus ou des injections de codes exécutables sur des pages "à priori légitimes" (comme c'est déjà le cas actuellement d'ailleurs). Dans un tel cas, l'utilisateur normal ne pourra en rien se douter de l'attaque et donc s'en prémunir.

On peut en déduire que c'est tout de même plus pernicieux, tout comme c'est le cas déjà maintenant avec ActiveX.
@burningHat : Identifier l'origine d'un mail frauduleux n'est pas toujours évident, surtout pour un débutant en informatique. Car, il ne faut pas se leurrer, ce sont avant tous les débutants que se font avoir, les utilisateurs avertis sont plus vigilants.
@jusled certes mais ça reste très nettement plus facile que de détecter un DNS et/ou un site corrompu.