WebGL was bleeding-edge when IE 9 was released, and there were still very valid concerns about its security for a while after that. Opera implemented it, but disabled it due to these concerns. After their nightmarish history with security, Microsoft are very focused on hardening Windows — so I wouldn't exactly call it regressive to leave WebGL out of IE 10, which was probably feature-frozen in early 2012.
It is fair to say that there were some security concerns, but those have been addressed, and actually Microsoft - which controls the OS and the browser, and is heavily involved in driver quality - is in an excellent position to create a safe implementation of WebGL.
It's fine that it took them time and they wanted to do it properly. It is however annoying that they did not give any forward notice of their intention to implement WebGL and have not been active in the standards bodies at all. For example, Microsoft input on the safety aspects could have been very useful.
Opera didn't disable it due to security concerns per se — rather more just the general bugginess of Opera's hardware acceleration. I wouldn't consider crash bugs in general security issues. Equally, there is software rendered mode, but it's pointlessly slow to enable.
Note the prior concerns are still just as true today as they were a few years ago — graphics drivers are still relatively easy to find crash bugs in, leading browser vendors to try and hack around and avoid hitting those bugs in all too many cases. :(
> I wouldn't consider crash bugs in general security issues
You should, until proven otherwise. If it crashes because it's reading an invalid memory location (for instance), it's a matter of time before someone figures out how to place executable code there.
I have no problem with MS's original position. WebGL forces your hardware drivers to run random code downloaded from the internet. I'm frankly surprised that the other browser vendors ran ahead with it so quickly and that we haven't heard about any exploits caused by it.
On that matter, it is not difficult for someone who knows how to use WinDbg or similar to see if a crash is exploitable. For example, in user mode, null pointer accesses are generally not exploitable. I personally was able to get an IE6/IE7 bug described in http://www.satzansatz.de/cssd/pseudocss.html#fltadjacent fixed in the May 2013 security update by proving there is an exploitable crash.
Most crashes as shipped are just the shader over running maximum time and it being killed, AIUI, rather than actual segmentation faults or attempts to read garbage. Most actual known issues that are potentially security concerns are worked around through preprocessing what the driver gets, and given the level of testing I don't worry about it more than any other OS component security wise. The biggest risk would probably be a new driver release shipping with bug leading to exploitable code being executed.
Also, if I'm not mistaken Chrome shipped first: and they'd done masses of fuzzing of both their code and the drivers. Nobody really rushed into it, everyone keeping it off by default for an unusually long time to catch issues before shipping.
