WebGL Security and Microsoft Bullshit


1) I work at Google on Chrome
2) Nothing I say here represents my employer in anyway. This my own opinion.

It’s frustrating to see how bad Microsoft can really be. I’m one of Microsoft’s biggest fans. I still think Windows7 is better than OSX or Linux(*). I play more XBox 360 games than any other console. I was hopeful for Win7 Phone and am hopeful for Windows 8. I was on Microsoft’s side in the Java lawsuit, the Internet Explorer lawsuit and several others. I think Visual Studio’s debugger is way better than anything I’ve used on OSX or Linux. I think C# is way more awesome than Java. I was really happy when they started IE9 development and started actually competing.

So imagine my disappointment when I start seeing the FUD from Microsoft about IE9 vs other browsers. Cherry picking benchmarks, cherry picking conformance tests and generally basically lying.

The latest FUD is Microsoft’s claim that they won’t support WebGL because it’s insecure. They might have a little more credibility if they weren’t promoting a technology, Silverlight 5, that provides the EXACT SAME FEATURES with all the same issues. They can’t have it both ways. Either it’s possible to make this tech safe or else it’s not. If it is possible to make it safe in Silverlight 5 then it’s also just as possible in WebGL. If it’s not possible to make it safe Microsoft would have to come out and say (1) They are removing GPU access from Silverlight 5. (2) They are banning Unity3D from running in IE since it also provides access to the EXACT SAME FEATURES. (3) They are banning Flash 11 from running in IE since it also provides access to the EXACT SAME FEATURES.

Since they have done none of these things then we know with 100% certainty that their claims are self serving FUD meant only to try to scare people into using IE on the one hand while exposing the exact same feature set with the exact same risks (according to them) on the other.

It’s even more telling that Microsoft hired a firm, ContextIS, to create this bogus FUD so they’d have someone to hide behind. It’s pretty convenient that only a few minutes after ContextIS’s latest post Microsoft already had a well manicured response. If ContextIS had any credibility they’d be posting about the same issues on Silverlight5 (warning: might crash your machine), Flash 11 and Unity3D.

The sad truth is Microsoft has a vested interest in spreading FUD about WebGL. WebGL enables features that make IE9 and IE10 look like crap. Amazing 3D demos. Even 2D, for example the Facebook JSGameBench got a 4x speed up when switching from 2d canvas to WebGL.

Microsoft has never supported OpenGL which is what WebGL is based on. Instead they have their DirectX API. The DirectX API is great but the #1 reason Microsoft doesn’t want to support anything based on OpenGL is that it robs them of some of their lock-in. You see, if you program an application using DirectX for 360, DirectX for Windows, DirectX for Silverlight or DirectX for Window7 Phone, well, you’re stuck on those platforms. Want to port to OSX or iOS or Android and you’re out of luck. You have to re-write a bunch of your graphics code and shaders.

On the other hand, if IE supports WebGL then more and more programmers will get use to OpenGL like APIs and there will be pressure for Microsoft to start officially supporting OpenGL on their other platforms. THAT is their biggest worry. Not this trumped up security issue that they are oh-so-happy to ignore when it comes to Silverlight 5.

So, Is WebGL a security risk? IMO no more than any other part of the browser. Remember when IE had issues with specially formed JPG images? That was a bug. It was fixed. Problem solved. Remember when IE had issues with specially formed AVI files? That was a bug. It was fixed. Problem solved. ContextIS claims WebGL lets webpages execute native code. Well guess what? JavaScript lets pages execute native code since pretty much every browser, including IE, compiles JavaScript into native code. One mistake on their part and your machine is owned unless the browser provides better defenses.

There are 2 main issues with giving anything access to the GPU

#1) Denial of Service issue.

What is a “Denial of Service” issue in WebGL? It’s a situation that happens if a webpage asks the GPU to do something that takes a really long time. Most current GPUs can not multi-task and most OSes need the GPU to do windowing and other things. Unfortunately if a program asks a GPU to do something that takes a long time, say 5 minutes, during that time nothing else can access the GPU. The OS is stuck waiting until that particular task is finished.

We studied this issue in depth at Google and we’ve proven there is no way you can limit the features of access to the GPU enough to prevent this and still have useful access to the GPU. You can cause this with or without shaders. As long as you can submit geometry to the GPU you can cause this problem.

Fortunately there are solutions. The simplest solution is to time how long the GPU is taking to execute each task. If it’s taking too long reset the GPU and kill the page that issued the command. Microsoft Windows is one of the only OSes that currently provides this solution. They should be proud of this. They can basically claim the best place to run WebGL is on Windows. The Khronos group is working to bring similar functionality to other OSes as fast as possible and it may already be available in some drivers.

The other thing about DOSing a machine is if a user goes to “” and their machine freezes how many times do you think they are going to go back? It’s a very limited type of attack. It doesn’t let you install a virus. It’s doesn’t let your steal information. All it lets you do is annoy someone until they ignore you. People trying to do bad things to you are going to want to do something permanent, not something that makes you stop going to their site.

Of course it’s completely unacceptable if your machine gets DOSed. My only point is (1) there are fixes, Windows already support them and they are coming soon to other OSes. (2) it’s not has bad as your machine getting owned. In fact most likely very soon now, if a page takes too long on the GPU it will be marked bad by the browser. If you try to visit it again you’ll be warned. Similarly using techniques like “Safe Browsing” we can warn you in advance while we work on providing the real fixes in all OSes.

2) The second issue is whether or not running WebGL is a path for native code exploits.

Here, like everywhere, it’s really no different than any other bug. Like I pointed out above if your jpg decoder has bugs it’s bad. If your AVI decoder has bugs it’s bad. If your font renderer has bugs it’s bad.

So what do you do to prevent programs from accessing bugs in drivers? Well, #1 is you test your code and try to make sure it’s bug free. Of course you can’t count on finding every bug so the next thing you do is security in depth. That’s like having a safe deposit box, in vault, surrounded by lasers, surrounded by guards, surrounded by the bank with even more security guarding the bank. If you get through one you have to get through the next and each one making it harder and harder to get through.

So what does Chrome do to keep WebGL safe? #1, like everything in Chrome, we run the webpage in its own process. Even if the webpage could somehow execute native code it can’t access files. It can’t access the network. It can’t access the keyboard or the mouse. In the WebGL case it can’t access the GPU. All GPU access in Chrome happens in a separate process called the GPU process. We get 2 big benefits from this design.

The first is that we can parallelize WebGL calls. Once your webpage has issued a command to draw it’s free to go do something else while a completely separate process goes off and actually sets up the GPU to do the drawing. For well written WebGL programs, all else being equal, this should make Chrome faster than single process architectures.

The other is that the GPU process validates EVERYTHING!!!! before calling the GPU drivers.

  • It validates all parameters so a webpage can not pass unknown parameters to the GPU.
  • It validates the size of all buffers created and all access to them. The webpage can not exploit buffer overruns in a driver. This is part of the WebGL spec.
  • It validates all indices against the size of all buffers that will be accessed during a draw call. This means a webpage can NOT submit indices that would access data outside a valid range. This too is part of the spec.
  • It validates that all writing to textures is within bounds. This means a webpage can not submit texture data outside the bounds of a texture.
  • It validates all buffers, textures and renderbuffers are cleared on creation. This means a webpage can not access data left over from other apps or pages. This is part of the WebGL spec. That Firefox had a bug in this area which has already been fixed. It was a bug in Firefox , not a bug in WebGL.
  • It validates that every GPU object referenced by the WebGL page was created by that page. If it’s not the call is not passed through to the driver.
  • It validates that the shaders submitted to the GPU use only the minimal features allowed by the spec. That means no dynamic indexing of sampler arrays. It means no infinite loops. There’s actually a huge list of features that native apps would have access do that are disallowed by this validation.

On top of all of that we work around bugs in drivers where possible. Examples of some of these bugs.

  • Some drivers are buggy in that if you give them a shader with an array of uniforms and only access uniforms at the end of the array they’ll screw up. We work around that.
  • Some drivers are buggy in that they crash if multi-sampling is enabled. We disable multi-sampling on those drivers.
  • Some drivers have bugs with long identifiers in shaders. We work around that by re-writing the shaders with small identifiers and then mapping the user’s identifiers to ours.
  • Some drivers have issues we certain kinds of loops in shaders. We unroll the loops.
  • Some drivers when asked for an RGB surface will actually return an RGBA surface. We work around this bug as well.
  • Some drivers don’t return the correct format for array identifiers and/or don’t correctly identify uniform arrays or attribute arrays as arrays. We work around these bugs too.

I’m sure there are other bugs I don’t even remember that we work around.

I think you can see, with all this validation, the odds that a webpage can exercise a bug in a driver become vanishingly small. And finally, if push comes to shove and we can’t program a workaround we blacklist the card and/or the driver.

WebGL is taking the web to the next level. Apps like Google Body, Tinkercad and multi-media demos like show the way forward.

But don’t take my word for it. Here’s another opinion by someone who apparently works for Microsoft.

The sad thing is, this is a chance for Microsoft to shine. They are currently the best OS for WebGL. They are clearly pushing Silverlight 5 and even if they decided to pull support for Silverlight 5 there is no way they are going to prevent users from installing Flash 11 which will likely auto install everywhere.

Instead, Microsoft could be leaders here. Since they want Silverlight5 and they know their users will want Flash 11 as well as WebGL in Chrome and Firefox, Microsoft could put even more pressure on GPU vendors to make the drivers awesome! They could add more security tests to their WHQL program. They could require GPUs to handle resetting better than they do. They have the power. Will they use it for evil and selfishly try to hold the web back as they appear to be doing now or will they use their power for good and help take it forward? Imagine if Windows8’s HTML5 based UI had access to WebGL!

(*) Maybe it’s not better in every way but I still prefer Windows 7 over OSX and Linux most of the time.

  • Leo Comerford

    The DirectX API is great but the #1 reason Microsoft doesn’t want to support anything based on OpenGL is that it robs them of some of their lock-in.

  • Leo Comerford

    The DirectX API is great but the #1 reason Microsoft doesn’t want to support anything based on OpenGL is that it robs them of some of their lock-in.

  • FreshCode

    nitpick: disclosure vs disclaimer?

  • fader

    It’s interesting how you supported and cheered on Microsoft when they were behaving this way outside of your space, but now that they’re doing it with something you are working on they’re spreading FUD and lies.  Maybe there was something to all the previous lawsuits after all?

  • Anonymous

    +1 (I was going to write the same idea before reading your comment)

  • Anonymous

    I’m not concerned about a lot of things till it encroaches my area, too. Don’t try to deflect from the topic or issue.

  • fader

    It’s interesting how you supported and cheered on Microsoft when they were behaving this way outside of your space, but now that they’re doing it with something you are working on they’re spreading FUD and lies.  Maybe there was something to all the previous lawsuits after all?

  • Tisham Dhar

    There is a 3rd option for GL in the browser (Java OpenGL – JOGL) which I pretty heavily use. In this case the driver code is linked to open-source (unlike Sliverlight or Flash) native libraries and signed. So you can track down whoever is sending you naughty things.

  • greggman

    Funny, the principle implementor of JOGL is the principle implementor of WebGL and is chairman of the Khronos WebGL Group.

  • Tisham Dhar

    I wasn’t aware of this tid-bit (my principle JOGL project is NASA worldwind) – Ken JOGL Russell is doing well then.

  • Larry Zoumas

    You think Win7 is better than Mac OSX? For what? Crashing or gaming?

  • greggman

    I have 4 OSX machines. A Mac mini, A Personal i7 8gig Macbook Pro. A company i7 8gig macbook pro and an 8 core 12gig MacPro. All of them crash on me WAY MORE THAN Win7. That’s my experience. That doesn’t mean I hate OSX. In fact I use it more then Win7 at this point. Mostly because I like the hardware better than any Win machine I have access to so I carry the Macbook Pros everywhere.

  • Anonymous

    Win 7 is better than Mac OSx for everything.  Period.

  • greggman

    The fact is their announcement is BS for the same reasons pointed out above. Namely they are claiming exposing GPU features is insecure while at the same time exposing those same GPU features in Silverlight. That’s hypocritical and proof of FUD.

  • Anonymous

    Actually greggman, you are incorrect. Silverlight uses a plugin architecture where WebGL runs in the browser and uses javascript and, as a result, is much slower.

  • Anonymous

    What on earth does “uses javascript and, as a result, is much slower” have to do with security? Once it’s installed, it’s either resilient to these kinds of problems, or not. If a Silverlight plugin is indeed so much faster than Javascript, and has a security hole, then it’ll just end up screwing up your machine more quickly 😛

  • Anonymous

    I thought we were speaking to hardware acceleration on a GPU level per Jata’s post…must have misread your post, but honestly…when you say they’re exposing the same features, that doesn’t mean they’re doing it in the same way. I’M NOT SAYING GOOGLE WON’T FIGURE OUT THE RIGHT WAY…just to be clear :)

  • Anonymous

    We are indeed speaking to “hardware acceleration on a GPU level”. And for all intents and purposes, they are exposing the features in the same way — the purported security flaws in WebGL have everything to do with buggy drivers and DOS of the graphics hardware. These apply to both WebGL and D3D, and the same techniques can be used to mitigate them.

    In many cases, the “WebGL” implementation is actually going through the D3D driver stack anyway (c.f., so if the D3D driver and hardware stack is secure, so is the WebGL code that sits on top of it. If it’s not secure, then Silverlight and WebGL have the same problem (which, again, was the point of Gregg’s post).

  • greggman

    If MS was saying they were going to remove GPU features from Sliverlight5 and block Flash 11 and Unity3D they’d have a point. Since they didn’t they are being hypocrites. That’s the point and the proof that it’s FUD.

  • Vlad Vukicevic

    Actually, no — Google and Mozilla have a vested interest in working with various parties to resolve any issues with WebGL.  Both those organizations are doing that pretty aggressively, and  have generally been happy to engage in public discussion about issues (whether security or otherwise) in WebGL, and how they can be fixed.  Microsoft’s approach is to just attempt to smear the tech to cause developers to be scared of it; the very definition of FUD.

  • Anonymous

    Once again…plug-in architecture…do you guys have any concept of how these things work? are you developers?

  • Vlad Vukicevic

    Pretty sure Gregg and I are both intimately familiar with how these things work, yeah :-)

  • Anonymous

    okay well first off I appreciate your patience with my comment there…I didn’t mean to be so aggresive, but there are some fundamental differences here that I think put the two technologies in two very different categories regardless of the merits of one or the other

  • Anonymous

    I wouldn’t say Silverlight offers the EXACT same features and it’s also important to note that those features are just a small subset of what Silverlight has to offer. Silverlight 4, in fact, is a sophisticated platform and that is without the 3D/Unmanaged (C++) code capabilities of Silverlight 5. Silverlight is a mature plug-in architecture. Sure, you guys at Google are doing some great stuff, but who are you kidding – you and Microsoft are playing the same game and along those lines…SURE, Microsoft is going to jump on Google whenever they screw up (and vice versa), but if you want to call out Microsoft I’d be interested to know why I was unable to run the OpenGL samples Google put out in Safari, Mozilla or Opera or why several other security groups indicated there were security concerns with OpenGL.

  • greggman

    The issue is whether or not the various systems, WebGL, Flash 11, Unity3D and Silverlight5 provide access to the features MS and ContextIS are complaining about. The answer is YES. You can use any of those technologies to get the SAME access to the GPU features and if there are bugs in those technologies you can access bugs in the GPU drivers and DOS the machine.

    Microsoft is claiming they won’t support WebGL because it provides access to those “risky” features while at the same time promoting Silverlight5 with access to the same “risky” features at the same level. Sliverlight5 lets you upload and access GPU hardware buffers. Silverlight5 lets you access GPU framebuffers, textures etc. Silverlight5 lets you write hardware shaders. If you can secure Silverlight5 you can secure WebGL. If you can’t secure Silverlight5 then Microsoft is lying about their reasons for not supporting WebGL since those same reasons would apply to Silverlight5.

    I’ve already posted one sample that points out how Silverlight5 exposes the same issues.

    Microsoft should stop spreading the FUD and instead work towards solutions that would help all 4 of those technologies.

  • Anonymous

    You CAN use any of those technologies with the SAME access to the GPU features for the most part, but in Silverlight you will have even more access if you want…and to that extent YES there MAY be some weaknesses there that have yet to be exposed, but there are also some greater strengths in that what you can do with Silverlight you can do much faster because you can COMPILE code. On top of the fact that you’re working with compiled code, you can write code targetted for your application which will always yield greater performance than standardized features. That said, there’s something to be said for standards (Apple benefits quite a bit from using standardized controls in their software, granted they are proprietary to Apple, but it keeps developers from making their products look bad and helps with battery life).

  • brons

    SoundLogic, you’re way out in the weeds.  What does any of this have to do with WebGL and driver bugs?

    You can COMPILE code?  Oh, that changes everything!  Oh wait, no it doesn’t.

  • Terry

    Thank You brons for injecting sanity and logic into the conversation. And Gregg good rational and fact-based account about WebGL and how other comparable tech uses it. We need more rational fact-based debates in the interwebs nowadays. 

  • Anonymous

    Honestly, I can’t make any sense out of your insistence that Silverlight being a plugin makes it fundamentally different from WebGL. Microsoft designed and promotes this plugin as a mechanism for building media-heavy apps, using GPU features in more recent versions. Once I’ve installed it (as Microsoft asks me to, e.g., to view Netflix movies), I’m just as vulnerable as if it was built into the browser.

    And to reinforce Gregg’s point, check out this little tidbit:

    Somewhere near the bottom of this bug report, a Microsoft representative states “To clarify the earlier statement, DoS mitigations are implemented in current internal builds and will ship with Silverlight 5 RTM.” It seems pretty obvious they could do the same for GL.

  • Anonymous

    …I never said one was more secure than the other, but I do think that having a more propietary language can’t hurt (but if it’s good enough, it will become mainstream and that is then a moot point)

  • Anonymous

    I’m kind of lost here. What does a “proprietary” language have to do with anything? Are you referring to C# (ECMA-334) or MSIL (ECMA-335)? I feel fairly comfortable with both Silverlight’s VM and Javascript VMs being roughly equally secure.

  • Anonymous

    Meanwhile…whoever blocked my IP address…pretty weak…I thought Google was all about being open?

  • Robin Lee

     Only to people who aren’t dicktrolls.

  • Robin Lee

     Only to people who aren’t dicktrolls.

  • Anonymous

    I respond to reason…maybe you should read Justice Brandeis’ 1927 famous brief in the Whitney v. California case.

  • greggman

    Really? Hmmm, the latest post on their silverlight page was yesterday, June 20th

  • Richard Fine

    That just means that it still has funding *for now*. Considering the number of companies around who have built tech on top of Silverlight, there’s no way that shutting it down overnight is something Microsoft would be prepared to do.

    That doesn’t mean that they aren’t reducing new investment in the technology. My guess is that it’ll have been officially retired within 3 years.

  • John


  • Anonymous

    [disclaimer: I also work at Google. This is my opnion, not Google’s, etc., etc.]

    I’d just like to share this little tidbit:

  • Anonymous

    That’s only Silverlight 5, which is in beta.  So no kudos for you.

  • greggman

    And WebGL is still experimental. No browser is shipping yet with WebGL 1.0

  • Anonymous

    Chrome will currently run WebGL just to be clear – it may not be 1.0, but how does that make a difference if someone can run it in their browser? Silverlight 5 is not shipping to any browser unless you explicitly seek it out to download.

  • Anonymous

    WebGL is enabled by default in release builds of Firefox and Chrome, so saying ‘no browser is shipping’ it yet is a bald-faced lie. Does the spec not having a 1.0 on it make any potential security vulnerabilities irrelevant somehow?

  • greggman

    I didn’t say they weren’t shipping WebGL. I said they weren’t 1.0. In other words they are still beta. The point is someone was claiming Silverlight5 issues are off the hook because it’s beta even though IT’S ALREADY SHIPPING. By that argument WebGL is in the same boat.

  • Anonymous

    “That’s only Silverlight 5, which is in beta.” – Gregg’s point, as I read it, is that the same techniques used to make Silverlight/XNA/D3D resilient to these kinds of attacks can be applied to making WebGL resilient as well. This bug report, and the response to it, bolster his position. The beta label is irrelevant to this point at hand.
    “So no kudos for you.” – That’s just a weird statement.

  • Anonymous

    Bullshit followed by more bullshit.  Funny.  It never ends from either side.

  • Anonymous

    If you’re going to call bullshit, explain what you mean. Otherwise you’re just wasting everyone’s time.

  • Anonymous

    If you don’t understand, then you’re lost.  Consider your time completely wasted, on everything.

  • greggman

    The point is Microsoft doesn’t really believe it’s insecure. if they did they’d be banning the other 3 technologies. Silverlight5, Flash 11 and Unity3D. Since they are not it’s clear they don’t really believe what they are saying and instead have ulterior motives.

  • Richard Fine

    I think you’re crediting Microsoft with waaaay more coordination and coherency than they really deserve. The organisation, as a whole, rarely believes *anything* in any single-minded way.

    Unless you can demonstrate that the particular people at MS who are defaming GPU-in-the-browser are the *same* people who are shipping it in Silverlight, then I think you’re attributing to malice what can be adequately explained by incompetence.

  • Anonymous

    I’m sorry but when you’re commenting on a blog written by someone at Google with a bunch of Google people reading it I think the burden of proof about your particular thoughts on Microsoft is solely on you…otherwise what you’re saying is just an exercise in masturbation. There are so few comments that are objective here. I’m happy I work at a company where I don’t have to put a disclaimer at the top of every post. We aren’t tied down to a particular technology…we use C# and Silverlight, sure, but we also use Mongo DB, PostGIS, C++, PHP and Java…not one particular technology stack. I have been very openly critical of Microsoft and at the moment they risk alienating their entire Silverlight developer base so this discussion clearly doesn’t have any grounding in reality.

  • greggman

    That’s certainly possible. Doesn’t matter to the central point though. They can’t have it both ways. As a company they can’t claim they won’t ship something with access to the GPU because it’s insecure while at the same time shipping something with the same access to the GPU and allowing 2 other technologies with the same access to the GPU.

  • greggman

    There is no way to secure the GPU more than WebGL has done and still provide useful access to the GPU. Flash 11, Unity3D and Silverlight5 all provide the same level of access. Any less would be useless.

  • GeoffTyler

    I think you are simplifying to the point of confusing the issues:
    1) Useful is relative. I think most people would agree that canvas is very useful. Canvas is not Turing complete and does not expose the GPU to these kind of attacks. You can make WebGL non-turing complete and get rid of the halting problem. Instead you are CHOOSING to implement a specification that enables DOS scenarios.
    2) From what I understand it seems as if Apple agrees with Microsoft and is not opening up WebGL to general Internet at this time. It’s only exposed to controlled and vetted programs/ads. There are some drawbacks to this approach of course.

    There are options and it’s not as B&W as you make it out to be. 

  • greggman

    Microsoft doesn’t agree with Apple as they are releasing Silverlight5. It supports HLSL Shader Model 2.0 which is the exact same level of shaders implemented in WebGL. If Microsoft is releasing this tech then they must believe it’s not a problem.

  • Corbin Simpson

    I was quite critical of NaCl when I first heard about the way GPU access is
    granted to developers, but it sounds like you guys are quite on top of things
    and know exactly what’s going on, and so I’m changing my tune about Chrome’s
    GPU behavior in light of this very informational post. I did also notice that
    you guys have acquired long-time Mesa coder and all-around cool guy Stephane,
    which I find very cool.

    I just wanted to double-check: You *are* filing bugs for buggy drivers, right?
    I’d hate to think that you aren’t participating in the community, when it
    sounds like you’ve gotten just about everything else right. :3

    ~ C.

  • greggman

    Yes, bugs are and have been filed with Apple, with Intel, with AMD, with NVidia, and other GPU vendors.

  • Anonymous

    This is the same thing they did with Java.  Microsoft takes security seriously now, and if they can’t control the environment, they can’t control security.  So they’d rather not support something that they find full of holes and can’t get fixed.  Sorry to you negative heads, but this is a very good step.  Some have found similar holes in Silverlight, but guess what, those will get fixed!  This GL bullshit will probably not get fixed any time soon, if at all.

  • greggman

    it’s worse than that. You don’t even need shaders. Just draw a lot of large polygons .

  • Ssh

    teh issue about wbgl might be like this:

    i am pretty sure you willl understand what i want to show you :)

  • Tom Keetch

    Thanks, I thought this was an interesting read. Do you have any specific evidence that ContextIS were hired by MS?

    I’ve not looked at the way in which SilverLight and WebGL expose graphics acceleration, so I can’t really comment on the article as a whole, except to say that  “exactly the same features” might not be exposed in the same way, which would make a difference to the level of risk the feature poses.

    But I can comment on this paragraph:

    “So what does Chrome do to keep WebGL safe? #1, like everything in Chrome, we run the webpage in its own process. Even if the webpage could somehow execute native code it can’t access files. It can’t access the network. It can’t access the keyboard or the mouse. In the WebGL case it can’t access the GPU. All GPU access in Chrome happens in a separate process called the GPU process.”
    Malicious Code in a browser renderer tab can (on Windows at least):

    * Access the network
    * Call Kernel Interfaces (IOCTLs – which may expose graphics drivers)
    * Send Key and Mouse Events to NPAPI plugins (like Flash)

    Also, it is not prevented from accessing any files, but it can only access files as permitted by the broker.

    Lastly, the GPU processes itself is not sandboxed, but it will be at some point in future and WebGL support may make this more important.

    Let me know if you want any references to back up these comments.

    – Tom Keetch (@tkeetch:disqus )

  • Stilgar

    As a web developer I couldn’t care less about WebGL. As a user I don’t care much about security on this level because I don’t think many attacks come from actual vulnerabilities in drivers and such.

     As a gamer I hope WebGL dies a horrible death. I don’t want thousands of talanted game developers going out to create 3D Farmville. I want them to create Rage, Crysis 2, CoD and the likes. I believe everyone who supports WebGL hates me that’s why I hate everyone who supports WebGL

  • Anonymous

    “I believe everyone who supports WebGL hates me that’s why I hate everyone who supports WebGL.”
    What a stunningly inane outlook. I just love the logic of “All developers must work on the things that *I* want, and any developer who wants to build games on the web is a developer who would otherwise be working on Crysis 27.” This makes precisely zero sense.

    If you don’t want better games on the web, then just ignore them. But there are those of us who would like to have the technology to create more interesting games than Farmville, that are easily accessible to a wider audience.

  • Stilgar

    I don’t blame the game devs. I blame the “everything should be web” mafia lead by Google. My fear is not that I won’t be able to ignore Farmville (I am doing pretty good job at that right now). My fear is that one day I may need to ignore things in the Quake or StarCraft franchises

  • Anonymous

    There’s a vast difference between “we’d like to be able to do most things on the web” and “everything should be web”. No one’s trying to take your phone, game console, laptop, or desktop away, nor stop anyone from building games for it.

    Would you refer to Nintendo as the “everything should be Wii” mafia? In addition to the “hate” and “mafia” comments, maybe you could throw in a nazi reference for a trifecta? :)

  • greggman

    First of all, crashing your driver != insecure. You are not able to execute code by crashing your driver.

    Second of all, I never claimed you couldn’t DOS your machine with WebGL (which is what your page demonstrates). I claimed that Microsoft is releasing the exact same tech in Sliverlight5 which has the same problem. Click the link in the post and see your machine have the same issue with Silverlight5. They can’t claim they won’t ship something that has this problem on the one and while on the other shipping something that has this problem.

    I’m happy to provide you with examples from Flash 11 and Unity3D as well.

    3rd. I pointed out, except for being annoying, what’s the point of crashing your driver or DOSing your machine from the point of view of someone trying to be malicious? If you go to a site and it crashes your driver you won’t go back to the site. That’s not helpful to someone who wants to be malicious. They want read your files or steal your passwords. WebGL exposes nothing that makes that possible.

    4th, as was pointed out in the article. Windows is currently the only OS that handles this case by resetting the driver. OSX, iOS, Android do not. As I also stated above the Khronos group is working on resolving this issue. They’ve already gotten driver vendors to release extensions to handling this in Linux. At some point Apple will as well.

  • Adam Hoka

    “I claimed that Microsoft is releasing the exact same tech in Sliverlight5 which has the same problem.”

    Unfortunately I get this: The version of Silverlight you have requested is not yet publicly available.
    So we are currently talking about a bug in a beta versions software, it “may” be fixed in the final version. Let’s hope for it and don’t judge an unfinished product. With WebGL we are talking about a _released_ specification, which is already included in actual products. And it is proven to be defective by design. Thats a slight difference…

    “First of all, crashing your driver != insecure. You are not able to execute code by crashing your driver.”

    We heard this crap from OpenBSD, so I don’t want to really comment why is this a big bullshit bingo. 😉

  • greggman

    The problem is we’ve proven that any access to the GPU allows this DOSing feature. It doesn’t matter what Silverlight5, Flash11 or Unity3D do. You need very minimal features for this DOSing to happen. The features they all claim to expose are plenty. If any one of them finds a solution that same solution can be applied to all of them. Hence why Microsoft should be helping to find a solution that’s better than just resetting the driver since they needed it as much as anyone.

  • Jeff Carr

    Isn’t it just that your javascript example is defectively written? So it are tries to make 100000 thingamaggigs (numQuads). Change numQuads to 100 and it doesn’t spin the cpu/crash. What’s so impressive about this? It seems more like: “oh look I can write javascript that will suck CPU/crash”. Who cares.

  • Anonymous

    I think you’ve completely missed the point. Silverlight/DirectX abstract much further from the drivers than OpenGL does and there is even a proof of concept in the Khronos FAQ section that uses WebGL to execute arbitrary code by a buffer overflow on the GPU. And there is a proof of concept that reads graphic rams to reconstruct what websites you’ve visited by exploiting WebGL. Even John Carmack, quite the OpenGL evangelist, has publicaly voiced on his twitter stream that he agrees with Microsoft’s assessment (now that really is quite something). DirectX does more abstraction from the driver than OpenGL and DirectX is in such a way part of the OS that it receives automatic updates, (which MS can’t provide for the OpenGL API/drivers because it’s provided by 3rd party vendors).  

    A lot of people have been screaming ‘OH MS not AGAIN’ or whatever, but MS actually has quite a strong argument here and many industry professionals (like John Carmack) agree. Even Khronos agrees there are security issues, (even before MS’ accusations) but they are trying to downplay it.

  • greggman

    1) There is no proof of concept executing arbitrary code in the Khronos FAQ.
    2) The exploit reading vram was a bug in FireFox, not in WebGL.
    3) WebGL runs on DirectX on Windows
    4) Silverlight 5 does NOT provide more abstraction than WebGL

  • Anonymous

    Silverlight 5 does provide more abstraction that WebGL in the context of when you’re running it in a browser (see my post below). Also, this doesn’t just get pushed out while it’s still experimental. You have to go and explicitly download it. If you want to install it as a desktop app, you have to explicitly do that too and you have to explicitly give the application elevated permissions. You should try it sometime :)

  • Anonymous

    I didn’t realize how much direct access WebGL gave you to the hardware level. This is absolutely a problem. In order to get to this hardware level in Silverlight, you have to run a PInvoke. Silverlight WILL NOT LET YOU USE PINVOKE IN THE BROWSER. In order to do a PInvoke operation in Silverlight and get this level of access, you have to install the application OUT OF BROWSER…essentially, as a desktop application.

  • greggman

    You don’t need to call PINVOKE. This Silverlight5 sample shows all the features needed to do all the things MS claims are supposedly insecure

    It shows creating buffers, creating textures, loading shaders. Those are the only features WebGL exposes. It exposes them at the same level as seen here in Silverlight5.

    There is no call to PINVOKE and there is no more or less abstraction in the 2 APIs.

    VertexShader.fromStream is the same as gl.CompileShader()
    new Texture2D(…) is the same as gl.texImage2d(…)
    new VertexBuffer(…) / vb.SetData is the same as gl.createBuffer(…) / gl.bufferData(…)
    graphicsDevice.DrawPrimitives(…) is the same as gl.drawArrays()

  • Anonymous

    That’s using the High Level Shader language and using pre-compiled hlsl files…I guarantee you PInvoke is used to compile those shaders – In Silverlight 4 you can use HLSL’s – it’s like working with a writeable bitmap. There is a HUGE difference between VertexShader.fromStream (which is reading from a bit stream that uses the basis of a pre-compiled hlsl file and gl.CompileShader() which I’m pretty sure is using a PInvoke behind the scenes) the point is you don’t have access to do something like THAT in Silverlight 5 unless you’re out of the browser (no longer a plug-in but an acctual application) and then you’ve already been notified that you’re giving elevated trust to the application and have agreed to that…. it’s the same as playing a game you installed from a DVD at that point.

  • Asdf

    I already have to turn off cookies, disk caching, password saving, search
    suggestions, Javascript, Flash, Java, Quicktime, and Silverlight to have a sane
    browsing experience.

    Thank you for yet another idiotic thing I will have to go disable by default
    in my browser.

    Maybe some people need to get it through their heads that some of us DON’T WANT a bouncing dancing flashy animated bullshit web that assaults my machine with mobile code, ads, drive-by attacks, spam, and malware every time I just want to read the god damn news.

    I am annoyed that I had to turn on Javascript just to post this comment.

  • James Stone

    Rant or not, IE, whatever number you put at the end of it, puts a huge number of hours on development.

  • Alex

    You are right, and they have the same reasons than Google to make everything running inside a browser and “lock-in” developers with web tech so Google can get money from Ads and other cloud based services. Same reason why Apple try to lock-in developers in their iOS. Google, Microsoft, Apple, same thing. Anyway, I think that web is “less-evil” but still…

  • Guest

    Problems Solved ??  ……or not ?? 
    I know this thread is old but am hoping someone will comment about

  • Seljo Myeri

    sounds like a rant to me, since Silverlight is also cross-platform… I don’t see the lock-in argument.  Now, might grant you MS could be disingenuous about the security concerns, given that Silverlight is similar.

  • Tom

    Yea, microsoft is just telling bullshit.. that why the security problems are taken in consideration in the new WebGL 1.0.1 specification. Even Microsoft was working on that specification. Sorry greggman, but you failed miserably.

  • Shell

    An amount of FUD it could be, but still, even now months later, the OS-crashing WebGL bugs still bring down the entire OS in both Chrome 15 & FireFox 8. I can’t think of any other browser-based scripting that can bring down my entire machine.

  • greggman

    I pointed out that was a problem for WebGL as well as Sliverlight 5 and Flash 11 and asked Microsoft for help.

    The FUD is that Microsoft is dissing WebGL on the one hand and on the other releasing tech with the same issue (Silverlight 5) and also not complaining about Flash 11. It’s that hypocrisy that’s the issue.

  • Joyle

    I think the blog post you link to pretty well proves greggman’s point.  The ‘solution’ to secure Silverlight 5 at this point is to disable 3d by default.  From the linked page:

    By the way, you may experience security errors with Silverlight 5 RTM
    when you want to use the wonderful new 3D feature. In fact, some
    graphics drivers may allow malicious code to execute. That may lead to
    an unwanted hard reset or a blue screen.

  • Hey

    Yes, the solution was to disable 3D (in a way, that regular consumer is not able to turn it on easily, devs are crying about this, google it), so the 3D features definitely become useless on any partial-trust site (which means definitely all internet sites). The single statement of gregman that was valid, is about the inconsistency of Microsoft’s policy. But since MS definitely killed off the 3D feature of SL (on the internet), the policy become consistent.

    We will see if they include WebGL in their new WinJs full-trust client solution.

  • Gabriel

    A title like “WebGL security and my full load of bullshit” would be more suitable.

  • greggman

    Nothing has changed in WebGL and now Microsoft is shipping WebGL in IE11 and has even posted a WebGL game written by them. Guess that proves we were right. It was Microsoft FUD because suddenly they’ve changed their tune.