The recent suggestion that WebGL 1.0 has security holes launches the wrong set of fears. Jon Peddie takes a closer look.
When Khronos launched the WebGL specifications with strong backing from Mozilla, Google, Apple, and Opera, we thought at last peace had come to the 3D web valley. We should have known better; seems that there are competing vested interests in proprietary software and plug-ins that will put a few bumps in the road in WebGL’s journey to pervasiveness.
Last week we were told by Microsoft, the developers of Silverlight, that WebGL is a giant piss-hole into which any yahoo can pour viruses, spoofs, and even DoS attacks — ack! The sky is falling, Run! Run! Run! The post at Microsoft Security Research & Defense was titled simply, “WebGL Considered Harmful.”
In a post by James Forshaw of Context, “an independent information security consultancy,” in London, WebGL (it is suggested) is a great big welcome sign to all the malcontents and malicious code writers on the web, which we must assume number in the millions. Some have suggested WebGL needs to be redesigned from the ground up due to security concerns.
Khronos, as you might expect, has answers to these concerns. The Khronos view is that any new browser capability exposes new code that inevitably needs to be hardened. Any GPU accelerated capability—be it HTML, Canvas, WebGL, Adobe Molehill, Silverlight 5, etc.—will require the graphics drivers to be hardened. This is an inevitable process that needs to be managed carefully—and WebGL is the right technology to spearhead this process, as it has the backing of the browser and GPU communities.
Khronos says they would welcome Context and/or Microsoft to join Khronos to help the industry move forward on secure, accelerated graphics for the Web.
Why has this come up?
It looks a little suspicious that the Microsoft Blog appeared on the same day as a Context security report that it was referring too. Why would Microsoft do such a thing? Some suspect that as Silverlight 5 will include 3D, someone doesn’t want to see WebGL become widely used.
Conspiracy theories aside, Context did raise two valid issues to be addressed by the WebGL implementations as the industry goes through the hardening process. Context demonstrated that a shader program could implement a loop that could be used to approximately reconstruct an image from another domain—a serious potential security hole. Khronos had previously debated on its open mailing list whether this was a real-world possibility and once the exploit was demonstrated by Context, Khronos worked swiftly with the WHATWG (Web Hypertext Application Technology Working Group) to mandate the CORS spec (Cross Origin Resource Sharing) in both the HTML and WebGL specs to make sure servers have to explicitly allow access to media assets across domains.
The second valid concern raised by Context is that a WebGL shader program can, deliberately or not, take a long time to execute, causing the graphics card and system to become unresponsive, effectively a DoS attack. Khronos is fully aware of this and has posted a security white paper that explains how the group has developed ARB robustness extensions to enable a system to cleanly recover from such a situation. It has also discussed other security issues: http://www.khronos.org/webgl/security/.
Confusion in the industry
It’s clear that Khronos needs to educate the industry on the technology and the process underway here. The next step is that Khronos is preparing an imminent WebGL 1.0.1 release that will fix bugs in the current conformance tests and tighten the screws on resolving any security issues that have arisen.
WebGL 1.0.1 should start allaying fears in the industry as the spec will take a 100% robust stance on security; implementations that pass the conformance tests will be able to remove the “experimental” from the getContext (“webgl”)query — giving content developers the confidence they working with a secure WebGL implementation.
What do we think?
The basic security concern is that graphic drivers are being exposed to the Web in more direct ways than before—which is true—and they will need to be hardened. But that’s true of WebGL, Adobe Flash, Silverlight and Canvas. If we can never expose any graphics drivers to the web, we can never have any GPU graphics in the browser—and that’s not going to happen.
Khronos has the right attitude that this is an inevitable process that needs to be carefully managed. This is why Khronos is precisely the place where WebGL needs to be developed—we need the GPU and browser vendors working side-by-side to make sure the browsers and graphics drivers work together to provide overall security.
If these security reports are smear tactics then they will never work. These kinds of tactics always backfire. If, as it is being rumored, they are sponsored by Microsoft, they will do more to discredit the company than help it. Consumers are a lot smarter today than too many manufacturers give them credit for. And, as proven in the Mideast, communications among peers and friends is at the speed of light. There’s an awful of smart people in Khronos and this isn’t their first time at bat. They know the issues, know how to deal with them and they will. If Context is looking for PR, we suggest a better path would have been for them to have taken their concerns directly to Khronos. And if Context is really seriously interested in moving the industry forward they should join Khronos and help fix any problems they discover.
However, security issues and bugs always occur. So we will be watching carefully to see how Khronos manages the situation. In the shorter term when issues arise, browser vendors are maintaining white and black lists so compromised systems can have WebGL disabled until mitigation is developed.
Longer term we expect GPUs will provide increasingly robust security and multitasking to enable the GPU to truly become a first-class computing platform longside CPUs.
Jon Peddie is president of Jon Peddie Research, publisher of GraphicSpeak. This article originally appeared in TechWatch, the JPR newsletter.