Mozilla VP Mike Shaver responds to Microsoft's WebGL security concerns
shaver.off.net
shaver.off.net
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.
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".
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.
(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.)
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.)
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?
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)).
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.
See for yourself: http://www.nihilogic.dk/labs/webgl_cheat_sheet/WebGL_Cheat_S...
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.
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.
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.
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.
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).
It could well be the case that the IE team thinks that what SL does is something they wouldn't put into Windows.
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.
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 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.
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?
https://twitter.com/ID_AA_Carmack/status/81732190949486592
I agree with Microsoft’s assessment that WebGL is a severe security risk. The gfx driver culture is not the culture of security.
https://twitter.com/ID_AA_Carmack/status/81745430152609793
They are orthogonal technologies, but NaCl is much, much easier to make secure than WebGL, even though it sounds scarier.
+ 1 for Microsoft keeping them accountable.
- 2 for Microsoft keeping yet another awesome technology out of their browser
Mozilla wins. We're back to zero.
Edit: http://webcache.googleusercontent.com/search?sclient=psy&...
Installing an entirely new browser is a huge barrier to entry for the average end user.
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.
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?
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.
Only one or the other could get blacklisted. If it was both of them, what remains? The Sandy Bridge GPU? WebGL needs them more than they need WebGL.