Live data from Hacker News

Microsoft refuses to endorse WebGL, labels it ‘harmful’

winrumors.com

21–30 of 114 posts

Re: Microsoft refuses to endorse WebGL, labels it ‘harmful’

#21
post #6

This is why I'm absolutely terrible at security considerations. When I look at webGL, I think what's the problem? So what if you have direct access to the GPU? My naive view of the graphic card is: shader instructions -> VIDEO CARD -> PIXEL DATA Shader instructions are a limited to a specified function set directed at transforming and calculating numbers. What possible risk can a calculator represent? Video Card is a…

Read these papers:

http://www.contextis.com/resources/blog/webgl/

http://www.contextis.com/resources/blog/webgl2/

To learn more about WebGl and security. Goes into more depth than that article.

Re: Microsoft refuses to endorse WebGL, labels it ‘harmful’

#23
post #11

Earlier quoted context omitted.

But before the code gets to the GPU it has to be compiled and that's the job of the GPU drivers which are know to crash often. Video card drivers are the problem. If you can manage to make them crash in a predictable way then you have a way to crash the machine and I guess reboot the box on windows. Who would have thought that a small program to do graphics manipulation could be used to reboot a box? I mean something…

I'd be more worried that the drivers run in kernel mode and this could actually allow a new class of root-level arbitrary code execution vulnerabilities.

That's definitively an issue. Is there a way around graphic drivers in the kernel? Userspace graphics drivers could be interesting if they were possible.

Re: Microsoft refuses to endorse WebGL, labels it ‘harmful’

#24
post #4

For those who think that HTML/CSS/JS will replace native apps, just take a look at Microsoft, Apple and Google (yes, Google - no thanks for ditching the open standard h264 on Chrome). Standards, when they threaten to disrupt existing powerful players, will be ignored, delayed or sabotaged. Thus innovation that requires standards-based clients even with nimble outfits like Apple, Google, Mozilla, and Facebook pushing…

>thanks for ditching the open standard h264 on Chrome

I think that someone may have lied to you when they explained the words "open" or "standard".

Also, why am I "looking at" MSFT/AAPL/GOOG for in relation to HTML/CSS/JS apps? They fact that many are still native? Google's apps for iOS are web based, and I'm sure iCloud apps for Android will be web based. Microsoft just got done demoing HTML5/CSS3 applications for Windows 8.

Your comment is all over the place without actually saying much or really making any legitimate claims.

Re: Microsoft refuses to endorse WebGL, labels it ‘harmful’

#25

Possibly off topic, possibly related, but can anyone explain to me how Google's Native Client (NaCl) is different from ActiveX and Flash? Sounds like a security exploit waiting to happen.

The whole point of NaCl is that it provides a safe sandbox for running verified native code - the Wikipedia article has more on this: http://en.wikipedia.org/wiki/Google_Native_Client

Google ran a security contest to find problems with it, which turned up a few. I'm not sure what the status is at the moment with regards to security: http://code.google.com/contests/nativeclient-security/faq.ht...

Re: Microsoft refuses to endorse WebGL, labels it ‘harmful’

#26

Wow. Could they be more transparent? This couldn't have anything to do with Direct X, could it?

It's not about whether it could affect Direct X or not - one game crashing your GPU due to some unintentional bug code (there's no incentive on game publisher's side to make it intentional) is not the same as the Web, where anybody can push something to your browser that exploits hole in some graphics card driver. Microsoft has a point. They do not explain, however, how Silverlight is invincible in the same situation.

Re: Microsoft refuses to endorse WebGL, labels it ‘harmful’

#27
They have a point. OpenGL was not designed with security in mind (same goes for Direct 3D). Prior to WebGL there wasn't really a need for security, since applications making use of OpenGL would typically be considered trusted.

Index buffers into vertex arrays, for example, are not bounds checked in OpenGL. This makes perfect sense in terms of efficiency, but can lead to code execution in adversarial settings. I'm sure there are many more cases where choices were made in favor of speed, and where security was simply not a concern.

Having said that, all these things can certainly be fixed. For example, Microsoft could add a security layer that does all the bounds checking prior to passing on the commands to the driver (so securing all the drivers is not necessary). Makes me wonder how Chrome or Safari handle this. Anyone know more?

Re: Microsoft refuses to endorse WebGL, labels it ‘harmful’

#28
post #23

Earlier quoted context omitted.

I'd be more worried that the drivers run in kernel mode and this could actually allow a new class of root-level arbitrary code execution vulnerabilities.

That's definitively an issue. Is there a way around graphic drivers in the kernel? Userspace graphics drivers could be interesting if they were possible.

Isn't that what microkernels are all about? http://en.wikipedia.org/wiki/Microkernel

Re: Microsoft refuses to endorse WebGL, labels it ‘harmful’

#29
post #23

Earlier quoted context omitted.

I'd be more worried that the drivers run in kernel mode and this could actually allow a new class of root-level arbitrary code execution vulnerabilities.

That's definitively an issue. Is there a way around graphic drivers in the kernel? Userspace graphics drivers could be interesting if they were possible.

User space drivers are possible, the problem is efficiency nosedives. The premise of microkernels[1] is that the kernel itself is "trivially" small and everything else runs as a userspace task.

[1] http://en.wikipedia.org/wiki/Microkernel

Post reply on HN