WebAssembly, le format binaire du web créé par Apple, Google, Microsoft et Mozilla

WebAssembly, le format binaire du web créé par Apple, Google, Microsoft et Mozilla

Les développeurs Java et .NET s’écrient : « Ah ! »

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

19/06/2015 5 minutes
106

WebAssembly, le format binaire du web créé par Apple, Google, Microsoft et Mozilla

Apple, Google, Microsoft et Mozilla s’associent autour d’un projet commun pour accélérer largement le chargement des sites et l’exécution du code sous-jacent. Nommé « WebAssembly », il doit fournir en fait un bytecode aux navigateurs, pour des performances qui pourraient être multipliées par plus de 20.

Le JavaScript, toujours l'objet de toutes les attentions

Si le JavaScript a permis l’émergence du Web 2.0, il fait l’objet de critiques permanentes. Il a conféré au développement web des avantages indéniables, parmi lesquels son indépendance face aux architectures matérielles coté clients. Tant qu’aucune faille de sécurité ne vient gâter la situation, la présence d’une sandbox est une certaine garantie de sécurité. Heureusement d’ailleurs, puisque l’objectif du JavaScript reste d’exécuter du code capable de transformer une simple page web en un service ayant presque autant de possibilités qu’un logiciel natif.

Le langage est tellement utilisé, y compris sur le web mobile, que de nombreux éditeurs se penchent continuellement sur ses performances. Car ces dernières sont désormais un élément clé de la rapidité générale d’un site web. Améliorer ces performances passe aussi bien par des modifications dans l’écriture du code que dans la manière dont il est lu, interprété puis exécuté. Mais ce sont justement toutes ces étapes qui empêchent le JavaScript d’avoir les mêmes performances qu’un code natif.

Parmi les améliorations les plus notables de ces dernières années autour du JavaScript, on pourra notamment citer asm.js, un sous-ensemble de JavaScript conçu par Mozilla pour être exécuté très rapidement. Le TypeScript de Microsoft se destine pour sa part à ceux qui ont de vastes projets en JavaScript et qui veulent donc simplifier l’écriture via l’ajout de fonctionnalités spécifiques. Le standard ECMAScript (derrière le JavaScript) évolue également de son côté en ajoutant notamment de nouveaux types de données.

WebAssembly, un code intermédiaire lu vingt fois plus vite

La question était donc de savoir comment garder les avantages de JavaScript tout en gommant ses défauts. La réponse proposée par Microsoft, Google, Apple et Mozilla est simple : fournir un bytecode. Il s’agit d’un code intermédiaire, que les développeurs .NET et Java connaissent déjà, et qui vient se placer entre le fichier texte classique et l’assembleur. On pourrait parler vulgairement de code « prémâché » ou simplement précompilé. De fait, présenté au compilateur, il est beaucoup plus facile à lire par la machine et n’a plus besoin d’être interprété.

Le projet se nomme WebAssembly, ou « wasm », et le fait qu’il soit soutenu par les quatre plus grands éditeurs de navigateurs représente d’emblée un sérieux atout. L’idée était de rester sur le JavaScript, qui sert dans tous les cas de dénominateur commun. Par exemple, un développeur peut utiliser le TypeScript de Microsoft sans craindre que le code ne soit pas lisible puisqu’il est converti en JavaScript. Ce dernier peut être utilisé pour atteindre des API ou certaines technologies, comme WebGL, d’où l’idée d’en bâtir une amélioration, et surtout pas d’essayer de le remplacer.

Dans la pratique, un code WebAssembly est donc déjà précompilé et beaucoup plus léger à télécharger. Pour le compilateur, le code wasm présente un visage uniforme avec des types de données faciles à comprendre, comme des entiers 32 bits ou des nombres à virgule flottante. Sous cette forme, le parsing du code est vingt fois plus rapide qu’avec asm.js.

Un projet qui démarre, mais qui devrait rapidement prendre de l'ampleur

Parce que WebAssembly devra se faire une place parmi les solutions web, les quatre éditeurs prévoient donc de faciliter le travail des développeurs. Lors de la préparation du bytecode, ces derniers obtiendront donc le wasm lui-même, ainsi qu’une version texte pour le débogage. Par ailleurs, puisqu’il faudra le temps que tous les navigateurs soient à jour chez les utilisateurs, un script JavaScript (nommé « polyfill ») permettra aux développeurs de convertir le code wasm en JavaScript classique. La lecture d’un code ou de l’autre dépendra donc uniquement du navigateur et de sa compatibilité avec la nouvelle technologie.

Pour l’instant, WebAssembly en est à un stade assez peu avancé, on pourrait même dire de prototype. Pour l’instant, l’écriture du code se focalise sur les langages C et C++, mais d’autres sont prévus par la suite. En outre, aucun organisme de standardisation ne travaille encore sur ce projet, mais les quatre éditeurs impliqués attendent sans doute de progresser plus avant dans les spécifications avant de le faire passer à la moulinette du W3C notamment.

Enfin, on signalera la participation au projet commun de Brendan Eich, créateur du JavaScript, et pendant un court laps de temps PDG de Mozilla. Dans un billet sur son blog, daté de mercredi, il fait d’ailleurs le récapitulatif de la situation et explique pourquoi, en dépit des nombreux efforts faits jusqu’à présent, WebAssembly peut apporter un véritable avantage au web.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le JavaScript, toujours l'objet de toutes les attentions

WebAssembly, un code intermédiaire lu vingt fois plus vite

Un projet qui démarre, mais qui devrait rapidement prendre de l'ampleur

Fermer

Commentaires (106)


LostSoul Abonné
Le 19/06/2015 à 15h 32

Like !


ILPlais
Le 19/06/2015 à 15h 35

J’espère que ça ne sera pas un remake des applets Java ou d’ActiveX <img data-src=" />


otto
Le 19/06/2015 à 15h 37

C’est très bien pour les perfs… par contre plus moyen de regarder le code source…

&nbsp;


zempa Abonné
Le 19/06/2015 à 15h 41







ILPlais a écrit :



J’espère que ça ne sera pas un remake des applets Java ou d’ActiveX <img data-src=" />





si j’ai bien compris, l’idée n’est pas de faire des applets java-like ou des ActiveX-like mais de remplacer le code javascript par un pseudo binaire.

&nbsp;

Comme tous les langages de script, on doit nécessairement passer par une première phase de parsing qui peut prendre beaucoup de temps pour ensuite interpréter le code.

&nbsp;

Ce qui est envisagé est de “pre-compiler” le code pour que celui-ci soit directement interprété.

&nbsp;

Il ne s’agit donc pas d’étendre les possibilités mais juste d’optimiser le poids et le temps d’exécution du javascript.



porecreat
Le 19/06/2015 à 15h 42

Aucun risque puisqu’il ne s’agit pas d’applets et que le JS reste la base. Les changements ne concerneront que le process d’exécution (“sous le capot”), pas les fonctionnalités finales.


wagaf Abonné
Le 19/06/2015 à 15h 43

Aujourd’hui le code JS/Dart etc. est déjà “compilé” en JS&nbsp; illisible.


Clapitti
Le 19/06/2015 à 15h 45

Le js sera toujours dispo pour assurer la compatibilité avec “le reste du web”.


Firefly' Abonné
Le 19/06/2015 à 15h 46

Non, tu ne pourra pas en faire plus qu’en javascript classique ( niveau api ), c’est juste qu’au lieux d’avoir interpreteur + jit, on as que du jit. Avec un bytecode déjà optimisé (hors optimisation de plateforme, laissé au jit )

&nbsp;

&nbsp;Grosso modo, scope du JS, avec les perfs du java/c# ( voir mieux ? (doute) &nbsp;)

&nbsp;





otto a écrit :



C’est très bien pour les perfs… par contre plus moyen de regarder le code source…

&nbsp;



Tu peu déjà pas voir le code des applications que tu utilise, et le js est souvent obfusqué .. et puis il suffira d’utiliser un navigateur qui as pas cette fonction ( ou la désactiver si dispo ) pour que le serveur te renvoie un js classique&nbsp;

&nbsp;

&nbsp;edit : grillé :p



maxxyme
Le 19/06/2015 à 15h 48

C’est “offusqué” le terme il me semble… ;)


Naneday
Le 19/06/2015 à 15h 52

N’ont ils pas appris des erreur d’ActiveX, Java Applet, Flash etc ?



L’ouverture de OS au web, et ca sent pas bon


WereWindle
Le 19/06/2015 à 15h 54







maxxyme a écrit :



C’est “obfusqué” le terme il me semble… ;)





avec un b



Le code est un sujet sensible et il râle souvent mais il ne s’offusque pas d’un rien <img data-src=" /> <img data-src=" />



js2082
Le 19/06/2015 à 15h 56







LostSoul a écrit :



Like !





Tu likeras moins le jour où tu t’apercevras que ce nouveau langage est aussi un afficheur de pub intégré que tu ne pourras pas contourner malgré les adblocks et consorts.

&nbsp;&nbsp;

&nbsp;Tout ça pour dire, l’initiative parait bonne, mais vu le passif des entreprises concernées, ça ne serait pas surprenant que ça devienne un programme espion et publicitaire de plus dans l’internet actuel.

&nbsp;

&nbsp;Bref, wetandsea comme on dit.



zempa Abonné
Le 19/06/2015 à 15h 59







wagaf a écrit :



Aujourd’hui le code JS/Dart etc. est déjà “compilé” en JS&nbsp; illisible.



&nbsp;L’obfuscation n’est pas de la compilation.

C’est juste de la simplification sémantique pour réduire le poids des fichiers : réduction des noms de variable en une seule lettre, tout le code placé sur une seule ligne, etc



levhieu
Le 19/06/2015 à 16h 00

J’ai apprécié ce commentaire lu ailleurs (enfin, je traduis…):

&nbsp;

Tiens, le retour du p-code UCSD


Z-os Abonné
Le 19/06/2015 à 16h 02

Avec l’arrivée de la 4G, le plus lourd sur une page ce sont quand même les images et les vidéos. Le temps d’exécution du javascript est du même ordre de grandeur en temps de traitement ?


Fuinril
Le 19/06/2015 à 16h 02







js2082 a écrit :



Tu likeras moins le jour où tu t’apercevras que ce nouveau langage est aussi un afficheur de pub intégré que tu ne pourras pas contourner malgré les adblocks et consorts.

&nbsp;&nbsp;

&nbsp;Tout ça pour dire, l’initiative parait bonne, mais vu le passif des entreprises concernées, ça ne serait pas surprenant que ça devienne un programme espion et publicitaire de plus dans l’internet actuel.

&nbsp;

&nbsp;Bref, wetandsea comme on dit.





Je vois pas le rapport…. adblock et consort ne touchent pas le code js d’une part, d’autre part tu peux aussi bien modifier du bytecode que du code… tant que c’est exécuté sur ta machine bien sûr.



Nikodym
Le 19/06/2015 à 16h 03







js2082 a écrit :



Tu likeras moins le jour où tu t’apercevras que ce nouveau langage est aussi un afficheur de pub intégré que tu ne pourras pas contourner malgré les adblocks et consorts.

&nbsp;&nbsp;

&nbsp;Tout ça pour dire, l’initiative parait bonne, mais vu le passif des entreprises concernées, ça ne serait pas surprenant que ça devienne un programme espion et publicitaire de plus dans l’internet actuel.

&nbsp;

&nbsp;Bref, wetandsea comme on dit.





C’est faux sur la partie pub, le code source étant toujours récupérable…



ErGo_404
Le 19/06/2015 à 16h 04

Obfusqué :)


Pr. Thibault
Le 19/06/2015 à 16h 04

&nbsp;Parce qu’avant l’arrivée de la 4G ce n’était pas le cas ?


ErGo_404
Le 19/06/2015 à 16h 06

Le temps de chargement est une chose, mais un site bien foutu aujourd’hui ne charge pas les données à chaque ouverture de la page, le cache est là pour ça. Par contre, le code est exécuté à chaque fois et il s’agit bien de réduire ce temps d’exécution. Tout est bon à prendre dans l’optimisation, et cette techno pourrait signifier la possibilité de faire des webapps multiplateformes qui soient enfin efficaces.


wagaf Abonné
Le 19/06/2015 à 16h 18

Dans la même opération le code est souvent vastement optimisé, on peut alors parler de compilation.


brazomyna
Le 19/06/2015 à 16h 34

je vois pas comment ça peut faire gagner quoi que ce soit en perfs lors de l’exécution.

Ce que cette solution semble améliorer c’est juste le temps entre le moment où le code a fini de charger et le début de son exécution.

Donc ça démarrera plus vite mais ça s’exécutera pas plus vite pour autant.


bobdu87
Le 19/06/2015 à 16h 36







zogG a écrit :



Le js sera toujours dispo pour assurer la compatibilité avec “le reste du web”.





Au début oui…&nbsp;



bobdu87
Le 19/06/2015 à 16h 40







Nikodym a écrit :



C’est faux sur la partie pub, le code source étant toujours récupérable…





Jusqu’a ce que ça devienne la norme… et là ça sera une autre histoire… y a plus qu’a signé le code pour des histoire de sécurité et il ne sera même pas possible de modifier le code avec un addblock nouvelle génération… et hop voilà le web 3.0…



Bou2004
Le 19/06/2015 à 16h 48

Par contre, c’est quoi cette histoire de C/C++ ? <img data-src=" />









wagaf a écrit :



Dans la même opération le code est souvent vastement optimisé, on peut alors parler de compilation.







Hum, quelles optimisations ? Ça rend juste le code plus court et plus chiant à lire.







brazomyna a écrit :



je vois pas comment ça peut faire gagner quoi que ce soit en perfs lors de l’exécution.

Ce que cette solution semble améliorer c’est juste le temps entre le moment où le code a fini de charger et le début de son exécution.

Donc ça démarrera plus vite mais ça s’exécutera pas plus vite pour autant.







Quelqu’un en a parlé plus haut, on saute une étape, la précompilation sera faite une fois pour toutes côté serveur au lieu d’être faite par chaque client, le gain vient de là.







Z-os a écrit :



Avec l’arrivée de la 4G, le plus lourd sur une page ce sont quand même les images et les vidéos. Le temps d’exécution du javascript est du même ordre de grandeur en temps de traitement ?







Ça dépend, un site AngularJS avec une cinquantaine de pages assez chargées, il doit y avoir moyen de fumer un smartphone.



Bou2004
Le 19/06/2015 à 16h 49

oups


Clapitti
Le 19/06/2015 à 16h 53

Quoi qu’il arrive c’est du code qui va modifier le page HTML, bref du javascript, donc je vois pas ce qu’adblock vient faire la dedans. Suffit de charger ton adblock après leur webassembly pour virer ce que leur code rajoutera eventuellement… comme maintenant en fait.


Thoscellen Abonné
Le 19/06/2015 à 16h 58

Pas forcément. Certes, ton navigateur exécutera du Bytecode (attention, pas du code d’assembleur), mais il pourra aussi débugger en JIT (par exemple) sur les sources. Comme le fait Java et .net actuellement.


Danytime
Le 19/06/2015 à 16h 58







zogG a écrit :



Quoi qu’il arrive c’est du code qui va modifier le page HTML, bref du javascript, donc je vois pas ce qu’adblock vient faire la dedans. Suffit de charger ton adblock après leur webassembly pour virer ce que leur code rajoutera eventuellement… comme maintenant en fait.



Laisse tomber, c’est encore un pecno qui vit dans le peur de tout.



francois-battail
Le 19/06/2015 à 17h 00







Bou2004 a écrit :



Quelqu’un en a parlé plus haut, on saute une étape, la précompilation sera faite une fois pour toutes côté serveur au lieu d’être faite par chaque client, le gain vient de là.





Bof, analyse lexicale, sémantique et optimisation c’est pas forcément critique si après le code fait un max de requêtes en JSON par exemple de plus il faut soit pré-compiler côté serveur soit le faire à la volée puisqu’il faudrait proposer deux versions (JS et version compilée). Et avec la compression et HTTP 2 qui se profile le gain qui serait obtenu par ce moyen semble complètement marginal si l’application est bien foutue dès le départ.



Strimy
Le 19/06/2015 à 17h 12

Avec un bytecode qui est généré AOT, on doit bien pouvoir apporter plus d’optimisations que sur du code JS dont la compilation JIT doit se faire le plus rapidement possible.


Dude76 Abonné
Le 19/06/2015 à 17h 32







otto a écrit :



C’est très bien pour les perfs… par contre plus moyen de regarder le code source…





Si c’est du bytecode, il y aura bien des Reflector-ILSpy like pour pouvoir les lire, on a bien ça en C#, je ne vois pas pourquoi ce ne serait pas possible avec ce WebAssembly.





zempa a écrit :



L’obfuscation n’est pas de la compilation.

C’est juste de la simplification sémantique pour réduire le poids des fichiers : réduction des noms de variable en une seule lettre, tout le code placé sur une seule ligne, etc





Non, l’obfuscation ce n’est pas la “simplification” des noms des variables et autres réductions et optimisations, mais c’est tenter de rendre son code trèèès difficilement compréhensible, même une fois réfléchi; ça en passe par le renommages des variables, mais pas pour des raisons de perfs :)




RaoulC
Le 19/06/2015 à 17h 37







js2082 a écrit :



Tu likeras moins le jour où tu t’apercevras que ce nouveau langage est aussi un afficheur de pub intégré que tu ne pourras pas contourner malgré les adblocks et consorts.

&nbsp;&nbsp;

&nbsp;Tout ça pour dire, l’initiative parait bonne, mais vu le passif des entreprises concernées, ça ne serait pas surprenant que ça devienne un programme espion et publicitaire de plus dans l’internet actuel.

&nbsp;

&nbsp;Bref, wetandsea comme on dit.





bah. les publicités sont chargées à partir de domaines autres que le site que tu visite.&nbsp; Tant que c’est le navigateur qui va chercher la ressource, les bloqueurs peuvent travailler la dessus..

&nbsp;

Le soucis c’est quand c’est le plugin qui agit et que le navigateur na pas de prise sur la requête..

Exemple : le player Canal+ sur leur site, c’est le swf (Flash) qui load les pub chez VideoPlaza..

&nbsp;

Si tu trafique ton Host/bloque les ip , le flash t’envoie bouler.. Et ca, tu ne peut rien y faire (de manière simple, car en cumulant GreaseMonkey et Firewall, impeccable :p).

&nbsp;

Ca va faire du boulot pour les anti virus ca. Parce que maintenant il va falloir analyser le bytecode …

&nbsp;

Imaginez : du bytecode de JS, JS lui même obfusqué <img data-src=" />



wagaf Abonné
Le 19/06/2015 à 17h 44
RaoulC
Le 19/06/2015 à 17h 45







Dude76 a écrit :



Si c’est du bytecode, il y aura bien des Reflector-ILSpy like pour pouvoir les lire, on a bien ça en C#, je ne vois pas pourquoi ce ne serait pas possible avec ce WebAssembly.



Non, l’obfuscation ce n’est pas la “simplification” des noms des variables et autres réductions et optimisations, mais c’est tenter de rendre son code trèèès difficilement compréhensible, même une fois réfléchi; ça en passe par le renommages des variables, mais pas pour des raisons de perfs :)



Oui enfn l’obfu ca peut aller très loin. Le nom des variables c’est peanuts.

&nbsp;Certains outils exploitent meme les failles des Reflector-Like…

&nbsp;

J’ouvre un binaire sous Reflector, veut voir la fonction Main(); et…. IE s’ouvre comme par magie (mon nav par défaut étant Firefox) et ….Rick Roll <img data-src=" />…. Marrant ca

&nbsp;



127.0.0.1
Le 19/06/2015 à 18h 23

[quote]Les développeurs Java et .NET s’écrient : « Ah ! »|/quote]



Ah !



Faudrait que je retrouve mes vieux post sur NXI où je disais qu’il faudrait un jour choisir si le browser était un simple viewer (de page html) ou un complexe environnement d’execution (de bytecode).



Prochaine étape: la disparition de HTML/CSS. Quel besoin de se faire chier à créer, transférer et interpréter du HTML/CSS alors qu’on peut créer son layout avec du bytecode universel ?


Z-os Abonné
Le 19/06/2015 à 18h 45







Pr. Thibault a écrit :



Parce qu’avant l’arrivée de la 4G ce n’était pas le cas ?





Moi tu sais, tout ce qui n’est pas aussi réactif que des écrans 3270 m’insupporte. <img data-src=" /> (bon c’est que du texte)

J’ai l’impression que les sites webs sont lents quelques soient la configuration de la machine et les vitesses de bande passante montante et descendante.



ISPF vaincra. J’ai rarement vu des sites web utilisables sans souris. <img data-src=" />





ErGo_404 a écrit :



Le temps de chargement est une chose, mais un site bien foutu aujourd’hui ne charge pas les données à chaque ouverture de la page, le cache est là pour ça. Par contre, le code est exécuté à chaque fois et il s’agit bien de réduire ce temps d’exécution. Tout est bon à prendre dans l’optimisation, et cette techno pourrait signifier la possibilité de faire des webapps multiplateformes qui soient enfin efficaces.





Pas pensé à cela. Merci



jmm Abonné
Le 19/06/2015 à 19h 07

Encore un nid à failles de sécurité. Il va y avoir du RCE 0day à vendre.



Les applications supplantent peu à peu l’utilisation des sites web sur le mobile. Désormais c’est tout le web qui pourrait s’engouffrer dans cette voie. Certes, le rôle principale du navigateur reste encore le rendu, mais il devient de plus en plus un environnement d’exécution. Quelle différence avec l’actionscript compilé ou le byte-code java (applet, jnpl) ? Suis-je un vieux con nostalgique ou le web est-il en train d’y perdre son âme ? Question rhétorique : merci de ne pas répondre.


dj0- Abonné
Le 19/06/2015 à 19h 57

Ça fait plaisir de voir un débat de cette qualité, merci à tous !

J’aurais tendance à dire wait&see, il y a des questions sous-jacentes et il faut voir ce qui sera communiqué.

Je n’ai pas non plus compris le lien avec c/c++


zefling Abonné
Le 19/06/2015 à 20h 03







127.0.0.1 a écrit :



Prochaine étape: la disparition de HTML/CSS. Quel besoin de se faire chier à créer, transférer et interpréter du HTML/CSS alors qu’on peut créer son layout avec du bytecode universel ?







Disparition du CSS ? Mais je me rappelle m’en être servis dans plusieurs langages parce que c’est moins chiant de donner la mise en forme par CSS que d’aller le code soit-même ou passer pas une kyrielle de méthode de description. Je me sers aussi de HTML/CSS pour faire des PDF, et ça été un soulagement quand on a pu dégager l’équivalent en code (un usine à gaz). Perso, je veux bien la mort du JS, mais pas du HTML|XML/CSS.



zefling Abonné
Le 19/06/2015 à 20h 06

Ça c’est parce que quand tu vas sur un site t’as des requête vers tout l’univers : pubs, réseau sociaux, traceur, etc.



Celui qui m’impressionne le plus, récemment c’est Amazon qui t’affiche page pour la réécrire dernière en AJAX à l’identique… ça sert à rien.


Uther Abonné
Le 19/06/2015 à 20h 10







brazomyna a écrit :



je vois pas comment ça peut faire gagner quoi que ce soit en perfs lors de l’exécution.

Ce que cette solution semble améliorer c’est juste le temps entre le moment où le code a fini de charger et le début de son exécution.

Donc ça démarrera plus vite mais ça s’exécutera pas plus vite pour autant.



Le bytecode permettra d’améliorer les performances car il permettra de faire des chose plus bas niveau que le Javascript. Un peu comme le fait actuellement asm.js mais en encore plus poussé vu qu’il n’y a pas la contrainte de la syntaxe Javascript.





Bou2004 a écrit :



Par contre, c’est quoi cette histoire de C/C++ ? <img data-src=" />



Hum, quelles optimisations ? Ça rend juste le code plus court et plus chiant à lire.



L’objectif de ce bytecode est de pouvoir être généré a partir d’autres langages, et le C et le C++ sont les premiers langages qui devraient permettre de le faire





francois-battail a écrit :



Bof, analyse lexicale, sémantique et optimisation c’est pas forcément critique si après le code fait un max de requêtes en JSON par exemple de plus il faut soit pré-compiler côté serveur soit le faire à la volée puisqu’il faudrait proposer deux versions (JS et version compilée). Et avec la compression et HTTP 2 qui se profile le gain qui serait obtenu par ce moyen semble complètement marginal si l’application est bien foutue dès le départ.



En fait il n’y aurait que la version compilée en wasm a transmettre. Il y aurait une bibliothèque javascript coté client qui s’occuperait de faire la conversion wasm -&gt; javascript.&nbsp; Cette bibliothèque n’aurait a être chargée qu’une fois sur les navigateurs encore non compatibles et ne sera plus nécessaire du tout sur les futurs navigateurs qui prendront en charge la norme.

&nbsp;

Des mesures qui ont été publiées, même avec la compression activées, il semble que le gain est très sensible.



Clapitti
Le 19/06/2015 à 20h 18

En lisant les docs sur github visiblement tu vas pouvoir utiliser du C/C++ pour générer ton WebAssembly, qui va s’occuper de faire le lien entre ce que ton code veut faire et comment le navigateur peut le faire (exemple : OpenGL dans ton code &gt; WebGL dans le navigateur etc.).

&nbsp;


Clapitti
Le 19/06/2015 à 20h 22

Sans avoir les détails difficile de dire exactement, mais ça doit sûrement permettre à tout le monde de consulter les pages, ceux qui ont le JS ou un navigateur compatible ont les bénéfices de l’AJAX en plus.


TexMex
Le 19/06/2015 à 20h 46

C’est un peu bizarre de s’en occuper maintenant vu que les machines sont surpuissante aujourd’hui. Et plus avec l’arrivée des SSD qui se démocratisent partout (les portable en premier).

&nbsp;


francois-battail
Le 19/06/2015 à 20h 54

Oui, donc compilation côté serveur pour faire du wasm (en mode statique ou dynamique) parce que bien évidemment ton téléphone d’il y a un an va le supporter et sinon la lib miracle qui transforme du wasm en javascript puis un coup de JIT <img data-src=" />

&nbsp;

Si les « développeurs » web viraient les trucs mal codés et consommateurs de ressources… non à la réflexion ce serait un cauchemar <img data-src=" />


zefling Abonné
Le 19/06/2015 à 21h 05

Oui, mais pourquoi ré-afficher ce qui est déjà afficher ? Je m’en suis rendu compte en voulant modifier une page à la voler. Et forcement à l’arrivée ma modif saute. <img data-src=" />


Clapitti
Le 19/06/2015 à 21h 17

En tant que dev tu dois savoir pourquoi : c’est plus simple et ça marche !&nbsp;<img data-src=" />


zefling Abonné
Le 19/06/2015 à 21h 24

C’est plus simple de recharger à l’identique un élément déjà présent ? Il faudra que tu m’expliques en quoi c’est plus simple ? De plus, la bouffe de la bande passante pour rien, ça fait faire des calculs inutiles, ça augmente les ressources de navigateurs…


Clapitti
Le 19/06/2015 à 21h 37

Puisque tu vérifies pas si la MAJ est nécessaire… c’est plus simple. Bourin si tu préfères.

&nbsp;

Et pour la bande passante, quoi qu’il arrive pour savoir s’il doit mettre à jour l’affichage il doit télécharger la nouvelle version pour eventuellement vérifier s’il y a des différences… donc tu as seulement la première info qui téléchargée deux fois… avec le cache et les CDN qu’Amazon doit avoir ça doit pas représenter grand chose en plus à mon avis.


Tepec
Le 20/06/2015 à 03h 54







francois-battail a écrit :



si l’application est bien foutue dès le départ.





“application web”, “bien foutue”, dans la même phrase <img data-src=" /> ? C’est … Au mieux très audacieux, au pire complètement utopiste <img data-src=" />

Malheureusement, je ne pense pas que le web soit poussé par la qualité ; il suffit de voir qu’on considère le JS comme un peu plombant, et pour autant 98% des sites web utilisent jQuery, la grosse bertha fourre-tout de la rétro-compatibilité. Ajoutons à ça la surcharge du DOM souvent aberrante (au point qu’on en viendrait à trouver que Twitter Bootstrap est “propre” en comparaison <img data-src=" /> ), le CSS complètement foiré et monstrueux car beaucoup trop de développeurs sont pris dans l’urgence ou pas assez compétents pour concevoir l’application/le site avant de se jeter dans la réalisation … Et je ne parle vraiment que du côté client !

Attention, je ne dis pas ça de façon méprisante ou même méchante, mais c’est un fait : le web, c’est souvent codé avec les pieds <img data-src=" /> , et je suppose que c’est le revers de la médaille pour cette technologie très accessible.



Du coup, je vais tout de même suivre avec curiosité et intérêt ce projet, car je ne cracherai pas dans la soupe si on peut grappiller un peu de perfs sans sacrifier quoi que ce soit !



brazomyna
Le 20/06/2015 à 04h 23







Uther a écrit :



Le bytecode permettra d’améliorer les performances car il permettra de faire des chose plus bas niveau que le Javascript. Un peu comme le fait actuellement asm.js mais en encore plus poussé vu qu’il n’y a pas la contrainte de la syntaxe Javascript.





Je ne suis tpujours pas d’accord: quel que soit la précompil’ que tu fais, si tu dois rester sur les principes de fonctionnement intrinséque du JS, tu vas pas t’affranchir tout à coup des contraintes inhérentes langage. Par exemple le fait que le langage soit orienté prototype, soit des objets qui sont une map dynamique, avec des strings à comparer pour accéder à un attribut va pas tout à coup se changer pour avoir les perfs d’un typage fort du C++ avec des accés aux attributs via un simple offset mémoire. Mèle chose pour le transtypage, etc…




Nikodym
Le 20/06/2015 à 04h 53







brazomyna a écrit :



Je ne suis tpujours pas d’accord: quel que soit la précompil’ que tu fais, si tu dois rester sur les principes de fonctionnement intrinséque du JS, tu vas pas t’affranchir tout à coup des contraintes inhérentes langage. Par exemple le fait que le langage soit orienté prototype, soit des objets qui sont une map dynamique, avec des strings à comparer pour accéder à un attribut va pas tout à coup se changer pour avoir les perfs d’un typage fort du C++ avec des accés aux attributs via un simple offset mémoire. Mèle chose pour le transtypage, etc…





OCaml ?



Bou2004
Le 20/06/2015 à 05h 35







Uther a écrit :



Le bytecode permettra d’améliorer les performances car il permettra de faire des chose plus bas niveau que le Javascript. Un peu comme le fait actuellement asm.js mais en encore plus poussé vu qu’il n’y a pas la contrainte de la syntaxe Javascript.

L’objectif de ce bytecode est de pouvoir être généré a partir d’autres langages, et le C et le C++ sont les premiers langages qui devraient permettre de le faire

En fait il n’y aurait que la version compilée en wasm a transmettre. Il y aurait une bibliothèque javascript coté client qui s’occuperait de faire la conversion wasm -&gt; javascript.  Cette bibliothèque n’aurait a être chargée qu’une fois sur les navigateurs encore non compatibles et ne sera plus nécessaire du tout sur les futurs navigateurs qui prendront en charge la norme.

 

Des mesures qui ont été publiées, même avec la compression activées, il semble que le gain est très sensible.







Ah, c’est le retour des applets java en fait mais avec un compatibilité js. Du coup, quasi-aucun dev web ne va utiliser ce truc là.



brazomyna
Le 20/06/2015 à 06h 13







Nikodym a écrit :



OCaml ?





???



Nikodym
Le 20/06/2015 à 06h 32







brazomyna a écrit :



???





Regarde comment fonctionne ocaml <img data-src=" />



rbag
Le 20/06/2015 à 07h 06

j’ai l’occasion de travailler avec une application web bien faite (une Single Page Application développée avec ext.js), et c’est très agréable.

&nbsp;

Une appli qui n’a pas été bien conçue au niveau de l’interface utilisateur sera mauvaise, web ou pas web… Au passage si tu veux voir une appli web très avancée, tu peux jeter un coup d’oeil àhttps://portal.azure.com.

&nbsp;

ils ont fait un&nbsp; boulot impressionnant au niveau de l’UX et de la navigation, et sur ce genre d’appli tu comprends aisément que le parsing de 10 Mo de javascript peut prendre du temps, particulièrement sur&nbsp; des terminaux mobiles.


HarmattanBlow
Le 20/06/2015 à 07h 32







ILPlais a écrit :



J’espère que ça ne sera pas un remake des applets Java ou d’ActiveX <img data-src=" />





De nos jours tous les navigateurs s’orientent vers le modèle de Chrome, à savoir l’isolation de chaque page dans un processus distinct. Or l’isolation mémoire entre processus est mise en oeuvre par le matériel et le système d’exploitation, et elle est probablement inviolable en soi.



Dès lors un processus (une page web) ne peut dialoguer avec le reste du monde que via les API exposées via le navigateur. Autrement dit les possibles failles de sécurité sont les mêmes que pour JS, ni plus ni moins, et liées aux fonctionnalités exposées par le navigateur. A vrai dire la seule différence est dans le compilateur et celui de WebAssembly sera beaucoup plus simple.



La situation était très différente avec ActiveX, Flash ou Java : tout le navigateur s’exécutait dans un unique processus, et tous avaient accès à des fonctionnalités plus étendues que celles offertes à JS.







brazomyna a écrit :



je vois pas comment ça peut faire gagner quoi que ce soit en perfs lors de l’exécution.

Ce que cette solution semble améliorer c’est juste le temps entre le moment où le code a fini de charger et le début de son exécution.

Donc ça démarrera plus vite mais ça s’exécutera pas plus vite pour autant.









Firefly’ a écrit :



c’est juste qu’au lieux d’avoir interpreteur + jit, on as que du jit. Avec un bytecode déjà optimisé (hors optimisation de plateforme, laissé au jit )





Non, ça va au-delà.



a) C’est un bitcode, pas un bytecode : les instructions équivalent à un assembleur générique là où dans le bytecode de Java & co les instructions sont de haut niveau, décrivant directement des appels de fonction et se référant à une structure de types.



b) Javascript a un typage dynamique, ce qui rend littéralement impossible la compilation sans surcoût de nombreux types et méthodes. Et si en théorie on pourrait optimiser davantage qu’aujourd’hui, en pratique les compilateurs sont contraints par le temps de compilation. Un langage dynamique ne pourra jamais être aussi optimisé qu’un code avec typage statique en général, point barre (même si on peut toujours écrire telle ou telle courte méthode donnant les mêmes perfs en JS qu’en C).





Grosso modo, scope du JS, avec les perfs du java/c# ( voir mieux ? (doute)  )



Les performances théoriques seront maximales, ni plus ni moins : un programme écrit en C++ pourra s’exécuter dans la navigateur a la même vitesse que sur le bureau.



Le surcoût de l’isolation est le même que celui déjà payé par les applis natives, “sur le bureau” (et équivalents smartphones). Et les défis de la compilation sont là aussi les mêmes.



La seule petite différence c’est que la compilation devra rester rapide sur le navigateur, une contrainte absente en offline. Mais il n’y a pas tant de boulot que ça à faire pour convertir du webassembly en asm. Il y a aussi le fait que les API du navigateur auront un léger surcoût par rapport aux API du système mais ça devrait être négligeable (encore qu’il y faudra offrir des API graphiques sans surcoût pour les applis en plein écran - en-dehors de ce mode il faudra conserver des garde-fous pour ne pas compromettre l’affichage).



HarmattanBlow
Le 20/06/2015 à 07h 42







Nikodym a écrit :



OCaml ?





Ce n’est pas la même chose, OCaml a un typage statique, inféré à la compilation (voir Hindley-Milner).



En particulier tu ne peux pas créer une chaîne de caractères à l’exécution et déclarer un membre avec cette chaîne à l’exécution. SI c’était le cas, alors puisque le problème de l’arrêt rendrait impossible de connaître cette chaîne sans exécuter le programme, il serait donc impossible de générer des types à la compilation et il faudrait se résoudre à utiliser des dictionnaires clé-valeur lents comme dans les langages dynamiques.



De la même façon si tu indexes un membre via une chaîne inconnue à la compilation, alors il faut passer par un dictionnaire.



Le seul cas où un compilateur JIT pour un langage dynamique peut vraiment optimiser, c’est lorsque que le type est connu avec certitude via une analyse statique superficielle, et que le type en question n’est utilisé que de façon statique (tous les membres sont accédés et déclarés via des littéraux connus à la compilation).



francois-battail
Le 20/06/2015 à 08h 08







rbag a écrit :



&nbsp;

ils ont fait un&nbsp; boulot impressionnant au niveau de l’UX et de la navigation, et sur ce genre d’appli tu comprends aisément que le parsing de 10 Mo de javascript peut prendre du temps, particulièrement sur&nbsp; des terminaux mobiles.





&nbsp;Quand il y a 300000 lignes de javascript, le problème ce n’est vraiment plus le parsing mais plutôt les « développeurs ». C’est probablement là qu’il y a une optimisation à faire <img data-src=" />



brazomyna
Le 20/06/2015 à 08h 45







HarmattanBlow a écrit :



Non, ça va au-delà.



b) Javascript a un typage dynamique, ce qui rend littéralement impossible la compilation sans surcoût de nombreux types et méthodes. Et si en théorie on pourrait optimiser davantage qu’aujourd’hui, en pratique les compilateurs sont contraints par le temps de compilation. Un langage dynamique ne pourra jamais être aussi optimisé qu’un code avec typage statique en général, point barre (même si on peut toujours écrire telle ou telle courte méthode donnant les mêmes perfs en JS qu’en C).





Ce n’est ni plus ni moins que ce que je disais avant: les optimisations possibles sont à regarder du côté du temps de démarrage, pas de l’exécution en soi, car le JS reste le JS.



Si on veut pouvoir faire les optimisations (donc avoir les perfs) d’un langage style Java, C++, etc… pour ce qui concerne les perfs d’exécution, il faut changer la nature même du langage (genre en rajoutant du typage fort, etc…) et donc c’est hors du cadre de ce dont on parle ici puisque le WebAssembly concerne le support de l’ECMA Script dans son ensemble.

&nbsp;

&nbsp;



brazomyna
Le 20/06/2015 à 08h 47







rbag a écrit :



tu comprends aisément que le parsing de 10 Mo de javascript peut prendre du temps, particulièrement sur&nbsp; des terminaux mobiles.





&nbsp;

Oui, mais en général, tes 10Mo sont pas parsés en une fois ; ça se fait au fur et à mesure des besoins (genre je vais sur tel écran, on charge ce contrôleur dynamiquement à ce moment là), donc même si la totalité du code de l’appli est imposant, on n’en charge que des petits bouts à chaque fois. Et donc ça reste peu perceptible pour l’utilisateur.

Et d’autres possibilités viennent également s’ajouter pour ne pas le faire à chaque fois qu’on visite tel écran, mais seulement la première fois (on peut faire de la mise en cache pour ça aussi)



Uther Abonné
Le 20/06/2015 à 09h 54







brazomyna a écrit :



Je ne suis tpujours pas d’accord: quel que soit la précompil’ que tu fais, si tu dois rester sur les principes de fonctionnement intrinséque du JS, tu vas pas t’affranchir tout à coup des contraintes inhérentes langage. Par exemple le fait que le langage soit orienté prototype, soit des objets qui sont une map dynamique, avec des strings à comparer pour accéder à un attribut va pas tout à coup se changer pour avoir les perfs d’un typage fort du C++ avec des accés aux attributs via un simple offset mémoire. Mèle chose pour le transtypage, etc…



Justement, si : c’est tout l’intérêt d’asm.js. Il permet de s’affranchir d’une grosse partie des contraintes du langage en le limitant le code à des fonctionalités de bas niveau dont on peut garantir les performances. Les fonctionnalités de haut niveau de C++ ne sont que du sucre syntaxique: elles sont produites à partir de fonctionnalités de bas niveau.

&nbsp;Comme toute les fonctionnalités de haut niveau qui pourraient impacter les performance sont désactivées, c’est infâme à utiliser pour un humain, mais parfait pour un convertisseur.

&nbsp;

Et le Web Assembly pourra aller encore plus loin à terme, quand il sera traité directement par le navigateur, vu qu’il n’aura aucune des restrictions liées au langage Javascript. 



&nbsp;




Bou2004 a écrit :



Ah, c’est le retour des applets java en fait mais avec un compatibilité js. Du coup, quasi-aucun dev web ne va utiliser ce truc là.



&nbsp; Ça dépend pourquoi : en effet ça ne remplacera pas Javascript pour tout et ça n’est absolument pas le but. Javascript est très bon quand il s’agit d’avoir de petits scripts et il n’y a pas de raison de changer ça.

&nbsp; Par contre si on a du code lourd, ou l’on serait tenté d’utiliser du Flash/SilverLight/Java/… ça prend tout son interet.





brazomyna a écrit :



Ce n’est ni plus ni moins que ce que je disais avant: les optimisations possibles sont à regarder du côté du temps de démarrage, pas de l’exécution en soi, car le JS reste le JS. 



&nbsp;




&nbsp;Tant que ça ne sera pas supporté directement par les navigateurs, Ça sera en effet juste du asm.js qui se chargera plus vite.

&nbsp;Mais c’est déjà un gain énorme :

&nbsp; - par rapport a du JavaScript standard vu les gros écarts de performances avec asm.js

&nbsp; - par rapport à du asm.js classique dont le temps de chargement est le principal souci.

&nbsp; 



Et quand on ne passera plus par du transpilage, les performances seront certainement très proches du natif.


&nbsp;

&nbsp;



brazomyna a écrit :



donc c’est hors du cadre de ce dont on parle ici puisque le WebAssembly concerne le support de l’ECMA Script dans son ensemble. 



&nbsp;




Tu as mal compris. Pour assurer la compatibilité,&nbsp; le WebAssembly est conçu pour être transpilé vers Javascript dans un premier temps, mais à terme il sera traité directement par le navigateur.



HarmattanBlow
Le 20/06/2015 à 10h 25







brazomyna a écrit :



Ce n’est ni plus ni moins que ce que je disais avant: les optimisations possibles sont à regarder du côté du temps de démarrage, pas de l’exécution en soi, car le JS reste le JS.



Si on veut pouvoir faire les optimisations (donc avoir les perfs) d’un langage style Java, C++, etc… pour ce qui concerne les perfs d’exécution, il faut changer la nature même du langage (genre en rajoutant du typage fort, etc…) et donc c’est hors du cadre de ce dont on parle ici puisque le WebAssembly concerne le support de l’ECMA Script dans son ensemble.





Non, tu as compris de travers tout le projet.



Ce n’est PAS un bytecode pour Javascript. C’est un bitcode du niveau assembleur, avec des instructions du type “charger le contenu de l’adresse mémoire du registre A dans le registre B” ou “additionner le contenu des registres A et B en les considérant comme des entiers 64 bits”. C’est un assembleur pour un processeur imaginaire, conçu pour servir de source à la compilation vers n’importe quel CPU. Comme dans LLVM et PNaCl, et d’autres compilateurs.



Le seul moment où JS interviendra à terme dans tout ça ce sera parce que les API du navigateur (et seulement elles) resteront conçues pour JS. Autrement dit les objets du DOM demeureront des objets dynamiques pour JS. Et il y aura donc vraisemblablement quelques instructions du type “tenter de charger un entier 32 bits depuis la référence JS dans le registre A avec le membre nommé selon l’adresse d’une chaîne utf-8 stockée dans le registre B”. Mais ces instructions ne seront utilisées que pour interagir avec le navigateur. Et on peut même imaginer qu’à terme tout ou partie des API auront des contreparties natives.







brazomyna a écrit :



Oui, mais en général, tes 10Mo sont pas parsés en une fois ; ça se fait au fur et à mesure des besoins (genre je vais sur tel écran, on charge ce contrôleur dynamiquement à ce moment là)





Ce n’est pas possible pour une compilation statique, même en JIT : si ta méthode “abc” appelle la fonction nommée “def”, il faut que tu localises “def” avant de compiler “abc”. Tu dois donc tout parser dès le départ.



Sans cela à l’appel de “def” tu vas demander à ton compilateur de scanner toutes les sources jusqu’à ce qu’il trouve enfin une fonction appelée “def”. Autrement dit il va rapidement devoir tout parser. Autant le faire dès le départ, ça sera plus efficace.



En revanche tu peux, après avoir parser “def”, en retarder la compilation jusqu’à sa première invocation. Mais je ne suis pas sûr que ça n’aie pas d’impact sur les performances, même en supposant que tu accordes au compilateur tout le temps nécessaire pour bien optimiser.



brazomyna
Le 20/06/2015 à 10h 53







HarmattanBlow a écrit :



Ce n’est PAS un bytecode pour Javascript. C’est un bitcode du niveau assembleur





&nbsp;

Ok, donc si on parle d’un nouveau langage qu’on compile ensuite, je comprends mieux ; mais l’article laissait justement penser que c’était censé permettre de réutiliser toutes composantes de l’ECMA Script actuel. D’où mon incompréhension quant aux perfs envisagées ailleurs qu’au moment du parsing initial.

&nbsp;

&nbsp;



brazomyna
Le 20/06/2015 à 10h 56







HarmattanBlow a écrit :



Ce n’est pas possible pour une compilation statique, même en JIT : si ta méthode “abc” appelle la fonction nommée “def”, il faut que tu localises “def” avant de compiler “abc”. Tu dois donc tout parser dès le départ.





Je parlais du fonctionnement actuel. Par exemple tu as une énorme appli Angular composée de 200 controlleurs avec 10Mo de code source en tout, le browser charge pas la totalité des controlleurs, seuls ceux dont il a besoin, au fur et à mesure.

Quant au statique + résolution de dépendances tierces, on ne fait que retomber dans le principe des libs dynamiques (DLL, SO, …): tu as effectivement besoin d’un prototype, pas forcément du contenu d’une foncion en entier.

&nbsp;

&nbsp;



Firefly' Abonné
Le 20/06/2015 à 11h 04







HarmattanBlow a écrit :



a) C’est un bitcode, pas un bytecode : les instructions équivalent à un assembleur générique là où dans le bytecode de Java & co les instructions sont de haut niveau, décrivant directement des appels de fonction et se référant à une structure de types.






 "Les développeurs Java et .NET s’écrient : « Ah ! »"


&nbsp;&nbsp;“«&nbsp;WebAssembly&nbsp;»[..] doit fournir en fait un&nbsp;bytecode&nbsp;aux navigateurs”&nbsp;



J’allais dire que j’avais &nbsp;été induit en erreur par la news, mais en pratique, c’est pas un bitcode ( pas executable directement, puisqu’il doit être traduit en code machine spécifique à la platforme, aussi simple cette conversion soit elle ), mais bien un code intermédiaire ( bytecode ), même si déjà optimisé et déjà low lvl.&nbsp;

&nbsp;

On peu débattre sur dans quelle catégorie ça rentre mais je suis pas sur qu’on arrive à se convaincre l’un l’autre :)

&nbsp;

&nbsp;edit: foirage des retour à la ligne



sr17
Le 20/06/2015 à 12h 27







HarmattanBlow a écrit :



…

Les performances théoriques seront maximales, ni plus ni moins : un programme écrit en C++ pourra s’exécuter dans la navigateur a la même vitesse que sur le bureau.







Non



Car les implémentations seront vraisemblablement “bound checked”.



Donc les performances d’un programme en C++ fonctionnant sous ce système seront plutôt comparables à celui d’un programme écrit en java.






Uther Abonné
Le 20/06/2015 à 12h 34

C’est pas encore garanti : si c’est sandboxé, on peut se permettre d’autoriser les bound check sans compromettre&nbsp; le navigateur.


HarmattanBlow
Le 20/06/2015 à 12h 36







brazomyna a écrit :



Ok, donc si on parle d’un nouveau langage qu’on compile ensuite, je comprends mieux ; mais l’article laissait justement penser que c’était censé permettre de réutiliser toutes composantes de l’ECMA Script actuel.





Ils proposeront bien sûr des instructions pour que le code natif puisse interagir avec les objets JS, notamment parce que les API du navigateur continueront à fournir des objets JS et parce qu’il faudra pouvoir dialoguer avec le code JS existant. Mais comme je le disais ce ne sera qu’accessoire, via par exemple des instructions exigeant une référence JS dans un registre et l’adresse de la chaîne d’un nom d’un membre dans un autre registre.



Mais encore une fois ce n’est pas le coeur du projet et les instructions de base seront quant à elles d’aussi bas niveau que que l’asm.







brazomyna a écrit :



Je parlais du fonctionnement actuel. Par exemple tu as une énorme appli Angular composée de 200 controlleurs avec 10Mo de code source en tout, le browser charge pas la totalité des controlleurs, seuls ceux dont il a besoin, au fur et à mesure.





Ok mais ce sont des chargements effectués à la volée par des bibliothèques modulaires, pas par le compilateur.



C’est très bien pour les bibliothèques modulaires dont une partie seulement des fonctionnalités sont utilisées par tel ou tel site. Mais ce n’est possible pour une application native compilée en un gros paquet de 100Mo d’asm.js et qui nécessite que tout ait été parsé et compilé avant de démarrer.

 





Firefly’ a écrit :



“Les développeurs Java et .NET s’écrient : « Ah ! »”

  ”« WebAssembly »[..] doit fournir en fait un bytecode aux navigateurs” 



J’allais dire que j’avais  été induit en erreur par la news, mais en pratique, c’est pas un bitcode ( pas executable directement, puisqu’il doit être traduit en code machine spécifique à la platforme, aussi simple cette conversion soit elle ), mais bien un code intermédiaire ( bytecode ), même si déjà optimisé et déjà low lvl.





Laissons tomber la distinction vaseuse “bitcode” / “bytecode” pour laquelle tout le monde n’est pas d’accord sur le sens.



Ce qui importe c’est que ces instructions sont bel et bien du niveau de l’assembleur. L’assembleur d’un processeur fictif mais permettant une traduction parfaite vers les instructions du processeur cible.









sr17 a écrit :



Non



Car les implémentations seront vraisemblablement “bound checked”.





Non elles ne le seront pas : chaque page s’exécute dans un processus distinct sans la permission d’accéder aux API du système ou à la mémoire des autres processus et c’est la seule sécurité nécessaire. Au sein de ce processus le code peut faire tout ce qu’il veut.



Donc les seuls vérifications aux frontières seront celles qui existent pour n’importe quel code en espace utilisateur : la table de mémoire virtuelle du processus, consultée par le CPU à chaque lecture.



Le seul surcoût sera le fait de devoir passer par les API du navigateur plutôt que par celles du système.



On parle de modèle “double sandbox” : une première sandbox constituée du processus isolé (isolation mémoire, permissions du système), la seconde sandbox en ce que les seules API externes autorisées sont celles du navigateur.



Nikodym
Le 20/06/2015 à 13h 18







HarmattanBlow a écrit :



Ce n’est pas la même chose, OCaml a un typage statique, inféré à la compilation (voir Hindley-Milner).



En particulier tu ne peux pas créer une chaîne de caractères à l’exécution et déclarer un membre avec cette chaîne à l’exécution. SI c’était le cas, alors puisque le problème de l’arrêt rendrait impossible de connaître cette chaîne sans exécuter le programme, il serait donc impossible de générer des types à la compilation et il faudrait se résoudre à utiliser des dictionnaires clé-valeur lents comme dans les langages dynamiques.



De la même façon si tu indexes un membre via une chaîne inconnue à la compilation, alors il faut passer par un dictionnaire.



Le seul cas où un compilateur JIT pour un langage dynamique peut vraiment optimiser, c’est lorsque que le type est connu avec certitude via une analyse statique superficielle, et que le type en question n’est utilisé que de façon statique (tous les membres sont accédés et déclarés via des littéraux connus à la compilation).





Merci je sais ce que c’est <img data-src=" />

Il ne faut pas sortir le problème d’arrêt à toutes les sauces hein !

On peut toujours dans le cadre particulier écrire un algorithme déterminant la terminaison d’un programme, l’ensemble des programmes sur lesquels cette détermination échoue étant non pertinent en utilisation réelle.



Je répondais de manière générale à brazo sur l’inférence de type justement.

Moyennant un certain coût, on peut trouver les types des structures de données fréquemment utilisées, voire tous les types, quitte à exécuter le programme.



Uther Abonné
Le 20/06/2015 à 13h 48







HarmattanBlow a écrit :



Le seul surcoût sera le fait de devoir passer par les API du navigateur plutôt que par celles du système.



A terme, il n’y aura pas forcément de surcoût à ce niveau.

&nbsp;

En effet, même si JavaScript, actuellement le seul à vraiment utiliser les API définies par le W3C est dynamiquement typé,&nbsp; les API définies par le W3C sont fortement typées donc théoriquement utilisable de manière optimale par wasm.



Firefly' Abonné
Le 20/06/2015 à 14h 48







HarmattanBlow a écrit :



Laissons tomber la distinction vaseuse “bitcode” / “bytecode” pour laquelle tout le monde n’est pas d’accord sur le sens.



Ce qui importe c’est que ces instructions sont bel et bien du niveau de l’assembleur. L’assembleur d’un processeur fictif mais permettant une traduction parfaite vers les instructions du processeur cible.





&nbsp;Exactement, là dessus, y as pas de doute ^^



Tepec
Le 20/06/2015 à 15h 06

1° tu peux avoir une application avec un GUI tout à fait agréable à l’utilisation, et pourtant qui est une horreur en code, donc je vois pas trop le rapport avec ce que je disais ;

2° regarde l’exemple que tu donnes (MS Azure), et dis-moi qu’il concerne davantage que 0,1% du web.



Je ne dis pas que 100% du web est codé avec les pieds … Seulement, disons, 99,5% <img data-src=" /> Et encore une fois, je parle de la conception au niveau technique, pas au niveau fonctionnelle ou ergonomique.


HarmattanBlow
Le 20/06/2015 à 15h 13







Nikodym a écrit :



On peut toujours dans le cadre particulier écrire un algorithme déterminant la terminaison d’un programme, l’ensemble des programmes sur lesquels cette détermination échoue étant non pertinent en utilisation réelle.





Le problème de l’arrêt est mentionné non pas en tant que tel mais comme représentant de l’indécidablité de certains traits d’un programme. En l’occurrence, bien souvent le seul moyen de connaître la chaîne qui sera fournie par un programme est d’exécuter le programme. C’est le cas très concret de la plupart des programmes utilisant un typage dynamique.





Moyennant un certain coût, on peut trouver les types des structures de données fréquemment utilisées, voire tous les types, quitte à exécuter le programme.



Soit un programme énumérant tous les nombres jusqu’à l’infini et stockant / consommant à chaque fois un nombre nommé “membreN” où N est le nombre en question. Tu vas générer à la volée un type à chaque itération ? Ce serait absurde.



Or le cas est très concret : rappelle-toi qu’en JS on n’a pas de table de hachage dédiée parce que n’importe quel objet remplit ce rôle. Donc avec ta technique tu aurais bel et bien des objets avec des millions de membres. Pire : tu aurais créé un type avec un membre, puis un type avec deux membres, puis avec trois, puis…



Non, dès lors qu’un type utilise des membres dynamiques, la seule approche raisonnable est d’utiliser un type dynamique. Et puisque l’analyse statique menée est rudimentaire et faillible (courte durée allouée), cela s’étend à l’ensemble des types qui sont susceptibles de se voir assigner un membre dont le nom est formé à l’exécution. Et ils sont plus nombreux que tu ne l’imagines.







Uther a écrit :



A terme, il n’y aura pas forcément de surcoût à ce niveau.

 

En effet, même si JavaScript, actuellement le seul à vraiment utiliser les API définies par le W3C est dynamiquement typé,  les API définies par le W3C sont fortement typées donc théoriquement utilisable de manière optimale par wasm.





Mais le type de ces objets descend d’un type général JSObject qui fournit notamment une table de hachage pour stocker toutes les paires clés/valeurs assignées à cet objet. Si je ne m’abuse n’importe qui peut en effet décider d’ajouter des membres à un div, par exemple pour l’étiqueter.



Et de la même façon ces objets sont gérés par un ramasse-miettes, ce qui signifie qu’ils emportent un en-tête de plusieurs octets.



Et enfin tout objet JS peut/pourra informer ses abonnés de tout changement de son état via les nouvelles API réactives. Ce qui impose toute une plomberie chaque fois qu’une propriété est assignée. ET l’objet passé pour cela contient une chaîne identifiant le champ qui a changé. Toutes ces API sont dynamiques par essence.



PS : je ne suis pas un grand connaisseur du JS, il se peut donc que j’ai tort sur quelques uns de ces derniers points.



Uther Abonné
Le 20/06/2015 à 15h 14

Et pourtant ce n’est pas tout à fait ça.

&nbsp;

En fait le wasm sera assez bas niveau (typage,…) et sans contraintes lourde (GC,…) pour permettre d’avoir des performance proches du natif tout en étant le plus neutre possible face aux différents matériels.

Mais techniquement, contrairement à la JVM ou au CLR, il ne se présentera&nbsp; pas,&nbsp; par une suite d’instruction d’un processeur fictif , mais plutôt comme une sorte d’AST : la structure intermédiaire en forme d’arbre sur laquelle travaille le compilateur une fois qu’il a fait l’analyse syntaxique du code.

&nbsp;

Selon ce qu’a annoncé l’équipe travaillant sur wasm, ça permettrait à la fois de gagner en taille et en vitesse de traitement.


maestro321
Le 20/06/2015 à 16h 28

Vivement que les langages clients du web supplantent les applications proprio.



Le web est compatible avec n’importe quel device tant qu’il est capable d’afficher une page web correctement.



Il reste encore du boulot au web pour unifier les usages mobile/bureau mais tout les outils sont là, et surtout ils ont le gros avantage de ne pas dépendre (dans le meilleur des mondes) de la plateforme d’exécution ou d’un quelconque market à la con…


sr17
Le 20/06/2015 à 21h 17







HarmattanBlow a écrit :



…

Non elles ne le seront pas : chaque page s’exécute dans un processus distinct sans la permission d’accéder aux API du système ou à la mémoire des autres processus et c’est la seule sécurité nécessaire. Au sein de ce processus le code peut faire tout ce qu’il veut.



Donc les seuls vérifications aux frontières seront celles qui existent pour n’importe quel code en espace utilisateur : la table de mémoire virtuelle du processus, consultée par le CPU à chaque lecture.



Le seul surcoût sera le fait de devoir passer par les API du navigateur plutôt que par celles du système.



On parle de modèle “double sandbox” : une première sandbox constituée du processus isolé (isolation mémoire, permissions du système), la seconde sandbox en ce que les seules API externes autorisées sont celles du navigateur.







Pour ma part, je trouverais excellent de le voir implémenté ainsi.



Mais le modèle théorique est une chose, la pratique en est une autre.



D’abord, les sandbox matérielles sont t’elles suffisamment inviolables sur tous les matériels actuels ?



Après des années de sandboxing par bound checking, je pense sincèrement que plus personne n’en sait rien. (Voir à ce sujet les propos inquiétants de Theo de Raadt, même s’ils datent un peu).



Et l’on pourra interroger tous les experts qu’on voudra, la seule vérité tangible sera l’épreuve des hackers… une fois le système sorti.



Cela dit, qu’on ne s’y méprenne pas, c’est la voie du futur, la seule dans laquelle je crois.



La vraie question, c’est de savoir s’ils oseront vraiment se passer de bound checking logiciel à court terme…



En tout cas, si quelqu’un le fait, je lui tire mon chapeau.



HarmattanBlow
Le 21/06/2015 à 05h 41







sr17 a écrit :



Mais le modèle théorique est une chose, la pratique en est une autre.





De toute façon ce modèle est en pratique celui qui assure aujourd’hui la sécurité de tous les systèmes d’exploitation, du mobile au serveur.



Si ce modèle n’est pas fiable alors n’importe qui peut lancer un calcul dans le nuage d’Amazon pour prendre possession des sites partageant ces machines, ou créer une appli mobile pour prendre le contrôle des smartphones.



Alors est-ce que ça ne pose absolument aucun problème ? Sans doute pas, j’imagine que le modèle JS + double sandbox reste mieux sécurisable. Mais ce sur quoi ils s’appuient est de toute façon la base critique de toute la sécurité informatique.







Uther a écrit :



En fait le wasm sera assez bas niveau (typage,…) et sans contraintes lourde (GC,…) pour permettre d’avoir des performance proches du natif tout en étant le plus neutre possible face aux différents matériels.

Mais techniquement, contrairement à la JVM ou au CLR, il ne se présentera  pas,  par une suite d’instruction d’un processeur fictif , mais plutôt comme une sorte d’AST : la structure intermédiaire en forme d’arbre sur laquelle travaille le compilateur une fois qu’il a fait l’analyse syntaxique du code.





Au temps pour moi, leurs instructions sont effectivement basées sur une pile et non sur des registres fictifs, et elles sont d’un niveau plus proche du C que de l’assembleur (notamment en ce qu’ils une pile d’exécution et retirent son contrôle direct). source



Cela dit les bytecodes Java et C# suivent le même principe : des instructions basées sur une pile forment un arbre.



En revanche contrairement à ces dernières les seules types ayant cours dans le webassembly sont les primitives i32, i64, f32, f64, et le tas (heap) n’est pas typé.

 



Selon ce qu’a annoncé l’équipe travaillant sur wasm, ça permettrait à la fois de gagner en taille et en vitesse de traitement.



Au prix malheureusement du support de langages plus exotiques. Mais leur choix se défend pour les raisons que tu mentionnes.



Uther Abonné
Le 21/06/2015 à 13h 06







HarmattanBlow a écrit :



Au prix malheureusement du support de langages plus exotiques. Mais leur choix se défend pour les raisons que tu mentionnes.





Ca n’a rien d’impossible, ca sera au pire plus complexe. A priori il y aura un backend LLVM pour wasm donc quasiment tous les langages devraient pouvoir être supportés.



OlivierJ Abonné
Le 21/06/2015 à 13h 23







Firefly’ a écrit :



&nbsp;

&nbsp;Tu peu déjà pas voir le code des applications que tu utilise, et le js est souvent obfusqué ..









maxxyme a écrit :



C’est “offusqué” le terme il me semble… ;)









WereWindle a écrit :



avec un b



Le code est un sujet sensible et il râle souvent mais il ne s’offusque pas d’un rien <img data-src=" /> <img data-src=" />









zempa a écrit :



&nbsp;L’obfuscation n’est pas de la compilation.

C’est juste de la simplification sémantique pour réduire le poids des fichiers : réduction des noms de variable en une seule lettre, tout le code placé sur une seule ligne, etc







ErGo_404 a écrit :



Obfusqué :)





<img data-src=" />

En français, to obfuscate peut se traduire par obscurcir, opacifier, assombrir ou embrouiller.

Perso je dirais que le code a été obscurci (le contraire étant un code clair).



OlivierJ Abonné
Le 21/06/2015 à 13h 26







Dude76 a écrit :



Non, l’obfuscation ce n’est pas la “simplification” des noms des variables et autres réductions et optimisations, mais c’est tenter de rendre son code trèèès difficilement compréhensible, même une fois réfléchi; ça en passe par le renommages des variables, mais pas pour des raisons de perdfs :)









RaoulC a écrit :



Oui enfn l’obfu ca peut aller très loin. Le nom des variables c’est peanuts.

&nbsp;Certains outils exploitent meme les failles des Reflector-Like…&nbsp;





cf mon commentaire 82 ci-dessus sur la traduction de “obfuscation” (obscurcissement, on pourrait aussi parler de brouillage).



marba
Le 21/06/2015 à 14h 37







bobdu87 a écrit :



Jusqu’a ce que ça devienne la norme… et là ça sera une autre histoire… y a plus qu’a signé le code pour des histoire de sécurité et il ne sera même pas possible de modifier le code avec un addblock nouvelle génération… et hop voilà le web 3.0…





Cette nouvelle m’inquiète pour les mêmes raisons. Aujourd’hui il est possible d’obscurcir le code js, cependant une analyse du comportement et un dé-obscurcissement est toujours possible. Avec le bytecodes c’est casser un peu ce qui à fait que le web est le web. L’ouverture, un langage universel, chacun peu faire du web, héberger son site, tout le monde au meme niveau.

&nbsp;



&nbsp;Web 3.0 full DRM réservé aux technocrates et aux grosses entreprises.

&nbsp;



Pourquoi ne pas parler des alternatives au JS ?

&nbsp;



http://www.brython.info/ &nbsp; je préfère ce genre d’alternative



HarmattanBlow
Le 21/06/2015 à 16h 19







Uther a écrit :



Ca n’a rien d’impossible, ca sera au pire plus complexe.





Ce serait surtout plus lent, donc je considère que ça ne sera pas viable.



Ça reste marginal cela dit : leur modèle conviendra à plus de 99% des applications existantes, écrites dans des langages avec pile d’appels et sans fibres ou autres fioritures.







marba a écrit :



Cette nouvelle m’inquiète pour les mêmes raisons. Aujourd’hui il est possible d’obscurcir le code js, cependant une analyse du comportement et un dé-obscurcissement est toujours possible. Avec le bytecodes c’est casser un peu ce qui à fait que le web est le web. L’ouverture, un langage universel, chacun peu faire du web, héberger son site, tout le monde au meme niveau.





Rien ne changera côté hébergement et le gain en performances et fonctionnalités vaut très largement le sacrifice d’une plus grande difficulté à désobscurcir.



On ne peut pas tout avoir et ils font inconstestablement le bon choix. Il est temps que le web offre enfin des performances natives et que le navigateur devienne un OS.

 



Pourquoi ne pas parler des alternatives au JS ?

 http://www.brython.info/   je préfère ce genre d’alternative



Le but même du projet est que chacun puisse utiliser le langage de son choix mais sans être limité par les possibilités de JS, que ce soit en termes de performances et de fonctionnalités.



La moitié des gros sites sont déjà écrits dans autre chose que du JS, puis compilés en JS sur serveur (ou plus rarement à l’exécution comme dans ton exemple). Mais JS limite cette approche.



Ta suggestion était tout simplement à côté de la plaque : ce n’est pas un nouveau langage, c’est un outil pour te rendre libre d’utiliser le langage de ton choix.



zempa Abonné
Le 21/06/2015 à 16h 47







OlivierJ a écrit :



<img data-src=" />

En français, to obfuscate peut se traduire par obscurcir, opacifier, assombrir ou embrouiller.

Perso je dirais que le code a été obscurci (le contraire étant un code clair).





https://fr.wikipedia.org/wiki/Obfuscation



Clapitti
Le 21/06/2015 à 16h 58







HarmattanBlow a écrit :



On ne peut pas tout avoir et ils font inconstestablement le bon choix. Il est temps que le web offre enfin des performances natives et que le navigateur devienne un OS.

&nbsp;





Et on comprend pourquoi Google est dans la partie avec son Chrome OS, ils avaient vraiment une vision&nbsp;très&nbsp;très&nbsp;long terme&nbsp;avec leur projet.



OlivierJ Abonné
Le 21/06/2015 à 17h 04







zempa a écrit :



https://fr.wikipedia.org/wiki/Obfuscation






C'est un anglicisme, ça ne figure pas dans le dictionnaire (en tous cas pas la plupart). L'informatique est pleine d'anglicisme. J'aime parler anglais correctement, tout comme le français, sans mélanger les 2.


&nbsp;

&nbsp;





marba a écrit :



Cette nouvelle m’inquiète pour les mêmes raisons. Aujourd’hui il est possible d’obscurcir le code js, cependant une analyse du comportement et un dé-obscurcissement est toujours possible. Avec le bytecodes c’est casser un peu ce qui à fait que le web est le web. L’ouverture, un langage universel, chacun peu faire du web, héberger son site, tout le monde au meme niveau.





<img data-src=" />



Uther Abonné
Le 21/06/2015 à 17h 35







marba a écrit :



Cette nouvelle m’inquiète pour les mêmes raisons. Aujourd’hui il est possible d’obscurcir le code js, cependant une analyse du comportement et un dé-obscurcissement est toujours possible. Avec le bytecodes c’est casser un peu ce qui à fait que le web est le web. L’ouverture, un langage universel, chacun peu faire du web, héberger son site, tout le monde au meme niveau.

&nbsp;



C’est le contraire. Un “obscurscurcissement” efficace peut tout à fait employer des méthodes non bijectives qui font que le résultat ne sera pas réversible alors que le wasm est conçu pour avoir une représentation textuelle lisible.



Il faut voir que le wasm à pour but de remplacer les codes Javascript lourds qui ne sont de toute façon pas l’apanage du&nbsp; débutant. Il ne vise pas a remplacer totalement Javascript. Il&nbsp; sera tout aussi universel, standardisé. Et rien n’empèche d’avoir des outils accessibles aux débutants qui compilent vers du wasm.

&nbsp;



HarmattanBlow
Le 22/06/2015 à 05h 32







Uther a écrit :



C’est le contraire. Un “obscurscurcissement” efficace peut tout à fait employer des méthodes non bijectives qui font que le résultat ne sera pas réversible alors que le wasm est conçu pour avoir une représentation textuelle lisible.





Mais la représentation textuelle contient beaucoup moins d’informations que la source. En particulier elle ne contient pas les informations de type : maVarDeTypeBidule.monMembreDeTypeTruc devient “charger le contenu de l’adresse maVarSansTypeSpécifié + 12 en tant que i64”









zogG a écrit :



Et on comprend pourquoi Google est dans la partie avec son Chrome OS, ils avaient vraiment une vision très très long terme avec leur projet.





Ils n’étaient pas les seuls, loin s’en faut. Et il reste encore du travail.



white_tentacle Abonné
Le 22/06/2015 à 06h 18

Ils veulent faire faire du C++ aux développeurs web ??? Enfermez-les, ils sont devenus fous !!! <img data-src=" />


Kulvar
Le 22/06/2015 à 06h 38

Vu qu’adBlock & cie bloquent les REQUÊTES vers les pubs, tu t’en balance complètement du JS/WA…


HarmattanBlow
Le 22/06/2015 à 07h 06







js2082 a écrit :



Tu likeras moins le jour où tu t’apercevras que ce nouveau langage est aussi un afficheur de pub intégré que tu ne pourras pas contourner malgré les adblocks et consorts.





C’est faux : cette techno ne change strictement rien pour la publicité par rapport à JS.







Kulvar a écrit :



Vu qu’adBlock & cie bloquent les REQUÊTES vers les pubs, tu t’en balance complètement du JS/WA…





C’est effectivement le cas sur Firefox.



Mais Chrome, lui, n’interdit que les modifications de l’affichage. ^^

Tu penses bien que Google n’allait pas t’autoriser à échapper à leur surveillance.



Vekin
Le 22/06/2015 à 08h 13

Oh purée, c’est possible de savoir de quel binaire il s’agit ?


Uther Abonné
Le 22/06/2015 à 09h 50







HarmattanBlow a écrit :



Mais la représentation textuelle contient beaucoup moins d’informations que la source. En particulier elle ne contient pas les informations de type : maVarDeTypeBidule.monMembreDeTypeTruc devient “charger le contenu de l’adresse maVarSansTypeSpécifié + 12 en tant que i64”



Certes, il y aura de la perte d’infos, ce que je voulais dire c’est que ça sera toujours mieux que du javascript brouillé.

&nbsp;



white_tentacle a écrit :



Ils veulent faire faire du C++ aux développeurs web ??? Enfermez-les, ils sont devenus fous !!! <img data-src=" />



Le C++ c’est juste pour l’expérimentation. Je suppose qu’il se sont dit que si il on un bytecode assez bas niveau pour traiter efficacement le C/C++, ça devrait fonctionner aussi avec la plupart des autres langages.

&nbsp;Je pense qu’à terme les développeur web auront des outils de type flash qui leur génèreront les wasm qu’ils ont besoin



Dr.Wily
Le 22/06/2015 à 10h 25







otto a écrit :



C’est très bien pour les perfs… par contre plus moyen de regarder le code source…







+1, le web c’est ouvert… des page avec des “exe” bof quoi…



HarmattanBlow
Le 22/06/2015 à 10h 39







Uther a écrit :



Certes, il y aura de la perte d’infos, ce que je voulais dire c’est que ça sera toujours mieux que du javascript brouillé.





Je ne connais pas assez les techniques d’obscurcissement mais celles que j’ai vues préservaient les informations de types, se contentant de renommer ceux-ci. Il est ainsi possible de savoir que deux variables sont deux instances du même type ou de rechercher toutes les instances de ce type. Et a priori je ne pense pas qu’il soit possible de dissimuler cela en JS sans heurter les performances.



Donc je maintiens que du JS brouillé reste un peu mieux de c côté. Mais encore une fois je ne pense pas que ce soit important : voir le code source des pages que je visite est bien moins intéressant que d’avoir un web rapide où l’on peut efficacement utiliser d’autres langages que le JS.







Je pense qu’à terme les développeur web auront des outils de type flash qui leur génèreront les wasm qu’ils ont besoin



Chacun utilisera simplement le langage correspondant à son besoin, comme aujourd’hui en-dehors du web.



Certains voudront de grosses performances (C/C++/Rust), d’autres voudront des langages pour de très gros projets et de grandes équipes avec du typage statique (Java/C#/etc), d’autres enfin adopteront des langages dynamiques adaptés à de petits projets (Python, Ruby, JS). Et beaucoup choisiront simplement ce que leur équipe connaît.



brazomyna
Le 22/06/2015 à 10h 47







HarmattanBlow a écrit :



Je ne connais pas assez les techniques de dissimulation mais celles que j’ai vues préservaient les informations de types, se contentant de renommer ceux-ci. Il est ainsi possible de savoir que deux variables sont deux instances du même type ou de rechercher toutes les instances de ce type. Et a priori je ne pense pas qu’il soit possible de dissimuler cela en JS sans heurter les performances.






&nbsp;Il n'y a pas de notion de type d'objet (ou de classes) en JS.  Les seuls types existant sont: String, Number, Boolean, Object, Array, Null et Undefined.    







Plus globalement, le principe de l'obfuscation, ce n'est pas de rendre le reverse  engineering impossible (ceci est utopique), le principe c'est de mettre  suffisamment de bâtons dans les roues pour que le reverse engineering  soit suffisamment couteux en ressource pour que ça n'en vaille pas la  peine.      


&nbsp;      


A ce titre, faire du reverse engineering sur un code obfusqué, même avec les infos de type qui perdurent (et donc juste les nomages qui dégagent), reste suffisamment consommateur en temps pour que ça ne soit plus intéressant de tenter l'opération inverse.


HarmattanBlow
Le 22/06/2015 à 11h 04







brazomyna a écrit :



Il n’y a pas de notion de type d’objet (ou de classes) en JS. Les seuls types existant sont: String, Number, Boolean, Object, Array, Null et Undefined.





Le langage lui-même ne permet pas de déclarer des types mais en pratique le programmeur en définit quand même de fait, dans son esprit et dans son code. On peut même créer une taxonomie de types dans les objets du quotidien (les types sont un concept mathématique avant d’être un concept informatique).



Ainsi on peut considérer que tous les objets créés par la fonction bidule forment un type, et c’est presque toujours pertinent.



Dès lors en partant des fonctions globales tu vas pouvoir deviner les types créés par elles, puis les types créés par leurs membres, etc. Jusqu’à pouvoir typer chaque objet (indiquer au programmeur qu’il a été produit par la fonction XYZ).



Rien de tel avec un langage du niveau assembleur. Tu pourrais être tenté d’identifier des constructeurs mais ceux-ci sotn multiples, parfois “inlinés”, et parfois non appelés car la mise à zéro suffisait. Et plus simplement il est difficile d’identifier un appel comme étant un constructeur (allocation sur la pile en particulier).







A ce titre, faire du reverse engineering sur un code obfusqué, même avec les infos de type qui perdurent (et donc juste les nomages qui dégagent), reste suffisamment consommateur en temps pour que ça ne soit plus intéressant de tenter l’opération inverse.



Je suis d’accord.



white_tentacle Abonné
Le 22/06/2015 à 12h 16







HarmattanBlow a écrit :



Mais encore une fois je ne pense pas que ce soit important : voir le code source des pages que je visite est bien moins intéressant que d’avoir un web rapide où l’on peut efficacement utiliser d’autres langages que le JS.





Effectivement. Ça l’était à la fin des années 90, quand le code était simple, que les gens bricolaient, pour voir « et là, comment il a fait son machin », mais maintenant, ce n’est plus pertinent.

&nbsp;



&nbsp;



Uther a écrit :



Le C++ c’est juste pour l’expérimentation. Je suppose qu’il se sont dit que si il on un bytecode assez bas niveau pour traiter efficacement le C/C++, ça devrait fonctionner aussi avec la plupart des autres langages.

&nbsp;Je pense qu’à terme les développeur web auront des outils de type flash qui leur génèreront les wasm qu’ils ont besoin





C’est aussi ce que je pense. Mais je suis curieux sur les raisons du choix de C++ : un langage typé statiquement, sans GC, bref, à des années lumière de ce que connaissent les dev web. Donc pas vraiment le candidat idéal au vu de la cible finale (à moins que le but ne soit à terme d’amener ces développements vers des langages statiquement typés)



HarmattanBlow
Le 22/06/2015 à 14h 14







white_tentacle a écrit :



Mais je suis curieux sur les raisons du choix de C++ : un langage typé statiquement, sans GC, bref, à des années lumière de ce que connaissent les dev web. Donc pas vraiment le candidat idéal au vu de la cible finale (à moins que le but ne soit à terme d’amener ces développements vers des langages statiquement typés)





Ils ne poussent personne à opter pour le C++. Ils veillent simplement à ce que leur jeu d’instructions soit suffisamment riche pour supporter toutes les fonctionnalités du C++ car si c’est le cas il peut supporter efficacement 99% des langages de programmation.



sr17
Le 22/06/2015 à 14h 21







HarmattanBlow a écrit :



De toute façon ce modèle est en pratique celui qui assure aujourd’hui la sécurité de tous les systèmes d’exploitation, du mobile au serveur.







Pas réellement.



Aujourd’hui, l’essentiel de la sécurité informatique est focalisé sur le fait d’empêcher l’exécution directe de code d’origine inconnue.





Si ce modèle n’est pas fiable alors n’importe qui peut lancer un calcul dans le nuage d’Amazon pour prendre possession des sites partageant ces machines,





Les hébergeurs ne sont pas fous, la sécurité ne repose pas uniquement sur le matériel ou le logiciel, mais également beaucoup sur le contractuel : pour louer un espace d’hébergement, il faut s’identifier formellement.



Avec des équipes de sécurité qui veillent au grain, ce n’est probablement pas le meilleur plan pour des hackers.





ou créer une appli mobile pour prendre le contrôle des smartphones.





Et bien cela existe…



La encore, on peut souligner que la sécurité des smartphone repose beaucoup sur l’identification des éditeurs et la responsabilité pénale plus que sur la technique proprement dite.





Alors est-ce que ça ne pose absolument aucun problème ? Sans doute pas, j’imagine que le modèle JS + double sandbox reste mieux sécurisable. Mais ce sur quoi ils s’appuient est de toute façon la base critique de toute la sécurité informatique.





Le problème, c’est qu’après des années a se reposer sur des modèles de code managé, si on change brusquement de modèle, c’est la qu’on peut avoir des surprises.



Le problème avec le matériel, c’est que si on découvre ne fut ce qu’une faille, ça peut affecter des millions de machine. Et contrairement au logiciel, ce n’est pas toujours possible de les colmater.



Pour des raisons de performances, c’est inéluctable de revenir au matériel. Mais il faudra logiquement du temps.



sr17
Le 22/06/2015 à 14h 26







white_tentacle a écrit :



…

C’est aussi ce que je pense. Mais je suis curieux sur les raisons du choix de C++ : un langage typé statiquement, sans GC, bref, à des années lumière de ce que connaissent les dev web. Donc pas vraiment le candidat idéal au vu de la cible finale (à moins que le but ne soit à terme d’amener ces développements vers des langages statiquement typés)







Non, ce système n’impose en rien C++. Ce n’est pas lié à un langage précis.




Nikodym
Le 22/06/2015 à 18h 29







HarmattanBlow a écrit :



Soit un programme énumérant tous les nombres jusqu’à l’infini et stockant / consommant à chaque fois un nombre nommé “membreN” où N est le nombre en question. Tu vas générer à la volée un type à chaque itération ? Ce serait absurde.





C’est censé servir de démonstration ? Ridicule.



Il y a différentes façons de traiter les problèmes de preuve, et je ne connais pas bien JS pour y répondre spécifiquement.



Bref, on s’écarte du sujet. L’idée sous-jacente est comme tu l’as par ailleurs souligné, n’est pas d’optimiser le JS, mais de fournir une solution plus robuste pour remplacer asmjs et emscripten/llvm.





Define a portable, size- and load-time-efficient binary format to serve as a compilation target which can be compiled to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms, including mobile and IoT.



https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md



MVP

https://github.com/WebAssembly/design/blob/master/MVP.md



brazomyna
Le 22/06/2015 à 18h 41







white_tentacle a écrit :





Le but c’est justement d’être complémentaire: si c’est pour refaire la même chose, l’intérêt est limité. Si c’est pour proposer de nouvelles alternatives, là ça ouvre plus de possibilités.

&nbsp;



RaoulC
Le 24/06/2015 à 16h 24







Vekin a écrit :



Oh purée, c’est possible de savoir de quel binaire il s’agit ?





Oh, un malware quelconque que j’ai jté aux orties :)

&nbsp;Mais depuis j’ai googlé le phénomène, et j’ai vu que c’est une fonctionnalité de ConfuserEx, sucesseur de Confuser…

&nbsp;

https://github.com/yck1509/ConfuserEx/blob/816172adcb1ea2a6c74a964274373987fc2e9…

&nbsp;

&nbsp;