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...
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 ?
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.
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 TImaniac (site web personnel) . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing". É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.