Sommaire
Ceci est une traduction de mon entree de blog recente. Quelques remarques avant de commencer:
- mon biais: je travaille chez Mozilla Corporation sur WebGL.
- desole pour les accents mais QWERTY, j'habite en Amerique, toussa.
- le titre original de mon entree de blog etait trop long pour la limite de longueur de titres. Il ne s'agit pas seulement de "Sandboxing".
- la traduction est parfois un peu libre, un peu differente de l'original
D'autre part, comme ici on est chez les Francais raleurs, je n'ai pas a prendre autant de pincettes que dans mon blog agrege sur Planet Mozilla. Donc soyons clairs, ce texte se veut un coup de gueule. Il y a des soi-disant experts en securite qui pretendent que Firefox est vulnerable parce qu'il lui manque telle ou telle fonctionalite presente chez tel concurrent. Sans vouloir nier l'utilite de ces fonctionalites, j'ai pense qu'il etait temps de remettre les pendules a l'heure: la securite des navigateurs est un sujet trop vaste pour qu'une ou deux techniques en particulier puissent faire une grande difference au total, et ces "experts" et autres journalistes se ridiculisent en repetant, sans distance critique, le marketing d'une entreprise... avec laquelle je ne tiens pas a me brouiller car si je critique son marketing, j'ai souvent a travailler avec ses ingenieurs dans les comites de standards, et ca se passe tres bien.
Au fil de mon blog, j'ai largement devie sur un autre sujet qui me tient a coeur: la securite de WebGL, qui a elle aussi ete victime d'une campagne de denigrement de la part, cette fois-ci, d'un autre concurrent, qui lui n'a vraiment pas fait dans la dentelle alors qu'ils avaient eux-memes une technologie avec les memes "failles".
Sur ce, commencons la traduction de ce blog:
Traduction de l'article: Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" et la "separation des processus"
Je ne connais pas grand chose en matiere de securite. C'est un vaste domaine, qui touche a presque tous les aspects de l'informatique, et je n'y suis confronte qu'occasionnellement, dans le cadre de mon travail sur WebGL.
Mais recemment, j'ai trouve quelques articles parlant de securite des navigateurs (comme celui-ci et celui-la) qui brossent un tableau de la securite des navigateurs qui ne resiste meme pas aux quelques exemples que j'ai personnellement rencontres. En effet, ils tendent a reduire la securite des navigateurs a en gros deux aspects:
- L'execution de code arbitraire
- La fuite d'informations entre differents onglets du navigateurs
Ainsi, ils en viennent a juger de la securite des navigateurs sur la base de seulement quelques fonctionnalites tournant autour de ces aspects, telles que le "sandboxing" et la separation en multiples processus.
Ces aspects de la securite sont certes tres importants et interessants, mais meritaient-ils vraiment d'etre ainsi exacerbes au detriment d'autres aspects?
Dans mon experience limitee, dans le cadre de WebGL, ces aspects se sont effectivement manifestes dans certains bugs qu'on a corriges, comme par exemple certains plantages avec corruption du tas. Nous les avons pris tres au serieux et les avons declares "critiques" parce que, en theories, c'est bien ce genre de bugs qui conduit a de l'execution arbitraire de code. Cependant, en pratique, pour autant que je sache, nous n'avons jamais vus d'exploitation de ces bugs, et pour de bonnes raisons: d'abord, une majorite de ces bugs n'est probablement pas reelement exploitable, a plus forte raison avec l'ASLR et la DEP. Mais surtout, ces bugs ont toujours ete faciles a corriger, donc ils ont simplement ete corriges avant d'avoir pu etre largement exploites.
Donc ce dont je voudrais parler ici, c'est d'autres categories de bugs que j'ai rencontres autour de WebGL, qui n'ont pas ete aussi faciles a corriger.
Exemple 1: fuite d'information entre domaines differents
Il y avait une faille dans la version 1.0.0 de la spec WebGL, que Firefox 4 suivait, qui a conduit a une vulnerabilite a la fuite d'information entre domaines differents. Les details sont donnes sur cette page; disons simplement ici qu'elle permettaient a des scripts vicieux provenant d'un domaine, de lire des images provenant d'autres domaines, ce qui est tres preoccupant; cette vulnerabilite a ete reparee dans Firefox 5, mais ca fendait le coeur car le correctif consistait a interdire l'usage d'images d'autres domaines dans WebGL, ce qui a casse la compatibilite avec des pages Web legitimes. Une solution pour ces pages Web a depuis ete implementee.
Il y a de nombreux exemples de vulnerabilites a la fuite d'information entre differents domaines; elles sont un element-cle du paysage du Web car elles decident souvent de ce qui est faisable et de ce qui ne l'est pas (lisez ceci). Par exemple, elles sont une raison majeure pour laquelle on ne permet pas aux pages Web normales de faire le rendu d'autres pages Web avec WebGL, et elles constituent le defi principal pour les CSS Shaders. En plus de faconner les limites de nouvelles technologies Web, elles rendent aussi trop risque l'usage de certaines optimisations par exemples dans les implementations du Canvas 2D.
Il peut etre utile de souligner le fait que la fuite d'information entre differents domaines n'a a peu pres rien a voir avec la fuite d'information entre differents onglets d'un navigateur, ce qui explique pourquoi la separation en multiples processus est hors-sujet ici. La vulnerabilite mentionnee ci-dessus pouvait etre exploitee avec un unique onglet: en effet, le code de demonstration utilisait un unique canvas; et meme si un jour l'exploitation d'une vulnerabilite demandait deux canvas provenant de deux domaines differents, on pourrait encore le faire dans un unique onglet avec des iframes.
Exemple 2: bugs du navigateur ou des drivers exposant de la memoire video
Nous avons vu (et corrige!) quelques bugs qui permettaient, via WebGL, d'acceder en lecture a des parties aleatoires de la memoire video.
Parfois c'etait de notre faute (comme ici): nous ne programmions pas correctement le systeme graphique pour effacer le contenu de nouvelles surfaces, donc elles conservaient leur contenu provenant d'un usage anterieur de cette zone de memoire.
Parfois c'etait la faute du pilote (comme ici et ici), car bien que nous programmions correctement le systeme graphique, il s'emmelait les pinceaux et vous vous retrouviez avec votre fenetre Terminal peinte dans une scene en 3D. De toute facon, c'est la responsabilite du navigateur de garantir que ces bugs n'affectent pas l'utilisateur du fait de sa navigation. Ce dernier bug a ete resolu en mettant Mac OS 10.5 sur la liste noire pour WebGL, mais l'autre affecte des OS plus recents que ca (quoique pas Linux), donc j'encourage tous les utilisateurs a s'assurer qu'ils utilisent la derniere version stable de leur navigateur, qui contourne le probleme!
Exemple 3: deni de service sur le client
Les vulnerabilites de deni de service sont tres preoccupantes pour les serveurs, car pour des gens mal intentionnes, il existe des motivations a attaquer un serveur ainsi. Dans le cas de clients (comme des navigateurs Web), la motivation d'une attaque par deni de service (DoS) est bien plus faible, voire inexistante dans beaucoup de cas. Nous ne rencontrons pas beaucoup de pages Web qui essayent de DoSer le navigateur, parce tout ce qu'elles aurait a y gagner... c'est qu'on ne les visiterait pas a nouveau.
L'existence de vulnerabilites DoS dans la plate-forme Web a toujours ete une realite, et il n'y a pas trop de solutions pour eviter ca. Par exemple, un script peut allouer beaucoup de memoire, ce qui "denie" aux autres programmes sur votre ordinateur le "service" d'avoir cette memoire a leur disposition. Et si le navigateur decidait de limiter la quantite de memoire qu'un script peut utiliser, ca entrerait en conflit avec des cas d'utilisation legitimes, et il resterait encore bien d'autres vulnerabilites DoS ne faisant pas du tout intervenir de scripts. Exercice amusant: avec un navigateur effectuant le rendu sur la carte graphique (ce qui sera bientot tous les navigateurs), essayez de saturer la memoire video avec une page web contenant beaucoup de grandes images.
WebGL, comme toutes les APIs 3D depuis qu'OpenGL 1.1 a introduit en 1997 la notion de "vertex arrays", a une vulnerabilite DoS bien specifique: il permet de monopoliser la carte graphique (GPU), ce qui est particulierement casse-pieds parce que les GPUs actuels sont non-preemptibles. Les OS modernes (oui, ca inclut Linux avec certains pilotes, je crois Mesa/Intel et NVIDIA au moins, mais on est en discussion avec des devs de pilotes au sujet de certains bugs) ont une fonctionnalite qui reinitialise automatiquement le GPU s'il est gele depuis environ 2 secondes. Malheureusement, certains pilotes repondend encore assez mal a ca (sous Windows on a encore de beaux plantages bleus). C'est vraiment triste, mais on n'a pas vu beaucoup d'utilisateurs souffrir de ca dans le monde reel, et au moins ca a mene a de bonnes conversations avec les fabricants de GPUs et les choses sont en bonne voie, meme si ca prend du temps.
Conclusion
Voici les trois pires sortes de vulnerabilites liees a WebGL que j'ai personnellement rencontrees. Les techniques de securite que certains considerent comme l'Alpha et l'Omega de la securite des navigateurs, ne peuvent rien contre ces vulnerabilites. Je ne veux pas dire que ces techniques ("sandboxing", separation en multiples processus...) sont inutiles en general: elles sont extremement utiles, mais elles sont inutiles pour les bugs securite qui ont ete les plus inquietants dans ma propre et humble experience. Ceci veut au moins dire que la securite des navigateurs ne se resume pas a ces techniques, comme ces articles de securite que j'ai mentionnes au debut voudraient le faire croire.
# super article
Posté par ZeroHeure (site web personnel) . Évalué à 8.
Wow!
super article, merci de l'avoir partagé avec nous.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Et ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -9.
Et le bépo, c'est interdit par le FBI ?
L'US International aussi ?
Comment écris-tu des mots, parfaitement anglais, comme « aide-mémoire, » « pâté, » ou « attaché » ?
Mauvaise excuse, changer layout.
[^] # Re: Et ?
Posté par esdeem . Évalué à 2.
Que agressivité ! Et pour peu de choses… Tout le monde, à tout moment ne pense pas forcément à la meilleure solution à son problème.
Son journal a-t-il au moins, à tes yeux, un minimum d'intérêt, où te contentes-tu de lire les journaux pour faire des remarques désagréables ?
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Et ?
Posté par ahuillet (site web personnel) . Évalué à 9.
Le journal a de l'intérêt mais il est écrit dans une langue curieuse que j'ai beaucoup de mal à lire. Donc je lis la version originale.
Les accents ne sont pas une composante facultative de l'orthographe du français. On peut comprendre qu'un texte de quelques lignes omette les accents pour des raisons de confort du rédacteur, mais on ne peut pas infliger au lecteur un texte aussi volumineux sans accent.
C'est exactement le même débat pour le "langage SMS" : "oui, mé com sa jécri + vit". C'est vrai, mais "moi jé du mal a lir".
[^] # Re: Et ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 7.
Je propose pas la meilleure, j'en propose plusieurs.
Et j'en omets, comme le clavier québécois, ou simplement mettre son clavier en mode azerty (même si ça ne correspond pas aux jolis imprimés sure le clavier), ce qui est trivial à faire sous les principaux systèmes d'exploitation.
J'aurais préféré lire « j'ai pas d'accents, ça me fait chier de les taper avec compose » plutôt que « je peux pas, j'habite un pays sans accents » (ce qui, par ailleurs, est faux).
J'habite un pays où l'alphabet latin n'est pas utilisé, ça ne m'empêche pas de taper mes accents quand j'écris en français.
L'intérêt que je porte aux journaux et autres contenus se retrouve dans mes votes, comme il se doit.
Je me réserve le droit de faire les remarques que je veux, c'est bien l'objectif de la mise en place d'un système de commentaires, non ?
[^] # Re: Et ?
Posté par Maxime (site web personnel) . Évalué à 4.
Pas besoin d'aller jusqu'au bépo, les accents sont dispos sur le layout qwerty international.
[^] # Re: Et ?
Posté par Fabimaru (site web personnel) . Évalué à 3. Dernière modification le 22 janvier 2012 à 23:36.
Sous Linux, il y a la touche compose.
[^] # Re: Et ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Ben, le qwerty international, c'est l'US international, non ?
[^] # Outils automatisés disponibles sur le web
Posté par JGO . Évalué à 8.
Et sans aller jusqu'à changer de clavier, il existe des outils automatisés pour la réaccentuation automatique de textes français.
Oui mesdames et messieurs, en deux minutes et un copier coller, vous pouvez réaccentuer vos textes, vous dispensant ainsi de l'inconfort d'excuses en début de votre journal.
Ceux qui veulent payer peuvent aussi acheter un correcteur orthographique avec un module de réaccentuation.
[^] # Re: Outils automatisés disponibles sur le web
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
C'est vraiment super cet outil. Quant au bepo / international je vais regarder, mais il faut bien que vous admettiez qu'il n'y a guere que sur linuxfr que les gens considerent comme acquis que tout le monde connait ces technologies.
Peut-on mettre a jour un journal linuxfr deja publie?
[^] # Re: Outils automatisés disponibles sur le web
Posté par BAud (site web personnel) . Évalué à 2.
Seuls les modérateurs le peuvent.
Il y a aussi l'option de le transformer en dépêche qui a été prise http://linuxfr.org/news/quelques-aspects-de-la-securite-qui-n-ont-rien-a-voir-avec-le-sandboxing car bien rédigé et avec un axe d'analyse intéressant :-)
[^] # Re: Outils automatisés disponibles sur le web
Posté par JGO . Évalué à 2.
Sinon je pense que là où tu habites tu dois pouvoir te procurer un clavier québécois. Comme il est basé sur un qwerty, c'est peu d'efforts d'adaptation pour passer d'une disposition à l'autre au cours de la journée selon les besoins.
[^] # Re: Outils automatisés disponibles sur le web
Posté par CHP . Évalué à 1.
L'outil web se vautre comme une otarie bourrée à la bière sur la règle de à/a
[^] # Re: Et ?
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Quels râleurs ces français !
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
# ...
Posté par M . Évalué à 10.
[i]
Parfois c'etait la faute du pilote
[...]
WebGL, comme toutes les APIs 3D depuis qu'OpenGL 1.1 a introduit en 1997 la notion de "vertex arrays", a une vulnerabilite DoS bien specifique
[/i]
Et oui c'est ça de vouloir utiliser une API qui a été prévu pour être utilisé par des appli locale (donc auquel on fait confiance) pour une utilisation avec des applis dont on ignore la provenance.
Et vu la complexité d'opengl je predis que les bugs welgl ont de beau jour devant eux...
D'une manière plus général on rend le navigateur de plus en plus proche d'un OS (gestion onglet, video, son, script interprété ou natif, stockage persistant, ...) et tout ca sur des données qui peuvent venir de n'importe ou.
[^] # Re: ...
Posté par Benoit Jacob (site web personnel) . Évalué à 4.
Vous avez bien entendu raison sur le fond, mais le marche etant ce qu'il est, un projet comme Mozilla a le choix entre suivre la tendance ou devenir un dinosaure :-)
Ensuite pour les bugs dans les pilotes qui exposent de la memoire video, il faut bien voir que c'est deja un vrai probleme de securite pour les applications locales. Un peu comme si un processus pouvait lire dans l'espace d'adresses d'un autre.
[^] # Re: ...
Posté par mackwic . Évalué à 1.
J'ai l'impression que Mozilla ne sait pas choisir...
[^] # Re: ...
Posté par Grunt . Évalué à 5.
Ça c'est en parti vrai et en partie une excuse. Je veux dire par là que Mozilla, comme d'autres acteurs d'Internet (comme Google, comme les sites Web les plus visités, comme chaque internaute également) a aussi une influence sur l'évolution des technologies.
Mozilla a, par exemple, fermement défendu le choix de WebM face à h264. Au lieu de se dire "On va devenir des dinosaures".
La bataille de la "dé-webbisation" d'Internet mérite d'être menée. En témoignent les atteintes à la neutralité qui visent à ralentir ou bloquer des ports différents du port 80, les problèmes de sécurité des navigateurs qui doivent concilier le fait d'exécuter du véritable code en interaction avec les ressources de la machine (fichiers, webcam..) et le "blindage" contre un Web auquel on n'a à priori aucune raison de faire confiance, les problèmes de performances (comment peut-on faire une appli de chat qui bouffe 100 fois plus de ressources que irssi pour 10 fois moins de fonctionnalités ? En faisant une appli Web). Par exemple, Thunderbird mériterait un traitement plus attentionné. Ce n'est pas logique que l'application "javascript + html" nommée Gmail soit plus performante, localement, qu'un Thunderbird compilé en natif.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ...
Posté par Benoit Jacob (site web personnel) . Évalué à 7. Dernière modification le 22 janvier 2012 à 22:04.
Oui bon, c'est un peu ambigu. D'une part WebGL a bien ete invente a Mozilla (par Vlad), donc en effet on ne peut pas se dedouaner, mais d'un autre cote il est tres clair a posteriori (vus, successivement, le projet de Canvas 3D d'Opera, O3D de Google, Flash 11, Silverlight 5, et NaCl) que si on ne l'avait pas fait, un concurrent aurait impose sa propre techno de 3D pour "le web" et on aurait du vivre avec. Comme WebGL est AMHA mieux que ces concurrents qu'il a ou a eus, je pense que la strategie de "suivre le vent sans attendre les autres" etait la bonne.
[^] # Re: ...
Posté par reno . Évalué à 2.
Si je suis d'accord avec toi en gros, je pense que les GPUs ont des gros problèmes, même en local à cause de leur histoire: au départ il s'agissait d'accelerer une application (une appli de CAD ou bien un jeu), passer d'une application a plusieurs est très compliqué (surtout que ça n'est pas un gros argument pour les ventes donc la priorité est secondaire pour les vendeurs) donc même maintenant ça n'est pas terrible: je ne pense pas qu'utiliser un GPU soit compatible avec des garanties temps réels par exemple.
Bref, la 3D a l'heure actuelle c'est loin d'être mur, alors quand on rajoute du distant la dessus forcément ça ne peut qu'exacerber les problèmes..
# ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 3.
Ben oui, parcque c'est une problématique présente dans tous les navigateurs web. Toi tu arrives avec des aspects spécifiques à une techno qui n'est pour ainsi dire utilisé par... pas grand monde. Cela dit ça n'enlève en rien la pertinence de ton propos, mais c'est logique qu'on entende pas parler autant de ces problèmes.
Ce qui fait peur par contre, c'est que les exemples que tu présentes montrent que WebGL a l'air particulièrement dangereux : il introduit tout un tas de nouvelles problématiques de sécurité, dont certaines semblent, de ce que tu en dis, difficilement contournable à l'heure actuelle (le coup du DoS présent dans la spec depuis 1997 sans solution clean utilisable partout).
Bref, WebGL ne semble pas prêt pour le Web. La question qui tue : est-ce que avoir choisi de se base sur OpenGL, qui n'a jamais été conçu pour répondre aux problèmes de sécurité liés à l'exécution de code provenant du web, est bien judicieux ? Ne faudrait-il pas mieux repartir d'une nouvelle API (pourquoi pas au dessus d'OpenGL) mais en prenant en compte les problématiques de sécurité "by design" ?
[^] # Re: ca fait peur
Posté par claudex . Évalué à 1.
Firefox, Chrome, Opera (dans sa version 12), Safari (pas activé par défaut). C'est vrai que ça ne fait pas grand monde dans les navigateurs Web.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 2.
Je te parle d'utilisation, pas d'implémentation.
[^] # Re: ca fait peur
Posté par claudex . Évalué à 3.
Sauf que si tu as des trous de sécurité, ce sera vite utilisé pour les exploiter.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 3.
Effectivement, tu as totalement raison.
Ce qui est m'interpelle, c'est que là on a un développeur qui admet explicitement qu'on peut en l'état provoquer un DoS sans réelle solution de contournement sur certains OS, et ca serait en prod dans Firefox ??
[^] # Re: ca fait peur
Posté par BFG . Évalué à 3.
Bienvenue dans HTML 5.0, le nouveau standard
qui établit un nouveau record d'alourdissement du logicieldu Web 2.0.[^] # Re: ca fait peur
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Oui, comme je l'explique dans le journal, tu as des tas de DoS inherents a la plateforme web (html+js), dans tous les navigateurs, meme sans "html5". Je ne nie pas que c'est tres triste, mais en meme temps force est de constater que ca n'est jamais exploite en pratique, probablement parce qu'il n'y a rien a y gagner.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 3.
Tu as des exemples concrêts de DoS inherents à la plateforme web (html+js) ?
[^] # Re: ca fait peur
Posté par pasScott pasForstall . Évalué à 6.
FF a eu il ya longtemps un bug provoquant un freeze du browser.
En gros, suffisait de faire cliquer l'utilisateur sur une url demesurement longue, ca mettait au tas le gestionnaire d'historique a demarrage suivant.
Cela dit, a moins d'avoir un bug monstrueux dans l'interpreteur JS, je vois pas trop comment on peut mettre au tas un os complet.
Avec opengl, j'imagine que c'est beaucoup plus simple.
De meme pour une elevation de privilege. Sandboxer et eviter une elevation de privilege dans un code "ballot", on sait faire.
Sandboxer au niveau du pilote graphique, ca devient deja plus coton.
Disons que c'est pas comme si les pilotes 3D etaient pas reputes pour etre la principale source de crash et de problemes de secu dans un os.
Non pas que "juste le browser" soit ideal, mais entre une appli dans les choux et un hard crash, voir un privilege escalation, je sais de quel cote je me porte.
Bon, ensuite, c'est quoi les applications concretes de webgl? Non pas que je veuille faire mon vieux con, mais mon petit doigt me dit que s'occuper des problemes de reactivite et l'absence de threading de JS ferait plus de bien que d'avoir un un webglxgears.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 2.
Là on parle d'un bug dans un navigateur. Moi je demande à voir un problème inhérent dans HTML+JS qui ouvre la porte à un DoS de la même manière que la spec WebGL.
Toutafé, raison de plus pour éviter d'exposer des API aussi bas niveau qu'OpenGL à une page HTML+JS.
[^] # Re: ca fait peur
Posté par pasScott pasForstall . Évalué à 2.
Ben le pb inherent, c'est que les urls peuvent etre aussi longue que tu veux, et qu'il est donc possible d'avoir un dos de ce genre. Ou que si tu tentes d'afficher un jpeg a 150000dpi, tu vas probablement mettre la machine a genoux.
Oui, c'est gros et tire par les chevrux, mais le pb inherent de webgl est sensiblement le meme, tu peux mettre la machine a genoux si le browser n'a pas un watchdog qui va sauvagement tuer les gorets.
Ya pas plus de cote inherent d'un cote ou de l'autre, ca reste au browser de s'assurer que tout va pas peter, apres tout, c'est lui qui alloue ces ressources au final...
Dans le fond, on est d'accord, donner acces direct au matos au premier clampin venu sur internet, ca pue la mauvaise idee, point a la ligne.
Et c'est pas les failles de flash avec les webcams/micros qui vont me contredire.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 2.
Je suis bien d'accord, mais de ce que je comprend du problème soulevé par WebGL, c'est que le navigateur ne peut justement pas empêcher ce problème, le GPU étant non-préemptible. Ou alors il faut contrôler le problème en amont et construire une API qui interdisent d'arriver dans une situation de blocage. D'où ma question : OpenGL (variante ES) était-il vraiment la bonne base à prendre dans un contexte d'exécution de code web ?
C'est même encore pire : flash est une sandbox, et comme tu le fais remarqué, il y a quand même des bugs. C'est bien pour celà que WebGL me fait peur : on expose des API encore plus bas-niveau, non sandboxés si je comprends bien.
[^] # Re: ca fait peur
Posté par Fabimaru (site web personnel) . Évalué à 2.
Pas exemple les cartes de Nokia, une sorte de Google Earth version web:
http://maps3d.svc.nokia.com/webgl/index.html
[^] # Re: ca fait peur
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Il y en a au moins 2 dans mon journal, si tu le lis (allouer de la memoire en JS, et une simple page web avec beaucoup de grandes images, surtout sur un navigateur qui utilise le GPU).
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 2.
La spec JS (ou EcmaScript) ne dit absolument pas qu'un code JS peut allouer autant de mémoire qu'il veut : il est tout à fait normal et légitime de mettre une limite, et c'est ce qui est fait en pratique par les runtime JS. Donc non, ce n'est pas un DoS inhérent à la plateforme HTML+JS.
Là encore, le navigateur peut tout à fait empêcher ça et imposer une limite : je ne vois donc pas où est le soucis.
Rappel : toi tu parles d'un problème inhérent à la spec qui offre un accès à des fonctions trop bas niveau conduisant à l'impossibilité par le système d'empêcher une monopolisation du GPU. Bref, c'est un DoS "by design".
[^] # Re: ca fait peur
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Je pense que tu n'as rien compris a pourquoi ces DoS sont difficiles a eviter. Bien sur que l'implementation peut imposer une limite. Mais quelle limite? Impossible de choisir une limite qui soit assez haute pour ne gener aucune application legitime, et en meme temps assez basse pour eviter les DoS sur tous les systemes, etc. Tout ce qu'on pourrait faire c'est couper la poire en deux, taper au milieu de la fourchette, dire "pas plus de 256 M de memoire par domaine pour les scripts" et on aurait encore tous les problemes: ca serait encore trop pour beaucoup de machines, et pas assez pour beaucoup de scripts specialises. Et quand un jeu Facebook buggerait a cause de ca, on recevrait des milliers de plaintes. Idem pour le bug avec beaucoup de grandes images. Et ca n'etait que 2 exemples...
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 2.
Bien sûr que si c'est possible de choisir une limite ! Prends la conso mémoire de la JVM : elle impose une limite, configurable, qui empêche une appli web d'en demander trop. Si une appli légitime en a besoin, l'utilisateur peut modifier la config de la JVM au cas par cas, mais il est primordiale d'avoir une limite par défaut pour empêcher les applications non légitimes de faire des conneries et s'écrouler le système.
Mais c'est sûr, si tu pars du principe qu'un jour y'aura une appli légitime qui a besoin d'un accès root, de 5 Go de ram, alors oui, c'est difficile de choisir des limites.
Le runtime peut très bien s'adapter aux ressources disponibles pour définir la limite à ne pas atteindre. Et si le script a besoin de plus, bah tant pis : pas assez de ressources, c'est comme ça : message d'erreur à la limite. Les ressources ne sont pas infinis, il est normal que le runtime impose une limite pour ne pas mettre la machine à genoux, et c'est aux scripts de s'adapter !
Mouais c'est vrai, autant laisser la machine tomber à genou plutôt que d'afficher un beau message d'erreur quand la conso mémoire commence à devenir indécente aux regards des ressources dispo...
Surtout que ce que tu dis est totalement contradictoire avec la réalité : prends par exemple la conso CPU : Firefox comme Chrome affiche un message d'erreur si un script met trop de temps à s'exécuter. Il y a une limite d'imposée, un message d'erreur affiché. Comment t'explique ce comportement alors qu'il peut y avoir des applications légitimes qui consomment beaucoup de CPU ?
Et dis moi, vous faite pareil aussi pour la gestion sur disque ? Vous laissez les cookies ou les données HTML5 locales faire 1Go sur disque ? Non parcque je suis sûr qu'on peut trouver des applications légitimes...
Même si on est pas d'accord sur la pertinence ou non de mettre une limite, le principal est qu'il soit possible d'en mettre une.
Dans tous les cas, la situation est bien différente telle que tu la présentes avec WebGL et le GPU : d'après ce que tu dis, il n'est techniquement pas possible (en tout cas de manière générale) de poser une limite sur la monopolisation du GPU, et ca c'est un vrai problème.
[^] # Re: ca fait peur
Posté par Grunt . Évalué à 2.
J'suis en train de me dire que choisir Konqueror (du projet Trinity, c'est à dire KDE 3.5) voire w3m comme navigateur principal n'est pas si malavisé, là.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Si tu veux eviter les DoS inherents a JS, tu ferais mieux d'installer NoScript. Si tu veux eviter les DoS inherents a l'acceleration par le GPU, Firefox (et les autres navigateurs) te permettent de desactiver ca (Firefox a meme une boite a cocher dans les prefs). WebGL peut aussi etre desactive dans about:config quoique NoScript s'en charge.
[^] # Re: ca fait peur
Posté par Grunt . Évalué à 4.
Nan mais ça va, j'ai déjà Noscript, AdBlockPlus, pas de plugin Flash, et Cookie-Monster. Mais bon, je me sens un peu comme un windowsien avec son artillerie d'antitrucs.
Sur mes autres protocoles (SSH, IRC, IMAP, SMTP, BitTorrent, FTP, XMPP..) j'ai pas besoin de ça, j'ai pas l'impression d'avoir un Windows crevu de trous auquel il faut des rustines (impression que donne le Web si on tient à sa vie privée et à la sécurité de ses données).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par Benoit Jacob (site web personnel) . Évalué à 1. Dernière modification le 23 janvier 2012 à 01:44.
Les applis implementant ces protocoles de messagerie (IMAP, etc) en question peuvent et doivent, contrairement au navigateur, etre nettement plus strictes sur les contenus autorises, par defaut. Par exemple, Thunderbird n'autorise pas (en tout cas par defaut) l'execution de JavaScript dans les mails HTML.
(La difference avec le navigateur etant bien entendu qu'avec le navigateur, tu vas ou tu veux, alors qu'avec la messagerie, on t'envoie ce qu'on veut)
[^] # Re: ca fait peur
Posté par Grunt . Évalué à 3.
Ta réponse est exacte sur le plan technique mais manque de recul sur l'histoire des protocoles. A-t-on vraiment besoin de faire passer tout ça (animations, discussions, vidéos, mails, jeux, interface de configuration d'équipement, administration de systèmes..) via un seul protocole ?
Il fut un temps (on m'a raconté, j'étais pas né à l'époque, je suis de 1984) où les gens qui faisaient Internet avaient à coeur de se mettre d'accord sur des protocoles, de les définir, de les implémenter et de les faire évoluer ensemble.
Ce temps semble être révolu. Maintenant, le premier besoin semble être de fourguer à l'utilisateur final un mélange volontairement obfusqué de javascripts très spéciaux appelant d'autres scripts, des applis Flash, modifiant dynamiquement le document, le tout vomissant de la pub, du contenu utile, une "application", du contenu moins utile..
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par pasScott pasForstall . Évalué à 3.
Tu sais, du javascript, qu'il soit servi via http, ftp, rtsp imap ou tcp over pigeon, ca reste du javascript. C'est pas foudroyant et c'est potentiellement ecrit par un gars qui sait pas trop ce qu'il fait.
Melangeons tout et rajoutons une bonne dose de "c'etait mieux a vent"... Simplement parce que http a ete sous exploite et limite a servir du html pendant des annees ne veut pas dire que le protocole n'a pas ete concu pour plus que ca.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: ca fait peur
Posté par Grunt . Évalué à 5.
Justement, sur les autres protocoles on ne transporte généralement pas de code : on transporte des données. Le code, c'est l'utilisateur qui le choisit, on n'essaie pas de lui fourguer (par exemple) le lecteur vidéo avec le fichier vidéo.
Heu ? Sous-exploité ? Je dirais surtout "qui nécessite des hacks grotesques pour en faire ce qu'on en fait maintenant". À titre d'exemple j'ai testé l'installation d'un noeud status.net chez moi avec un pont vers Twitter©. Un système 100% HTTP(S). C'est très simple : à chaque synchronisation entre Twitter et mon serveur, la bande passante était saturée. Tout ça pour transporter quelques dizaines de messages de .. 140 caractères (le genre de choses qui s'échangeait aux tous débuts d'Internet).
À côté de ça j'ai un serveur XMPP qui tourne, il n'a jamais fait lagguer mes sessions SSH. Même quand (par exemple) im.apinc.net sort de son sommeil et me balance des dizaines de contacts avec leur statut, leur avatar voire leur messages différés.
Je trouve plutôt que ce sont des très bon protocoles comme rsync (au lieu de svn via HTTP par exemple), XMPP (au lieu de appli-de-chat-moisie-via-HTTP+javascript), BitTorrent (au lieu de vidéo via Flash via HTTP(S)), UUCP (au lieu de forum en PHP qui rame over HTTP) qui sont hélas sous-exploités.
Dans une optique de re-acentralisation d'Internet (qui semble nécessaire vus les enjeux) je trouve que la plupart des usages faits via HTTP ne sont tout simplement pas adaptés : impossible d'avoir plusieurs sources pour un même fichier (donc demande élevée de bande passante en cas de gros fichier type photo, vidéo), consommation élevée de ressources côté serveur (incompatible avec une box d'auto-hébergement qui tourne 24H/24), sécurité problématique (tant côté client que côté serveur) pour des débutants, difficultés à mettre en place des systèmes sécurisés ne dépendant pas de Grandes Puissances (les messages délirants de navigateurs comme Firefox en cas de certificat auto-signé, alors que la même page en HTTP clair est servie sans sourciller)..
Je trouverais sympa que la MoFo se penche sur la question et propose, aussi, des solutions à ce type de problèmes. Je sais pas moi, un système comme Opera Unite, ou bien la possibilité d'intégrer un lien torrent dans une page Web pour charger une image ou une vidéo, ou un client Torrent intégré au navigateur, ou un client mail qui mette une vraie baffe à Outlook (c'est pas difficile mais on sent que Thunderbird, par rapport à Firefox, est le parent pauvre).. au lieu de suivre passivement (avec de plus en plus de mal, cf les performances de Chrome) la "course à la puissance" qui profite finalement aux géants commerciaux du Web et pas tant que ça aux utilisateurs.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par pasScott pasForstall . Évalué à 1.
Qu'est ce que ca a voir avec le protocole au juste?
Le fait d'envoyer du code au client repond a une problematique bien precise que tous les protocoles du monde ne peuvent resoudre.
Le probleme, c'est de faire tourner du code cote client, ca te defrise peut etre, mais eviter un aller retour au serveur quand un formulaire est invalide ou qu'on veut juste rafraichir un div, tu vas avoir du mal a le resoudre au niveau protocolaire.
Et au passage, un player mp4 peut executer du code js embarque dans la video, qui va pas etre servie en http pourtant. Ou pas forcement.
Ce que je voulais dire par la, c'est que contrairement a ce que des gens comme tanguy pensent, http n'a pas ete cree pour servir du web. Http est un protocole applicatif qui definit des verbes permettant de manipuler des ressources. Le concept de ressource etant volontairement le plus vague possible, car ca peut etre n'importe quoi. Un put sur un salon de discussion, un delete sur un email ou autre.
Le tout en etant totalement stateless, ce qui a des avantages enormes face aux inconvenients.
Le concept de rest est au contraire tres propre et elegant.
Que status.net fasse visiblement portnawak (ou plutot que ce qu'il fait t'echappe) n'a pas grand chose a voir avec http, javascript ou le jardin de mon oncle.
Apres, si ta reponse a la complexite et aux pb de resources de js, c'est d'integrer un client bittorrent au navigateur, je reste perplexe.
Mais qu'est ce que ca a voir avec http ca? Serieusement? Ssl gueule en cas de certificat auto signe, oui c'est normal, vu que le but du jeu c'est d'avoir une authentificaton de la source par un tiers de confiance. Si le tiers est inconnu, il n'est pas de confiance et donc ca gueule, c'est quoi le pb au juste?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: ca fait peur
Posté par Grunt . Évalué à 6.
Si cette problématique est "contrôler le plus possible le code exécuté par l'utilisateur" je suis d'accord. Mais je trouve dommage de ne pas prendre de recul critique sur cette exigence du "Web 2.0", qui est, finalement, une resucée moins performante, pleine de publicités, centralisée, limitée, de ce que les internautes faisaient y'a 20 ans : Échanger des fichiers. Discuter en temps réel. Avoir une discussion publique, organisée par fils de discussion. S'envoyer des messages différés. Avant même que le Web n'existe on pouvait faire ça (y compris la causette, CF IRC ou talk). Maintenant 99% des utilisateurs le font en utilisant une machine virtuelle nommée navigateur, qui exécute des applications choisies par le fournisseur du service. C'est.. problématique, en effet.
Tu parles avec une vision très "web centrée". Ton formulaire il sert à quoi, finalement ? À publier un commentaire sur LinuxFR ? Avec NNTP (par exemple) le serveur n'a pas à se soucier de la forme des données, c'est le client qui respecte le format et va, par exemple, dire "cette adresse mail est bizarre, j'envoie quand même ?" ou "Attention, message vide !". Bien évidemment je pars du principe que des données volontairement corrompues ne mettrons pas en danger ton serveur, sinon ce serait du délire de les valider avec du code qui tourne chez l'utilisateur final et hostile. Quoi que, y'a pas mal de poutrages de services Web qui se font en partie à cause de ça (path disclosure, injection SQL). Des failles récurrentes, inimaginables sur d'autres protocoles.
On a réinventé TCP/IP, super :)
Et par dessus ce HTTP, ben on code des applis, qui pourraient très bien être codées en utilisant directement TCP/IP et en tournant nativement chez l'utilisateur. Moins de ressources réseau et CPU gâchées. Ah, bien sûr ça implique de communiquer avec des protocoles à peu près standard et de laisser l'utilisateur libre de choisir son implémentation, c'est embêtant : il risque de préférer l'implémentation sans publicité.
Ouais, j'avoue que ce gloubi-boulga m'échappe. Faut se lever de bonne heure pour comprendre et débugger une "application Web", c'est à dire, d'un point de vue système, un serveur Web qui sert des pages, lesquelles sont en fait des scripts qui tapent dans une base de données en s'authentifiant pour ensuite renvoyer du contenu HTML,et du javascript qui fait des trucs côté client afin que le client vienne faire d'autres trucs sur le serveur, ou des cookies.. Je préfère le bon vieux démon IRC, Jabber, mail, ce que tu veux, qui va simplement "faire le truc dont il est question" et dont les logs sont lisibles :)
Ça a à voir avec la plupart des implémentations de HTTP : le client gueule comme un putois. Ce qui est très différent de notifier l'utilisateur. Un débutant, je peux le guider au téléphone et lui confirmer (par exemple) le certificat auto-signé d'un serveur Jabber. Par contre, sur un site Web, si Firefox lui affiche l'image d'un flic en haut à gauche, et qu'il doive confirmer qu'il "comprend les risques" avant de continuer, il va laisser tomber. Pire que ça : il n'aura même pas la possibilité d'accepter ce certificat uniquement pour un site précis, soit il fait confiance totale au propriétaire du certificat (y compris pour sa banque, ses mails..), soit il visite le site en version sans SSL. Super. Pendant ce temps, Gajim (c'est pas un projet aussi gros que Firefox hein) affiche le certificat sans hurler, préviens quand le certificat a changé, et n'accepte pas le certificat auto-signé de Claude le geek pour signer le service Jabber de Google.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par pasScott pasForstall . Évalué à 0.
Ben ouais, mais t'es mignon, le W3C a mit JS dans la spec depuis un bail, parce que, ben, on en a besoin.
Tu peux tourner le pb dans tous les sens, on a en a besoin, avoir une techno de présentation 100% statique, ça pose des pb et on peut pas faire sans.
Apres, si tu veux m'expliquer comment faire un truc comme GMail ou de l'ajax sans code qui tourne cote client, ben tu me fais signe.
Ben ça change pas grand chose au pb, tu veux toujours valider tes données cote client avant envoi, parce que t'as pas forcement envie de te fader le reremplissage du formulaire cote serveur et que tu veux avertir l'utilisateur des pb avant meme qu'il clique sur envoyer.
Pour autant que je sache, TCP et IP ne sont pas des protocoles applicatif. Je peux me tromper cela dit, hein.
Mais en quoi HTTP bouffe des resources? Le protocole est simplissime, tellement simple que tu l'implementes sur tcp avec 2 fois rien (je sais, je le fais, ça tiens en 200 lignes). C'est sur que si tu veux garder une connexion permanente entre le serveur et le client, HTTP ça va pas être au poil, apres utiliser un protocole stateful pour du stateless, ça va être le meme merdier...
Implementer un salon de discussion over HTTP, oui, c'est con.
A peu près aussi con que réinventer un protocole dédie pour poster 140 characteres sur une ressource.
Maintenant, si t'as une meilleur idée que HTTP pour transférer des données sans authentification, je suis toute ouïe.
Si l'overhead de qq dizaines d'octets est trop pour toi, va falloir argumenter. Serieusement.
Non, ce qu'il se passe c'est que tu comprends pas ce qu'il se passe, et que tu clames qu'il faut se passer de ce genre de fonctionnalité parce que tu comprends pas comment ça marche.
C'est simple pourtant. Ca a rien de bien complique pourtant.
Juste parce que t'es pas foutu de comprendre comment ça marche, ça le rend pas inutile.
Maintenant, je veux bien que tu m'expliques en quoi HTTP live streaming est plus complexe et gourmand en ressource que bittorrent pour une video embarquée dans une page web. Et au passage, tu vas m'expliquer comment tu garantis de recevoir la video en premier avec bittorrent, vu que le concept c'est justement "chope ce qui est dispo, dans n'importe quel ordre, on s'en fout end' façons, c'est pour visionner offline".
Je sais tres bien ce que tu vas me répondre a ce point c'est "la video, tu la mattes offline". En gros, dit moi ce dont t'as besoin, je t'expliquerais comment t'en passer.
Tu peux utiliser RTSP, mais va falloir m'expliquer quel est l'intérêt de RTSP quand 95% des clients peuvent telecharger la video en moins de qq secondes via un protocole achement plus simple, et faire le playback de leur cote.
Super, et next thing you know, tu te retrouves aver 150 protocols differents.
Et quand tu les regardes de pres, ce qu'ils font pour la plupart, c'est du CRUD sur une ressource distante. Oh. ben tient. Ca sera pas le principe de base de REST ça des fois?
On peut lire une ressource, la créer, la modifier, la supprimer. Tu couvres 99,9% des besoins avec ça, sur un protocole tellement simple a comprendre que meme toi t'arrives (presque) a le comprendre. Protocole qui est implemente par quasiment tout le monde partout (forcement, simple comme il est...)
T'es au courant que la partie "je te gueule dessus", elle vient de SSL/TLS, pas d'HTTP?
Gne? Donc en gros, parce qu'un client met en garde ses clients contre un vecteur d'attaque courant, HTTP, qui n'a strictement rien a voir avec le problème en question, est un mauvais protocole?
Et si iChat se met a afficher un flic pour les certifs auto signes, Jabber va devenir un mauvais protocole aussi?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: ca fait peur
Posté par Grunt . Évalué à 5.
Je n'ai jamais dit que le code côté client c'était mal. Je dis qu'un truc comme Gmail ça s'appelle par exemple Thunderbird. Avec du code choisi par l'utilisateur (il peut remplacer Thunderbird par Kmail ou Evolution) indépendamment du service (t'as déjà utilisé le webmail de Yahoo chez Google ou l'inverse ? Ah zut on peut pas). Avec une économie de ressource incroyable à fonctionnalités égales. Avec de bien plus grandes facilités pour héberger soi-même le service (même si le code source de Gmail était libre, je préfère mille fois mieux me taper l'installation d'un postfix+dovecot côté serveur et Thunderbird côté client, que l'installation d'un Gmail-like sur un LAMP).
D'un autre côté, si tu laisses l'utilisateur choisir son application cliente au lieu d'en proposer une toute faite en javascript, je suis absolument certain qu'elle finira par proposer de garder en mémoire les données saisies au lieu de les retaper. Exemple, 100% des clients de messagerie instantanée, en cas de mot de passe erroné ou de données rejetées par le serveur, gardent dans les champs déjà remplis les données saisies. Par contre, des sites Web qui te bennent tout, ou qui déclarent comme invalide un truc qui est valide, j'en ai vu ma dose.
Exemple, le webmail d'Orange :
http://www.bortzmeyer.org/arreter-d-interdire-des-adresses-legales.html
Si c'est pour coder des applications aussi merdiques et les imposer à l'utilisateur final, il vaut franchement mieux le laisser choisir une application qui fonctionne, qui tourne chez lui.
Pas la peine, il existe : XMPP. Et il est à tous points de vue de meilleure qualité que le bordel mis en branle par l'interface de Twitter. Que ce soit "le site Web Twitter dans un navigateur" ou bien "l'API Twitter pour faire sa propre application over HTTP".
C'est pas forcément une "meilleure idée", ce sont des idées équivalentes : FTP, rsync, NFS, BitTorrent. Des protocoles standards qui permettent de copier des données publiées, et qui peuvent offrir des fonctionnalités supplémentaires par rapport à HTTP. rsync est réellement fait pour ne copier que ce qui a changé. BitTorrent permet de répartir la charge entre tous les gens ayant déjà téléchargé le fichier.
BitTorrent, en l'état, n'est pas utilisable pour cet usage, on est d'accord. Mais il ne lui manque pas grand chose. HTTP non plus n'a pas été prêt pour le streaming tout de suite (sans les requêtes "Partial Content" qui permettent de récupérer la vidéo à partir d'un certain délai, ça serait franchement moins pratique. Je pense que tu vois mieux que moi de quoi je parle sur ce point :D)
Tu connais l'histoire des abonnés Free chez qui Youtube il rame tellement qu'ils ouvrent la page, et patientent dix minutes pour regarder une vidéo de deux minutes ? Je trouve qu'ils ressemblent furieusement à des gens qui ont appris à se passer du caractère instantané du streaming. Ils ont besoin de streaming, la réalité physique du réseau (des tuyaux congestionnés, tout simplement) leur apprend à s'en passer.
Si c'était possible de "lire du BitTorrent en streaming" je suis certain qu'avec une dizaine de seeders (autrement dit, une dizaine de gens ont vu la vidéo récemment) ça irait plus vite s'ils cliquaient sur le lien "torrent-streaming" que sur le lien "Youtube".
Je t'explique ça avec plaisir. Le RTSP, je peux le lire dans VLC, ou dans mplayer si VLC me plaît pas/plante chez moi/n'est pas dispo sur mon OS. Je peux l'enregistrer. Je peux le mettre sur pause avec le raccourci que je connais par coeur de mon "lecteur qui lit toutes mes vidéos". Je peux le minimiser et continuer à lire le texte de la page Web en n'écoutant que le son, parce que l'image c'est juste quelqu'un qui parle et ça distrait plus qu'autre chose. Ouais, c'est une bonne idée en fait, au lieu d'incruster dans une page Web une application Flash (ou sa version moderne, une balise < video >, qui contraint à utiliser le lecteur intégré au navigateur), un lien "rtsp://" c'est mieux. Bien mieux à tous points de vue. Ça fait moins "fancy kikoolol 2.0", mais c'est carrément plus pratique. Genre, je vois l'article, je peux décider de commencer à télécharger la vidéo, lire tout l'article, puis lire la vidéo, si ma connexion est pas terrible. Avec du YouMotion incrusté ça demande des manipulations rusées, différentes selon chaque site, à base de "je lance la lecture, je baisse le son, je mets sur pause, je vérifie que la barre de chargement, si y'en a une, est pleine, je remets au début, je remonte le son, je relance la lecture".
556
C'est grave docteur ? La terre va arrêter de tourner ?
Ça c'est le beau protocole bisounours, et je suis d'accord avec toi sur ce point. Mon problème, c'est que, de facto, le protocole tu l'utilises dans 99,9% des cas avec l'application choisie par le fournisseur du service. Et cette application se présente sous la forme d'une URL HTTP qui ouvre une page dans laquelle se "passent des choses" qui sont, toutes ou presque, hors de contrôle de l'utilisateur lambda.
Maintenant, je vais te dire comment ça aurait pu, ou ça peut tourner, ce genre d'histoires. En prenant l'exemple des XEP (extensions au protocole XMPP). T'as un protocole de base (XMPP), on se rend compte qu'il permet de faire pas mal de choses, on regroupe des usages similaires dans des XEP histoire de pas éparpiller les implémentations. Un mélange de souplesse et d'intéropérabilité.
Sur le Web, le même schéma pourrait être appliqué. Combien de sites d'information se présentent sous l'aspect "article - ressources externes (vidéos, liens..) - commentaires" ? Des centaines, voire des milliers. Actuellement ce sont des milliers d'applications Web qui font toute la même chose (d'un point de vue fonctionnalités). Proposer (comme j'ai tendance à le faire) de remplacer ce bordel par des serveurs NNTP en réservant le droit d'initier un fil de discussion à ceux qui gèrent le serveur de news, c'est peut-être un peu exagéré. Mais on pourrait imaginer une vraie standardisation du modèle HTTP actuel, qui aboutirait à ce que l'utilisateur final ait un client dédié à la "lecture de journaux", qui saurait où taper pour avoir l'article, pour avoir la/les vidéos, pour lire/publier les commentaires. Autrement dit, chaque utilisateur choisit parmi plusieurs applications et garde la même sur chaque site. Au lieu d'avoir, comme actuellement, une application liée à un site. C'est pas sympa et ergonomique, comme idée ?
Je parle (même si ça n'en a pas l'air) du point de vue de l'utilisation finale, tant pour celui qui consulte l'information que pour celui qui va la diffuser et/ou l'héberger. Et je montre du doigt plusieurs obstacles à une "libération d'Internet", ou "libération du Web" si tu veux. Les messages flippant des navigateurs sont un de ces obstacles, qui n'est pas présent sur d'autres clients destinés à d'autres protocoles (où on mentionne simplement la non validité du certificat, où on accepte d'associer un certificat auto-signé à un serveur particulier, sans faire déborder cette acceptation sur tous les serveurs, et en prévenant si le certificat change).
Et, pour résumer, je dirais que le Web, dans sa forme actuelle, implique nécessairement, pour celui qui publie, qui diffuse, des ressources importantes, en sécurité, en complexité de mise en place et d'administration, en puissance de calcul, et en bande passante. Et il implique également pour celui qui lit des trucs et poste des commentaires, une impuissance dans le choix de l'application et des difficultés pour contrôler et limiter le comportement de celle-ci ("Empêcher ce site de générer des boîtes de dialogue supplémentaires", c'est fou d'en arriver là, non ?).
Donc voilà, le bilan : les choix techniques faits, et le manque de recul, y compris du monde du libre, face à la "webbisation" d'Internet, font que l'utilisateur chez lui avec son serveur basse consommation et sa bande passante limitée, il ne peut pas, de façon autonome, poster un billet pour dire "regardez mon chat qui monte une échelle", mettre un lien vers une vidéo qu'il héberge (même s'il n'est pas le seul à l'héberger, merci BitTorrent), et le faire avec un semblant d'égalité par rapport à Twitter, Youtube, Facebook et leur formidable puissance de feu. Avec d'autres protocoles, et/ou une extension du Web dans d'autres directions que "faire de l'OpenGL et un OS en javascript", il pourrait. Et ça serait bon pour Internet et bon pour les internautes.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ca fait peur
Posté par pasScott pasForstall . Évalué à 0.
On peut utiliser des liens en dehors du web. Juste parce que le web est une application parfaite de REST/HTTP ne veut pas dire que c'est le seul usage que les créateurs avaient en tete.
Je les vois pas trop créer la méthode DELETE sinon, ni faire la différence en PUT et POST si c'est juste pour servir du HTML.
C'est meme un peu la base de REST et de la discoverability, une ressource te dit vers ou tu peux aller ensuite.
Et quand on regarde de quand date REST et qui est derrière, on retrouve les gars derrière HTTP.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 0.
Tu veux diffuser un live vidéo en BitTorrent ? Et tu nous parles d'efficacité ?
Ils sont adaptés à la réalité d'internet : en gros seul HTTP passe à peu prêt partout.
Gni ?
Tu peux expliquer en quoi un serveur de fichier en HTTP consomme beaucoup trop de ressource par rapport à un serveur de fichiers en FTP ?
[^] # Re: ca fait peur
Posté par pasScott pasForstall . Évalué à 2.
Il veut distribuer la video sur plusieurs hotes pour diminuer les besoins de bp de chaque. Ce qui est en ligne avec le grand delire de streamer via bittorrent.
Ca aurait un interet certain, et je me dit qu'une extension d'http live streaming devrait pouvoir y repondre, au moins partiellement.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: ca fait peur
Posté par Grunt . Évalué à 5.
Ahah :) Forcément, vu que maintenant on est censés faire tout via le Web, et que les autres protocoles sont relégués au rang de trucs suspects d'experts pirates.
On arrive à un raisonnement circulaire : on fait tout via le Web car seul le Web passe partout car on fait tout via le Web.
Au passage je m'étonne que tu ne sois pas plus critique envers le fait que des accès présentés comme "à Internet" (mais qui n'en sont pas) ne permettent d'accéder qu'au Web. C'est aussi délirant qu'un accès sur lequel seul SSH passerait (en fait, c'est pire, car SSH permet au moins d'y tunneler facilement autre chose sans overhead délirant).
S'il ne s'agit que de servir des fichiers statiques il ne consomme pas beaucoup. S'il s'agit de publier des informations de statut (micro-blogging versus XMPP), de proposer une interface de discussion (IRC/XMPP versus appli Web de chat), de discuter (forum PHPxx versus UUCP), alors le serveur HTTP sera accompagné d'une base de données, de scripts en PHP ou autre langage interprété, et nécessitera davantage qu'un CPU de modem-routeur pour faire ce qu'on lui demande dans un délai raisonnable.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 0.
Houlà, mais je dis pas que c'est bien de tout faire passer sur HTTP, je donne juste l'explication. Le problème est bien dans les politiques d'accès internet, que ce soit l'admin psychopathe en entreprise qui trouve le port POP dangereux ou le méchant FAI mobile qui veut pas que tu fasses de SSH.
Voilà, l'overhead est techniquement ridicule, on est d'accord.
Tu mélanges tout et n'importe quoi. HTTP n'est qu'un protocole offrant la possibilité de requêter une ressource distante : tu peux faire au dessus un protocole de type IRC, de type XMPP (ce dernier le fait déjà d'ailleur).
Pour toi HTTP == application web HTML + tout le bordel : tu compares un simple serveur de communication avec un serveur qui t'expose le client utilisateur. Non, dans HTTP tu peux faire passer la même chose que ce que tu fais passer au niveau XMPP ou IRC. Il y a un overhead, certes, des contraintes qui font que ce n'est pas aussi efficace, mais si ton serveur fait le même boulot avec pour seule différence de le faire au dessus de HTTP, alors il le consommera probablement pas beaucoup plus de ressources.
Si tu veux vraiment te soucier de ce problème d'overhead ajouté par HTTP, arrête de parler d'XMPP, parcque dans le genre overhead, XMPP te formatte tes messages en XML, qui, je te le rappelle, doit être le langage le plus verbeux inventé pour faire circuler la moindre donnée. A côté, l'en-tête HTTP est ridicule.
[^] # Re: ca fait peur
Posté par Grunt . Évalué à 5.
De facto, l'usage est de s'en servir dans un navigateur, avec donc un gaspillage assez énorme de bande passante (re-téléchargement d'une application à chaque usage) et de puissance CPU (javascript sur navigateur sur OS, versus application native sur OS).
Je suis d'accord avec toi sur le fait qu'on peut utiliser HTTP pour faire communiquer "un client truc over HTTP" avec "un serveur truc over HTTP". Dans les faits, on met d'un côté un navigateur Web qui bouffe un maximum de RAM et de CPU, de l'autre côté généralement un LAMP qui bouffe aussi un max de ressources, par rapport à ce qui serait bouffé si c'était prosody qui parle à mcabber. (Et pas la peine de troller sur le côté rustique de mcabber, il présente plus de fonctionnalités que la totalité des applis Web de chat que j'ai pu voir).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par pasScott pasForstall . Évalué à -1.
De facto, l'usage HTTP "sans UI", ie en dehors du contexte pur web est en train de monter en fleche, tellement en fleche que beaucoup de sites se rendent compte que d'ici un an, la version appli de leur site fera autant si ce n'est plus de traffic que le site web.
Et crois moi, su un telephone, tu te fais pas chier a telecahrger 25 fois la meme chose.
Ola, tu vas bien vite en besogne!
T'as entends parler du pragma cache?
Pourquoi tu crois qu'on s'emmerde a mettre le js dans des fichiers sépares, juste pour le fun de se prendre une requête supplémentaire par script?
Non, parce que ce js est cache cote client...
Pour le gaspillage de CPU, je te repose la question, vu que tu visiblement pas y répondre.
Comment tu fais pour résoudre le problème sans JS?
Il faut faire tourner du code cote client, tu peux pas y échapper. C'est comme ca. C'est un pré requis, comme on dit.
PArtant de la, on fait quoi?
On envoie du code natif?
On reinvente des protocoles super compliques et incomplets tous les 4 matins?
On s'encule?
Moi perso, le natif, j'aime pas et les protocoles compliques, ça m'irrite.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 3.
C'est du grand n'importe quoi. Il y a de nombreux usages hors-navigateur : SVN, transfert de fichier, web-services, API REST, HTTP streaming, etc. Forcement, toi tu te contente de ta petite expérience utilisateur et ce que tu en vois.
Ce qui me fait doucement rire, c'est que tu ventes des solutions pourtant réputées pour ne pas être efficace pour 2 sous niveau ressources (XMPP over bloated XML), et que tu utilises parfois ces protocoles au dessus de HTTP (genre là j'utilises Pidgin, client XMPP, à travers un passerelle HTTP).
Admet que tu mélanges tout : javascript & HTML c'est au niveau supérieur. HTTP c'est relativement neutre sur le contenu, et tu peux à prêt y faire circuler n'importe quoi. Forcement, à vouloir mettre tout dans le même panier, on fait forcement des raccourcis foireux.
Nawak. Je mets en place régulièrement des web-services. Côté serveur, si je mets un LAMP, c'est que j'ai besoin d'une base de donnée et d'un contenu dynamique : ca n'a rien à voir avec HTTP, quelque soit le protocole que tu choisis, si t'as besoin de gérer des contenus dynamiques qui doivent persister, il te faudra un serveur applicatif capable de cracher les données et un serveur de données pour les stocker.
[^] # Re: ca fait peur
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Les aspects que j'ai mentionnes ici dans le contexte de WebGL (deni de service, fuite d'into trans-domaine, lecture de memoire video) ne sont pas specifiques a WebGL et ont tous ete rencontres aussi en dehors de WebGL. Au moins pour le deni de service et la fuite d'info trans-domaine, j'en ai donne des exemples precis dans mon journal. Bref, tu fais la lecture que tu veux de mon journal en fonction de ce que tu veux y voir, mais ca en dit plus sur tes prejuges que sur WebGL.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 4.
Le coup du DoS, tu pointes explicitement un problème intégré dans la spec en 1997. Donc oui, je lis ce que je veux : je lis ton journal.
Préjugés ? Je constate juste des faits :
- WebGL se base sur les API d'OpenGL
- OpenGL n'a jamais été conçu dans un contexte Web
- Vous rencontrez des problèmes spécifiques à la spec OpenGL
- Vous exposez de nouvelles API qui interagissent avec le matos, plus difficilement contrôlable par l'OS, bref, vous élargissez l'exposition en terme de sécurité.
C'est pas des préjugés mais de simples constats !
[^] # Re: ca fait peur
Posté par tallion . Évalué à 3.
Je suis un peu gêné par tes propos car tu exposes un problème générale comme si ca provenais de WebGL.
Tu peux réaliser du DoS avec un peu n'importe quoi... Ca à déjà été fait avec les décodeurs jpeg, j'en avais même trouvé un dans le format WebP alors que je ne me considère pas comme un codeur fou (et pour mon plus grand malheur avait déjà été reporté :) ou le javascript lorsque l'interpréteur ou le compilateur JIT à des bugs!
WebGL est une adaptation d'OpenGL ES pour le web, je ne vois pas le problème. Ca reviendrait à dire que le java ne peut pas être intégré comme langage web (quoi dart? ;) ou que le JS ne peut pas faire du serveur (nodejs). Bien sûr, il faut ajouter ou enlever quelques fonctionnalités et le résultat sera plus ou moins adapté, mais c'est toujours possible.
Si c'est difficile et ajoute un risque, on ne doit rien faire? Dans ce cas les compilateurs JIT des moteurs javascript ne devraient pas exister. D'autant plus que, si j'ai bien compris, le vrai problème ne se situe pas vraiment au niveau de l'OS mais des drivers mal fait, drivers qui sont blacklisté et désactive WebGL. On a déjà vue pire pour des drivers réseaux et c'est hautement plus crucial car faire planter serveur ca n'a pas le même impact qu'un poste client. Du coups, je débranche internet?
A noter que les sources de WebGL (les shaders) sont aussi compilé à la volé, un peu comme le javascript donc il est possible de le rendre parfaitement sécurisé, soit en faisant des vérifications formelles soit en ajoutant des watch sur les opcodes bas niveau ou un mix des deux. Le problème, j’imagine, c'est que les fabricants doivent préférer le faire eux même car ca impacte beaucoup les performances. Je crois qu' ANGLE* fait une partie de ces vérifications (*la lib ajoutant OpenGL ES au dessus de directX)
C'est le cas pour toutes nouvelles fonctionnalités et pas seulement dans le monde du navigateur mais aussi dans le kernel, les solutions de virtualisations (oui je triche, un navigateur c'est un OS virtualisé pour moi)...
Je ne sais pas si j'ai été clair et je m'excuse si ce n'est pas le cas : j'ai tendance à m'égarer dans mes propos.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . Évalué à 4.
Oui mais là le problème ne vient pas d'un bug... mais d'une fonctionnalité de la spec !
Java a été conçu pour que le code qui s'exécute soit entièrement contrôlable (bytecode + VM), bref une sandbox pour exécuter du code potentiellement non-sûr. Je ne sais pas s'ils l'ont fait en pensant au web, mais le fait est que cela répondait déjà à la problématique. OpenGL n'a jamais été conçu avec ça en tête.
Je ne dis pas que c'est impossible : je constate juste qu'ils font fasse à des problèmes issus d'OpenGL, qui semblent être "by design" dans la spec. Bref, je pose la question : est-ce la bonne voie ?
Je ne dis pas ca, je pose juste la question : ne peut-on pas faire autrement ?Comme trouver un meilleur compromis entre API bas-niveau proche du GPU et sécurité ? Là on multiplie les risques : nouvelles API (surface d'attaque plus importante), basées sur des trucs non pensés pour la sécurité (OpenGL).
[^] # Re: ca fait peur
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
Bah vu qu'ils ont sorti le navigateur HotJava peu après les débuts du langage, on peut se douter qu'ils pensaient bien au grand Web mondial...
[^] # Re: ca fait peur
Posté par BAud (site web personnel) . Évalué à 2.
et la prise de courant ainsi que l'alimentation, pour éviter tout reboot intempestif : voilà, tu es en sécurité ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.