Microsoft refuses to endorse WebGL, labels it ‘harmful’
winrumors.com
winrumors.com
"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.
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.
You do not have permission to call Direct3D directly. You can't even do cool hacks like you can in WPF, stealing the Direct3D video feed and writing it to a movie file. Everything is abstracted away by (underpowered) APIs.
All Secunia advisories on .NET Framework / Silverlight are presently patched, and the total number is relatively small compared to other technologies like web browsers and Flash. I don't really know enough about WebGL to compare, though.
Silverlight is more secure than WPF, too, by the way, and has to be. For example, in WPF there is a very insecure static method that allows you to steal a bitmap of the entire screen! This was one of the first things taken out of Silverlight.
If you want to know more about Silverlight security, ask Nick Kramer who maintains the Silverlight security best practices document for Microsoft.
(I worked on XNA while at Microsoft about a year ago)
I knew that this was happening, but didn't know they released it yet. It's my understanding that they worked crazy hard to make this secure.
Given the concerns Microsoft is voicing (and they aren't the first to voice them) are well below the application itself, I tend to trust Microsoft more on this one.
Then there's XNA in Silverlight. If they believe in the security of that, why not build WebGL on top of it? Probably because they're in direct competition with one another, and Microsoft wants Silverlight to win.
I'm pretty sure you could build a WebGL API on top of Silverlight by yourself. It would suck, but it is possible.
That's why I always thought Silverlight is pretty cool as a technology, as compared to Flash. Among other things, a Silverlight plugin could also allow you to serve OGG Theora videos to users.
We cannot, however, discount the incentive Microsoft has in preventing the formation of another standard it can't control. I would consider any info coming from Redmond on this issue to be somewhat exaggerated.
And Windows-specific.
http://twitter.com/#!/paul_irish/status/81492337108328448 @AlexGraul i think chrome's record in pwn2own is a good indicator of our commitment to security while delivering great features. :)
I do know Chrome and FF just fixed a timing attack vector where you could apparently intuit the content of a crossdomain image by interpreting what hues were based on it via the application of shaders. Which means hypothetically you could read text. Like a crazy-person's OCR.
Should Microsoft stop supporting Java applets for the same reason?
Any game developer will tell you: It's pretty easy to accidentally craft a shader that will totally stall particular GPUs, taking down the entire windowing environment, if not the entire system. With malicious intent, shaders are a giant gaping DoS attack waiting to happen.
Beyond that, the shader compiler backends are supplied by third parties because they generate hardware specific opcodes and optimizations. Considering how poor nVidia and ATI's drivers have been historically, do you really trust them to create secure compilers?
In theory, Microsoft could implement a subset of WebGL without shaders, but I'd rather it not exist than be crippled and unusable. There are probably several other potential vulnerabilities I don't have firsthand experience with too.
All that said, I think that Java applets & JOGL already expose this attack vector.
The solution is to address the problems in the article.
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.
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.
The open source drivers also follow this kind of model where the kernel modules handle hardware access and memory management but not a whole lot more. Mesa (and Gallium 3D) all work in userspace to handle compiling things to the native formats of the cards.
It's been about time for 15 years, and they still haven't. Video card drivers are #1 reason for windows crashes. Microsoft put a lot of pressure on these companies (and Microsoft knows pressure) and it still didn't help.
The biggest issue is that GPUs can do DMA to read and write directly in main RAM. This can be exploited to overwrite arbitrary kernel data structures, for example.
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.
In general, when I see blog recaps I almost always go to the source. This blog entry, like most good ones, will link to their sources.
I wish I could say it was because I'm an expert on OpenGl and security. I'm really just a rabid link follower.
That is. They can:
a)Make your computer "impossible" to use(until you plug the computer power off and restart), what they cal Denial of Service
b) They can get access to your super important and super confidential screen information, like your bank account or your plans to dominate the world.
I agree with you,not a big deal to me, I find WebGL to be very useful, like google body(use google Chrome, Firefox is slower): http://bodybrowser.googlelabs.com/body.html
Here common sense applies, if you are going to use financial services just use them. Visit WebGL sites when you are not doing something serious and problem solved. Also while it is technically possible to do, it is really difficult to exploit, I program GPUs.
I understand Microsoft position here too, they don't want people suing them because someone manage to get their financial data and stole their identity and money while watching cool webGL animations, but I think you can trust the big guys (google) on this one, they are not going to steal your financial data, in some cases they already have it :-).
"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."
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?
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.
Post-XP, very little of the graphics driver is in the kernel (just the KMD bits). It is mostly all in user space.
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.
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.
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.
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.
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.
I know you like to hate on MS (how many times have we been over this in the past few months?), but really, your claims here are completely unfounded. IE has a completely shit track record, but they have done a whole, whole lot in recent years to improve its security. Look at the many, many vulnerabilities in other browsers/layout engines compared to IE in recent years -- it's pretty startling. There are many reasons to hate on IE, but the effort put into securing it -- and the way they've gone about securing it -- is definitely not on of them.
As for your claim IE is no more dependent on Windows than Safari or Firefox, I will have to take your word for it, as it has been a long time (almost a decade) since I last inspected IE and what interfaces it used from the underlying OS. At that time, they both seemed very intimate.
And yes. I derive a lot of fun from observing Microsoft.
As for investments in an OS affecting all software running on it, it all depends on the fix not being the introduction of an improved API, as software using the old one will remain vulnerable.
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.
I guess it might be a valid concern. Though I would love if WebGL becomes adopted by everyone.
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.
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 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.
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.
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...
Did Google back the wrong horse?
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.
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.
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.
your mother said to get off the computer
h.264 is not royalty free, but it is open and a standard (from 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."
But if you look for precise definitions of the phrase "open standard" you might find that H.264 fails 14/16 of the various definitions offered by governments and standards bodies on the wikipedia page for that term. All failing for the same reason of charging patent fees. One of the other definitions is a historical accident that I doubt the same body would stand by today, or at any point in the last 5 or so years. The final definition, the one that it passes, just so happens to be written by patent attorneys of the people who developed H.264.