5 ms·
What a bunch of lies this is. Silverlight has nothing to do with XNA linked by the author. But even if we assume that SL5 uses XNA, XNA does not expose raw buff
by hubriz 15y ago
What a bunch of lies this is. Silverlight has nothing to do with XNA linked by the author. But even if we assume that SL5 uses XNA, XNA does not expose raw buffers in the code the way WebGL does and it does not allow one to write shaders on the mobile devices (one of the attack vectors mentioned in the MS article). SL itself does let you write PS (FS if you're from OGL crowd) and yes, this is an attack vector. But comparing this to WebGL is a false equivalence.
I find it amusing that even John Carmack (strong OGL supporter) agrees with MS on this one yet it is some random Google employee who gets his word spread. This author knows FUD very well, I give him that. He's proficient in spreading it.
- daleharvey 15y ago> Silverlight has nothing to do with XNA linked by the author. But even if we assume that SL5 uses XNA I am not amazingly familiar with windows development, but "The core of the XNA Games Studio 4.0 graphics libraries is now included in Silverlight 5 Beta and is used to create 3D graphics. ", doesnt seem like a large assumption > "John Carmack (strong OGL supporter) agrees with MS on this one yet it is some random Google employee who gets his word spread" I have a feeling the chrome developers have a better idea about how to sandbox a browser than John Carmack does, as awesome as he is, this is just arguing to authority when there is a long list of points that OP made that havent been refuted.
- JonoW 15y ago> I have a feeling the chrome developers have a better idea about how to sandbox a browser than John Carmack does, as awesome as he is In fairness, we have no idea of the extend of the authors expertise, I would bet John Carmack as an insanely intimate knowledge of drivers and their issues.
- daleharvey 15y agoYes to be honest I shouldnt have made that part of my point, none of us apart from the author and John Carmack know how they familiar they are with the issues involved in sandboxing browsers and driver reliability, and even then they could both be wrong. We should just discuss the points made, not who is making them.
- talmand 15y agoWho is making the comments you wish to discuss does have a great deal to do with it. I know nothing of OpenGL technologies so I would assume you wouldn't hold my opinion as high as Carmack's or Google employees. Also, I've followed Carmack's exploits for something like twenty years. In my humble opinion, when he speaks of anything OpenGL I would suggest you listen to what he has to say.
- daleharvey 15y agoI imagine there are thousands of people who are deeply familiar with openGL whose names you have never heard of. If you dont understand a subject enough to be able to debate on the points that are being made rather than who is making them you should not be debating it I just dont think its good practice to disregard someones opinion just because someone you have heard of disagrees with them
- hubriz 15y ago> doesnt seem like a large assumption It is for the reason I've mentioned before: XNA abstracts out pretty much everything. With XNA you're not programming to the metal anymore, which is unfortunately true with WebGL. The greatest concern seems to be with the way OGL handles various buffers. For example in WebGL it is possible to create bufferData stating that it's of size X and provide Y values with Y much smaller than X. What you get is a buffer full of stale data from the memory. Bad idea. Also there's much less "stuff" you can break in XNA with lower profile levels (feature sets) which are suitable for the web. E.g. you can't write shaders for the mobile devices today for both security and perf reasons. You get a preset amount of them and that's it. Yes, it's limiting, but you can't choke GPU to death and you can't submit shader payload that's known to crash given driver. It's all about false equivalence that author makes in his blog entry. Problems exist with pretty much every piece of advanced software. But you can add small attack vector, or a large one. They are not equal and making it seem otherwise is bogus. JS is amazing and I love 2D canvas. But WebGL is trying to put low-level stuff in the high-level code. It's awesome in terms of performance, but is inherently fragile and may be abused easily. It seems that it's not sensible programmers MS is afraid of but malicious attackers. And it's very unlikely that WebGL won't be happily abused. As for Carmack, he stated at various occasions that he's closely following web graphics. He's also more than knowledgeable about the issues with drivers, how they can be hit even accidentally and how (un)likely it is for hardware vendor to fix them timely. Also aside from the security, drawing from my experience, it is extremely difficult to make semi-advanced graphics code perform well and look acceptably similar on different GPUs. This is something APIs exposed in the high-level languages (which JS I think undeniably is) should hide from the developer, not dump on him. The fact that there are two different 3D canvas contexts - webgl and experimental-webgl - doesn't really help.
- magicalist 15y ago> The greatest concern seems to be with the way OGL handles various buffers. For example in WebGL it is possible to create bufferData stating that it's of size X and provide Y values with Y much smaller than X. What you get is a buffer full of stale data from the memory. Bad idea. Please at least check these things before asserting them. Assuming good will, I can see how it might be easy to assume that some things that are true in desktop opengl will be true in webgl, but both the linked blog post and the webgl spec explicitly state that all buffers are initialized upon creation, and all access calls are bounds checked. Tests of this are also part of the webgl conformance suite. If you want to see where it is specified, see here: http://www.khronos.org/registry/webgl/specs/latest/#4.1 http://www.khronos.org/registry/webgl/specs/latest/#4.1
- bonch 15y ago> I have a feeling the chrome developers have a better idea about how to sandbox a browser than John Carmack does, as awesome as he is, this is just arguing to authority when there is a long list of points that OP made that havent been refuted. Carmack is probably more familiar with hardware drivers and 3D APIs than anyone working on Chrome. Plenty of the points made have been refuted in the discussion here.
- nkassis 15y agoWell to be fair Gregg Tavares works directly on the issue since he is part of the team implementing WebGL in chrome. He might not have Carmack's insane amount of knowledge about the subject but I wouldn't discount Tavares' views completely here.