[cmccabe]

The security claims were bullshit. For details see:

http://games.greggman.com/game/webgl-security-and-microsoft-...

tl;dr: While it was talking up the security risk of WebGL, Microsoft was allowing Silverlight to permit untrusted code to access graphics APIs in exactly the same way. Chrome validates everything before calling the actual driver APIs, so the opportunities for fuzzing are limited.

[josteink]

> Chrome validates everything before calling the actual driver APIs, so the opportunities for fuzzing are limited.

Well I guess that's the end of the story then. Google says it's secure so there can't possibly be any bugs or risks or anything worth caring about.

Everyone: put down your work. It's OK now. Google says so.

[Paradigma11]

But in SL you had to specifically and manually whitelist the website to allow access to the graphics api.

[snogglethorpe]

If it's a user-accessible WL, that doesn't actually add much security of course, because it's pretty simple to get users to add to the whitelist ("To play our awesome game online, open up the preferences dialogue and ...").

[TheAnimus]

>open up the preferences dialogue and

Ultimately though, that is the difference between a drive by infection and user interaction required. In the same way people on the whole now are too savy to download the super-awesome-screensaver or whatever, plenty are smart enough to not say yes to some prompt.

The security model of Silverlight dare is say, is superior to that of WebGL. The guys blog post doesn't actually help the issue of "Is WebGL a worrying attack vector?" instead it starts a seperate concern about Silverlight.

[cmccabe]

If we learned anything from ActiveX, it's that "click to continue" is an ineffective defense against malware on the web-- at least for most people.

I don't think it's 100% impossible that there will be a WebGL exploit against some driver or other at some point, but I think the odds have been greatly exaggerated by Microsoft and others. The reality of modern graphics cards is that most of the action happens on the card, not on the host CPU. Combine that with Intel's recent IOMMU technology and you find that exploits usually aren't that interesting. Even if you can get control of the card, you can't do much with it.

Of course, there could be a flaw in the host driver, but it would have to be a really unusual flaw. WebGL itself stops almost all invalid input (and some unsupported valid input) from being sent to the driver, so you'd have to find a perfectly reasonable set of polygons that still triggered an exploit. It would be similar to finding an mp3 that, when played, hacked your sound card driver. It's not impossible, but it's getting into tinfoil hat territory.

[kristiandupont]

Well there is the case where you were redirected to a page you are not interested in (like popups). If confirmation is required, users will mostly close them without being exposed.

[ajuc]

It would be still useful to ask users before enabling WebGL on a site the first time. I would certainly think twice before enabling webgl if a site doesn't seem to need it. It could work like flash content with flashblock extention.

[AshleysBrain]

Don't forget they were already supporting the same things in Java and Flash.