"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."
These are all technologies that have, in fact, been a continuing source of terrible security vulnerabilities. I'm not sure of the point he's making; surely, he has to know that font and image libraries --- and even just new ways of gluing those things together, like the new CSS font goo --- actually are security threats.
I don't have much of an opinion here. Microsoft is right that WebGL is scary from a security perspective. Maybe Mozilla is right that it's worth the risk. But this is a bit of a weird post.
My point is that those technologies have been added to browsers, and we've been able to deal with the security surface. Microsoft's position is that WebGL is inherently unsecurable, and therefore somehow qualitatively and fundamentally different from doing hardware accelerated 2D graphics, JS JITs, or -- as they brag about in IE9 literature -- handing off H.264 content straight to drivers and hardware to decode.
WebGL absolutely needs care taken from a security perspective, as do video and RTC capabilities, new network protocols, and support for unicode. (The "text-display facilities" I mention were some OS-supplied ones that crashed out if given the right -- wrong -- sequence of characters to display.) Especially in light of the impending support in SL5, I don't think MSFT has made a case that this facility is actually as world-ending as they make it sound. I believe that WebGL can be secured, and am disappointed that MSFT is throwing up their hands and saying "can't be done! all gonna die!" about WebGL while they've obviously invested to the point of comfort in the equivalent SL5 APIs. On Windows, in fact, we map GL to D3D and use the same shader-compilation and API pipeline as SL5.
Advice and input from Microsoft on this would be very welcome. They know a lot about the whole (Windows) stack, though perhaps not OpenGL, and like us they had to deal with driver and D2D bugs while accelerating the 2D portions of their browser. But if they're going to raise security concerns about things, a conversation rather than a blog-post broadside would probably contribute more to the security of the web.
(People point at the Context IS bug reports, but they had nothing to do with access to fragile driver code or unsuspecting hardware. They were origin-management problems in the spec, and a straight up C-pointer-mgmt-claims-more-toes bug in our implementation.)
My point is that those technologies have been added to browsers, and we've been able to deal with the security surface.
Is merely repeating these past mistakes a high enough standard for a new technology? Particularly for one that would arguably be the worst of the lot? And for one that is getting a very late start in the arms race of exploit sophistication?
Is there not a suitable middle ground between <canvas> and OpenGL? An abstraction layer that is sufficiently powerful to not be the bottleneck, while permitting a secure implementation without the help of driver vendors and avoiding all the legacy cruft of OpenGL to boot?
First, it's not even close to being "worst of the lot".
Second, there might or might not be a middle ground, but you're not proposing it, Microsoft isn't proposing it and no one else is proposing it. In that context, bringing up non-existent, maybe-or-maybe-not better solution isn't advancing the discussion. In theory everything is possible but in practice WebGL implements a well understood model that has been in use for decades (just like canvas implemented a well understood model for 2D graphics). If we want fast 3D graphics in the browser, and we do, building on top of well understood technology is definitely the way to go (compared to trying to reinvent extremely complex technology that took years to perfect in the currently dominant standards (Direct3D and OpenGL)).
I disagree with the notion that it's OK to adopt a flawed standard just because no better proposal exists. A better proposal could most certainly exist if it was agreed that it should exist and resources were committed.
The OpenGL API has a ton of legacy baggage. Nearly all of GL 1.0 is deprecated and some parts of the API have endured multiple cycles of deprecation. Improving on it would not be difficult.
GLES is even cruftier than OpenGL, because they removed a bunch of functionality but didn't simplify the API. So you have all sorts of parameters and options that literally have no purpose. The documentation frequently says things like "The blah parameter controls yada yada. It's value must be zero." That's gotta be mighty confusing for a web developer doing 3D graphics for the first time.
The design of OpenGL is optimized for stateful, fixed pipeline, immediate mode drawing, an extinct paradigm that is unsupported in GLES and WebGL. The modern paradigm of shaders and GPU objects is radically different and demands an API tailored for it.
The continuity of OpenGL has been justified by its established ecosystem. Game developers prefered one patched up API to a new API for every generation of graphics hardware. But now hardware architecture has more or less stabilized and it's the developers that are new. Let's give them a fresh start instead of a badly mutilated API that, frankly, I think most of them will find impenetrable.
Is merely repeating these past mistakes a high enough standard for a new technology?
In a word, yes. Computing needs to be dragged kicking and screaming into the future of platform independence, and powerful 3D acceleration is an important component of a modern desktop system. The lessons learned in the previous rounds of new technology can be applied to mitigate some of the risks associated with WebGL.
I'd like to point out that we have not been able to deal with the security surface: you list "font engines, video codecs, OS text-display facilities (!) and image libraries", and browser-based access to each of these has led to horrific security bugs.
Yes, most of the bugs in those components eventually got fixed; yes, 3D access via Silverlight is scary too; but let's not pretend that this isn't going to get people 0wned.
It's not weird. What he's saying is that "if we applied Microsoft logic about WebGL to everything, then we'd have to get rid of fonts, video codecs, text-display facilities and image libraries which would make the browser suck".
But Microsoft isn't saying we shouldn't have fonts, video codecs, and whatnot. They're saying this thing isn't worth the security price we will inevitably pay for it. And: fine, if you want to disagree with that. Maybe I disagree too. But fonts and image libraries are facts that seem to me to support Microsoft's point.
Microsoft isn't saying that. They completely avoided talking about the trade offs i.e. they didn't even try to weight the benefits of having WebGL vs. the security risks.
The point is that they took a hard line: this technology has potential problems therefore we're not going to implement it.
The point is that they never took this hard line wrt. any other technology implemented in the browser, either standard or of their own making (like ActiveX, BHOs, Silverlight). In fact, as far as I know, they never even publicly mentioned the fact that essentially every new feature you add to a browser comes with a risk of new bugs just by virtue of them being implemented in C.
The point is that they singled out WebGL and made a big, public stink about it when they have never made even a small stink about any other browser technology with similar issues.
The point is that they didn't bother to even hint that they have a proposal for standard web technology that fills the same role as WebGL which strongly suggest that they just want to kill it. After all, who needs it when we have Silverlight 5.
MSRC didn't say it's not worth it. They said it couldn't survive the SDL process or be securable, which is the standard for technologies they deploy. Given that they deploy those pre-existing technologies and added more in IE9 (WOFF, accelerated H.264, accelerated canvas), and given that they have to pass SDL review, I think they are being unhelpfully inconsistent.
(Does MSRC ever make the worth it/not worth it call? I thought they just analyzed the security side, and didn't make the product decisions.)
I did appreciate that Microsoft gave reasons along with their snub, but their analysis felt pretty NIH-and-not-going-to-help-with-the-inventing to me.
Shaver says:
>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.
Nice point. Whether Microsoft engages with and helps improve WebGL could be seen as a proxy for whether they will in fact engage with Web Standards in IE 1X. Or is WebGL so broken that it's impossible to contribute?
I'm also surprised since the next battleground for browsers seems to be in mobile and pushing forward a unified and seriously advanced browser strategy could be a serious advantage for MSMobile (whatever the hell it's called now). Instead, they seem to be re-fighting battles in a war that's already been semi-lost (the PC browser).
I missed that, thanks. In that case they pretty clearly know the delta between the XNA in SL support and OpenGL. Do you know what the big differences are in how shaders are handled between XNA and OpenGl? Can we work to get them to be more similar?
The shader models in XNA D3D and WebGL are pretty similar. One travels as pre-compiled bytecode and the other as text, and there are some differences in how loop constructs work, but they're both basically shader model 2.
But the argument I read from MSRC wasn't about the capabilities of the system when working as intended, it was about weaknesses in OEM/IHV drivers causing unintended behaviour that is qualitatively harder to fix than bugs in the drivers for hardware H.264 decoding. I haven't yet found a way that HLSL/XNA is more robust than GLSL/WebGL, and I've been in threads about those shader models for quite a while now. Of note, perhaps, is that on Windows we compile GLSL into HLSL and then effect bytecode (with Microsoft's compiler) and feed it through Direct3D. It's a very very similar pipeline.
The claim is that driver blacklisting hasn't been used to address recent vulnerabilities, but...the recent vulnerabilities have had nothing whatsoever to do with problems in a driver.
There's a marked contrast between Mozilla's eagerness to press ahead with WebGL and tidy up the problems later, and the abundance of caution it displays when facing NaCl, a technology that threatens its own ricebowl.
To be completely honest, it doesn't matter what their response is (and the site isn't loading, anyways). If Microsoft refuses to implement WebGL, the technology will have been effectively hamstringed.
Not precisely. Firefox and Chrome have enough marketshare that games with WebGL can just detect IE, then throw up a message "your browser does not support WebGL, click here to download a browser that does.".
Possibly, but how many companies will actively target a platform that, say, roughly half of their visitors can actually use? It won't be a safe bet like Flash is with 97% of users having it available.
Installing an entirely new browser is a huge barrier to entry for the average end user.
webgl requires a graphics card that is known to work, this alone is a bigger problem than asking people to install something. Last time i tried, installing Firefox was easier than installing Flash.
Unfortunately, a large number of those people will still see "your browser does not support webgl" after changing browsers, thanks to old/broken/blacklisted gpus and no browser shipping a software renderer for webgl.
I would have thought the time that IE could effectively hold back the web had passed.
Even if they were on board with WebGL then I assume we're talking support in IE10 released alongside and quite possibly restricted to Windows 8. It wouldn't be crazy to think that IE, across all versions, would be down to 25% marketshare at that point and their mobile marketshare is basically non-existant.
IE's outmoded release schedule means that they can't really help or hinder the web much with decisions they make today. Certainly not compared with the damage they do by having old versions hanging around.
>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
ATI and NVidia have never cared about driver stability (or anything other than benchmark performance), and now we're supposed to believe that they will start caring about security?
I wouldn't say that about the ATI driver folks. Back when I was running a small team at MSFT, we were the first serious users of the then-new WPF text rendering APIs that were built on top of the new driver models. So, we hit bugs. The ATI on-site folks were awesome. Usually, they had already found the bugs and had a patch that was going through stability testing. When they didn't know about it, one of them would come by, usually within a couple of hours, and connect up a kernel debugger or whatever else was needed to track down the bug and turn us around a fix. I still prefer AMD video cards to this day based on that experience.
ATI and NVidia surely cares about driver stability. Who would buy their graphics cards if the games kept crashing all the time?
ATI and NVidia didn't have to care about security before, since the only applications that could access the drivers and graphics cards were trusted applications. Now we have a new situation where they they have to start to care about security. I don't think AMD or NVidia want to be blacklisted in WebGL implementations because their driver isn't secure enough.
Based on face-to-face conversations with senior people at GPU manufacturers, I do, yes. You should absolutely decide for yourself; I said what our belief was, and what it was based on.
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
This is assuming that the web needs to be a competitive app platform, but that is a wole other debate. Regardless, it's immaterial to the security issue. No matter how badly we need it, if WebGL really is as insecure as some have suggested then it will only sabotage the underlying goal.
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
Web video (and audio) have been effectively phased in over a good 10 to 15 years. Ditto Flash and PDF. These technologies have had the luxury of evolving security gradually along with the threat and their record is still far from spotless. I don't know a lot about font engines, but I doubt they compare in complexity and diversity to 3D graphics drivers.
GL drivers will be thrown right into the deep end. I am skeptical that driver makers can really understand what they are getting into, or that they really have the incentive to care.
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 is a huge assumption. Here, you're talking about Microsoft's own 3D API bound to their own VM, running on their own OS. Or in the case of cross-platform Silverlight, a 3D API wrapping a completely different 3D API. I would like to know the details of how that works and how it is secured. But without knowing, I wouldn't assume it was at all applicable to WebGL.
And anyway, even if Microsoft can do a secure implementation on Windows, what about every other browser on every other platform? Conspiracy theories aside, this is not about Microsoft.
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
If WebGL is to be a true web standard that works everywhere, then that's a lot of different developers, present and future. The responsibility to keep browsers secure is being spread awfully thin, across some parties that aren't very accountable.
So far, I haven't seen any response to the WebGL security issues stronger than "don't worry, we'll try really hard" and that is not very reassuring.
With regards to web security in general, everything that could conceivably go wrong up until now has. We have to assume that the same principle will hold for future technologies and make sure they are air tight from the start. If we accept compromise with WebGL then we won't know for sure if there is a problem until it's too late -- that is, until it is widely deployed and difficult to change or abandon.
> This is assuming that the web needs to be a competitive app platform
This is one of the goals of HTML5.
> That is a huge assumption. Here, you're talking about Microsoft's own 3D API bound to their own VM, running on their own OS.
Whenever you have code that has access to low level API and hardware, you'll encounter the same issues. Look at the history of windows with running native code and all the security issues it has enabled, there is no question they will meet the same issues with 3D on silverlight.
> this is not about Microsoft.
It is about Microsoft. They also had tons of reasons not implement SVG because SilverLight was better and SVG had flaws according to Microsoft... until they added it to IE9 because it was turning popular. They'll try the same with WebGL, this is typical Microsoft behavior.
> So far, I haven't seen any response to the WebGL security issues stronger than "don't worry, we'll try really hard" and that is not very reassuring.
They said they will improve the specs to fix the issue. What else do you want?
> With regards to web security in general, everything that could conceivably go wrong up until now has.
The same could be said about native apps security. The real story here is that Microsoft doesn't want to implement WebGL for two very known reason:
1) It competes with Silvernight 3D
2) WebGL is based on OpenGL while Microsoft is pushing hard for Direct 3D. If webgl gets popular they'll have to implement WebGL on windows and developers might want to develop against it instead of D3D, although they could limit it to IE. Either way, it's not appealing to them, like SVG was when they still believed Silvernight would take off.
It is about Microsoft. They also had tons of reasons not implement SVG because SilverLight was better and SVG had flaws according to Microsoft... until they added it to IE9 because it was turning popular. They'll try the same with WebGL, this is typical Microsoft behavior.
Microsoft is not the only party criticizing WebGL and the motives of any such party are a separate issue. The technical problems with WebGL have been made clear and appeasing Microsoft or questioning their motives does not address those problems.
They said they will improve the specs to fix the issue. What else do you want?
Who said they will improve the specs and in what way? There are fixes for specific bugs, like cross-domain image loading. ARB_robustness is in the works, which is an implementation detail that might help somewhat. But I've seen nothing that claims to fix issues of the sort mentioned by Microsoft, just claims that they aren't really a problem.
And if WebGL is being fixed then why is it enabled in production browsers today?
These are all technologies that have, in fact, been a continuing source of terrible security vulnerabilities. I'm not sure of the point he's making; surely, he has to know that font and image libraries --- and even just new ways of gluing those things together, like the new CSS font goo --- actually are security threats.
I don't have much of an opinion here. Microsoft is right that WebGL is scary from a security perspective. Maybe Mozilla is right that it's worth the risk. But this is a bit of a weird post.