Wow, this thread is turning into another security-clueless developer freakout. Microsoft very clearly laid out reasons why they believe that WebGL presents possible security vulnerabilities. While GPU security isn't my area of expertise, the driver issues seem very plausible. If someone wants to actually address Microsoft's points in this thread then that would be great.
Any game developer will tell you: It's pretty easy to accidentally craft a shader that will totally stall particular GPUs, taking down the entire windowing environment, if not the entire system. With malicious intent, shaders are a giant gaping DoS attack waiting to happen.
Beyond that, the shader compiler backends are supplied by third parties because they generate hardware specific opcodes and optimizations. Considering how poor nVidia and ATI's drivers have been historically, do you really trust them to create secure compilers?
In theory, Microsoft could implement a subset of WebGL without shaders, but I'd rather it not exist than be crippled and unusable. There are probably several other potential vulnerabilities I don't have firsthand experience with too.
All that said, I think that Java applets & JOGL already expose this attack vector.
Those, like activex controls, require the user to agree to install something that can do whatever to their system. WebGL would be available to any web site.
That should be easy enough to duplicate, just make the feature one of those "Site X wants to use WebGL. [Allow] [Deny]" things. It would make it useless for ads and such, of course, but it seems that most people want to use it for games. Might be workable.
I can also support their claims with some preliminary research I've done. When I have free time, I've been poking at the security of shader compilers -- both the translation that's done in Webkit and the compilers in drivers -- and things are pretty bad. Don't have much to show for it yet (a couple non-exploitable crashes/bugs), but I think future research will prove very fruitful.
I don't know anything about how they're doing this, but I wonder if it has something to do with the bytecode abstraction used in D3D. In D3D, you compile HLSL to bytecode which then gets passed down to the kernel, but in the OGL world you pass source straight down to the kernel. Definitely still risks there, but significantly diminished, and some simple verification in userland would make it next to impossible to get a lot of nasty code down into the kernel.
MS could (and probably would) write an Angle style abstraction layer that runs WebGL on top of D3D9 or D3D11 anyway, so I think source going to the kernel isn't a big deal.
It's possible that because MS has more knowledge of the graphics drivers work in Windows they know about some dangerous security holes that Mozilla, Google, or even Nvidia or AMD aren't aware of, but its equally possible that they just don't want to support WebGL for political reasons and this is a semi-technical excuse.
The D3D bytecode IR generated by the HLSL shader compiler in the runtime isn't verified for security concerns before being passed to the driver, so there's no real extra protection there, so ultimately D3D makes it no harder to lock the GPU than OpenGL (ES in the WebGL case) does.
It is a completely separate house / separate bed issue.
You do not have permission to call Direct3D directly. You can't even do cool hacks like you can in WPF, stealing the Direct3D video feed and writing it to a movie file. Everything is abstracted away by (underpowered) APIs.
All Secunia advisories on .NET Framework / Silverlight are presently patched, and the total number is relatively small compared to other technologies like web browsers and Flash.
I don't really know enough about WebGL to compare, though.
That blog is trolling. The blog author copied and pasted the material from the blog we are currently discussing, and replaced WebGL with Silverlight.
Silverlight is more secure than WPF, too, by the way, and has to be. For example, in WPF there is a very insecure static method that allows you to steal a bitmap of the entire screen! This was one of the first things taken out of Silverlight.
If you want to know more about Silverlight security, ask Nick Kramer who maintains the Silverlight security best practices document for Microsoft.
It's the same thing as Safari, IE, and Chrome using the GPU to composite pages: Silverlight is hardware accelerated, but does not expose the hardware acceleration primitives. GL or Direct3D expose more-or-less direct hardware access, which is very different.
Well either Google and Mozilla are knowingly shipping insecure code or Microsoft is, to some degree, wrong. Given the history of the organisations in question I'm going to assume Microsoft wrong or not telling the whole story until we hear a response from Moz or Google.
Microsoft has the perspective of the entire OS from top to bottom. Google and Firefox have the perspective of their respective applications.
Given the concerns Microsoft is voicing (and they aren't the first to voice them) are well below the application itself, I tend to trust Microsoft more on this one.
What about Apple? They're clearly working on WebGL support for Safari. They have at least equal insight into the whole stack, considering the ship the GPU drivers with the OS.
Then there's XNA in Silverlight. If they believe in the security of that, why not build WebGL on top of it? Probably because they're in direct competition with one another, and Microsoft wants Silverlight to win.
Apple has announced that, for now, WebGL on iOS will only be available to WebKit when it's displaying advertisements through iAd (where Apple controls which ads are distributed), and not to web pages generally.
I would think that security in this regard is far easier for Apple than it is for Microsoft. By virtue of their closed hardware, Apple has a very limited set of graphics cards for OS X to support. I'd imagine that this makes graphics drivers a lot easier to police and keep secure.
Let's face it, AMD, nVidia and Intel have >99% of the PC GPU market, and 100% of the Mac market. The drivers only change from one chip generation to the next, and the Mac has had chips from all recent generations from all 3 manufacturers. The total number of drivers is therefore identical. I really don't think there's much in it. See also: Silverlight's XNA.
Silverlight's integration with the host browser, DOM and Javascript is pretty good.
I'm pretty sure you could build a WebGL API on top of Silverlight by yourself. It would suck, but it is possible.
That's why I always thought Silverlight is pretty cool as a technology, as compared to Flash. Among other things, a Silverlight plugin could also allow you to serve OGG Theora videos to users.
This is an argument from ignorance and, knowing engineers at both Google and Microsoft, I have no reason to believe that the Google engineers are any more competent than Microsoft. I do know that the Google security team is smaller than Microsoft's.
Hence the 'not telling the whole story' part. Would Microsoft play politics with something like this? Not saying that's the case, only that one would have to be silly to think they wouldn't.
This is a false dichotomy. Mozilla and Google could both be unknowingly introducing the possibility of bugs and errors. The depth of their testing could be inadequate -- bugs could occur only on certain combinations of hardware and driver (and even, versions of drivers).
I believe Google and Mozilla (doesn't Safari support WebGL?) are shipping code that interfaces with insecure GPU drivers.
We cannot, however, discount the incentive Microsoft has in preventing the formation of another standard it can't control. I would consider any info coming from Redmond on this issue to be somewhat exaggerated.
Speaking as someone doing security research on WebGL but no real dog in this fight (aside from developing on WebGL on the side, making me potentially biased in its favor), nothing MS has said is Windows-specific or remotely exaggerated. In fact, they explicitly didn't talk about many potential attack vectors against WebGL, which makes me think they really don't care much about this either way.
I'm not at all an expert to handle details about the security of WebGL. I have no idea on that front.
I do know Chrome and FF just fixed a timing attack vector where you could apparently intuit the content of a crossdomain image by interpreting what hues were based on it via the application of shaders. Which means hypothetically you could read text. Like a crazy-person's OCR.
