Microsoft has released a blog warning us about the dangers of WebGL. It is ironic to see how skeptic the anti-Microsoft community responds to this article. Hasn’t security always been one of the main arguments against using Microsoft products? And when Microsoft points out security issues in WebGL, suddenly security is not an important subject!
It’s quite easy to shoot down their arguments as well, since as usual, they are not very well-informed. The most obvious fallacy is the one of “It’s Microsoft, don’t trust anything they say!” Well, fine, but they are not the only ones who say it. Other analysts also say the same thing, Khronos and Mozilla are aware of security issues as well (and working on them), and even OpenGL-advocate of the first hour John Carmack says that Microsoft has a point about WebGL security. In fact, proof-of-concept exploits for WebGL already exist.
So, now that we have established that Microsoft’s concerns are indeed valid, let’s move on. Microsoft argues that Direct3D would be more secure, since it depends on a single implementation of the runtime, which sits between the application and the display driver. This runtime can be secured and can act as a ‘catch-all’ filter that sits on top of the display driver. Security is then centralized, and is of no concern to the display driver developers.
OpenGL on the other hand has the entire runtime inside the driver, which means that every vendor (or even different versions from the same vendor) may have a slightly different implementation of the runtime. This is a problem that has long plagued OpenGL anyway. Not in the sense of security specifically, but in general operation, where different OpenGL runtimes have slightly different behaviour, or are just downright incompatible with eachother. I have mentioned this before, referring to Gallium3D.
Now again, uninformed anti-Microsoft souls try to claim that this is a Windows-only problem, and is the result of Microsoft removing OpenGL support from their OS. Which is wrong on several counts. Firstly, Microsoft did not remove OpenGL from their OS. The only thing that Microsoft removed was their software implementation of OpenGL, which used to be present in older versions of Windows NT. This was never a very good or fast implementation anyway (and was criticized by SGI, who had developed a much faster alternative, under the name of Cosmo OpenGL. Again, know your facts. Funny enough, Cosmo OpenGL was developed for Cosmo Player, an attempt at using 3D/OpenGL inside a browser, much like what WebGL is doing now). For hardware acceleration, you always needed a display driver supplied by your graphics card vendor (the so-called ICD: Installable Client Driver). Since all major video cards support hardware acceleration and all major video card vendors include an OpenGL ICD with their drivers, any Windows PC will support hardware-accelerated OpenGL out-0f-the-box anyway. So where is the problem? Trying to complain about removing a software implementation that is useless anyway is a bit silly. Also, Microsoft was not selective here: they also stopped supplying a software implementation for Direct3D (although with DirectX11 they started supplying one again: WARP).
Nothing has changed about this in ages, OpenGL still works the same way it always did on Windows. Are alternative OSes any different? Well, I am not entirely sure about Apple’s OS X. I believe Apple supplies at least a part of the OpenGL runtime there, so that would make it more like Direct3D in that sense. But for traditional UNIX-like OSes, where OpenGL stems from, it is no different from Windows, really. The display driver supplies the entire OpenGL runtime. People may be fooled by a project such as MesaGL, which is a free opensource implementation of OpenGL (but is not allowed to use the OpenGL trademark, that’s how open OpenGL is). Sure, this project includes a lot of display drivers, and they share a lot of code for the runtime (but it is still monolithic in nature). However, as nice as MesaGL is for video cards that do not have vendor support for linux and other OSes, the opensource drivers are no match for official binary drivers supplied by nVidia and AMD. These official drivers have much better performance, support more features, and suffer from less bugs. So these are the drivers that people will be using in practice. And indeed, these drivers have nothing to do with MesaGL, they come with their own runtime, just like in Windows.
So once again I would like to direct attention to the Gallium3D project. This is being developed as part of MesaGL, but it is still in its infancy. Most of the MesaGL drivers do not use Gallium3D yet, and the ones that do are generally not as fast yet as the monolithic legacy drivers they are replacing. But the idea is the same as Microsoft’s Direct3D: separate the common runtime functionality from the device-specific driver as much as possible. Let the device-driver do only the most basic hardware operations, and let a common runtime handle the more highlevel tasks. This would be a good starting point for building better security into WebGL and the underlying OpenGL layer.
Scali's OpenBlog™ 