TImaniac a écrit 6423 commentaires

allouer de la memoire en JS

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.

une simple page web avec beaucoup de grandes images, surtout sur un navigateur qui utilise le GPU

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".

FF a eu il ya longtemps un bug provoquant un freeze du browser.

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.

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.

Toutafé, raison de plus pour éviter d'exposer des API aussi bas niveau qu'OpenGL à une page HTML+JS.

Tu as des exemples concrêts de DoS inherents à la plateforme web (html+js) ?

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!

Oui mais là le problème ne vient pas d'un bug... mais d'une fonctionnalité de la spec !

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? ;)

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.

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.

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 ?

Si c'est difficile et ajoute un risque, on ne doit rien faire?

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).

Ben oui c'est bien le problème : WebGL en exposant des API trop bas niveau, rend difficile le sandboxing. La seule solution que je vois est d'exposer une API de plus haut niveau, sans doute moins puissante, mais beaucoup moins dangereuse.

C'est bien simple: on resout les bugs au cas par cas.

En terme de sécurité, se contenter de ça me paraît extrêment dangereux comme philosophie. Il faut anticiper, pas se contenter de sortir la lance à incendie quand on aperçoit les flammes.

Le sandboxing est une façon d'ajouter une barrière "globale" supplémentaire, qui limite l'impact des futurs bugs.

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 ??

specifiques a WebGL et ont tous ete rencontres aussi en dehors de WebGL.

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.

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.

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 !

Je te parle d'utilisation, pas d'implémentation.

Ces aspects de la securite sont certes tres importants et interessants, mais meritaient-ils vraiment d'etre ainsi exacerbes au detriment d'autres aspects?

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" ?

Pas de modification de l'engagement.

En tout cas la FAQ est clair, à la question l'usage modem du téléphone est-elle autorisée, la réponse est "oui".
La limitation contractuelle est donc bien sur le type de device, et pas sur la fonctionnalité de partage en soit.

Mouais, après la bataille pour la définition de "accès internet", voici la bataille pour la définition du mot filtre qui s'ouvre :)

Un filtre c'est "choisir" ce que tu laisses passer ou non (bref, ne pas être neutre), pas limiter la quantité qui peut passer à un instant T. En tout cas moi c'est comme ca que marche les filtres dans ma cuisine et les filtres sur mon oscilloscope ou sur ma chaîne HiFi.

Pour faire une analogie (comme d'hab, ca vaut ce que ca vaut), limiter à 100 connexions TCP s'apparente plus à un entonoir qu'à un filtre.

Au bout de 3 Gio téléchargé, ton débit est suffisamment bridé pour que ce ne soit pas utilisable.

Ok, donc tu préconises bien un bridage, par le débit : toi non plus tu n'as donc pas de solution miracle. Et encore une fois : pourquoi ce bridage là te semble plus acceptable que la limitation de 100 connexions TCP ? (A part crier au scandale parcqu'on tape pas dans la même couche réseau et que c'est de la violation de ta vie privée pour 2 malheureux paquets ?)

Si leur crainte c'est de voir 3 million de personnes télécharger à 300Kio/s en même temps ils n'ont qu'a limité le débit en fonction de ce qu'ils sont capable de fournir derrière

et si le problème n'était pas le débit mais le fait que tout le monde ouvre 1000 ports d'un coup ?

Ca veut dire quelque chose dans le langage juridique :

http://www.lawperationnel.com/EncyclopedieJur/bonperedefamille.html

On me propose une connexion jusqu'à 3 Go/mois, ce qu'il y a derrière ne les regarde pas. C'est ça la neutralité.

Ca c'est la jolie théorie, en pratique il ne faut pas que le réseau sature à cause d'usages "bourrins".

On propose une connexion à 3Go/mois et 100 connexion TCP simultanées max. T'as 2 limitations et les 2 sont aussi "neutres".

Ce qui serait non neutre, c'est d'interdire un protocole explicitement, de baisser la bande passage en fonction de l'IP cible (tiens c'est megaupload, on bride, et pourtant dans ta définition c'est bien au niveau IP comme outil).

Faut arrêter 2 minutes : regarder le protocole et les port, c'est ouvrir les enveloppes. C'est privé aussi.

C'est à peu prêt aussi privé que de lire "à l'intention de M.Richard" sur une enveloppe. En théorie on est d'accord que c'est privé, mais ca n'a quand même rien de comparable avec ouvrir l'enveloppe.

Ca tombe bien, le protocole du dessus et port n'a rien à voir avec la QoS. une trame IP ne change pas de danger suivant le protocole et port.

Je penses pas que limiter à 100 connexions TCP soit une forme d'atteinte à tes communications privées : pour moi s'ils grimpent d'une couche dans le modèle ISO, l'objectif est pour Free (à mon avis) de limiter l'utilisation "lourde" de la connexion depuis un pc si le tel est en mode routeur. L'objectif étant bien derrière d'avoir un certain niveau de QoS sur le réseau. C'est bien une limitation, qui, pour l'utilisateur finale est à peu prêt aussi chiante que limiter le débit ou limiter la quantité de données. Dire que y'en a une d'acceptable et pas l'autre, juste en se basant sur le modèle théorique ISO, c'est juste de l'enculage de mouche pour tenter de justifier ce qu'est ou non une connexion internet "pure et idéale au sens de Zenitram" : toute forme de bridage est chiante, c'est mon point de vue.

Tu proposes quoi comme solution pour répondre à la même problématique miracle pour limiter les abus de type "modem fixe avec 3 PC derrières qui font tout et n'importe quoi" ?

Oui, le coup de l'usine est un peu réducteur, m'enfin ok, prenons le 2ème élément "clé" d'une tablette, à côté du hardware, c'est le soft : Android et Windows (les OS qu'on trouve sur tablets archos), c'est du made in France ?

Quelle réelle valeur ajoutée "made in France" qui justifierai un savoir faire technologique innovant et unique y-a-t-il dans une tablet Archos ? Non parcque n'importe quel chinois arrive à faire une tablet...

Pour reprendre ca en termes "économiques", combien de personnes chez Archos s'occupe d'un produit tablet ? C'est 1000 personnes 100 ou 10 ? La préférence nationale d'un marché à plusieurs millions de ventes doit elle être la même quand c'est 10 100 ou 1000 personnes derrière ? Surtout qu'il n'y a aucune technologie innovante et stratégique made in France derrière ?

Oué bah une tablette Samsung c'est un iPad non ? Enfin tu vois ce que je veux dire ;)

Chez moi, mscorlib, a elle seule, fait 2.5Mo.

En fait en mode de déploiement "embarqué", tu peux demander à mono de créer un subset de la lib avec uniquement les API concrêtement utilisées. 2.5Mo, c'est le poids de mscorlib dans son ensemble.

Le runtime, tu veux le partager avec quoi ??? Il n'y a rien d'autre qui tourne !

C'est pas faux.

Par contre, pour tes graphismes et le son oui.

C'est vrai.

Different pays, different ayant droit, differente regles.

Toutafé, mais on est d'accord que ca reste des devices qui ciblent bien les mêmes usages, et que le store de la XBox est largment plus conséquent que celui de la freebox, toi qui comparait au "store" de TV Samsung & co.

Pff, tu es desesperant. Je te demande une repartition entre les differents postes necessaire a la realisation du jeu.

Euh non, ca c'est peut être ce que tu voulais demander, mais c'est pas ce que tu as demandé :) T'as demandé le coût de développement, je t'ai donné un prix.

Mais ca a l'air d'etre complique de concevoir qu'il y a autre chose que du developpement en Mono...

En l'occurence moi je disais pas d'utiliser mono (ca c'était pour le débat v5 perf mémoire JS), moi je proposais plutôt Unity : environnement complet pour créer des jeux de manière portable.

Non, proprio n'est pas l'oppose de standard ! Mais c'est pas possible d'etre autant de mauvaise fois et d'essayer au tant de se rattraper a des branches pourries. Pour info, Opera est un logiciel PROPRIETAIRE qui respecte un STANDARD ! C'est deux concepts orthogonal !

Il n'y a aucune mauvaise foi, juste qu'on utilise pas le même vocabulaire pour dire la même chose. C'est quoi pour toi l'opposé de Standard alors ? (parcque au final c'est ca que je voulais exprimé). T'as compris l'idée, revenons sur le fond.

Youhou ! Le store est vide parce que personne chez Free s'en occupe sur la v6. C'est tout. La solution SDL + OpenGL ES, marche tres bien. Pas la peine de demander a qui que ce soit de tout recoder pour tes beaux yeux !

Je demande rien, et ce n'est pas pour mes beaux yeux. C'est très bien que vous ayez une solution qui marche, mais encore une fois, c'est totalement fermé, on voit rien, donc je demande des infos.

Faut arreter avec ton reve de cross plateforme. Les editeurs de jeux ont deja des solutions maisons ou du marche. Ils veulent un truc bas niveau qui marche et soit bien documente. Faut pas aller chercher midi a quatorze heure non plus.

Ben je cherche pas midi à 14h, au contraire, je pointais une solution du marche, largement utilisée par les éditeurs de jeux. J'aurai juste aimé que tu donnes ton avis sur cette solution, en quoi elle te paraissait pertiente ou non, mais visiblement tu préfères juste gueuler sur chacune de mes phrases.

le problème sur Internet, c'est que tous les intermédiaires peuvent ouvrir le paquet IP pour voir ce qu'il y a dedans : qu'il y est des limitations contractuelles n'y change pas grand chose.

Et pour l'avoir vécu, je t'assure que La Poste ouvre parfois tes paquets, et même qu'ils te volent parfois du contenu ;) Et si t'as pas pris d'assurance, tu l'as dans le cul lulu :)

e problème des FAI est qu'ils ne restent pas à leurs places. Ils veulent ouvrir les enveloppes.

Faut arrêter 2 minutes : limiter à 100 connections TCP simultanées, ce n'est pas comparable à ouvrir les enveloppes : les données privées circulent dans les couches au dessus de TCP hein.

Et de la même manière que contractuellement il y a une limite à 100 connections TCP simultanées, à la Poste tu as des limites sur les contenus que tu transportes (argent, produits périssables, etc.) Bref, il y a toujours des limitations l'idée étant d'assurer un minimum de qualité de service et de s'assurer que le réseau ne soit pas saturé par des usages non prévus.

De plus, ce n’est pas une « offre », c’est un service pour lequel on paye.

D'après le larousse, une des défition de "offre" est :

"Acte consistant à proposer à une autre personne la conclusion d'un contrat ; objet de la proposition ainsi faite."

Là on parle bien de l'objet d'une proposition contractuelle, une offre commerciale quoi.

(si un système a besoin de 101 ports TCP, hop problème : ce n'est pas neutre, ça limite)

Si j'ai un système qui a besoin de transférer 4 Go de données, hop problème : ce n'est pas neutre, ca limite.

Valable aussi sur ta connexion ADSL :

Si j'ai un système qui a besoin d'utiliser des adresses IP multicast, hop problème : ce n'est pas neutre ca limite.

Si j'ai un système qui a besoin de de 10 Mb/s en up, hop problème : ce n'est pas neutre, ca limite.

Si j'ai un système qui a besoin d'écouter sur 4 IPv4 publiques différentes pour fonctionner : hop problème, ce n'est pas neutre ca limite.

Des limitations, tu peux en mettre sur toutes les couches, le résultat est le même : tu impacts toutes les couches supérieures.

Pfff t'es pas drôle, pour une fois qu'il y en a un qui troll jusqu'au bout :)
En plus je suis sûr que t'as rien d'autres à foutre :)