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