[Candescence]

I knew Microsoft would never want to support WebGL, but this is silly.

Microsoft has always never gone with the flow when it comes to the web, they want to monopolize and force everyone to do things their way. That, and they really, really want to see OpenGL dead and buried, too, so it's no surprise that they would want to make an excuse not to support WebGL. Khronos' basic response is "we're still working on it'll be fine once we do that, and Mozilla already fixed the arbitrary windows problem".

Oh, yeah, and, java applets have always been able to use OpenGL, so these security concerns should be nothing new. If they're an issue, they should always have been an issue with Java applets, but nobody seems to have minded until now.

Ah, right, I just remember... Microsoft aren't exactly masters of security, themselves. And they might as well be pointing fingers at multiple web plugins that have worse security flaws. Including ones that MS itself has made. ActiveX, anyone?

Microsoft, stop trying to force everyone to do things your way. That tactic isn't working nearly as well as it used to.

This post has been edited by Candescence: 17 June 2011 - 01:15 PM

[Meat Miracle]

... newsflash: they aren't the first to say that WebGL is a complete piece of shit as it is right now, and they are right, too.

You could bash MS for this if they had their own gpu acceleration standard to counter, but they don't.

OpenGL inside a Java wrapper is completely different from WebGL.

[Sik]

They're just taking advantage of some guy who said that WebGL wasn't sandboxed so it could be used to break out of the browser. Problem: GLSL shaders are always provided as a script*, so they're always sandboxed. I can't say the same about Direct3D (which always provided platform-independent binary shaders).

On the other hand, what is possible is trying to read what may be on screen by swapping the buffer and reading the undefined contents that were there. This doesn't work for all drivers though (sometimes you truly get garbage, and it definitely doesn't work when the buffer is in a window), and Direct3D is also affected by this (or anything using shaders, for that matter). If Microsoft comes up with WebD3D and they claim it to be secure, they're being hypocrite.

*OpenGL 4 provies binary shaders, but they have to be built on the machine they're running on, making them quite pointless... They're only useful as part of an installer, really. And this isn't even part of the WebGL spec...

This post has been edited by Sik: 17 June 2011 - 05:40 PM

[Candescence]

Dude from Mozilla: "Um, adding new features always exposes new components to possible attack - WebGL is nothing special, and it can be made robust against attacks over time anyway."

Also, they point out D3D support is in Silverlight so would have the same security problems in theory! And they're working on 'Silverlight 3D' as part of Silverlight 5, so yes, that DOES make them hypocrites.

Basically, I'm convinced that Microsoft are reluctant to support OpenGL/WebGL and want to find any possible excuse to avoid doing so. That, and they want to stop Silverlight from dying out. Seriously, who actually uses Silverlight?

[Guess Who]

Seriously, who actually uses Silverlight?

Anyone watching Netflix on their PC?

Also, you keep comparing WebGL to things like OpenGL in Java or DX support in Silverlight, but they're very different beasts.

[saxman]

I'm not very knowledgeable on WebGL and Silverlight and such. What I CAN tell you, purely based on what little I've read, is apparently WebGL gives your browser direct access to the video hardware of your computer with absolutely no input from the user to allow or deny this access. That's something almost out of the 16-bit MS-DOS days. In this modern age, operating systems don't allow direct access to any piece of hardware in part because of the increasing need for security.

So, if it's true that it allows this kind of access to hardware, then yeah, it's extremely unsafe! At first I thought maybe Microsoft was simply dragging it's feet, but the more I learn, the more it doesn't appear to be the case at all. John Carmack even endorsed Microsoft's stand on this; that's pretty telling.

This post has been edited by saxman: 18 June 2011 - 12:00 PM

[Sik]

WebGL is basically OpenGL ES 2.0 adapted for javascript, so yes, it's fair to compare it to OpenGL. It won't give you any more access to the GPU than OpenGL does. In fact, it gives you less access to the GPU than OpenGL does, period. And ultimately it's all up to the drivers and what the browser says is OK.

Seriously, this is like complaining that javascript gives you access to the CPU.

[saxman]

When Carmack says it's insecure and a bad idea, I have to take him at his word. Even so, it does make me curious what the difference from a security perspective would be in supporting OpenGL or Direct3D or anything else that accesses video hardware. What makes WebGL's direct access worse? From what I understand, OpenGL and Direct3D both access hardware directly. Unless I'm mistaken.

EDIT: Interesting discussion going on here -- http://news.ycombinator.com/item?id=2662632

This post has been edited by saxman: 18 June 2011 - 01:28 PM

[GerbilSoft]

When Carmack says it's insecure and a bad idea, I have to take him at his word. Even so, it does make me curious what the difference from a security perspective would be in supporting OpenGL or Direct3D or anything else that accesses video hardware. What makes WebGL's direct access worse? From what I understand, OpenGL and Direct3D both access hardware directly. Unless I'm mistaken.

Neither OpenGL nor Direct3D accesses the hardware directly. They both go through the video driver. (Of course, considering how poorly both AMD and nVidia's binary drivers are designed, I wouldn't be surprised if they were full of security holes.)

The only obvious security issue that stands out is uninitialized textures, and that's easily fixed by having the renderer zero out newly-allocated textures before handing them to the WebGL program. Shaders shouldn't be an issue, since OpenGL <4.1 doesn't support binary shaders. (OpenGL 4.1 has an extension GL_ARB_get_program_binary, but this extension most likely won't be supported by WebGL renderers.)

This post has been edited by GerbilSoft: 18 June 2011 - 11:11 PM