a three-dimensional platform

Firefox now includes, on all desktop platforms, support for a technology known as WebGL. WebGL allows web developers to use accelerated 3D graphics, including textures and shaders; it exposes the same capabilities used by games like Doom 3 and (optionally) World of Warcraft, and virtually every game that runs on the iPhone, OS X, Android or Linux.

Security professionals, including Context IS, have discovered bugs in the specification (related to cross-domain image loading) and in Firefox’s specific implementation. Both are being addressed, as with security problems in any other technology we ship, but recently the conversation has turned to inherent security characteristics of WebGL and whether it should be supported at all by browsers, ever.

I think that there is no question that the web needs 3D capabilities. Pretty much every platform has or is building ways for developers to perform low-level 3D operations, giving them the capabilities they need to create advanced visualizations, games, or new user interfaces:

  • Adobe is building 3D for Flash in a project called “Molehill“, about which they say: “In terms of design, our approach is very similar to the WebGL design.”
  • Microsoft is doing something similar with Silverlight 5, where they’re bringing XNA Graphics to Silverlight 3D.

Adding new capabilities can expose parts of the application stack to potentially-hostile content for the first time. Graphics drivers are an example of that, as are font engines, video codecs, OS text-display facilities (!) and image libraries. Even improvements in existing capabilities can lead to new types of threats that need to be modelled, understood, and mitigated. We have a number of mitigations in place, including a driver whitelist that’s checked daily for updates; this seems similar to the driver-blocking model used in SL5, based on what information is available. Shaders are validated as legal GLSL before being sent to the driver (or to Direct3D’s HLSL compiler), to avoid problems with drivers mishandling invalid shader text. We’re also working with the ARB and driver vendors on extensions to OpenGL which will make the system even more robust against runaway shaders and the like.

Microsoft’s concern that a technology be able to pass their security review process is reasonable, and similar matters were the subject of a large proportion of the discussions leading to WebGL’s standardization; I also suspect that whatever hardening they applied to the low-level D3D API wrapped by Silverlight 3D can be applied to a Microsoft WebGL implementation as well. That Silverlight supports Mac as well, where these capabilities must be mapped to OpenGL, makes me even more confident. The Microsoft graphics team seems to have done a great job of making the D3D shader pipeline robust against invalid input, for example. (The Windows Display Driver Model in Vista and Windows 7 is a great asset here, because it dramatically reduces the “blast radius” of a problem at the driver level. This likely explains the difference between default-enable and default-disable for WDDM/non-WDDM drivers in SL5′s 3D support. It’s not yet clear to me what the model will be for SL5 on OS X.)

It may be that we’re more comfortable living on top of a stack we don’t control all the way to the metal than are OS vendors, but our conversations with the developers of the drivers in question make us confident that they’re as committed as us and Microsoft to a robust and secure experience for our shared users. Web developers, like all developers, need good 3D support, and — as with Flash and Silverlight — browser implementers will need to be careful and thoughtful about how to expose that functionality securely on all operating systems.