12 ms·

Microsoft refuses to endorse WebGL, labels it ‘harmful’

109 points by ssclafani 15y ago

vbrenny 15y ago
Yeah, sure. Silverlight is the future!
- jimbobimbo 15y ago
  Actually, that's an interesting point. Silverlight allows pixel shader usage, which they view unsafe in WebGL. That'd be interesting to read SDL team's views on this.
  - jimbobimbo 15y ago
    Looks, like this is the answer: http://news.ycombinator.com/item?id=2663497 http://news.ycombinator.com/item?id=2663497
nextparadigms 15y ago
Whatever. Whoever makes WebGL games will benefit from 50% of the total browser market share, and this market share will keep increasing as I doubt the new versions of IE (9/10) will replace the older IE browsers, especially since the new ones only work on certain Windows versions. Whether Microsoft embraces WebGL or not, it's irrelevant, because they'd only add like 5% market share they have with IE9, anyway. I think WebGL developers can safely ignore the IE9/IE10 markets.
- hartror 15y ago
  But can Google and Mozilla ignore the security concerns that are a inherent part of WebGL?
  - robin_reala 15y ago
    No, they can deal with them. The only inherent thing about security concerns exposed by WebGL is that there will be them, not that they can’t be fixed.
r00fus 15y ago
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 the envelope, will take much longer than with a cohesive, well-driven native app platform.
- drivebyacct2 15y ago
  >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.
  - BadHabitz 15y ago
    who gives a shit about the quality of his comment. your mother said to get off the computer
    - drivebyacct2 15y ago
      I don't understand. Did I offend someone, was I out of line?
  - r00fus 15y ago
    > I think that someone may have lied to you when they explained the words "open" or "standard". h.264 is not royalty free, but it is open and a standard (from Ars: http://arstechnica.com/web/news/2011/01/googles-dropping-h264-from-chrome-a-step-backward-for-openness.ars http://arstechnica.com/web/news/2011/01/googles-dropping-h26... ) "In the traditional sense, H.264 is an open standard. That is to say, it was a standard designed by a range of domain experts from across the industry, working to the remit of a standards organization. In fact, two standards organizations were involved: ISO and ITU. The specification was devised collaboratively, with its final ratification dependent on the agreement of the individuals, corporations, and national standards bodies that variously make up ISO and ITU. This makes H.264 an open standard in the same way as, for example, JPEG still images, or the C++ programming language, or the ISO 9660 filesystem used on CD-ROMs. H.264 is unambiguously open."
keithwarren 15y ago
Cue the chorus of people saying this is because Microsoft sucks etc etc. Ignore the fact that Microsoft has spent more time and resources than any technology company in the world focusing on web related security. Mind you that is not an endorsement of their track record, but a statement with respect to the reality on the ground.
- drivebyacct2 15y ago
  What? I'd love a citation on that. And I've spent a lot of time trying to make a baby by myself, but that doesn't mean I've been the least bit successful. Seriously, come on. Where is this evidence that Microsoft has "spent more time on web security" than anyone else? Their track record sure doesn't support it. Is there a competition among the big-3 to compare amount of time spent on web security? In fact, the fact that Microsoft supposedly spends so much time on web security and continues to fail so bad makes me feel much worse about their opinions on the security of WebGL. This is also the company, mind you, that introduced the decade-long nightmare of ActiveX.
- rbanffy 15y ago
  > Microsoft has spent more time and resources than any technology company in the world focusing on web related security. Mostly because they had to. If others spent less it could be because they had a smaller vulnerable surface to begin with, or simpler codebases.
  - daeken 15y ago
    You evidently haven't seen the massive codebases from the Mozilla or Webkit camps, or the huge number of vulnerabilities therein in recent years. IE is a huge piece of shit, but MS has done a lot for web security. Mind you, I think Google's efforts have been more fruitful, but writing off MS's effort is silly.
    - rbanffy 15y ago
      The way IE is reliant on Windows and vice-versa, you can't really draw a clear line separating Windows and IE (at least not security-wise). It's very different with Mozilla and Webkit codebases, where the clean separation exists (as they are both multi-platform). I believe IE's base also carries lots of cruft from previous versions, something that complicates matters even more. Microsoft did a lot, quite possibly because they had a whole lot to do. No other company has an OS that large (Windows is huge) so tightly coupled to a browser.
giberson 15y ago
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 hardware device that simply implements the calculator language. It only has access to the numbers and data it was supplied. It crunches the numbers, and then returns pixel data. The video card is a black box, numbers go in, numbers come out. Pixel data is just a set of numbers that represent color. You take the pixel data and you send it to the monitor. Honestly, what could possibly go wrong? Seriously, I have a hard time comprehending the "surface" are of the attack. I'm familiar with ideas like memory buffer overflow attacks--but I mean video cards have their own dedicated memory, even if you manage to read some memory outside of your allocated block--you'd only be getting numbers from the video card memory which is just geometry definitions... Actually, just now typing that last paragraph I think I figured out why gaining access to the GPU memory would represent a security concern. I suppose if that memory contained screen pixel data, it could be used to "read" what was on the screen via some form of OCR? Or, perhaps maybe depending on the OS implementation, more than just "pixel" data may reside in the GPU memory. Gr, it's really quite frustrating that these stupid security issues keep getting in the way of forward progress--or more so that large company vendors are back pedaling simply because it's a "hard" problem to tackle.
- oomkiller 15y ago
  I think their concern is that the hardware drivers have bugs in them that could lead to remote compromise, not that access to the GPU. Microsoft knows something about this, as the execution of untrusted/unsigned shader code allowed the Xbox 360 to run unsigned code back in the day: http://en.wikipedia.org/wiki/Free60 http://en.wikipedia.org/wiki/Free60
- nkassis 15y ago
  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 is wrong here on many levels. My WebGL app has frozen a few machines in the past with random bugs that I haven't figured out yet. I tell my users to be careful but I know someone out there knows how to do it predictably. But you know what, it's about time Nvidia/ATI/Intel/others pull their own weight and fix the damn issues with their drivers. If it can be done with WebGL it can be done with native applications. Flash Molehill probably too.
tree_of_item 15y ago
Wow. Could they be more transparent? This couldn't have anything to do with Direct X, could it?
- jimbobimbo 15y ago
  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.
  - bmm6o 15y ago
    Exactly. TFA: "Attacks that may have previously resulted only in local elevation of privilege may now result in remote compromise."
  - Hov 15y ago
    I'm almost certain Silverlight's Pixel Shaders don't run on the GPU. I have no proof of this other than that they're pretty slow, hence my conclusion.
seanalltogether 15y ago
My biggest question with webgl is who is it targeted at? Certainly it can't be game developers because javascript is still way to slow to manage a game world and vector logic. Pipelining assets is also a big problem in html and I just can't see many devs taking it seriously as a way to deliver 3d games.
- Joeri 15y ago
  You can preload the assets and store them in the html5 app cache. If you've seen the webgl Quake 2 port you know that javascript is fast enough to do games, at least the lighter ones, like the stuff telltale makes.
- nkassis 15y ago
  Check out my application: https://brainbrowser.cbrain.mcgill.ca https://brainbrowser.cbrain.mcgill.ca (sorry if it's a little hard to use, I'm working on documentation but my user base usually knows what all the stuff means.) It's in use by neuroscientist for a varity of stuff. I have users in almost all continents. (I need people in Australia and African Countries ;p) There are many games that could be done with WebGL as it is today. Some little RTS games that could be fun. Zynga has proven that you don't need anything fancy to make money from games. As for other applications, well I think http://ro.me http://ro.me is a great example of something that can be done with WebGL. I bought the CD just because of that video. It was brilliant marketing.
  - seanalltogether 15y ago
    Your app is a great example as the requirements are very finite. Web games on the other hand seem better suited for 2D, since the requirements for 3D games are much larger.
    - nkassis 15y ago
      You are there definitively some things that will need to change for 3D games to be possible in WebGL. LocalStorage limits (unless using the Chrome WebStore) is preventing games from store let say 300mb of data into your browser for later use. For bigger games we are talking about GB. The audio api is also in flux right now and isn't ready for prime time in my view but it's getting there. WebCL is another thing that could help. Game physics will probably make good use of WebCL. But at the same time, games that can run on your iPad should be able to be made in WebGL with not to many issues. I'm looking at games like the new Age of Empires online (since I played that not to long ago). I feel that it's a game which could be implemented using WebGL and a larger local storage limit and proper WebSocket support. I'm sure you will find that I'm very optimistic but my app barely pushes the capabilities of WebGL and new javascript APIs.
Locke1689 15y ago
Wow, this thread is turning into another security-clueless developer freakout. Microsoft very clearly laid out reasons why they believe that WebGL presents possible security vulnerabilities. While GPU security isn't my area of expertise, the driver issues seem very plausible. If someone wants to actually address Microsoft's points in this thread then that would be great.
- daeken 15y ago
  I can also support their claims with some preliminary research I've done. When I have free time, I've been poking at the security of shader compilers -- both the translation that's done in Webkit and the compilers in drivers -- and things are pretty bad. Don't have much to show for it yet (a couple non-exploitable crashes/bugs), but I think future research will prove very fruitful.
- cma 15y ago
  I don't have a response, but Microsoft supposedly thinks it is securable enough for Silverlight: "With the release of Silverlight 3 Beta 1 GPU (Graphics Processing Unit) acceleration (or hardware acceleration) is now available." I'd like to hear what could make that secure that couldn't be used with WebGL.
  - daeken 15y ago
    I don't know anything about how they're doing this, but I wonder if it has something to do with the bytecode abstraction used in D3D. In D3D, you compile HLSL to bytecode which then gets passed down to the kernel, but in the OGL world you pass source straight down to the kernel. Definitely still risks there, but significantly diminished, and some simple verification in userland would make it next to impossible to get a lot of nasty code down into the kernel.
    - Impossible 15y ago
      MS could (and probably would) write an Angle style abstraction layer that runs WebGL on top of D3D9 or D3D11 anyway, so I think source going to the kernel isn't a big deal. It's possible that because MS has more knowledge of the graphics drivers work in Windows they know about some dangerous security holes that Mozilla, Google, or even Nvidia or AMD aren't aware of, but its equally possible that they just don't want to support WebGL for political reasons and this is a semi-technical excuse.
mixmastamyk 15y ago
I'm not a fan of most MS products, and I get a bit of NIH syndrome vibe from the article. However, the security argument is spot on. Perhaps browser developers have come up with strong countermeasures, but experience shows the state of OS and app development today is still ineffective in the area. I don't allow Java, most Javascript, and most Flash to run on my system either, so its nothing personal. With direct access to hardware, flakey video drivers, and no thought to security, the possibilities for disaster are even greater with WebGL. Remember Windows has graphics drivers in the kernel. Also, as long as browsers continue to execute objects on page load instead of behind a play button security breaches will continue.
- georgemcbay 15y ago
  "Remember Windows has graphics drivers in the kernel" Post-XP, very little of the graphics driver is in the kernel (just the KMD bits). It is mostly all in user space.
  - mixmastamyk 15y ago
    Ok, although "when there's a will, there's a way." ;)
- MatthewPhillips 15y ago
  Why is deferring execute to a button any better? A user that visits a site is implicitly trusting it; it doesn't take additional trust to click a link (or hover over a link, for that matter). Sandboxing js to only user explicit events will take us back to the browser stone ages.
  - mixmastamyk 15y ago
    It is much better security/performance-wise to only run programs you intend to. There are sites you visit every day like HN, and there are those sites you rarely if ever visit. Perhaps a link from a link to one of the stories here. Not allowing those sites to autoexecute code is very powerful. Hell, not allowing tracking code to run at trusted sites is just as powerful. With Flashblock et all, I can go to strange urls and not have to worry about dangerous, performance sapping shit getting loaded. There is a whitelist for sites/scripts I choose to enable. If you've never used NoScript/Ghostery give them a try. Your eyes will be opened to the sheer amount garbage loaded even on "trustworthy" sites.
jinushaun 15y ago
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.
- simonw 15y ago
  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 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.html http://code.google.com/contests/nativeclient-security/faq.ht...
extension 15y ago
This is absolutely correct. Exposing video drivers to untrusted code is bonkers. Unfortunately, the ad-hominem attacks against Microsoft will likely prevail here.
alexkcd 15y ago
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?
- silentOpen 15y ago
  They do bounds checking and shader verification using ANGLE. http://code.google.com/p/angleproject/ http://code.google.com/p/angleproject/
  - daeken 15y ago
    The shader verification isn't perfect (e.g. mishandling unicode), though, and is only syntax deep -- if you find bugs in the compiler based around, say, too many function calls nested together (e.g. foo(bar(baz(...))) ) then it will go through ANGLE with no changes. It's a good effort, but needs a lot of work. I've been fuzzing it off and on for that reason.
deleted 15y ago
[deleted]
joeybaker 15y ago
So… "native HTML5" in IE10 doesn't include 3D graphics?
leon_ 15y ago
If I think about it I really don't want to expose ring0 code (gfx drivers) to the web.
joelthelion 15y ago
They have a point, but coming from the company that invented ActiveX, I find it rather funny :)
- cube13 15y ago
  I would argue ActiveX gives MS a lot of credibility here. If they're saying it's insecure...
- jimbobimbo 15y ago
  Actually, thanks to the backlash they got in Windows XP pre-SP2 times, they are very security-conscious now. Blessing in disguise.
andybak 15y ago
Looks like O3D would have been a better approach after all. Did Google back the wrong horse?
- nkassis 15y ago
  As far as I know this would also have been possible in o3d. My current app,stated out on o3d but I think the webgl move was smart. Now if they could maintain the o3d-webgl library they wrote for the change, i would be really happy. I feel that they abandoned the o3d crowd and a pretty good library.
malkia 15y ago
Back in 2000, I remember that a PC game I was working on, was slower in NT, than Windows 98 or was it ME. Explanation from Microsoft (they ware the publisher too) was that in NT they had to check every vertex index, whether it's out of bounds, otherwise one somehow might be able to read memory which he's not supposed to. And couple of other things too. I guess it might be a valid concern. Though I would love if WebGL becomes adopted by everyone.
scotth 15y ago
From the WebGL spec: "It is possible to create, either intentionally or unintentionally, combinations of shaders and geometry that take an undesirably long time to render. This issue is analogous to that of long-running scripts, for which user agents already have safeguards. However, long-running draw calls can cause loss of interactivity for the entire window system, not just the user agent. In the general case it is not possible to impose limits on the structure of incoming shaders to guard against this problem. Experimentation has shown that even very strict structural limits are insufficient to prevent long rendering times, and such limits would prevent shader authors from implementing common algorithms. User agents should implement safeguards to prevent excessively long rendering times and associated loss of interactivity. Suggested safeguards include: Splitting up draw calls with large numbers of elements into smaller draw calls. Timing individual draw calls and forbidding further rendering from a page if a certain timeout is exceeded. Using any watchdog facilities available at the user level, graphics API level, or operating system level to limit the duration of draw calls. Separating the graphics rendering of the user agent into a distinct operating system process which can be terminated and restarted without losing application state. The supporting infrastructure at the OS and graphics API layer is expected to improve over time, which is why the exact nature of these safeguards is not specified."
rbanffy 15y ago
If your GPU has access to the same memory your OS is running in and you can make it run your own code, isn't the machine vulnerable?
hootmon 15y ago
This is as usual for a korpo giant press release, complete BS. What is is really saying is that MS is not going to work with WebGL like they would any other open standard in preference for their own proprietary formats. This of course is the fascist company that is more than happy to hand over backdoor keys to any power with enough cash where the only security they are concerned with is their own financial security. Is WebGL perfect no. Does it need the help many developers to overcome some of it's shortcomings, yes. Are there many MS fanboies around, yes, but fewer everyday. What a crock.
reduxredacted 15y ago
I'm actually a big fan of several Microsoft products, and think their stand on WebGL is completely right. OEM video card drivers have a history of already being unstable. In all likelihood, this represents an attack vector that, up until this point, I hadn't even thought of. That said, it highlights something that has become somewhat of a trend with Microsoft. They seem to have decision making in almost every area being done by different teams who don't talk to one another. While I agree that OpenGL isn't "safe", what about ActiveX? Isn't allowing a browser to execute arbitrary code directly against the processor (regardless of whether or not its "signed" and the user had to click a few dialogs), a far greater threat? I'd love to see a press release that indicated they were ripping that functionality out of all currently supported browsers. What about Silverlight? I thought that had elements of hardware acceleration (perhaps it's protected enough, who knows?). Kudos, to them, for taking a well reasoned stand for security in an application type that is routinely used to attack users, but I'd like to see the other 'harmful' features addressed as well. For now, I find Firefox with NoScript and Adblock+ to be the safest bet.
ashcairo 15y ago
I don't understand how running GPU exploits in a native application is anymore secure.
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
dantheta 15y ago
"Microsoft believes that WebGL will become an “ongoing source of hard-to-fix vulnerabilities” in its current form. " If only they'd had the same insight with ActiveX, and all of the other attempts to turn Internet Explorer into a zero-install native application execution environment.

109 points by ssclafani 15y ago

vbrenny 15y ago

Yeah, sure. Silverlight is the future!

jimbobimbo 15y ago
Actually, that's an interesting point. Silverlight allows pixel shader usage, which they view unsafe in WebGL. That'd be interesting to read SDL team's views on this.
- jimbobimbo 15y ago
  Looks, like this is the answer: http://news.ycombinator.com/item?id=2663497 http://news.ycombinator.com/item?id=2663497

nextparadigms 15y ago

Whatever. Whoever makes WebGL games will benefit from 50% of the total browser market share, and this market share will keep increasing as I doubt the new versions of IE (9/10) will replace the older IE browsers, especially since the new ones only work on certain Windows versions. Whether Microsoft embraces WebGL or not, it's irrelevant, because they'd only add like 5% market share they have with IE9, anyway. I think WebGL developers can safely ignore the IE9/IE10 markets.

hartror 15y ago
But can Google and Mozilla ignore the security concerns that are a inherent part of WebGL?
- robin_reala 15y ago
  No, they can deal with them. The only inherent thing about security concerns exposed by WebGL is that there will be them, not that they can’t be fixed.

r00fus 15y ago

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 the envelope, will take much longer than with a cohesive, well-driven native app platform.

drivebyacct2 15y ago
>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.
- BadHabitz 15y ago
  who gives a shit about the quality of his comment. your mother said to get off the computer
  - drivebyacct2 15y ago
    I don't understand. Did I offend someone, was I out of line?
- r00fus 15y ago
  > I think that someone may have lied to you when they explained the words "open" or "standard". h.264 is not royalty free, but it is open and a standard (from Ars: http://arstechnica.com/web/news/2011/01/googles-dropping-h264-from-chrome-a-step-backward-for-openness.ars http://arstechnica.com/web/news/2011/01/googles-dropping-h26... ) "In the traditional sense, H.264 is an open standard. That is to say, it was a standard designed by a range of domain experts from across the industry, working to the remit of a standards organization. In fact, two standards organizations were involved: ISO and ITU. The specification was devised collaboratively, with its final ratification dependent on the agreement of the individuals, corporations, and national standards bodies that variously make up ISO and ITU. This makes H.264 an open standard in the same way as, for example, JPEG still images, or the C++ programming language, or the ISO 9660 filesystem used on CD-ROMs. H.264 is unambiguously open."

keithwarren 15y ago

Cue the chorus of people saying this is because Microsoft sucks etc etc. Ignore the fact that Microsoft has spent more time and resources than any technology company in the world focusing on web related security. Mind you that is not an endorsement of their track record, but a statement with respect to the reality on the ground.

drivebyacct2 15y ago
What? I'd love a citation on that. And I've spent a lot of time trying to make a baby by myself, but that doesn't mean I've been the least bit successful. Seriously, come on. Where is this evidence that Microsoft has "spent more time on web security" than anyone else? Their track record sure doesn't support it. Is there a competition among the big-3 to compare amount of time spent on web security? In fact, the fact that Microsoft supposedly spends so much time on web security and continues to fail so bad makes me feel much worse about their opinions on the security of WebGL. This is also the company, mind you, that introduced the decade-long nightmare of ActiveX.
rbanffy 15y ago
> Microsoft has spent more time and resources than any technology company in the world focusing on web related security. Mostly because they had to. If others spent less it could be because they had a smaller vulnerable surface to begin with, or simpler codebases.
- daeken 15y ago
  You evidently haven't seen the massive codebases from the Mozilla or Webkit camps, or the huge number of vulnerabilities therein in recent years. IE is a huge piece of shit, but MS has done a lot for web security. Mind you, I think Google's efforts have been more fruitful, but writing off MS's effort is silly.
  - rbanffy 15y ago
    The way IE is reliant on Windows and vice-versa, you can't really draw a clear line separating Windows and IE (at least not security-wise). It's very different with Mozilla and Webkit codebases, where the clean separation exists (as they are both multi-platform). I believe IE's base also carries lots of cruft from previous versions, something that complicates matters even more. Microsoft did a lot, quite possibly because they had a whole lot to do. No other company has an OS that large (Windows is huge) so tightly coupled to a browser.

giberson 15y ago

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 hardware device that simply implements the calculator language. It only has access to the numbers and data it was supplied. It crunches the numbers, and then returns pixel data. The video card is a black box, numbers go in, numbers come out. Pixel data is just a set of numbers that represent color. You take the pixel data and you send it to the monitor. Honestly, what could possibly go wrong? Seriously, I have a hard time comprehending the "surface" are of the attack. I'm familiar with ideas like memory buffer overflow attacks--but I mean video cards have their own dedicated memory, even if you manage to read some memory outside of your allocated block--you'd only be getting numbers from the video card memory which is just geometry definitions... Actually, just now typing that last paragraph I think I figured out why gaining access to the GPU memory would represent a security concern. I suppose if that memory contained screen pixel data, it could be used to "read" what was on the screen via some form of OCR? Or, perhaps maybe depending on the OS implementation, more than just "pixel" data may reside in the GPU memory. Gr, it's really quite frustrating that these stupid security issues keep getting in the way of forward progress--or more so that large company vendors are back pedaling simply because it's a "hard" problem to tackle.

oomkiller 15y ago
I think their concern is that the hardware drivers have bugs in them that could lead to remote compromise, not that access to the GPU. Microsoft knows something about this, as the execution of untrusted/unsigned shader code allowed the Xbox 360 to run unsigned code back in the day: http://en.wikipedia.org/wiki/Free60 http://en.wikipedia.org/wiki/Free60
nkassis 15y ago
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 is wrong here on many levels. My WebGL app has frozen a few machines in the past with random bugs that I haven't figured out yet. I tell my users to be careful but I know someone out there knows how to do it predictably. But you know what, it's about time Nvidia/ATI/Intel/others pull their own weight and fix the damn issues with their drivers. If it can be done with WebGL it can be done with native applications. Flash Molehill probably too.

tree_of_item 15y ago

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

jimbobimbo 15y ago
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.
- bmm6o 15y ago
  Exactly. TFA: "Attacks that may have previously resulted only in local elevation of privilege may now result in remote compromise."
- Hov 15y ago
  I'm almost certain Silverlight's Pixel Shaders don't run on the GPU. I have no proof of this other than that they're pretty slow, hence my conclusion.

seanalltogether 15y ago

My biggest question with webgl is who is it targeted at? Certainly it can't be game developers because javascript is still way to slow to manage a game world and vector logic. Pipelining assets is also a big problem in html and I just can't see many devs taking it seriously as a way to deliver 3d games.

Joeri 15y ago
You can preload the assets and store them in the html5 app cache. If you've seen the webgl Quake 2 port you know that javascript is fast enough to do games, at least the lighter ones, like the stuff telltale makes.
nkassis 15y ago
Check out my application: https://brainbrowser.cbrain.mcgill.ca https://brainbrowser.cbrain.mcgill.ca (sorry if it's a little hard to use, I'm working on documentation but my user base usually knows what all the stuff means.) It's in use by neuroscientist for a varity of stuff. I have users in almost all continents. (I need people in Australia and African Countries ;p) There are many games that could be done with WebGL as it is today. Some little RTS games that could be fun. Zynga has proven that you don't need anything fancy to make money from games. As for other applications, well I think http://ro.me http://ro.me is a great example of something that can be done with WebGL. I bought the CD just because of that video. It was brilliant marketing.
- seanalltogether 15y ago
  Your app is a great example as the requirements are very finite. Web games on the other hand seem better suited for 2D, since the requirements for 3D games are much larger.
  - nkassis 15y ago
    You are there definitively some things that will need to change for 3D games to be possible in WebGL. LocalStorage limits (unless using the Chrome WebStore) is preventing games from store let say 300mb of data into your browser for later use. For bigger games we are talking about GB. The audio api is also in flux right now and isn't ready for prime time in my view but it's getting there. WebCL is another thing that could help. Game physics will probably make good use of WebCL. But at the same time, games that can run on your iPad should be able to be made in WebGL with not to many issues. I'm looking at games like the new Age of Empires online (since I played that not to long ago). I feel that it's a game which could be implemented using WebGL and a larger local storage limit and proper WebSocket support. I'm sure you will find that I'm very optimistic but my app barely pushes the capabilities of WebGL and new javascript APIs.

Locke1689 15y ago

Wow, this thread is turning into another security-clueless developer freakout. Microsoft very clearly laid out reasons why they believe that WebGL presents possible security vulnerabilities. While GPU security isn't my area of expertise, the driver issues seem very plausible. If someone wants to actually address Microsoft's points in this thread then that would be great.

daeken 15y ago
I can also support their claims with some preliminary research I've done. When I have free time, I've been poking at the security of shader compilers -- both the translation that's done in Webkit and the compilers in drivers -- and things are pretty bad. Don't have much to show for it yet (a couple non-exploitable crashes/bugs), but I think future research will prove very fruitful.
cma 15y ago
I don't have a response, but Microsoft supposedly thinks it is securable enough for Silverlight: "With the release of Silverlight 3 Beta 1 GPU (Graphics Processing Unit) acceleration (or hardware acceleration) is now available." I'd like to hear what could make that secure that couldn't be used with WebGL.
- daeken 15y ago
  I don't know anything about how they're doing this, but I wonder if it has something to do with the bytecode abstraction used in D3D. In D3D, you compile HLSL to bytecode which then gets passed down to the kernel, but in the OGL world you pass source straight down to the kernel. Definitely still risks there, but significantly diminished, and some simple verification in userland would make it next to impossible to get a lot of nasty code down into the kernel.
  - Impossible 15y ago
    MS could (and probably would) write an Angle style abstraction layer that runs WebGL on top of D3D9 or D3D11 anyway, so I think source going to the kernel isn't a big deal. It's possible that because MS has more knowledge of the graphics drivers work in Windows they know about some dangerous security holes that Mozilla, Google, or even Nvidia or AMD aren't aware of, but its equally possible that they just don't want to support WebGL for political reasons and this is a semi-technical excuse.

mixmastamyk 15y ago

I'm not a fan of most MS products, and I get a bit of NIH syndrome vibe from the article. However, the security argument is spot on. Perhaps browser developers have come up with strong countermeasures, but experience shows the state of OS and app development today is still ineffective in the area. I don't allow Java, most Javascript, and most Flash to run on my system either, so its nothing personal. With direct access to hardware, flakey video drivers, and no thought to security, the possibilities for disaster are even greater with WebGL. Remember Windows has graphics drivers in the kernel. Also, as long as browsers continue to execute objects on page load instead of behind a play button security breaches will continue.

georgemcbay 15y ago
"Remember Windows has graphics drivers in the kernel" Post-XP, very little of the graphics driver is in the kernel (just the KMD bits). It is mostly all in user space.
- mixmastamyk 15y ago
  Ok, although "when there's a will, there's a way." ;)
MatthewPhillips 15y ago
Why is deferring execute to a button any better? A user that visits a site is implicitly trusting it; it doesn't take additional trust to click a link (or hover over a link, for that matter). Sandboxing js to only user explicit events will take us back to the browser stone ages.
- mixmastamyk 15y ago
  It is much better security/performance-wise to only run programs you intend to. There are sites you visit every day like HN, and there are those sites you rarely if ever visit. Perhaps a link from a link to one of the stories here. Not allowing those sites to autoexecute code is very powerful. Hell, not allowing tracking code to run at trusted sites is just as powerful. With Flashblock et all, I can go to strange urls and not have to worry about dangerous, performance sapping shit getting loaded. There is a whitelist for sites/scripts I choose to enable. If you've never used NoScript/Ghostery give them a try. Your eyes will be opened to the sheer amount garbage loaded even on "trustworthy" sites.

jinushaun 15y ago

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.

simonw 15y ago
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 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.html http://code.google.com/contests/nativeclient-security/faq.ht...

extension 15y ago

This is absolutely correct. Exposing video drivers to untrusted code is bonkers. Unfortunately, the ad-hominem attacks against Microsoft will likely prevail here.

alexkcd 15y ago

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?

silentOpen 15y ago
They do bounds checking and shader verification using ANGLE. http://code.google.com/p/angleproject/ http://code.google.com/p/angleproject/
- daeken 15y ago
  The shader verification isn't perfect (e.g. mishandling unicode), though, and is only syntax deep -- if you find bugs in the compiler based around, say, too many function calls nested together (e.g. foo(bar(baz(...))) ) then it will go through ANGLE with no changes. It's a good effort, but needs a lot of work. I've been fuzzing it off and on for that reason.

deleted 15y ago

[deleted]

joeybaker 15y ago

So… "native HTML5" in IE10 doesn't include 3D graphics?

leon_ 15y ago

If I think about it I really don't want to expose ring0 code (gfx drivers) to the web.

joelthelion 15y ago

They have a point, but coming from the company that invented ActiveX, I find it rather funny :)

cube13 15y ago
I would argue ActiveX gives MS a lot of credibility here. If they're saying it's insecure...
jimbobimbo 15y ago
Actually, thanks to the backlash they got in Windows XP pre-SP2 times, they are very security-conscious now. Blessing in disguise.

andybak 15y ago

Looks like O3D would have been a better approach after all. Did Google back the wrong horse?

nkassis 15y ago
As far as I know this would also have been possible in o3d. My current app,stated out on o3d but I think the webgl move was smart. Now if they could maintain the o3d-webgl library they wrote for the change, i would be really happy. I feel that they abandoned the o3d crowd and a pretty good library.

malkia 15y ago

Back in 2000, I remember that a PC game I was working on, was slower in NT, than Windows 98 or was it ME. Explanation from Microsoft (they ware the publisher too) was that in NT they had to check every vertex index, whether it's out of bounds, otherwise one somehow might be able to read memory which he's not supposed to. And couple of other things too. I guess it might be a valid concern. Though I would love if WebGL becomes adopted by everyone.

scotth 15y ago

From the WebGL spec: "It is possible to create, either intentionally or unintentionally, combinations of shaders and geometry that take an undesirably long time to render. This issue is analogous to that of long-running scripts, for which user agents already have safeguards. However, long-running draw calls can cause loss of interactivity for the entire window system, not just the user agent. In the general case it is not possible to impose limits on the structure of incoming shaders to guard against this problem. Experimentation has shown that even very strict structural limits are insufficient to prevent long rendering times, and such limits would prevent shader authors from implementing common algorithms. User agents should implement safeguards to prevent excessively long rendering times and associated loss of interactivity. Suggested safeguards include: Splitting up draw calls with large numbers of elements into smaller draw calls. Timing individual draw calls and forbidding further rendering from a page if a certain timeout is exceeded. Using any watchdog facilities available at the user level, graphics API level, or operating system level to limit the duration of draw calls. Separating the graphics rendering of the user agent into a distinct operating system process which can be terminated and restarted without losing application state. The supporting infrastructure at the OS and graphics API layer is expected to improve over time, which is why the exact nature of these safeguards is not specified."

rbanffy 15y ago

If your GPU has access to the same memory your OS is running in and you can make it run your own code, isn't the machine vulnerable?

hootmon 15y ago

This is as usual for a korpo giant press release, complete BS. What is is really saying is that MS is not going to work with WebGL like they would any other open standard in preference for their own proprietary formats. This of course is the fascist company that is more than happy to hand over backdoor keys to any power with enough cash where the only security they are concerned with is their own financial security. Is WebGL perfect no. Does it need the help many developers to overcome some of it's shortcomings, yes. Are there many MS fanboies around, yes, but fewer everyday. What a crock.

reduxredacted 15y ago

I'm actually a big fan of several Microsoft products, and think their stand on WebGL is completely right. OEM video card drivers have a history of already being unstable. In all likelihood, this represents an attack vector that, up until this point, I hadn't even thought of. That said, it highlights something that has become somewhat of a trend with Microsoft. They seem to have decision making in almost every area being done by different teams who don't talk to one another. While I agree that OpenGL isn't "safe", what about ActiveX? Isn't allowing a browser to execute arbitrary code directly against the processor (regardless of whether or not its "signed" and the user had to click a few dialogs), a far greater threat? I'd love to see a press release that indicated they were ripping that functionality out of all currently supported browsers. What about Silverlight? I thought that had elements of hardware acceleration (perhaps it's protected enough, who knows?). Kudos, to them, for taking a well reasoned stand for security in an application type that is routinely used to attack users, but I'd like to see the other 'harmful' features addressed as well. For now, I find Firefox with NoScript and Adblock+ to be the safest bet.

ashcairo 15y ago

I don't understand how running GPU exploits in a native application is anymore secure.

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

dantheta 15y ago

"Microsoft believes that WebGL will become an “ongoing source of hard-to-fix vulnerabilities” in its current form. " If only they'd had the same insight with ActiveX, and all of the other attempts to turn Internet Explorer into a zero-install native application execution environment.