It seems to me the guy who reported the issue to Microsoft is doing the only thing that he can effectively do to help them.
My complaint isn't with the bug report per se. I think filing bugs is a very valid mechanism for handling defects.
WebGL is a standard developed in an open way. If someone wants to contribute, including Microsoft, they can send an e-mail to a mailing list and that will reach other people working on WebGL and hopefully a productive conversation would ensue.
My point is that open standards shouldn't be blazing new trails with somewhat unknown security surfaces (etc). Open standards should take what works and say, "This is now the accepted way to do it, we have good evidence that this way works best in practice."
They made no effort to improve the security of WebGL and didn't leave any opening for the discussion. They just communicated a decision.
They just communicated their decision. Just as Apple said they wouldn't support Flash. In fact MS went into a fair bit more detail why they wouldn't. Honestly, I think that was a mistake. They simply should have just said they wouldn't support WebGl, and left it at that.
But my broader point is that I don't like standards bodies trying to bully organizations into supporting a nascent standard that AFAICT hasn't really been vetted or sufficiently thought through yet.
The C++ standards committee ran into this last time with export. They pushed in a feature no one had used in practice and hadn't really been vetted by thousands of hours of testing. The end result, a dead feature, and lots of wasted person hours.
Take the time, do it right, let the vendors push forward first, and learn.
> My point is that open standards shouldn't be blazing new trails with somewhat unknown security surfaces (etc). Open standards should take what works and say, "This is now the accepted way to do it, we have good evidence that this way works best in practice."
I was going to rebut this with JavaScript and the "canvas" element as examples, but I did some research and that's about right.
Perhaps there's a push for early standardization because non-IE browsers have a lot to gain from being cross compatible?
A bunch of programmers involved in designing WebGL bullying Microsoft. Really?
There are 2 issues that Microsoft raised:
1. Sending arbitrary GPU shaders can slow down GPUs.
2. Using standard, public, official graphics APIs provided by Windows might crash buggy drivers.
Re 1: Adobe does that in Flash, Microsoft is planning to do that in Silverlight 5. WebGL isn't proposing anything that Microsoft isn't doing already. If you think WebGL is not thought out properly in that regard, neither is stuff that Microsoft is doing.
Re 2: I'm really dumbfounded how Microsoft can even make this argument with a straight face. They've spent the last 15 years designing and improving DirectX but they don't really want you to use those APIs? WebGL folks can't fix the drivers, Microsoft and Intel and ATI and Nvidia can and should, regardless of WebGL.
Finally, how do you propose that we vet the standard? What criteria do you propose to decide that WebGL standard is good enough?
Your position (that WebGL is not good enough) cannot be disproved because you don't provide any objective criteria to decide what is "good enough". It's non-constructive hand-waving.
On the other hand, WebGL is based on OpenGL, an API that has been vetted in the past 20 years, has proven to work and as far as I can tell, WebGL folks are highly competent people, both in 3D and security space.
A bunch of programmers involved in designing WebGL bullying Microsoft. Really?
It's not just a bunch of programmers. It is a working group intended to represent the recommendation for an important standard. Or at least I thought so. Maybe not?
Your position (that WebGL is not good enough)
I never said that.
Finally, how do you propose that we vet the standard? What criteria do you propose to decide that WebGL standard is good enough?
Standards should be based on techniques and technologies that are fairly well known. While there will always be debates about what goes in a standard, the arguments should almost always be able to point to existing implementations of a given technology. Especially in areas where there might be controversy or concern.
What I do NOT like is a standard body criticizing an organization for not picking up a standard, if the standard hasn't really been vetted or tested yet.
If you want to push a non-vetted technology, go ahead, and let Mozilla and Chrome pick it up, but don't criticize those who don't at the onset. Now in three years, once the kinks have been ironed out, then I think you can make the claim that the standard is solid -- everyone on board, but at this point I think its not fair to push anyone to implement it.
My complaint isn't with the bug report per se. I think filing bugs is a very valid mechanism for handling defects.
WebGL is a standard developed in an open way. If someone wants to contribute, including Microsoft, they can send an e-mail to a mailing list and that will reach other people working on WebGL and hopefully a productive conversation would ensue.
My point is that open standards shouldn't be blazing new trails with somewhat unknown security surfaces (etc). Open standards should take what works and say, "This is now the accepted way to do it, we have good evidence that this way works best in practice."
They made no effort to improve the security of WebGL and didn't leave any opening for the discussion. They just communicated a decision.
They just communicated their decision. Just as Apple said they wouldn't support Flash. In fact MS went into a fair bit more detail why they wouldn't. Honestly, I think that was a mistake. They simply should have just said they wouldn't support WebGl, and left it at that.
But my broader point is that I don't like standards bodies trying to bully organizations into supporting a nascent standard that AFAICT hasn't really been vetted or sufficiently thought through yet.
The C++ standards committee ran into this last time with export. They pushed in a feature no one had used in practice and hadn't really been vetted by thousands of hours of testing. The end result, a dead feature, and lots of wasted person hours.
Take the time, do it right, let the vendors push forward first, and learn.