Chrome 31 peut exécuter du code C/C++

Stéphane Moussie | 04/10/2013 à 21:54

La prochaine version de Chrome sera capable d'exécuter du code natif. Disponible en bêta depuis aujourd'hui [55,7 Mo], Chrome 31 intègre Portable Native Client Preview (PNaCl), une évolution de Native Client dévoilé en 2008, un environnement permettant d'exécuter du code natif (C/C++) dans un navigateur web. L'intérêt est de permettre aux applications web d'exploiter au mieux les capacités d'une machine sans être freinées par les langages intermédiaires (JavaScript, Flash...). À la clé, un gain de vitesse et de nouvelles possibilités offertes : créer son propre codec vidéo, intégrer des jeux, etc.

Les autres nouveautés de Chrome 31 sont tout autant destinées aux développeurs (nouvelles API pour les Chrome Apps, prise en charge de requestAutocomplete pour les formulaires...), sauf sur Android où les utilisateurs ont maintenant la possibilité d'ajouter des raccourcis vers des pages web sur l'écran d'accueil.

Sur le même sujet :
- Google NaCl : du code natif dans le navigateur

Apple doit-elle céder aux sirènes des IA génératives ?

Refurb : l'écran Studio Display 5K et les AirPods 3 sont de retour

Apple retire WhatsApp et Threads de l'App Store chinois sur demande de Pékin

Les puces produites par TSMC hors de Taiwan pourraient être plus onéreuses

Environnement : Apple réduit ses émissions de moitié, et après ?

Mr. THZ | 04/10/2013 à 22:01

J'ai hâte que ça arrive sur Safari !

Mdtdamien | 04/10/2013 à 22:02

Le C est puissant, mais très puissant pour attaquer les PC aussi

BooBoo | 04/10/2013 à 22:06

@mdtdamien : J'imagine que c'est dans un bac à sable...

f3nr1l | 04/10/2013 à 22:11

quelqu'un se dévoue pour porter le noyau linux la dessus?

bugman | 04/10/2013 à 22:21

Idem. Qu'est ce que cela donne niveau sécurité ?

nova313 | 04/10/2013 à 22:51

Encore une fois, Google fait preuve d'initiative en matière d'amélioration web. En espérant que les autres suivent

Darth Philou (non vérifié) | 04/10/2013 à 22:57

@mdtdamien Idem. Je ne trouve pas l'idée rassurante en terme de sécurité. Déjà Java qui est conçu, depuis plus de 15 ans maintenant, spécifiquement pour ce genre d'utilisation, n'est toujours pas suffisamment sécurisé comme l'ont montrés des événements récents, alors une technologie toute récente, ce n'est pas rassurant du tout. (Cf. Également les Active-x sous Windows/IE, une vraie passoire)

Mdtdamien | 04/10/2013 à 23:09

Le C est puissant, mais très puissant pour attaquer les PC aussi

Aquarius87 | 04/10/2013 à 23:16

Faut voir comment tout ça est possible sur le terrain autoriser d'exécuter du C/C++ c'est une porte sur tout tant ses langages sont puissants.

oomu | 04/10/2013 à 23:30

c'est juste la fin. c'est l'étape finale pour transformer le web en plateforme ultime de virus, prise de contrôle, hack, etc des machines. ou oui, je sais sandboxing, accès mandatoires, acl et tout le tralala dont on nous abreuvé dés les merveilleuses fonctionnalités de JAVA (sur le web) et Active X. (et ho, Corba, mais tout le monde s'en est foutu de Corba) bref, MERCI. ou plutôt, NON.

oomu | 04/10/2013 à 23:31

@nova313 [04/10/2013 22:51] via MacG Mobile "Encore une fois, Google fait preuve d'initiative en matière d'amélioration web. En espérant que les autres suivent" je préfère voir bruler mon ordinateur plutôt que d'autres suivent Google sur CA !

oomu | 04/10/2013 à 23:32

@Aquarius87 [04/10/2013 23:16] "Faut voir comment tout ça est possible sur le terrain autoriser d'exécuter du C/C++ c'est une porte sur tout tant ses langages sont puissants." sur le terrain, via ingénierie sociale, via paresse des concepteurs, et failles du navigateur, du système et du processeur, ça sera l'enfer sur terre tel java+flash+active X fusionné. bah ça excitera les ingénieurs...

lmouillart | 04/10/2013 à 23:35

@oomu pourtant les navigateurs ont un interpréteur js ? linux boot sur un émulateur PC en js : http://bellard.org/jslinux/ on peu compiler du C en asm et donc le faire tourner sur un runtime js Bref même combat. Un web sûr ne lit pas de chaines de caractères, d'images, documents, et pas extension de données. Amen ! Nostalgique de l'époque des VT et minitels ? :)

lmouillart | 04/10/2013 à 23:37

Vivement que PNaCl et NaCl soient standardisés, normalisés et intégrés dans TOUS les navigateurs modernes.

ericb2 | 04/10/2013 à 23:42

"... un environnement permettant d'exécuter du code natif (C/C++) dans un navigateur web. ..." Le tout sous Androïd : tout est dit :-) "... L'intérêt est de permettre aux applications web d'exploiter au mieux les capacités d'une machine sans être freinées par les langages intermédiaires ..." Sachant qu'on peut faire à peu près ce qu'on veut avec le C++, comment sécuriser ce type de fonctionnalité ? (à part avec une Sandbox, je ne vois pas) EDIT : la réponse est donnée avec le lien fourni "by running compiled C and C++ code securely and at near-native speeds" =) sandboxing Edit de Edit : "The NaCl validator statically analyzes code prior to running it to make sure it only uses code and data patterns that are permitted and safe." Bon courage ...

lmouillart | 04/10/2013 à 23:48

Coté technique le "p" tourne comme bien souvent actuellement, sur un sous ensemble de LLVM.

quark67 | 04/10/2013 à 23:52

Il y a plusieurs personnes qui ont jeté par-dessus bord leurs cours de chimie (et tout simplement de la jugeote) et ça craint : c'est quoi ce délire d'écrire NaCI là où il faut lire NaCl (oui, le L minuscule), ce qui donne la formule chimique du chlorure (Cl) de sodium (Na), plus communément appelé sel de table ? (plus simplement, Native Client - NAtive CLient - NaCl...). Je suis effaré par l'ignorance des gens. Des gens qui possèdent un droit de vote... Ça fait peur... [Édit : ça a été corrigé par le rédacteur, tant mieux ; un commentateur a aussi tenté de corriger, en douce, mais... bref, il n'a pas du suivre assidûment les cours de chimie, ça se voit... lol !] Sur le fond : cette initiative de Google n'est pas rassurante, compte-tenu de la nature foncièrement mauvaise de l'être humain...

BeePotato | 05/10/2013 à 00:15

Tiens, un truc pour ajouter des sources de plantage là où on en avait pourtant déjà bien assez… :-)

lmouillart | 05/10/2013 à 00:27

@quark67 si, mais j'avoue que le vendredi soir NaCI et pepper ça m'a pas sauté aux yeux, surtout que sur ma jolie police l et I sont quasi-identique :-).

Simeon | 05/10/2013 à 00:31

Je suis certain que safari ne disposera jamais de cette "feature". :-) Une raison de plus pour ne pas utiliser chrome!

Anonyme (non vérifié) | 05/10/2013 à 01:03

Oulala niveau securité ca va donner quoi ?

initialsBB | 05/10/2013 à 01:53

"sauf sur Android où les utilisateurs ont maintenant la possibilité d'ajouter des raccourcis vers des pages web sur l'écran d'accueil." C'était pas possible avant ??????

SSHNuke0 | 05/10/2013 à 03:19

Et la dépendance à l'architecture matérielle ? ... API facilement portable sur d'autre navigateur ? ... J'ai bien peur d'un nouveau ActiveX certes multiplateforme, mais amenant de la merde avec des sites uniquement compatibles avec Google Chrome / Chromium.

SugarWater | 05/10/2013 à 07:50

Gain d'autonomie?

Anonyme (non vérifié) | 05/10/2013 à 09:11

Avec ce module, Chrome met son grain de sel dans la guerre des navigateurs. Pourquoi pas ;)

BeePotato | 05/10/2013 à 10:01

Un volontaire pour expliquer à Google qu'un navigateur web doit rester un navigateur web et pas devenir un système d'exploitation ?

Anonyme (non vérifié) | 05/10/2013 à 13:01

Rien compris aux explications de Quark67. Peut on reformuler plus clairement svp merci

rva1mac | 05/10/2013 à 15:51

Ça y est, on ne sait plus quoi inventer. Chrome commence à partir en vrille.

Almux | 05/10/2013 à 16:05

Comme sûrement beaucoup d'autres, je me demande ce que cela implique en terme de sécurité. Ne serait-il pas (encore plus) facile d'intégrer spywares et autres joyeusetés dans les apps proposées?

C1rc3@0rc | 05/10/2013 à 16:45

" lmouillart [04/10/2013 23:35] @oomu pourtant les navigateurs ont un interpréteur js ? linux boot sur un émulateur PC en js : http://bellard.org/jslinux/ on peu compiler du C en asm et donc le faire tourner sur un runtime js Bref même combat. Un web sûr ne lit pas de chaines de caractères, d'images, documents, et pas extension de données. Amen ! Nostalgique de l'époque des VT et minitels ? :) " Heu tu te rend compte de ce que tu dis? Tu compares un interpreteur Javascript avec du code C/C++ compile qui exécute des instructions "machines"... Pour attaquer a partir de JS, faut trouver une faille dans l'interpréteur puis creer un exploit et passer le bac a sable. La il suffit de faire un bête bufferoverflow avec trois instructions en C ou assembleur... et on a acces a n'importe quoi dans l'OS... Deja Flash et Java, qui pourtant avaient un niveau d'abstraction et d'exécution plus compartimentés permetaient de realiser de vrais virus, alors la c'est l'autoroute pour les virus web. Bon je ne mentionne que les virus, parce que les troyens fonctionnent avec l'accord de l'utilisateur, et ils peuvent etre de fait codes avec n'importe quoi. On avait réussi a se debarasser de Flash, Java n'apparaissait quasi plus sur les postes clients. Restait ActivX comme voie de verolage, la Google rajoute non pas une faille mais carrément un gouffre :( Le pire c'est que cela n'a aucun sens par rapport a la dynamique de Google concernant le Web: opensource, optimsation des machines virtuelles et interpréteurs, respect des standards. De plus niveau codec, ca n'a pas non plus de sens. Tout ce qui est video ne doit pas etre l'objet de modules internes spécifiques, mais doit etre standardise. C'est l'objet des negotiation du W3C. La on revient a l'aire Flash avec ces pages bourees de code proprietaires uniquement déchiffrable par une seule version d'un navigateur Le retour de l'ere Internet Explorer ?

Psylo | 05/10/2013 à 17:04

Prochaine étape : lancer son navigateur pour lancer une machine virtuelle qui lancera un OS pour lancer un navigateur. #dividedbyzero

Seccotine | 05/10/2013 à 17:51

Merci Google, mais j'ai déjà un OS

lmouillart | 05/10/2013 à 19:50

@C1rc3@0rc non c'est pareil, les instructions sont scannées avant d'être interprétés, tu n'as pas non plus accès aux bibliothèques systèmes, mais aux sous-ensembles compilés par LLVM en JTI, tu te retrouves exactement dans le même type d'architecture qu'avec un interpréteur JS. Si tu fais ton buffer overflow en C ou ASM IL tu te retrouveras dans la sandbox, après il faut en sortir, c'est faisable, mais ni plus ni moins qu'en JS. L'objectif principal de cette technologie est de fournir un runtime pour les applications, au même titre que pour un Linux, un Windows, un OS X, sauf que la l'environnement support c'est entre autres un navigateur. Le but de Google c'est que ses technologies tournent en natif sur son OS ainsi que sur l'ensemble d’OS concurrent. Prenons un ou deux exemple : Lightroom et Office, tu as une base de code c/c++ tu souhaite proposer ces applications sur le web, tu as quoi ? asm.js tu entre du c/c++ ça te recrache un sous ensemble de javascript qui va passer dans les jit javascript des navigateurs ou tu compile pour ta plateforme cible PNaCl. Actuellement une solution est "industrialisée" et tourne depuis quelques années en code x86, la , la proposition de Google c'est juste de proposer une cible non ISA dépendante, par rapport à ce qu'elle faisait.