5 ms·

Mozilla VP Mike Shaver responds to Microsoft's WebGL security concerns

62 points by mbrubeck 15y ago

getsat 15y ago
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. Edit: http://webcache.googleusercontent.com/search?sclient=psy&hl=en&site=&source=hp&q=cache%3Ahttp%3A%2F%2Fshaver.off.net%2Fdiary%2F2011%2F06%2F17%2Fa-three-dimensional-platform%2F&aq=f&aqi=&aql=&oq=&pbx=1 http://webcache.googleusercontent.com/search?sclient=psy&#38...
- younata 15y ago
  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.".
  - hakl 15y ago
    Google Chrome Frame could also be helpful here. Macromedia somehow managed to get most people to install their terrible plugin.
    - yuhong 15y ago
      Long before Chrome Frame even existed.
  - getsat 15y ago
    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.
    - taken11 15y ago
      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.
  - kevingadd 15y ago
    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.
- ZeroGravitas 15y ago
  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.
smallblacksun 15y ago
>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?
- larsberg 15y ago
  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.
- shaver 15y ago
  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.
- lambda_cube 15y ago
  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.
  - seabee 15y ago
    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.
CoffeeDregs 15y ago
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).
- kenjackson 15y ago
  One thing to keep in mind though is that while MS is one company I don't think the IE team and the Silverlight team see eye-to-eye on everything. It could well be the case that the IE team thinks that what SL does is something they wouldn't put into Windows.
  - shaver 15y ago
    The post wasn't from the IE team, but from MSRC, the company-wide security research group.
    - kenjackson 15y ago
      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?
      - shaver 15y ago
        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.
extension 15y ago
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.
tptacek 15y ago
"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.
- shaver 15y ago
  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.)
aw3c2 15y ago
John Carmack said: https://twitter.com/ID_AA_Carmack/status/81732190949486592 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 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.
- leoc 15y ago
  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.
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
becomevocal 15y ago
+ 1 for Mozilla working in WebGL and moving the web forward. + 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.

62 points by mbrubeck 15y ago

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. Edit: http://webcache.googleusercontent.com/search?sclient=psy&hl=en&site=&source=hp&q=cache%3Ahttp%3A%2F%2Fshaver.off.net%2Fdiary%2F2011%2F06%2F17%2Fa-three-dimensional-platform%2F&aq=f&aqi=&aql=&oq=&pbx=1 http://webcache.googleusercontent.com/search?sclient=psy&#38...

younata 15y ago
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.".
- hakl 15y ago
  Google Chrome Frame could also be helpful here. Macromedia somehow managed to get most people to install their terrible plugin.
  - yuhong 15y ago
    Long before Chrome Frame even existed.
- getsat 15y ago
  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.
  - taken11 15y ago
    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.
- kevingadd 15y ago
  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.
ZeroGravitas 15y ago
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.

smallblacksun 15y ago

>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?

larsberg 15y ago
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.
shaver 15y ago
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.
lambda_cube 15y ago
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.
- seabee 15y ago
  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.

CoffeeDregs 15y ago

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).

kenjackson 15y ago
One thing to keep in mind though is that while MS is one company I don't think the IE team and the Silverlight team see eye-to-eye on everything. It could well be the case that the IE team thinks that what SL does is something they wouldn't put into Windows.
- shaver 15y ago
  The post wasn't from the IE team, but from MSRC, the company-wide security research group.
  - kenjackson 15y ago
    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?
    - shaver 15y ago
      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.

extension 15y ago

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.

tptacek 15y ago

"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.

shaver 15y ago
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.)

aw3c2 15y ago

John Carmack said: https://twitter.com/ID_AA_Carmack/status/81732190949486592 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 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.

leoc 15y ago
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.

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

becomevocal 15y ago

+ 1 for Mozilla working in WebGL and moving the web forward. + 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.