He has some good points and I like the description of safe-ish implementation of webgl in chrome. But I think the main point he misses with the Silverlight/Flash comparison is manageability from a security point of view. Running a plugin is different from using a feature in the browser - people often disable the plugins and are conscious about plugins being an attack surface so the admins often deploy policies disabling use of plugins.
> Running a plugin is different from using a feature in the browser - people often disable the plugins and are conscious about plugins being an attack surface so the admins often deploy policies disabling use of plugins.
1. It's not hard to expose a way to disable WebGL support, especially for admins. And no, overall people do not often disable plugins and they're not very conscious about plugins being an attack surfaces (though admins may be).
2. Are you saying it's OK to ship technologies known to be broken as long as it's in a plugin? Do you really think that makes sense?
Are you saying it's very hard to implement a checkbox to disable WebGL? A lot of browsers protect you from opening or resizing windows via Javascript. How could disabling WebGL be more complicated? My browser is even warning me when a Javascript is running slow.
I mostly agree, but there's a bit more to it than that. For example, you want to be able to report back to the page that WebGL is disabled, so that whatever content is supposed to be there can degrade semi-gracefully.
The author actually misses something SUBSTANTIALLY more important. He asserts that SL has the same problem as OpenGl, but never proves it. If Java has a bug in its type system then does C# also? Maybe, but maybe not. You can't infer one system does because another does based on the fact that both systems achieve somewhat similar goals.
Context went through the effort to do a proof of concept to show the OpenGl flaws. I think Google and Mozilla should at the very least show these same flaws exist in SL before asserting they do.
