Silverlight Has the Exact Same Vulnerability That WebGL Does
readwriteweb.com
readwriteweb.com
This storyline, like so many others, serves as an occasion for people to line up with one team or another and make whatever arguments support Google, Microsoft, Apple, Facebook, or whoever they're rooting for.
But obscured behind all that smoke is a subtle, nuanced conversation to be had about the problem itself: What are the essential performance vs security tradeoffs? What can be done about them? And then there are larger issues, like this: A curated app store model where code is vetted and apps are run in a sandbox might significantly reduce users' vulnerability to attacks like this, but at what cost, both to users, developers, and those running the app store?
Furthermore, these standards often haven't been well vetted. As I noted before C++ ran into this problem with export. It caused no end of headaches and wasted time. It was eventually effectively dropped (although EDG did appear to get a decent implementation in-place finally).
At the end of the day each vendor should feel they have the freedom to implement what they deem as important. Other vendors should respect it. Whether its Apple not supporting Flash (not a standard, but hugely popular) or MS not supporting WebGl (a draft, but not widely used).
This isn't to say that Silverlight is the solution - but rather that the idea of giving browsers a generic ability to bypass the operating system and access the hardware is different from how Silverlight is implemented in the vast majority of cases. The Silverlight implementation is provided by the OS vendor not a third party.
It's not that WebGL doesn't have a reasonable goal, but design a sandbox without a lid and you wind up with cat turds. A system which depends on the priority which the authors of graphic card drivers assign to security and mass market hardware vendors assign to driver updates and continued support within the consumer segment doesn't seem like a plan consistent with the potential for mischief the web offers.
The article from the Google guy a few days ago said their approach is that they an include in WebGL workarounds for all the buggy drivers. That approach has no chance of working.