Chrome

[Chrome] PNaCl enfin activé par défaut

Chrome 31 pour Windows, Mac et Linux débarque dans le quasi-anonymat et pourtant il embarque une nouvelle technologie révolutionnaire. Et je pèse mes mots!

31 secondes, montre en main. Trop fort Google!

Cette nouvelle version du canal stable active PNaCl (Portable Native Client), une technologie qui devrait permettre d’enclencher la deuxième vitesse pour les Chrome Apps.

Simple comme une page web.

Sans rentrer dans les détails techniques, on peut imaginer dans un futur plus ou moins proche voir Quick Office fonctionner dans le navigateur Chrome ou encore pouvoir acheter Call of Duty Ghosts sur le Chrome Web Store.

Si vous avez un PC bien puissant qui chauffe, avec des tuyaux de refroidissement bleu fluo, alors vous pouvez acheter le jeu français « From Dust » et le faire tourner directement dans Chrome. Comment cette prouesse technologique est-elle possible? C’est grâce à Arnaud Montdebourg (non, j’déconne…), à Native Client.

Du code C/C++ dans un navigateur.

Grosso modo, cette technologie permet de développer des modules ayant accès aux fonctions natives du CPU/GPU de l’ordinateur. Comme ces fonctions parlent directement dans la langue maternelle de la machine, celle-ci comprend vachement plus vite. Bref, cela permet de faire des hybrid apps aussi performante que des applications iOS, Windows, etc…

Bastion sur iTunes, mais aussi sur Chrome

En fait, Native Client est activé depuis Chrome 14 (en septembre 2011). Très vite, des jeux plutôt cools sont apparus sur le Chrome Web Store: Bastion, Mini Ninjas, Air Mech, Tomb Raider… Et puis plus rien! Le problème, c’est qu’une fois l’hybrid app codé en Native Client, le compilateur fournit un exécutable qui ne tourne que sur une famille de processeurs, par exemple les x86. Pour produire un autre binaire à destination des architectures ARM, il faut adapter le code et le recompiler pour qu’il soit optimisé pour le HP Chromebook 11 par exemple.

Google a du passer par là pour Google+Photos.

Donc, 80% du code est réutilisable, mais 20% reste à adapter/optimiser pour chacune des architectures cibles. Parfois, ces 20% se traduisent par des mois et des mois de boulot, et s’ils n’aboutissent pas, l’application peut se révéler finalement inutilisable. Pendant ce temps là, la concurrence a terminé son programme sur Android et iOS. C’est ballot pour la plateforme Chrome ayant comme principal bénéfice la portabilité.

Le but, c’est quand même que ça marche un peu partout, sans avoir à réécrire du code.

Nous en venons donc enfin à PNaCl, qui est une évolution majeure de Native Client. En compilant le code C/C++ via PNaCl, on obtient un exécutable écrit non pas en langage natif (x86-32 bits, x86-64 bits, ARM…) mais en bytecode bitcode.  C’est ensuite la LLVM (Low Level Virtual Machine) installée sur la machine cible qui se charge de traduire ce bitcode en langage natif. Dans l’histoire, vu qu’on a rajouté un intermédiaire (le traducteur), on perd un peu en vitesse d’exécution, mais il parait qu’on reste proche des 80% de performances (par rapport à un binaire natif).

Mettez un dragon dans votre Chrome!!

Ceux qui n’ont pas lâché en lisant le précédent paragraphe sont donc prêts pour la vidéo live de présentation qui démarre à minuit ce soir. J’en saurais un peu plus après l’avoir visionnée. Si vous avez trop sommeil et que l’informatique vous emmerde profondément, vous pouvez aller reluquer la [Babe] d’hier avant d’aller vous coucher.

Edit 2013/11/15: Voici la vidéo, finalement assez peu intéressante, malgré la présence d’Erik Kay.

A propos de l'auteur

Yvan

Enthousiasmé par Chrome OS, j'écris sur ce blog pour comprendre ce qui me plait tant en ce système né en pleine ère Internet. Vous pouvez également me retrouver sur http://yphiblog.blogspot.fr

18 commentaires absolument uniques ont été postés à ce jour

  • Mais c’est vrai b… faut être précis! Merci pour l’info, c’est noté et corrigé.

    C’est marrant que même certains développeur de Google le prononce « baïtcode ».

  • Aura t on droit à la prochaine étape, qui semble être de traduire le code en langage machine à l’installation (ou à l’ouverture de l’app) plutôt qu’à l’exécution ?
    Il semblerait que ce soit la tendance, avec l’ART chez Google et le projet N chez Microsoft…
  • On est déjà dans la prochaine étape, le code avec PNaCl et compilé en langage machine à l’ouverture de l’application plutôt qu’à l’exécution, et en plus le code natif est conservé dans le cache des browsers.

    PNaCl est une version actualisée de Native Client, dont le but de permettre d’exécuter des applications natives C et C++ ou autres dans le navigateur.

    En compilant le code C/C++ via PNaCl, on obtient un exécutable écrit non pas en langage natif mais en bitcode ou IR (Intermediate Representation), LLVM apporte cela.

    C’est ensuite la LLVM (Low Level Virtual Machine) installée sur la machine cible qui se charge de compiler oui de compiler ce bitcode en langage natif du poste client (x86-32 bits, x86-64 bits, ARM…).

    Native Client (NaCl) est une technologie open-source pour exécuter du code natif compilé dans le navigateur:
    https://developers.google.com/native-client/dev/overview

    Ce que jais voulu dire avec:

    « Différence entre bitcode et bytecode »
    « Différence entre le code Java (bytecode) et LLVM(bitcode) »
    http://www.scriptol.fr/programmation/llvm.php

    c’est que LLVM avec bitcode c’est de la vrai compilation, alors que bytecode c’est interpreté ou de la Just-in-time compilation (JIT).

    On pourrait même imaginer demain que les futurs plugins tel que Flash, Java, Silverlight, … utilisent la technologie PNaCl pour faire leur retour dans Chrome, ChromeOS, ChromeBook, ChromeBox ?

    Différence entre le code Java et LLVM:

    1) LLVM (anciennement appelé Low Level Virtual Machine en français « machine virtuelle de bas niveau ») est une infrastructure de compilateur conçue pour optimiser la compilation, l’édition de liens, l’exécution d’un programme écrit dans un langage quelconque.

    2)Le bytecode, outre qu’il est plus proche du langage machine, utilise une pile pour stocker les données et effectuer des opérations dessus alors que le bitcode (IR) utilise des registres et des zones de mémoire.

    3)L’IR (Intermediate Representation) est le langage conçu pour une machine virtuelle ou un compilateur, et il est encapsulé dans un fichier que l’on appelle dans le cas de LLVM, le bitcode.

    4)Voir le Diagramme du fonctionnement de LLVM avec la branche compilateur: http://www.scriptol.fr/programmation/llvm.php

    5) Voir les PNaCl Demos
    http://gonativeclient.appspot.com/demo

    6) Native Client (NaCl)

    https://developers.google.com/native-client/

    https://developers.google.com/native-client/dev/

    https://developers.google.com/native-client/dev/overview

    Très cordialement,
    Jean-Marie Stawikowski

  • Ce qui serait cool, c’est d’avoir la ToolChain pour l’Objective C, en plus de celle pour C/C++. Et là… très rapidement, les applications tournant actuellement sur iOS débarqueraient sur le Chrome Web Store :).

    On remarque d’ailleurs que parmi les applications Native Client d’ores et déjà disponible sur le Chrome Web Store, beaucoup sont des jeux déjà sortis sur iPhone.

    Cela dit, n’étant pas codeur, j’ai du mal à évaluer la difficulté de la tâche.

  • Bon ben, j’ai fini de lire la doc du machin. Chrome embarque bien la LLVM. Comme celle-ci est open-source, tout autre navigateur internet serait libre de l’intégrer.

    Pourvu que ça marche et que cela devienne un standard dans les prochaines années, parce que théoriquement, c’est vachement bien foutu!

  • Yvan, je pense vraiment que cela va marcher parce-que c’est stratégique pour Google qui a une vision «Cloud centric» de l’informatique.

    voir: «PC centric» ou «Cloud centric» : deux visions de l’avenir de l’informatique (Louis Naugès)

    http://nauges.typepad.com/my_weblog/2013/05/-pc-centric-ou-cloud-centric-deux-visions-de-lavenir-de-linformatique.html

    « Google Chrome OS ne va pas dans le sens de l’Histoire, il créé l’Histoire » (Louis Naugès)

    Je pense que si Google fournie l’équivalent de Microsoft Office avec Google Quickoffice par example Frédéric CAVAZZA parle de:

    Avec NaCl, Google complète sa vision de l’informatique du futur
    http://www.fredcavazza.net/2013/03/01/avec-nacl-google-complete-sa-vision-de-linformatique-du-futur/

    Google est donc en train de finaliser une nouvelle version de QuickOffice qui va vous permettre de consulter et éditer des documents Office dans votre navigateur.

    Le plus intéressant dans cette histoire, c’est que le portage de QuickOffice sous Chrome va se faire avec Native Client.

    Quickoffice désormais utilisable dans Chrome
    Google porte ses outils de bureautique dans le navigateur grâce à Native Client:

    http://www.developpez.com/actu/52210/Quickoffice-desormais-utilisable-dans-Chrome-Google-porte-ses-outils-de-bureautique-dans-le-navigateur-grace-a-Native-Client/

    Le port de Quickoffice sur Chrome a été possible grâce à l’utilisation de Native Client. Native Client est une technologie de type sandbox (bac à sable), qui permet d’exécuter des applications écrites en C/C++ à l’intérieur d’un navigateur, dans un environnement protégé.

    Conclusion:
    Le futur est bien «Cloud centric» avec des ChromeBooks 100% Web, par contre Apple et Microsoft on pris du retard sur cette vision.

    Avec des ChromeBooks ou des ChromeBox:

    Les ordinateurs Chromebook/ChromeBox sont fournis avec une protection intégrée contre les logiciels malveillants et les virus, avec plusieurs couches de sécurité :

    1) Aucun logiciel antivirus n’est requis:

    2) Les ordinateurs Chromebook sont fournis avec Chrome OS installé. Le micrologiciel et le BIOS sont conçus spécifiquement pour les Chromebook , et aucun autre système d’exploitation ne peut être installé.

    3) Système de mise à jour automatique : La protection contre les virus reste à jour automatiquement, et vous exécutez donc toujours la version la plus récente et la plus sûre. Chrome OS gère vos mises à jour silencieusement en arrière-plan.

    4) Utilisation de « sandbox » : Chaque page Web et chaque application s’exécutent dans un environnement de type « sandbox » limité. Si un onglet est infecté, il ne peut pas infecter d’autres onglets ou applications, ou quoi que ce soit d’autre sur votre Chromebook.

    5) Démarrage vérifié : Chromebook effectue sa propre vérification automatiquement contre les altérations et la corruption au démarrage. Si un problème est détecté, le système se répare lui-même, si possible.

    6) Cryptage des données : Toutes les données sont cryptées pour chaque compte, ce qui signifie que vous devez être connecté pour accéder à vos données, et qu’aucune autre personne ne peut accéder à des données depuis un autre compte.

    7) ChromeOS (ChromeBook et ChromeBox) et un véritable poste client qui ne mémorise rien sur chaque utilisateur loggé
    alors que les tous autres OS tel que iOS, Android, Windows 8, windows RT mémorise des choses sur chaque utilisateur loggé
    donc tous les autres OS sont tous des Ordinateur personnel (des PC ameliorés)
    alors que tous les ChromeOS qui ne mémorise rien, sont de véritable ordinateur impersonnel (un ordinateur qui ne se rapporte pas à une personne).

    cela change tout !

    J’ais par contre une très grande inquiétude avec cette vision «Cloud centric» de Google et les Chrome/ChromeBooks/ChromeBox , c’est le cas de la NAS:

    http://www.lemonde.fr/scandale-prism/

    http://www.lemonde.fr/vie-privee/

    http://www.agoravox.fr/actualites/citoyennete/article/l-affaire-snowden-devoile-t-elle-l-143846

    Très cordialement,
    Jean-Marie Stawikowski

  • Oui, j’ai vu que Quick Office était d’ores et déjà disponible sur le canal de dev de Chrome OS.

    Ce qui m’étonne, c’est qu’il ne le soit pas (encore) sous la forme d’une Chrome App, mais directement intégré à Chrome OS (un peu comme la File App au début), ce que je trouve assez moche.

    Mais peut-être est-ce parce que PNaCl n’était pas encore terminé, ou alors parce que le code de Quick Office pose certaines contraintes non encore adressées par PNaCl (appel à des fonctions assembleur ou gestion des exceptions en C++).

  • Si, quand même, entre un Windows XP sur lequel un keylogger est vite installé et Chrome OS, il y a un monde.

    Une transaction bancaire reste sécurisée, car cryptée. Détournée, elle peut toujours être déchiffrée, mais à grand renfort de moyens. En tout cas, ce n’est pas à la portée du hacker amateur.

  • Je entièrement d’accord, tous les OS tel que iOS, Android, Windows XP, 7, 8, RT qui autorise par exemple l’installation d’un keylogger ne sont pas sécurisés.

    Je suis également d’accord les menaces prennent aussi le virage du cloud (réseaux, câbles, et serveurs).

    Donc pour être sécurisés ils est obligatoire que toute les parties doivent être sécurisés:

    1) Le client (Chrome OS, …)

    2) Le réseau (internet, routeurs, câbles, …)

    3) Le Serveur (Cloud, Data Center, …)

    4) L’application (Les développeurs, Les compilateurs, Les OS, Open Source…)

    Espionnage : la NSA aurait effectivement demandé l’intégration d’un backdoor dans Linux Selon le père de Linus Torvalds
    Torvalds a sans doute répondu à la NSA qu’il ne pouvait pas insérer de backdoor même s’il le voulait, du fait de la disponibilité en open source du code Linux. En effet, l’intégration du moindre changement dans le noyau Linux doit passer par un processus d’approbation, et tous les ajouts de code sont inspectés par les administrateurs de chaque branche et par les développeurs.
    http://www.developpez.com/actu/64349/Espionnage-la-NSA-aurait-effectivement-demande-l-integration-d-un-backdoor-dans-Linux-selon-le-pere-de-Linus-Torvalds/

    5) Les outils de développement pour l’application (Les compilateurs avec backdoor, Le cas du compilateur C Unix : Trusting Trust http://en.wikipedia.org/wiki/Backdoor_(computing) …)

    Donc dans la partie qui nous intéresse, c’est a dire PNaCl et en particulier Chrome OS avec ChromeBook et ChromeBox nous somme bien dans le seul cas de produits commercialisés qui prennent en compte le cas du client sécurisés (pas d’installation et open source).
    Google a compris que cela été stratégique pour le futur !

    Tendance technos de 2014 selon Gartner: L’architecture client-cloud
    http://pro.01net.com/editorial/606252/les-dix-tendances-technos-de-2014-selon-gartner/

    Je le répète:

    ChromeOS (ChromeBook et ChromeBox) et un véritable poste client qui ne mémorise rien sur chaque utilisateur loggé, alors que les tous autres OS tel que iOS, Android, Windows XP, 7, 8, RT, mémorise des choses sur chaque utilisateur loggé, donc tous les autres OS sont tous des Ordinateur personnel qui autorise l’installation de keyloggers par exemple, alors que tous les ChromeOS ne mémorise rien, et sont de véritable ordinateur impersonnel (un ordinateur qui ne se rapporte pas à une personne).

    Cela change tout sur le poste client !

    Bien sur il faut que le Cloud soit fiable également

    Ceci dit les iOS, Android, Windows XP, 7, 8, RT utilisent tous déjà le cloud, donc il sont doublement pas fiable.

    Toute les parties doivent être sécurisés !

    Le plus dur à sécurisés sera toute les NSA et les futures NSA de tous les pays et du monde
    http://www.lemonde.fr/vie-privee/

    Par ailleurs cette histoire de NSA, embête bien Google dans sa stratégie ChromeOS + Cloud (architecture client-cloud).

    Mais Google à raison de chercher à sécurisés le poste Client au Maximun.

    Par ailleurs vous verrais que Microsoft suivra cette stratégie dans le futur:
    Windows 10 serait un « Cloud OS » Selon les rumeurs
    http://www.developpez.com/actu/60679/Windows-9-prevu-pour-2014-et-Windows-10-serait-un-Cloud-OS-selon-les-rumeurs/

    Si on pense que Microsoft en est à Windows 8 alors Google à pris une sérieuse avance avec ChromeOS (ChromeBook, ChromeBox, ChromeTV, ChromePhone, ChromeTablet, ChromeGlass, ChromeChose, ChromeThings, … ) qui est déjà un client sécurisés pour accéder à tous les serveurs Web ou WebService de type cloud ou pas cloud.

    Le futur = client-sécurisés + architecture client-cloud

    Très cordialement,
    Jean-Marie Stawikowski

  • : J’ai pris le cas extrême de Windows XP, mais comme l’explique Jean-Marie, tous les systèmes commercialisés sont concernés par les keyloggers, à des niveaux d’exposition variables, à l’exception de Chrome OS qui empêche toute installation frauduleuse. Il existe encore une faille: Si l’utilisateur installe une extension qui joue le rôle de keylogger, Chrome OS ne pourra l’en empêcher. Il ne fera qu’avertir l’utilisateur du haut-niveau d’autorisations demandé par cette extension. C’est d’ailleurs pour cela que Google va interdire à partir de janvier 2014 l’installation d’extension sans passage par le Chrome Web Store: http://www.zdnet.fr/actualites/chrome-pour-windows-les-extensions-hors-web-store-bannies-des-janvier-2014-39795404.htm

    Il faut donc faire attention aux extensions qu’on peut trouver en dehors du Chrome Web Store. Par exemple, je n’ai pas du tout confiance en Torque (Bittorrent).

    @Jean-Marie: Chrome OS doit quand même mémoriser le mot de passe du compte Google quelque part, non? Sinon comment fait-il pour permettre l’authentification en mode déconnecté? Mais peu importe, car le système crypte systématiquement tout ce qu’il conserve sur la machine cliente, à l’image de ce qu’on fait sur les PC de certaines grosses entreprises, à grands renforts de logiciels tiers. Je ne crois pas que ce soit le cas pour Android, iOS, RT…

    En résumé, Chrome OS crypte les données en local, donc hacker le disque n’est pas une mince affaire. A moins de prendre la forme d’une extension maligne récupérée hors du Chrome Web Store, un keylogger ne peut pas se nicher dans le système pour récupérer à la volée les informations saisies au clavier. Reste les Chrome Apps, qui sont elles protégées par la sandbox dans laquelle elles tournent. Maintenant l’app elle-même peut diffuser des informations à des pirates, mais c’est pareil partout. A moins de faire recours à la loi, je ne peux pas empêcher ma banque, ameli.fr, Facebook, Google, Yahoo!… de diffuser les informations qu’ils ont en leur possession.

  • Comme tu l’as dit, Yvan, les applications locales existent sous chrome OS : ce sont les extensions. Google va limiter la distribution au strore… ça ne va donc pas plus loin que sur iOS ou windows RT.
    Et j’imagine aussi que toute application pouvant fonctionner hors ligne stocke plus sur la machine que quelques données en cache.
    Pour les HDD crypté, je ne serais pas aussi catégorique que toi.
  • Oui je suis d’accord les extensions Chrome son bien le talon d’Achille des Chromebook et Chrome-OS.

    Les extensions Chrome son quand même limité seulement à la Sandbox de l’utilisateur qui est connecté à son compte Google, contrairement aux autres OS (iOS, Android, Windows XP, 7, 8, RT) ou un virus est installé pour tous les utilisateurs de l’OS.

    Par exemple si ma fille installe une extension Chrome virale sous son propre compte Google sur mon Chrome-Book personnel (je suis sympa!), je ne serais pas affecté par son installation virale depuis mon propre compte Google. Et cela change tout sur mon compte Google depuis un poste client impersonnel!

    Donc parce-que les extensions Chrome reste le maillon faible de la sécurité alors:

    Google prend le contrôle des extensions Chrome et il ne sera plus possible d’installer une extension qui n’a pas été validée par Google.

    http://blog.chromium.org/2013/11/protecting-windows-users-from-malicious.html

    Et n’oublions pas que les extensions Chrome ne sont pas les applications finales des utilisateurs du Cloud, mais bien des extensions communes à tout le monde tel qu’un lecteur PDF par exemple.

    Il faut voir les extensions Chrome comme des extensions de Chrome-OS plutôt que des comme applications finales des utilisateurs du Cloud.

    Il faut voir les extensions Chrome plutôt comme des mises à jour et des évolutions de OS Chrome-OS

    Et n’oublions pas que les extensions Chrome ne sont pas des applications Web/Cloud qui ne sont pas sous le contrôle du Store de Google, les applications Web/Cloud peuvent être dans mon Cloud Windows Azure par exemple.

    En gros le développeur d’extensions Chrome est un développeur système, et le développeur application cloud ne développe pas d’extensions Chrome, mais il utilise les extensions Chrome de confiances.

    Donc c’est bien que Google prenne le contrôle TOTAL des extensions Chrome et Chrome-OS,
    Et cela n’empêche pas les utilisateurs de développer librement leur applications Coud.

    Donc:

    Le futur = client-sécurisés + architecture client-cloud + contrôle des extensions par Google.

    Le futur = Chrome-OS + architecture client-cloud + extensions sécurisées et de confiances.

    Très cordialement,
    Jean-Marie Stawikowski

  • Jean-Marie: Je me suis toujours demandé pourquoi Google avait autorisé les extensions en dehors du Chrome Web Store. C’est peut-être pour attirer le plus de développeurs au départ et dépasser Firefox.

    @Olf: Les Chrome Apps installent leur code source sur le chromebook. Cela reste des web apps qui intrinsèquement sont plus sécurisés que les native apps. Le HTML ne peut pas pirater la machine. En revanche, le Javascript en est capable. Google gère ce problème via la Content Security Policy, désormais imposée sur les applications et extensions. Cela pose pas mal de contraintes aux développeurs. Pour ne pas brider les Chrome Apps, Google construit les Chrome API, qu’il contrôle totalement évidemment. Tout comme les modules PNaCl qui passent à la moulinette du « validator » lors de leur chargement. Si une instruction interdite se trouve dans le code, comme par exemple « eval » (don’t be eval :D), le module est considéré comme invalide et n’est pas chargé.

    Le niveau de sécurité de Chrome OS est vraiment très au dessus de tous les autres systèmes commercialisés, à part peut-être Firefox OS. Et maintenant que Google a réussi à mettre en prod PNaCl, c’est un système qui non seulement est extrêmement sûr, mais peut également être performant.

Laissez vous aussi un commentaire exceptionnel (ou pas !)

Pour lutter contre les spams, merci de valider le Captcha de sécurité * Time limit is exhausted. Please reload CAPTCHA.

Partage cet article par mail