Discussion :

[Hinault Romaric]

Chrome 14 disponible en téléchargement
Native Client et l'API Web Audio à l'épreuve du Web

Mise à jour du 19 septembre 2011 par Idelways


Et de 14 ! Chrome engrange une nouvelle version majeure, marquée par deux importantes nouveautés : Native Client (NaCl) et le support de l'API Web Audio du W3C.

Cette dernière est une API JavaScript standard de haut niveau pour créer des effets audio au sein des applications Web, et même plus comme le démontrent les exemples de code publiés à l'occasion par Google.
On y trouve par exemple une boîte à rythmes, quatre synthétiseurs-oscillateurs et un visualiseur/analyseur des ondes sonores en WebGL.



Chrome 14 introduit aussi — comme décrit ci-devant — la technologie Native Client (NaCl) qui permet d'exécuter du code C/C++ à l'intérieur du navigateur dans un environnement protégé.

Cette technologie plutôt controversée est destinée à faire du navigateur une plateforme plus puissante pour les jeux 3D, l'édition vidéo et d'autres usages où JavaScript montre des limites notamment dans le cadre d'un système fondé sur navigateur à l'instar de Chrome OS.

En substance, le code Native Client s'exécute dans un bac à sable à double protection :
Par les registres de segments (segment registers), exploités pour restreindre les zones mémoires où le code peut lire et écrire, renforcés par un compilateur modifié et un mécanisme de vérification du code pour éviter les sauts du code hors de ses zones.

Native Client repose par ailleurs sur Pepper, une API qui applique au code C/C++ une interface identique à celle appliquée à JavaScript, et qui lui permet d’accomplir tout ce qui peut être fait avec.

Google voit dans Native Code une extension naturelle du Web, mais Opera et la fondation Mozilla ne sont pas de cet avis.
Mountain View développe par ailleurs Dart, un nouveau langage pour Web qui aurait pour ambition de remplacer le JavaScript qui ne convainc plus chez Google où il est considéré comme un frein de compétitivité face aux écosystèmes alternatifs (Apple App Store notamment).

Le SDK de Native Client est disponible et comporte en plus des fichiers d'en-tête nécessaires, les versions modifiées du compilateur GNU.


Exemples d'utilisation de l'API Web Audio
Télécharger le SDK de Google Native Client
Télécharger Chrome 14

Source : Blog de Chrome Chrome

Et vous ?

Avez-vous essayé Chrome 14 ? Que pensez-vous de ses nouveautés ?



Chrome 14 bêta disponible
avec le support de Native Client et l’intégration de l’API Web Audio


Chrome 14 bêta est disponible.

La principale nouveauté de cette version est l’intégration de la technologie Native Client (NaCl).

Native Client est un projet qui permet à des codes natifs de s’exécuter dans le navigateur. Le but est de permettre le développement d'applications Web reposant sur d’autres langages que le JavaScript ou le HTML5.

À ce stade, la plateforme supporte le C et le C++. Des développeurs indépendants ont également mis au point des plugins qui permettent la prise en charge de langages supplémentaires comme le Tcl (Tool Command Language).

"Artic Sea", le SDK qui permet la conception des applications Web C et C++ pour Chrome a déjà été publié. Et le développement d’un plugin pour la prise en charge de NaCl dans les environnements de développement Visual Studio et Eclipse est en cours par Google.

Reste que l'arrivée du code natif dans le navigateur est une avancée qui fait polémique dans la communauté.

Autre nouveauté importante de Chrome 14 bêta : l’introduction d’une nouvelle API JavaScript baptisée « Web Audio ». Cette API offre des capacités audio avancées et supporte les effets audio comme la simulation des scènes audio spécialisées complexes.

On notera également la correction de plusieurs failles de sécurité.

Et l'intégration de la fenêtre d’aperçu avant impression pour les utilisateurs de Mac OS X.


Télécharger Chrome 14 bêta


Source : Blog Chrome


Et vous ?

Que pensez-vous de ces nouveautés ?

[Gordon Fowler]

On notera également le chiffrement des données synchronisées par Google (favoris, mots de passe, extensions, etc.) pour les réutiliser sur plusieurs appareils.

Pour mémoire, Mozilla a proposé ce chiffrement dès le lancement de son Firefox Sync (ex-Weave).

[Freem]

Et l'intégration de la fenêtre d’aperçu avant impression pour les utilisateurs de Mac OS X.

Ouahou quelle révolution
Cela dis, j'imagine que les utilisateurs de chrome sous mac vont être sacrément soulagés... qu'une telle fonction aie attendu la version 14 me dépasse! (j'imagine qu'avant ils imprimaient sur pdf pour avoir l'aperçu, mais dans le genre pénible c'est pas mal)

Pour le support du code C/C++ en natif, c'est pas un peu dangereux?
Ces langages permettent de tout faire, c'est vrai, mais justement...
Je suppose qu'ils tournent dans une sandbox? Sinon ça sent les failles de sécurité à gogo... (l'air de rien, même le vulgaire scanf du C est pas simple à maîtriser: http://xrenault.developpez.com/tutoriels/c/scanf/ (merci au passage à l'auteur, je lis plutôt régulièrement cette page, parce que je suis incapable de me souvenir comment marchent les retours, avec toutes les options embarquées dans ce couteau suisse))

Enfin, je suppose qu'ils savent ce qu'ils font...
Cela dis, une telle fonction va, j'espère, rester longtemps en bêta...

[Uther]

On notera également le chiffrement des données synchronisées par Google (favoris, mots de passe, extensions, etc.) pour les réutiliser sur plusieurs appareils.

Enfin! c'est vraiment un des gros défaut que je trouvais à Chrome.

Pour le support du code C/C++ en natif, c'est pas un peu dangereux?
Ces langages permettent de tout faire, c'est vrai, mais justement...
Je suppose qu'ils tournent dans une sandbox?

Si ça laissait accès a tout et n'importe quoi, oui ça serait dangereux. Mais ça sera évidemment limité. Le code a NaCl tournera dans une sandbox avec des droits très restreints.
Il y a toujours un risque que des piratent trouvent une faille pour passer à travers la sandbox comme c'est déjà arrivé à IE, mais ça serait corrigé. Comme beaucoup des nouvelles technologies ajoutées au navigateur (WebGL avait aussi été critiqué par Microsoft notamment) ça laisse une porte d'entrée supplémentaire a surveiller.

Pour moi le plus gros problème est que c'est une technologie non standardisée qui ne sera jamais supportée que par Chrome. Et même si d'autres navigateurs l'adoptaient, il rend dépendant de l'architecture de la machine, ce qui est contraire à la direction souhaitée pour le Web.

Même si ça a été un peu plus travaillé, ça reste dans le principe quand même assez proche d'ActiveX avec la plupart des problèmes qu'on lui connait.

Enfin, je suppose qu'ils savent ce qu'ils font...
Cela dis, une telle fonction va, j'espère, rester longtemps en bêta...

NaCl est déjà en bêta depuis bien longtemps maintenant.

[ArKam]

Moi ce que je comprend pas, c'est comment fait on pour integrer ça dans un site? CGI?

Parce que là pour le moment, j'ai des programmes en C++, mais comment je fait pour les faires lires par chrome?

De plus, ce pose pour moi le souci de la lourdeur des pages web, que je trouve déjà bien lourdes.

[Uther]

Moi ce que je comprend pas, c'est comment fait on pour integrer ça dans un site? CGI?

Parce que là pour le moment, j'ai des programmes en C++, mais comment je fait pour les faires lires par chrome?

De plus, ce pose pour moi le souci de la lourdeur des pages web, que je trouve déjà bien lourdes.

J'ai l'impression que tu mélanges un peu tout:

- Ça n'a rien à voir avec CGI qui est une technologie coté serveur. "Native Client" comme son nom l'indique est une technologie coté client. C'est le navigateur qui exécutera un fichier "nmf" comme il exécuterait un "swf" flash, via la balise <object>.
La différence est juste que le code cotenu dans fichier nmf n'est pas (pseudo-)interprété comme Flash mais compilé.

Si tu veux plus de détails regarde le site de NaCl : http://code.google.com/intl/fr/chrom..._overview.html

- Pour ce qui est de la lourdeur des pages, un code compilé sera probablement moins lourd que l'équivalent Javascript (surtout s'il y en a beaucoup). Mais de toute façon, je ne pense pas vraiment que ce problème joue de manière déterminante pour où contre l'utilisation de NaCl.
Ce qui pèse vraiment, c'est généralement plus les données annexes (images, sons,...) que le code lui même.

[ArKam]

J'ai l'impression que tu mélanges un peu tout:

- Ça n'a rien à voir avec CGI qui est une technologie coté serveur. "Native Client" comme son nom l'indique est une technologie coté client. C'est le navigateur qui exécutera un fichier "nmf" comme il exécuterait un "swf" flash, via la balise <object>.
La différence est juste que le code cotenu dans fichier nmf n'est pas (pseudo-)interprété comme Flash mais compilé.

Si tu veux plus de détails regarde le site de NaCl : http://code.google.com/intl/fr/chrom..._overview.html

- Pour ce qui est de la lourdeur des pages, un code compilé sera probablement moins lourd que l'équivalent Javascript (surtout s'il y en a beaucoup). Mais de toute façon, je ne pense pas vraiment que ce problème joue de manière déterminante pour où contre l'utilisation de NaCl.
Ce qui pèse vraiment, c'est généralement plus les données annexes (images, sons,...) que le code lui même.

Merci pour ces infos, j'avais déjà visité ce site mais je n'avais pas compris ce que c'etait.

Effectivement, ça peux devenir intéressant, par contre, j'ai peur que ça reste du coté de chez google et donc juste un + (marrant tiens) pour leur navigateur et surtout, que les webmaster vont encore devoir gérer plusieurs codes pour plusieurs navigateur.

Google ne pourrait pas faire une soumission de normalisation auprès du W3C ou autres?

Encore une question, est-ce que NaCL est une API C++ de chrome, ou bien tu peux écrire n'importe quel code? Si c'est le cas, ça risque d’être tendu niveau sécurité non?

[Uther]

Google ne pourrait pas faire une soumission de normalisation auprès du W3C ou autres?

Ils auraient bien souhaités que d'autres navigateurs l’adoptent, mais c'est mal parti :
- il y a peu de chance que le W3C le soutienne car le code natif est dépendant de l'architecture.
- Mozilla et Opéra s'y sont résolument opposé pour cette raison.
- Internet Explorer a déjà l'ActiveX.

Comme tu le dis, cela restera une techno Google. Elle ne sera vraiment intéressante que pour faire des applications pour ChromeOS.

Encore une question, est-ce que NaCL est une API C++ de chrome, ou bien tu peux écrire n'importe quel code? Si c'est le cas, ça risque d’être tendu niveau sécurité non?

En effet le code est natif mais il n'aura accès qu'aux API de NaCl.
Il ne peux pas accéder directement aux API systèmes pour des raisons évidentes de sécurité.

[ArKam]

Ils auraient bien souhaités que d'autres navigateurs l’adoptent, mais c'est mal parti :
- il y a peu de chance que le W3C le soutienne car le code natif est dépendant de l'architecture.
- Mozilla et Opéra s'y sont résolument opposé pour cette raison.
- Internet Explorer a déjà l'ActiveX.

Comme tu le dis, cela restera une techno Google. Elle ne sera vraiment intéressante que pour faire des applications pour ChromeOS.

En effet le code est natif mais il n'aura accès qu'aux API de NaCl.
Il ne peux pas accéder directement aux API systèmes pour des raisons évidentes de sécurité.

Je trouve dommage les raisons de refus, pour activeX pareil, l'idée est pas mauvaise je pense à la base.

Pour ce qui est des accés je m'en doutais un peu, mais sait-on jamais j'ai préféré demandé.

Je trouve que Google essaye beaucoup de choses en ce moment, je trouve ça bien, microsoft pareil, ils essayent de redoré leur blason.

Concernant google, meme si ils ont les travers d'une grosse boites, je trouvent qu'ils s'en sortent plutot bien niveau communication, et R&D en ce moment, en plus ils gardent tout de meme un certain niveau d'ouverture (niveau code source et autres) que je trouve appréciable en ces temps de patent troll à tout vas.

Bref, j’espère qu'ils vont continuez dans ce sens

[Uther]

Je trouve dommage les raisons de refus, pour activeX pareil, l'idée est pas mauvaise je pense à la base.

Je trouve au contraire que c'est une très bonne raison. C'est moins grave que l'ActiveX qui rend complètement dépendant de Windows, mais ça reste un sacré problème car il rend dépendant de l’architecture (x86, x64, PowerPC, ARM, ...).

Avec l'arrivé de HTML5, et des moteurs Javascript JIT puissants, on commence enfin à pouvoir se débarrasser doucement de ces saloperies que sont Flash et ActiveX, c'est pas pour se retrouver avec une nouvelle techno intrinsèquement contradictoire avec le cross-plateforme.

[Alpha573]

Pour moi le plus gros problème est que c'est une technologie non standardisée qui ne sera jamais supportée que par Chrome. Et même si d'autres navigateurs l'adoptaient, il rend dépendant de l'architecture de la machine, ce qui est contraire à la direction souhaitée pour le Web.

Totalement d'accord avec toi, c'est vraiment génant.
Pendant un moment je trouvais ça interessant et je voulais commencer à développer sur Chrome avec le SDK mais j'ai vtie laché l'idée, sachant que ça serait pas portable et standardisé... Dommage.

[Idelways]

Chrome 14 disponible en téléchargement
Native Client et l'API Web Audio à l'épreuve du Web

Mise à jour du 19 septembre 2011 par Idelways


Et de 14 ! Chrome engrange une nouvelle version majeure, marquée par deux importantes nouveautés : Native Client (NaCl) et le support de l'API Web Audio du W3C.

Cette dernière est une API JavaScript standard de haut niveau pour créer des effets audio au sein des applications Web, et même plus comme le démontrent les exemples de code publiés à l'occasion par Google.
On y trouve par exemple une boîte à rythmes, quatre synthétiseurs-oscillateurs et un visualiseur/analyseur des ondes sonores en WebGL.



Chrome 14 introduit aussi — comme décrit ci-devant — la technologie Native Client (NaCl) qui permet d'exécuter du code C/C++ à l'intérieur du navigateur dans un environnement protégé.

Cette technologie plutôt controversée est destinée à faire du navigateur une plateforme plus puissante pour les jeux 3D, l'édition vidéo et d'autres usages où JavaScript montre des limites notamment dans le cadre d'un système fondé sur navigateur à l'instar de Chrome OS.

En substance, le code Native Client s'exécute dans un bac à sable à double protection :
Par les registres de segments (segment registers), exploités pour restreindre les zones mémoires où le code peut lire et écrire, renforcés par un compilateur modifié et un mécanisme de vérification du code pour éviter les sauts du code hors de ses zones.

Native Client repose par ailleurs sur Pepper, une API qui expose au code C/C++ une interface identique à celle exposée à JavaScript, et lui permettre d’accomplir tout ce qui peut être fait avec.

Google y voit dans Native Code une extension naturelle du Web, mais Opera et la fondation Mozilla n’en sont pas de cet avis.
Mountain View développe par ailleurs Dart, un nouveau langage pour Web qui aurait pour ambition de remplacer le JavaScript qui ne convainc plus chez Google où il est considéré comme un frein de compétitivité face aux écosystèmes alternatifs (Apple App Store notamment).

Le SDK de Native Client est disponible et comporte en plus des fichiers d'en-tête nécessaires, les versions modifiées du compilateur GNU.


Exemples d'utilisation de l'API Web Audio
Télécharger le SDK de Google Native Client
Télécharger Chrome 14

Source : Blog de Chrome Chrome

Et vous ?

Avez-vous essayé Chrome 14 ? Que pensez-vous de ses nouveautés ?

[Aiekick]

Génial, enfin un browser qu'on va pouvoir hacker avec un des meilleurs outil qui soient à savoir le c++.

Je suis pas sure que leur sandbox va tenir longtemps.

[Lapinpanda]

Génial, enfin un browser qu'on va pouvoir hacker avec un des meilleurs outil qui soient à savoir le c++.

Je suis pas sure que leur sandbox va tenir longtemps.

Je pense que Google est certainement plus malin que nous et à soigneusement étudier les risques avant de se lancer.

[Freem]

La seule chose qui est certaine, c'est que les débuts risquent d'être dangereux si ça se popularise, sandbox ou pas, google ou pas. (Un système totalement sécurisé, ça n'existe pas)

Mais si le code est bien blindé, y'a pas de raison que ce soit facile.
En plus, les antivirus vont sûrement s'adapter, et je pense même qu'ils ont déjà certaines capacités à reconnaître les codes malicieux à l'exécution.

De toute façon, c'est bien d'intégrer une possibilité, mais il faut encore qu'elle soit utilisée. Si cette chose n'est supportée que par chrome, je suis presque prêt a parier que ça ne durera pas bien longtemps.
D'autant que comme précisé plus haut, la portabilité d'architecture risque d'être compiquée. (bien que du fait de la présence d'une API et du C++ même il sera possible de compiler pour diverses plates-forme sans toucher le code, mais il restera qu'il faudra bidouiller pour détecter l'archi et envoyer le bon code machine)

[lucideluciole]

Je pense que Google est certainement plus malin que nous et à soigneusement étudier les risques avant de se lancer.

Pas tout à fait d'accord avec ça! Soigneusement étudié les risques peut-être, mais de là à croire que Google est plus malin...pas certain. Si c'était le cas, les failles de sécurité n'existeraient jamais.

[Aiekick]

Je pense que Google est certainement plus malin que nous et à soigneusement étudier les risques avant de se lancer.

Franchement face à des hackers qui ne vivent que pour trouver la faille, c'est utopique de penser ça.

Arrêtez de mettre Google sur un piédestal !!! C'est une société a but lucrative comme les autres.