Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
bah alors pourquoi râler si la décision de crosoft ne changera rien.
après sur ce ballot screen, il me semble que ça déjà été discuté de la débilité de la décision. de plus celui qui s'est plaint, bah il a pas beaucoup décollé depuis
coupable de leur cupidité ... si on pouvait éviter de sortir les adeptes du "tout le monde il est beau, tout le monde il est gentil".
ça c'est un problème lié au RIA, pas à la 3D. Silverlight, FLash, Flex et javaFX ont exactement le même problème.ce qui m'épate avec ces types, c'est qu'ils pensent que la 3D par le navigateur c'est l'avenir ... mais l'avenir de quoi? des sites web en 3D, des applications dont on ne contrôle pas les données parce que utilisé à travers un navigateur, du cloud en somme.
A partir du moment où l'on quitte le format texte pour du binaire, on perd toute la flexibilité qui va avec.
Moi ce qui me ferait plaisir, c'est si on pouvait sortir du Forum tous les fans boys mono-Microsoft/Apple/Linux, qui crache sur logique, éthique et bon sens juste pour pouvoir rester assis sur leurs petits acquis liés à leur formation.coupable de leur cupidité ... si on pouvait éviter de sortir les adeptes du "tout le monde il est beau, tout le monde il est gentil".
Ne jamais oublier que c'est parce que d'autres ne pense pas comme vous, que le monde évolue.
It's not a bug, it's a feature
Si Microsoft a dans l'histoire d'autres intérêts que la seule protection des utilisateurs, il n'empêche que leurs critiques me semblent fondées et que vu la surface d'attaque au niveau des drivers, il ne suffira pas de quelques vérifications ici ou là ou d'une "culture de la sécurité" de la part des constructeurs (au détriment des performances : chacun appréciera diversement). J'ai plutôt l'impression qu'on devrait jeter ce standard aux oubliettes et en refaire un autre.
Le problème c'est que je trouve l'attitude de la fondation Mozilla légère dans l'affaire. Un discours à coups de comparaisons hasardeuses et d'approximations, qui nous promet d'abord que tout va bien avant d'expliquer que, bon, oui, il y a des problèmes mais que tout ça finira par s'arranger une fois les drivers sécurisés (avant 2020 si possible, vu les antécédents des constructeurs). Pour le coup, l'image que j'avais d'eux s'en trouve sacrément écornée. Et je note le silence de Google, caché dans le fond, comme s'il voulait se faire oublier et laisser Mozilla prendre les coups. Pas de doute : Mozilla n'a pas le même budget com' que les deux autres.
En attendant, Chrome et Firefox offrent tous deux des moyens de désactiver le support webGL, avis aux amateurs.
c'est ton avis pas un avis generalece qui m'épate avec ces types, c'est qu'ils pensent que la 3D par le navigateur c'est l'avenir ... mais l'avenir de quoi? des sites web en 3D, des applications dont on ne contrôle pas les données parce que utilisé à travers un navigateur, du cloud en somme.
quand a la pub en 3D il faut arreter de penser nimporte
évolue, ça signifie pas nécessairement dans le bon sens.Envoyé par Firwen
de plus loin de moi d'être un fanboy, puisque même l'accès au gpu par flash, silverlight ou même la cafetière, je trouve ça tout aussi dangereux.
et encore tu m'as pas vu il y a quelques jours pester parce que j'ai pas trouvé d'accès à l2cap autrement que d'écrire un code en kernel mode sur windows.
de plus je suis d'une formation en développement 3D, ça me ferait absolument pas bouger le cul de ma chaise vu que c'est ce que je fais tous les jours.
peut être que plus simplement je réfléchis 2s et que je regarde d'abord les conneries que ça peut amener avant de glorifier une techno. surtout une qui touche à ce que je sais faire ...
ensuite pourquoi pas les pubs en 3D, ça serait justement le contraire qui serait étonnant. le pékin moyen, ça lui tape dans l'oeil direct.
et oui c'est mon avis, pourquoi le mien ne serait il pas aussi cohérent que le leur?
finalement j'oubliais, et l'avis de Carmack, c'est du pâté? ou alors puisque ce n'est pas votre avis vous vous en foutez?
Peut-être qu'il s'agirait juste de considérer WebGL comme une extension (ce qu'il est finalement actuellement) et de l'annoncer comme tel à l'utilisateur final, en lui indiquant les risques que ça comporte ? A priori, il n'y a pas plus de risque que d'utiliser d'autres plugins, extensions, activeX, etc. non ?
Je ne connais pas très bien les limitations d'accès des différentes extensions, activeX, etc. au zone de l'OS client.
Enfin bref, j'ai un peu de mal à voir le problème finalement. Si je télécharge une appli compilée, je m'expose aux mêmes types de risques d'exploitation de failles de drivers, de vol de données, etc. ? Si les drivers ne sont pas sécu, le problème est le même en local, il me semble.
Vive les roues en pierre
totalement d'accord, dans ce cas pourquoi considérer microsoft comme le grand méchant alors que son navigateur perd des parts de marché et que tout le monde s'en réjouit.
si c'est si important ce support, il suffit d'écrire une extension à ie pour la prise en charge.
@Djakisback
Par rapport aux autres extensions, la plupart d'entre elles doivent présenter une surface d'attaque plus restreinte : souvent, seule une petite partie du code y est potentiellement dangereuse et peut donc faire l'objet d'attentions particulières. Mais pour webGL, c'est le driver qu'on attaque : il est gros, peu sécurisé et développé par des tiers.
En revanche une application traditionnelle demeure plus risquée, oui. Mais il y a une grosse différence entre une faille qui nécessite que tu installes et exécutes une application et une autre exploitée dès ton atterrissage sur une page, parfois contre ton gré. Les technos web réclament plus de prudence.
Ça c'est la théorie, dans les faits on installe flash et silverlight, et le contenu se lance automatiquement qu'il soit en 2D ou en 3D.Mais il y a une grosse différence entre une faille qui nécessite que tu installes et exécutes une application et une autre exploitée dès ton atterrissage sur une page, parfois contre ton gré.
Il n'y a qu'une solution : mettre par défaut un bloqueur de WeGL ET un bloqueur de flash et silverlight dans le navigateur (et pas seulement via des plugins).
Je t'invite à reprendre la discussion au début, la partie de mon message que tu cites répondait à Djakisback à propos d'applications proprement dîtes (exécutées offline), pas de plugins pour navigateur. Ces plugins étaient quant à eux traités dans la première partie.
A part ça, d'accord avec toi sur les deux points. Il me semble d'ailleurs avoir lu que Chrome ou Firefox allait s'enrichir d'un bloqueur de plugin par défaut, type Flashblock (contenu remplacé par un cadre sur lequel il faut cliquer pour charger l'original). Il serait plus que temps ! Surtout qu'on ne peut sans doute pas faire ce genre de plugin pour bloquer webGL : le seul élément associé dans le DOM est un bête canvas, c'est via le JS qu'on amorce un rendu GL dans ce canvas, sans transformation du DOM.
Finalement, pas tant que ça je trouve, du moment où tu as accepté de prendre le risque et que tu acceptes cette fonctionnalité, mais c'est une autre manière de voir les choses.
Et Flash, BS Contact ou d'autres plugins ont bien accès aux drivers également ?
Du coup, je me dis que peut-être au contraire, plutôt que d'avoir une myriade de plugins tiers utilisant directement l'accélération matériel, les navigateurs pourraient centraliser tout cela en forçant le passage par WebGL, ce qui réduirait les points d'entrées à des zones sensibles à une seule et unique API et en théorie accroîtrait la sécurité ?
Mais en fait savez-vous s'il est possible d'exécuter du code potentiellement réellement dangereux depuis la VRAM ? (je ne parle de "simples" plantages ni de récupérer son contenu, comme dans la faille spécifiée mais par exemple d'injecter et d'exécuter du code comme ça peut se faire en RAM). Peut-être dans le cas des chipsets utilisant la RAM ?
(Je me réponds à moi-même, en fait, les drivers manipulent aussi forcément la RAM)
Vive les roues en pierre
Ah oui, j'ai parcouru le fil trop vite ! Désolé.Je t'invite à reprendre la discussion au début, la partie de mon message que tu cites répondait à Djakisback à propos d'applications proprement dîtes (exécutées offline), pas de plugins pour navigateur. Ces plugins étaient quant à eux traités dans la première partie.
Pour Chrome c'est certains. En ce qui concerne Firefox les possibilités du système classique de plugin vont très loin (je ne parle pas du nouveau système de plugin installable à chaud), c'est peut-être faisable.Surtout qu'on ne peut sans doute pas faire ce genre de plugin pour bloquer webGL : le seul élément associé dans le DOM est un bête canvas, c'est via le JS qu'on amorce un rendu GL dans ce canvas, sans transformation du DOM.
@Djakisback
Il y a une grosse différence entre webGL et les Flash, Silverlight et compères : le premier autorise une manipulation bas-niveau de la CG (on cause presque directement au driver), les seconds reçoivent des objets de haut niveau (maillages et textures) définis en code managé et ce sont leurs moteurs qui se chargent de choisir les détails du procédé de rendu et les instructions à donner au driver. C'est beaucoup plus limité mais ça ne produit que des flots d'instructions relativement banals qui présentent moins de risques.
Alors si techniquement il est possible de faire reposer tout ça sur webGL, du point de vue sécurité ça n'apporte pas grand chose puisque ce n'est principalement pas webGL qui contiendrait les failles mais les drivers derrière. WebGL peut toujours se livrer à des vérifications ici ou là mais tout n'est pas vérifiable et ce qui l'est n'offre pas pour autant une garantie : conformité au standard ne veut pas dire inocuïté. Une séquence d'opérations peut être licite mais causer un bug dans le driver. C'est tout le problème de webGL : la sécurité repose beaucoup trop sur le driver.
Pour ta seconde question, c'est plutôt avant que les données n'atterrissent dans la VRAM que le bât blesse (le driver, toujours lui). Mais on peut toujours imaginer une faille qui causerait l'exécution de code malicieusement stocké comme donnée dans la VRAM et rapatrié ensuite pour finir exécuté par le CPU. On a bien vu des shaders contenir des codes malicieux de ce genre. Mais encore une fois ça repose sur un bug du driver.
c'est n'importe quoi ...
D'accord avec la personne qui a dit que la 3D dans les navigateurs c'est n'importe quoi:
Vous vous surfez sur le web avec vos ptite lunettes 3D et sans parler des risques sur la santé (fatigue des yeux), je n'aimerais pas surfer obligatoirement en 3D. Bientot les pubs et tout ca seront en 3D. Cela crée des failles de sécurités immenses en plus (celle montrée ici n'est qu'un exemple) mais j'ai déja vu sur chrome qu'on pouvais cpier le disque dur de la personne infiltrée (j'ai téstée sur le pc de mes parents ...)
Bref, risques de santé/sécurité et je ne pense pas que la 3D est sa place dans les navigateurs mais seulement dans les films par exemple ? Mais surtout Pas dans internet
On ne parle pas vraiment de cette 3D là ... mais simplement de la bonne "vieille" 3D avec des polygones, des shaders et des trucs auxquels je pige rien.Vous vous surfez sur le web avec vos ptite lunettes 3D et sans parler des risques sur la santé (fatigue des yeux), je n'aimerais pas surfer obligatoirement en 3D
La 3D avec les lunettes n'a absolument rien à voir avec la discussion. On peut faire ce type de 3D sans WebGL, on peut utiliser WebGL sans nécessiter de lunettes (c'est d'ailleurs le cas à 99%).
Quant aux publicités... je ne pense pas que ça changera grand-chose. Les publicités ne sont généralement pas interactives. Ce sont des images, des animations, parfois des vidéos... qui sont déjà en 3D ! Quand on filme quelque chose ou prend une photo, c'est naturellement de la 3D. Pour de la publicité non-interactive, WebGL n'apporte pas beaucoup, c'est tellement plus simple pour les graphistes d'utiliser leurs outils habituels que d'écrire du code, qui d'ailleurs ne tournera pas partout (selon le type de machine, de carte graphique et de navigateur de chacun).
Les applications de WebGL sont tout simplement les mêmes qu'en OpenGL et DirectX que l'on a depuis longtemps. C'est avant tout les jeux (donc, concurrence à Flash) et autres applications 3D. Par exemple, si on modélise un lieu en 3D, on peut proposer une visite virtuelle (et l'utilisateur contrôle la caméra). De la même façon que l'on trouve des adaptations d'Office pour le web, on trouvera aussi des logiciels 3D. Tout cela viendra, d'une façon ou d'une autre.
Enfin, la réaction de Firefox et Chrome se comprend. Mais comme à chaque fois, c'est politique. Pendant longtemps, les navigateurs avaient des incompatibilités au niveau du HTML, CSS et Javascript. Ces différences ont été quasiment gommées, mais la guerre de technologie continue et d'autres incompatibilités apparaissent (WebGL ne marche pas partout, mais Flash et Silverlight non plus).
Si on utilise Flash, ça fait un "point d'entrée" à sécuriser. Si on utiliser WebGL, ça fait autant de points d'entrée qu'il existe de navigateurs. Est-ce mieux ? Mais le vrai "problème" est que chacun veut continuer à développer sa solution. Va dire à Adobe d'arrêter de faire Flash. Va dire à Microsoft d'arrêter Silverlight. Va dire à Google d'arrêter de pousser WebGL. Pas sûr que l'un d'eux t'écoute... D'un autre côté, on peut aussi se dire que c'est le jeu de la concurrence, que chacun essaiera de faire mieux que le voisin et que le meilleur s'imposera dans quelques années.Du coup, je me dis que peut-être au contraire, plutôt que d'avoir une myriade de plugins tiers utilisant directement l'accélération matériel, les navigateurs pourraient centraliser tout cela en forçant le passage par WebGL, ce qui réduirait les points d'entrées à des zones sensibles à une seule et unique API et en théorie accroîtrait la sécurité ?
Quand tu télécharges une application et l'exécute, elle n'a pas besoin de passer par la carte graphique pour supprimer ou voler tes données. Je ne sais pas pour toi, mais la plupart des gens se méfient quand il faut télécharger quelque chose. On n'exécute que des applications de confiance. À l'inverse, on se méfie moins quand il faut cliquer sur un lien, tout simplement parce que le navigateur n'autorise pas une page à accéder à ton disque dur. La question est de savoir si l'accès à la carte graphique devrait interdit comme l'est celui au disque dur. En théorie, on aimerait lui donner l'accès s'il n'y avait aucun risque majeur. Attendons donc de voir comment les choses évoluent.Enfin bref, j'ai un peu de mal à voir le problème finalement. Si je télécharge une appli compilée, je m'expose aux mêmes types de risques d'exploitation de failles de drivers, de vol de données, etc. ? Si les drivers ne sont pas sécu, le problème est le même en local, il me semble.
Tu n'es jamais tombé sur une publicité interactive ? Genre des jeux bidons ou des animations qui demandent de pointer avec la souris à des endroits spécifiques ?
Pourtant il y en a (pas des tonnes non plus) mais la plupart des publicités peuvent se faire via des .gif ou autres ça ne dérangerait personne. Bizarrement la plupart sont en flash.
Alors ne t'inquiète pas, je suis sûr que pour faire classe les publicités exploiteront WebGL.
"Attention le site que [blablabla...] technologie webGl [blablabla...] potentiellement dangereux [blablabla...] si vous faites confiance [blablabla...] cliquez [blablabla...] ne plus poser cette question [blablabla...]"
Rien de neuf dans ce qui peut être entreprit en toute simplicité par les développeurs de navigateur sinon le terme webGL.
Il ne leur reste plus qu'à y songer.
C'est pas pire qu'une applet java ou qu'un https dont le certificat n'est pas/plus valide/vérifiable.
Most Valued Pas mvp
Au premier abord cet article m'a fait sourire, bien que n'ayant rien contre les stratégies de M$ qui font quand même pas mal bouger les lignes (sans directx, opengl serait surement encore à la version 2.0 et encore), j'ai quand même cru à de la mauvaise fois au début sur leur propos de WebGL pour favoriser leur solution SilverLight. En y pensant mieux il est vrai que c'est vraiment très dangereux de laisser un accès au matériel, un shader mal codé, une boucle infini et vous êtes bon pour redémarrer votre machine, et même si ce shader marche sur la plupart des machines il fera peut-être planter la votre.
Quelqu'un a parler plus loin, du fait que les constructeurs devront d'abord sécuriser les drivers, ce qui n'est pas possible, il n'est pas possible de savoir si un shader fera planter la carte graphique tant qu'il ne l'aura pas réellement fait planter, et le drivers ne va pas émuler la carte graphique pour vérifier cette hypothèse. Ajouter une couche sécurité c'est quasiment perdre l'intérêt d'avoir une carte graphique si on peut dire.
En conclusion il est vrai que le seul moyen viable est d'avoir une surcouche qui elle est sécurisé, mais forcément bien plus limitée, une sorte de silverlight en gros :s même s'ils peuvent aller se fai... pour que je l'installe
Cela vient de sortir. Silverlight 5 n'est pas du tout sécurisé pour WebGL.
http://www.readwriteweb.com/hack/201...ht-has-the.php
A lire ^^
Un jour quelqu'un a dit :
Je ne savais pas qu'il fallait faire correctement ...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager