IE11 to support WebGL(microsoft-news.com)
microsoft-news.com
IE11 to support WebGL
http://microsoft-news.com/webgl-spdy3-new-dev-tools-more-confirmed-for-ie11-in-win-8-1/
135 comments
And IE11 will support Windows 7, right?
They need to support these newer browsers on older operating systems. If the OS is still being actively patched, new browsers should be made backwards compatible to work on it otherwise we'll have exact same problem with IE8 on XP and IE9 on Vista. And soon to be IE10 on Windows 7.
They haven't said one way or the other at this point -- and have stated that they won't any time soon.
Yes. IE11 will be on Windows 7: http://www.engadget.com/2013/06/26/microsoft-internet-explor...
my long term dream is to see microsoft finally giving up on using their own rendering engine and move to either mozilla or webkit. both of them are following the standards pretty neatly so it would make dev's life far easier.
with each major release IE promises being better. which is true for an extent but they also introduce new bugs so our css / html has different hacks for each version
with each major release IE promises being better. which is true for an extent but they also introduce new bugs so our css / html has different hacks for each version
He's a fat boy. Walks really slow :) I expected WebDirectX!
This is great news for game development of the web. WebGL will become the standard for 3D browser games.
Credit to Microsoft for reversing their previous stance on WebGL.
Credit to Mozilla for pushing 3d on the web and forcing the issue. Any browser that doesn't implement WebGL will soon be considered crippled; Microsoft desperately wants to avoid that title again, so in a way, Mozilla forced their hand.
Competition at work.
Credit to Mozilla for pushing 3d on the web and forcing the issue. Any browser that doesn't implement WebGL will soon be considered crippled; Microsoft desperately wants to avoid that title again, so in a way, Mozilla forced their hand.
Competition at work.
memorable quote from http://john.jubjubs.net/2011/09/15/mike-shaver-thanks/
"And [Mozilla's Mike Shaver] affected my framing of the problem deeply – I remember one day a couple of years back when we were talking about some market share point, thinking about how incredibly, insanely competitive the browser technology landscape was – and he said to me: “Look, this is the world we wanted. And this is the world we made.” Wow. Exactly right. He taught me so much about how enormous an impact a group of dedicated people can make."
"And [Mozilla's Mike Shaver] affected my framing of the problem deeply – I remember one day a couple of years back when we were talking about some market share point, thinking about how incredibly, insanely competitive the browser technology landscape was – and he said to me: “Look, this is the world we wanted. And this is the world we made.” Wow. Exactly right. He taught me so much about how enormous an impact a group of dedicated people can make."
Thanks for the link.
I've bumped into Mike a few times at Facebook; he's one of the most knowledgeable people I've ever met.
I've bumped into Mike a few times at Facebook; he's one of the most knowledgeable people I've ever met.
"Any browser that doesn't implement WebGL will soon be considered crippled"
Really? I don't think WebGL is that important. What's it really good for besides laggy browser games? What's with the hype on browser games anyway? They're always going to perform much slower than native code. I don't see WebGL becoming such a critical aspect of browsing that the average user would consider IE "crippled" for not supporting it.
Really? I don't think WebGL is that important. What's it really good for besides laggy browser games? What's with the hype on browser games anyway? They're always going to perform much slower than native code. I don't see WebGL becoming such a critical aspect of browsing that the average user would consider IE "crippled" for not supporting it.
Your challenge, should you choose to accept it, is to dream up an amazing and popular application of WebGL, now that a majority of web browsers will be supporting it. It might not be a game. Warning: imagination required.
It's hard to dream big about the browsers getting the modern iteration of something we've had in some form since 1992.
How does that not apply to every single thing on the web, whether text, image, animation, video, or interaction?
You are assuming that a delivery mechanism can't be transformative.
ASM is only 2x slower than native (it was 10x prior to) and will be 1.5 soon. With a way better distribution model. Have you seen UE3 or UE4 demos?
>ASM is only 2x slower than native
Only in wilfully misleading benchmarks. Allow use of SIMD and multithreading and asm.js can be as much as 50 times slower:
http://cdn.arstechnica.net/wp-content/uploads/2013/05/native...
http://cdn.arstechnica.net/wp-content/uploads/2013/05/classi...
Only in wilfully misleading benchmarks. Allow use of SIMD and multithreading and asm.js can be as much as 50 times slower:
http://cdn.arstechnica.net/wp-content/uploads/2013/05/native...
http://cdn.arstechnica.net/wp-content/uploads/2013/05/classi...
Good point: re multithreading. I wonder if web workers could be used to resolve that?
Here's one application: http://youtu.be/zB7QEFCR1Zk?t=16m59s
It will soon be used for numerous business apps as companies are porting their native applications to work on browsers.
I just hope the desktop versions don't go away.
I am surprised they didnt try to push a webdx based off directx.
They did, sort of[1], it didn't appear to fly.
[1] http://lists.w3.org/Archives/Public/public-fx/2012JulSep/007...
[1] http://lists.w3.org/Archives/Public/public-fx/2012JulSep/007...
I dunno... Allowing the language to be selected like a video codec or image file format seems like a reasonable request.
There are three issues:
1) Language pluggable?
2) Spec-ed shader languages
3) Mandatory languages
The proposal was:
1) No
2 & 3) GL SL ES
Microsoft proposed:
1) Yes
2) GL SL ES
3) None
The perfectly reasonable compromise would have been:
1) Yes
2 & 3) GL SL ES
There are three issues:
1) Language pluggable?
2) Spec-ed shader languages
3) Mandatory languages
The proposal was:
1) No
2 & 3) GL SL ES
Microsoft proposed:
1) Yes
2) GL SL ES
3) None
The perfectly reasonable compromise would have been:
1) Yes
2 & 3) GL SL ES
It may sound reasonable, but ultimately is against the universal spirit of the web, and thus should not be standardized. Your #1 should be No, because if it were Yes, we'd have a mess of mutually incompatible, vendor-specific, proprietary languages fragmenting 3D content on the web.
Mutually incompatible, vendor-specific, proprietary anything is an inevitability. #1 isn't about that. That's what #2 and #3 are about.
#1 is about planning for extensibility. Just look at the hackery with JS where lonely, otherwise ignored, strings are used for things like "use strict" and "use asm". Or where Microsoft added "conditional comments", which quite frankly, was essential to the development of Outlook Web Access, which basically gave us Ajax. Or all the absurd vendor prefixes on CSS tag names. Or one of 100 other little hacks that browser vendors have invented to try to innovate past the standard. Pushing pass the standard, by the way, is the only way forward. We've learned that lesson by now, so we should plan for extensibility.
#1 is about planning for extensibility. Just look at the hackery with JS where lonely, otherwise ignored, strings are used for things like "use strict" and "use asm". Or where Microsoft added "conditional comments", which quite frankly, was essential to the development of Outlook Web Access, which basically gave us Ajax. Or all the absurd vendor prefixes on CSS tag names. Or one of 100 other little hacks that browser vendors have invented to try to innovate past the standard. Pushing pass the standard, by the way, is the only way forward. We've learned that lesson by now, so we should plan for extensibility.
OpenGL already has a mechanism for extensibility, and proprietary junk is only an inevitability if we allow it to be enshrined in open standards. There is no reason to accept proprietary DRM plugins in CDM, and there is no reason to accept proprietary shader languages.
The reasons are manifold, but here are a few:
- Standardizing non-standardness gives proprietary implementations an unwarranted air of legitimacy and blesses incompatibility.
- Proprietary plugins and extensions are more likely to have untested security vulnerabilities and widen the browser attack surface.
- Proprietary extensions violate the essential web principles of cross-platform compatibility, graceful degradation, progressive enhancement, and accessibility.
The reasons are manifold, but here are a few:
- Standardizing non-standardness gives proprietary implementations an unwarranted air of legitimacy and blesses incompatibility.
- Proprietary plugins and extensions are more likely to have untested security vulnerabilities and widen the browser attack surface.
- Proprietary extensions violate the essential web principles of cross-platform compatibility, graceful degradation, progressive enhancement, and accessibility.
Hopefully MS collaborates with other browser vendors in accommodating asm.js-optimized code, too.
Now let's see when mobile browsers start to support it. Probably 3 years from now for any meaningful support.
> Credit to Microsoft for reversing their previous stance on WebGL.
One cant believe anything MS says. And it's another proof of that.
Remember when WebGL wasnt "secure"? Strange , now it is.
I say bull* , like their bull Venture Capital sh*t.
But I guess they have enough spare change to do community management on HN ( ie propaganda ), looking at all the MS spin here.
One cant believe anything MS says. And it's another proof of that.
Remember when WebGL wasnt "secure"? Strange , now it is.
I say bull* , like their bull Venture Capital sh*t.
But I guess they have enough spare change to do community management on HN ( ie propaganda ), looking at all the MS spin here.
Hey I slated their VC stuff (see my threads), but this is good news.
I wouldn't tar the entire organisation with the same brush.
There is hope yet!
I wouldn't tar the entire organisation with the same brush.
There is hope yet!
now, where do they stand on WebRTC?
They waited until WebRTC was about to be ratified and then released their own incompatible spec.
They do that for everything. Ponderous silence then last minute derailing BS. Independent of the pros and cons of any particular single technology they should be called out for what a poor corporate citizen this makes them, and how it is anti-standards and anti-consumer.
And yet they're supporting SPDY instead of their own S+M proposal.
This is potentially great news for anyone using a browser. Let's hope that the implementation is close to spec, and makes for a relatively seamless experience across all browsers.
> Let's hope that the implementation is close to spec
I got so excited for a moment and then you had to go and post this. Microsoft seems to have a desire to make things difficult for web developers.
I got so excited for a moment and then you had to go and post this. Microsoft seems to have a desire to make things difficult for web developers.
Considering they way it went down [1], Microsoft felt (and may still feel) that the web is an enterprise market. In so, that it was selling developer tools to web shops because the code goes through Microsoft servers to Microsoft clients. IE, a vertical integration to simplify HR decisions. [2]
That ideology carries through to the spec—enterprise products often contain janky features that mean little to developers, but the world to the bosses buying them.
Thankfully Android and iOS are a driving force showing that the web is more a consumer broadcast space than one built simply for the spec that best matches someone's tech opinions.
1. http://www.techdirt.com/articles/20120507/12295718818/
2. Paraphrasing, but I've personally turned down jobs that were in this vein, specifically writing IE HTML in Visual Studio, because if their browser share is 80% IE, they might as well use the IDE from the company that makes the browser.
That ideology carries through to the spec—enterprise products often contain janky features that mean little to developers, but the world to the bosses buying them.
Thankfully Android and iOS are a driving force showing that the web is more a consumer broadcast space than one built simply for the spec that best matches someone's tech opinions.
1. http://www.techdirt.com/articles/20120507/12295718818/
2. Paraphrasing, but I've personally turned down jobs that were in this vein, specifically writing IE HTML in Visual Studio, because if their browser share is 80% IE, they might as well use the IDE from the company that makes the browser.
Is it common practice to force particular IDE to developers? Especially for web developers. I imagine my productivity would decrease quite dramatically for some time.
Only the most insane of companies explicitly require the use of a specific editor, but it's easy for the choices of technology to implicitly limit developers to a single IDE. If your project's build system assumes that everyone is using Visual Studio (or Eclipse, or whatever), then using something else is going to either require a lot of switching between them or a lot of extra work on your part.
The other big takeway is that they added support for SPDY3!
Wow. IE11 looks like it has some really great stuff in it, particularly the dev tools, even over the WebGL. Props to the IE team!
This is huge!
Love the improved dev tools and WebGL decision, but I also hate how long it's taken MS to reach this point.
Would also love for IE 11 to be available on Windows 7.
Would also love for IE 11 to be available on Windows 7.
Have they said it won't be on Windows 7? I would expect them to release it on Win7 to try and keep their market share. I hope they do as I am building a WebGL application for work :)
They haven't confirmed either way, which is why I'm still hoping it'll land in Win7:
http://www.ubergizmo.com/2013/06/internet-explorer-11-ie11-m...
"We aren't sharing anything around which versions of Windows IE11 will be available on at this time."
http://www.ubergizmo.com/2013/06/internet-explorer-11-ie11-m...
"We aren't sharing anything around which versions of Windows IE11 will be available on at this time."
So far it's at least safe to assume MS support current and previous releases. As this is a feature pack to w8 and not w9 I should be ok so assume ie11 will see w7.
But who knows, MS seem to think ie is some carrot to lure people to them. It could as such be crippled to w8.
But who knows, MS seem to think ie is some carrot to lure people to them. It could as such be crippled to w8.
I love the look of the new development tools, lightyears ahead of IE10. Lets see how it matches up to Chrome
Is it just me, or are that others that think "Didn't it support that yet?!" at every IE release? I don't use Windows so I never use IE anymore, but I'd think IE9 or 10 would support WebGL by now...
WebGL was bleeding-edge when IE 9 was released, and there were still very valid concerns about its security for a while after that. Opera implemented it, but disabled it due to these concerns. After their nightmarish history with security, Microsoft are very focused on hardening Windows — so I wouldn't exactly call it regressive to leave WebGL out of IE 10, which was probably feature-frozen in early 2012.
It is fair to say that there were some security concerns, but those have been addressed, and actually Microsoft - which controls the OS and the browser, and is heavily involved in driver quality - is in an excellent position to create a safe implementation of WebGL.
It's fine that it took them time and they wanted to do it properly. It is however annoying that they did not give any forward notice of their intention to implement WebGL and have not been active in the standards bodies at all. For example, Microsoft input on the safety aspects could have been very useful.
It's fine that it took them time and they wanted to do it properly. It is however annoying that they did not give any forward notice of their intention to implement WebGL and have not been active in the standards bodies at all. For example, Microsoft input on the safety aspects could have been very useful.
Opera didn't disable it due to security concerns per se — rather more just the general bugginess of Opera's hardware acceleration. I wouldn't consider crash bugs in general security issues. Equally, there is software rendered mode, but it's pointlessly slow to enable.
Note the prior concerns are still just as true today as they were a few years ago — graphics drivers are still relatively easy to find crash bugs in, leading browser vendors to try and hack around and avoid hitting those bugs in all too many cases. :(
Note the prior concerns are still just as true today as they were a few years ago — graphics drivers are still relatively easy to find crash bugs in, leading browser vendors to try and hack around and avoid hitting those bugs in all too many cases. :(
> I wouldn't consider crash bugs in general security issues
You should, until proven otherwise. If it crashes because it's reading an invalid memory location (for instance), it's a matter of time before someone figures out how to place executable code there.
I have no problem with MS's original position. WebGL forces your hardware drivers to run random code downloaded from the internet. I'm frankly surprised that the other browser vendors ran ahead with it so quickly and that we haven't heard about any exploits caused by it.
You should, until proven otherwise. If it crashes because it's reading an invalid memory location (for instance), it's a matter of time before someone figures out how to place executable code there.
I have no problem with MS's original position. WebGL forces your hardware drivers to run random code downloaded from the internet. I'm frankly surprised that the other browser vendors ran ahead with it so quickly and that we haven't heard about any exploits caused by it.
On that matter, it is not difficult for someone who knows how to use WinDbg or similar to see if a crash is exploitable. For example, in user mode, null pointer accesses are generally not exploitable. I personally was able to get an IE6/IE7 bug described in http://www.satzansatz.de/cssd/pseudocss.html#fltadjacent fixed in the May 2013 security update by proving there is an exploitable crash.
Most crashes as shipped are just the shader over running maximum time and it being killed, AIUI, rather than actual segmentation faults or attempts to read garbage. Most actual known issues that are potentially security concerns are worked around through preprocessing what the driver gets, and given the level of testing I don't worry about it more than any other OS component security wise. The biggest risk would probably be a new driver release shipping with bug leading to exploitable code being executed.
Also, if I'm not mistaken Chrome shipped first: and they'd done masses of fuzzing of both their code and the drivers. Nobody really rushed into it, everyone keeping it off by default for an unusually long time to catch issues before shipping.
Also, if I'm not mistaken Chrome shipped first: and they'd done masses of fuzzing of both their code and the drivers. Nobody really rushed into it, everyone keeping it off by default for an unusually long time to catch issues before shipping.
Additionally, Microsoft was on record saying they believed plugins like Silverlight provided sufficient 3d capabilities, and that WebGL was huge surface area for security vulnerabilities.
They've apparently reversed that stance.
They've apparently reversed that stance.
Since Windows 8, MS has reversed it's stance on Silverlight and browser plugins in general.
I don't disagree with Microsoft's point in this article. http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-cons...
I assume that they've decided to work towards solving the security issues instead of simply staying away from the issue.
Long term I hope this means more stable and reliable video drivers :)
I don't disagree with Microsoft's point in this article. http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-cons...
I assume that they've decided to work towards solving the security issues instead of simply staying away from the issue.
Long term I hope this means more stable and reliable video drivers :)
IE 9 was released only 11 days after WebGL was standardized.
So? It didn't prevent other browsers for having a mostly working implementation that they could improve upon with time.
And they supported those mostly working implementations for about 6 weeks. Microsoft supports their releases for years.
Is that even true now that IE11 keeps itself auto-updated to the latest major version?
Love the new changes in IE and the direction it is taking.
>IE11 allow you to turn off the SmartScreen filter right in the download UI.
Now only if chrome would do that I can keep myself from switching away from it. Its frustrating to know that everytime I download a file or save an image, the file hash, IP and the download URL is sent to Google. The whole NSA thing isn't making it better either. [1][2]
[1] http://superuser.com/questions/387724/how-to-disable-downloa... [2] http://blog.chromium.org/2012/01/all-about-safe-browsing.htm...
>IE11 allow you to turn off the SmartScreen filter right in the download UI.
Now only if chrome would do that I can keep myself from switching away from it. Its frustrating to know that everytime I download a file or save an image, the file hash, IP and the download URL is sent to Google. The whole NSA thing isn't making it better either. [1][2]
[1] http://superuser.com/questions/387724/how-to-disable-downloa... [2] http://blog.chromium.org/2012/01/all-about-safe-browsing.htm...
You can turn off the "Safe Browsing" features in Chromium; your link [2] explicitly says how to do so.
I know but that also turns off the malware links protection. I don't mind the malware site/link protection since it only sends in a small part of the URL's hash for matching (similar to how we have in Firefox). Comparatively, the file scanner requires the whole hash of the file, the clear text of the download URL and the IP address which I find far more intrusive to privacy. I am hoping for a future update where they would let us enable/disable them individually.
> only sends in a small part of the URL's hash for matching ...
Isn't it incredibly easy to bypass that check by using a randomly generated url segment?
[Edit: Formatting + isn't]
Isn't it incredibly easy to bypass that check by using a randomly generated url segment?
[Edit: Formatting + isn't]
No, its more like this. You download a series of truncated hashes; you generate a bunch of permutations of your URL (strip the query params, strip components of the path/domain), you hash those, check them against your local list. If you get any matches, you request an expanded list from Google, giving them the truncated hashes that matched. This gives you a cacheable list of full hashes; you check your matched hashes against those full hashes, and if any match, then its a match.
tl;dr No, its not that easy.
tl;dr No, its not that easy.
I have used the Safe Browsing API for one of my projects and if I remember correctly, you are supposed to sent hash of the root domain along with the hash of the URL. Assuming it works similarly for browsers, once the root domain is blacklisted randomly generated URLs won't be able to get through.
Right, so next time we download something private from a different party, we'll ask them to change their file structure to suit our privacy needs. :)
I am not questioning that sending entire URLs is undesirable, I am asking if the hash solution works (at all).
Usually I groan when people complain about the Malware features in Chrome in relation to privacy but this is definitely one I'd not heard of. The hash of the whole file is bad enough, but even if it were unique, the full URL could easily contain sensitive information or information about the file contents.
why wouldn't it be a hash of the download URL only?
Perhaps they are worried about the same url being used to serve multiple files. Eg: example.php/download/invoice.pdf might be customer / order specific.
Right, I can see why the hash of the file would be important, but I can't see why they would include the plain text URL instead of a hash.
It would be interesting to have a hash of a file that could identify embedded data but exclude private data. For instance, for a Microsoft Office file it would include hashes of embedded binary assets but exclude the text of the document.
It would be interesting to have a hash of a file that could identify embedded data but exclude private data. For instance, for a Microsoft Office file it would include hashes of embedded binary assets but exclude the text of the document.
No idea, I'm taking the GP at their word, their phrasing made me think that they work in the browser space and know that as a fact.
I can't say I've inspected Chrome specifically in Wireshark, nor looked at the code, so I will refrain from making any claims; I simply don't know.
I can't say I've inspected Chrome specifically in Wireshark, nor looked at the code, so I will refrain from making any claims; I simply don't know.
the dev tools look promising. But I do not understand what are they are trying to achieve by this. I do not see myself, or many people, switching to IE for development when there are no extensions available. I at least want some REST client like Postman. Now It appears they are only catching up on Chrome and Firebug, that will hardly convince anybody.
Do not get me wrong, they are doing good work making IE modern browser, But they can't do it alone, especially with such long release cycle. Maybe making dev branch like Canary or Aurora?
Do not get me wrong, they are doing good work making IE modern browser, But they can't do it alone, especially with such long release cycle. Maybe making dev branch like Canary or Aurora?
> But I do not understand what are they are trying to achieve by this. I do not see myself, or many people, switching to IE for development
Perhaps there are others who have to support IE as a target and would like to debug/verify front ends in-browser?
Perhaps there are others who have to support IE as a target and would like to debug/verify front ends in-browser?
Thank goodness that "Text - Empty Text Node" has been removed from the DOM explorer!
The new developer tools, especially that UI responsiveness report [1] are hot looking. Looking forward to giving that a spin.
[1] http://microsoft-news.com/wp-content/uploads/2013/06/UI-Resp...
The new developer tools, especially that UI responsiveness report [1] are hot looking. Looking forward to giving that a spin.
[1] http://microsoft-news.com/wp-content/uploads/2013/06/UI-Resp...
If you build it, they will eventually be dragged, kicking and screaming to it.
Now we just need Apple to make it available in Safari, without having to explicitly turn it on.
Oh, and enable it in iOS Safari too - which I rather suspect they wnt any time soon unfortunately.
Oh, and enable it in iOS Safari too - which I rather suspect they wnt any time soon unfortunately.
This is great news1 I'll be able to use WebGL with the majority of my users who use IE in what, 5-6 years?
Awesome news! And the Xbox One is already available in 3D display with WebGL! https://sketchfab.com/show/qsRPEw7hTKC4E02XMop9DUpu2wb
better late than never i guess.
What engineering did they do to reduce the security risk? As much as I like WebGL as a dev, Microsoft's arguments against feeding arbitrary machine code to buggy graphics cards that have kernel-level memory access privileges... seemed a bit convincing.
Just want to reply to say I also would like to hear an answer to this question. Something I've wanted to do for a while is write a fuzzer [1] that puts together arbitrary garbage shader script code and runs it with weird webgl operations looking for exploitable crashes. I would expect there to be a ton of bugs found, but then again the monetary barrier to entry might be high considering differences between hardware.
It also looks like the good folks at Mozilla have already been doing this to some degree [2], presumably shrinking the untested threat surface considerably (man I love those guys).
[1] http://en.wikipedia.org/wiki/Fuzz_testing
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=665936
It also looks like the good folks at Mozilla have already been doing this to some degree [2], presumably shrinking the untested threat surface considerably (man I love those guys).
[1] http://en.wikipedia.org/wiki/Fuzz_testing
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=665936
Here's a WebGL fuzzer from Mozilla bug 614678:
https://bug614678.bugzilla.mozilla.org/attachment.cgi?id=493...
https://bug614678.bugzilla.mozilla.org/attachment.cgi?id=493...
> Just want to reply to say I also would like to hear an answer to this question.
The question is that they do what a business is required to do: let the market decide. Shockingly, the market does not want actual security; it wants lip service to make people feel safe and it wants shiny features.
The question is that they do what a business is required to do: let the market decide. Shockingly, the market does not want actual security; it wants lip service to make people feel safe and it wants shiny features.
This is happening and Google & Mozilla have both been dealing out bug bounties for vulnerabilities found this way.
You can search for them in eg chrome bug db: https://encrypted.google.com/search?hl=en&q=site%3Acode.goog...
(this shows just the subset they've remembered to make public, some time after fixes were shipping in stable)
You can search for them in eg chrome bug db: https://encrypted.google.com/search?hl=en&q=site%3Acode.goog...
(this shows just the subset they've remembered to make public, some time after fixes were shipping in stable)
It would be an interesting project. You should go ahead and test the current implementations! Actually, would you even need webgl to hunt for GLSL exploits?
I don't know anything about what Microsoft has done in particular. But I can tell you what other WebGL implementations do, for example: rewrite shaders to ensure their memory accesses are safe, not accept as valid shaders code that is dangerous (but would be valid GLSL in general), validate input to the graphics card (e.g., buffers are bound, avoids depending on the GL driver to check that), do fuzz testing, maintain blacklists of known buggy drivers, etc. etc.
I would guess Microsoft is doing much the same, but it does have the extra advantage of only caring about one OS and also owning that OS.
I would guess Microsoft is doing much the same, but it does have the extra advantage of only caring about one OS and also owning that OS.
You know, the drivers could have just gotten better over time. Remember when Vista came out, they moved to a new driver model, and there were lots of bugs...people were worried about untrusted shader code bringing down machines (not quite security vulnerability, but definitely a DOS!).
These days, the driver model is more mature, drivers that consumers have are a bit more robust, they probably re-evaluated their worries, which I think is great! Dynamism and flexibility is good in big.corp.
Disclaimer: Microsoft employee, but speaking for myself.
These days, the driver model is more mature, drivers that consumers have are a bit more robust, they probably re-evaluated their worries, which I think is great! Dynamism and flexibility is good in big.corp.
Disclaimer: Microsoft employee, but speaking for myself.
It was just an excuse. The real reason is they didn't want to support anything OpenGL-based.
I agree that the threat is present, but rather than restrict freedom it is better to place decisions in the user's hands sometimes. There are security threats everywhere, even beyond the software or hardware level (i.e. phishing for passwords). I think that rather than not implement WebGL, it would be better to ask permission if the user trusts the domain (just as Chrome does with any plugin).
Who cares.
Typical way: Download game -> Confirm execution -> Play
WebGL way: Confirm execution -> Play
Typical way: Download game -> Confirm execution -> Play
WebGL way: Confirm execution -> Play
> Microsoft's arguments against feeding arbitrary machine code to buggy graphics cards
That would indeed be a bad idea. This is not how WebGL works. There's a translation layer that gets the WebGL calls and relays them to the graphics drivers after determining the calls are safe.
This layer can have bugs of course, like other sandboxes (javascript, flash, etc).
That would indeed be a bad idea. This is not how WebGL works. There's a translation layer that gets the WebGL calls and relays them to the graphics drivers after determining the calls are safe.
This layer can have bugs of course, like other sandboxes (javascript, flash, etc).
Shader validation in ANGLE and black-listed drivers are how this is protected against in Chrome and Firefox. Microsoft was never really clear what the security issues were- really felt like a bunch of FUD.
The security claims were bullshit. For details see:
http://games.greggman.com/game/webgl-security-and-microsoft-...
tl;dr: While it was talking up the security risk of WebGL, Microsoft was allowing Silverlight to permit untrusted code to access graphics APIs in exactly the same way. Chrome validates everything before calling the actual driver APIs, so the opportunities for fuzzing are limited.
http://games.greggman.com/game/webgl-security-and-microsoft-...
tl;dr: While it was talking up the security risk of WebGL, Microsoft was allowing Silverlight to permit untrusted code to access graphics APIs in exactly the same way. Chrome validates everything before calling the actual driver APIs, so the opportunities for fuzzing are limited.
> Chrome validates everything before calling the actual driver APIs, so the opportunities for fuzzing are limited.
Well I guess that's the end of the story then. Google says it's secure so there can't possibly be any bugs or risks or anything worth caring about.
Everyone: put down your work. It's OK now. Google says so.
Well I guess that's the end of the story then. Google says it's secure so there can't possibly be any bugs or risks or anything worth caring about.
Everyone: put down your work. It's OK now. Google says so.
But in SL you had to specifically and manually whitelist the website to allow access to the graphics api.
If it's a user-accessible WL, that doesn't actually add much security of course, because it's pretty simple to get users to add to the whitelist ("To play our awesome game online, open up the preferences dialogue and ...").
>open up the preferences dialogue and
Ultimately though, that is the difference between a drive by infection and user interaction required. In the same way people on the whole now are too savy to download the super-awesome-screensaver or whatever, plenty are smart enough to not say yes to some prompt.
The security model of Silverlight dare is say, is superior to that of WebGL. The guys blog post doesn't actually help the issue of "Is WebGL a worrying attack vector?" instead it starts a seperate concern about Silverlight.
Ultimately though, that is the difference between a drive by infection and user interaction required. In the same way people on the whole now are too savy to download the super-awesome-screensaver or whatever, plenty are smart enough to not say yes to some prompt.
The security model of Silverlight dare is say, is superior to that of WebGL. The guys blog post doesn't actually help the issue of "Is WebGL a worrying attack vector?" instead it starts a seperate concern about Silverlight.
If we learned anything from ActiveX, it's that "click to continue" is an ineffective defense against malware on the web-- at least for most people.
I don't think it's 100% impossible that there will be a WebGL exploit against some driver or other at some point, but I think the odds have been greatly exaggerated by Microsoft and others. The reality of modern graphics cards is that most of the action happens on the card, not on the host CPU. Combine that with Intel's recent IOMMU technology and you find that exploits usually aren't that interesting. Even if you can get control of the card, you can't do much with it.
Of course, there could be a flaw in the host driver, but it would have to be a really unusual flaw. WebGL itself stops almost all invalid input (and some unsupported valid input) from being sent to the driver, so you'd have to find a perfectly reasonable set of polygons that still triggered an exploit. It would be similar to finding an mp3 that, when played, hacked your sound card driver. It's not impossible, but it's getting into tinfoil hat territory.
I don't think it's 100% impossible that there will be a WebGL exploit against some driver or other at some point, but I think the odds have been greatly exaggerated by Microsoft and others. The reality of modern graphics cards is that most of the action happens on the card, not on the host CPU. Combine that with Intel's recent IOMMU technology and you find that exploits usually aren't that interesting. Even if you can get control of the card, you can't do much with it.
Of course, there could be a flaw in the host driver, but it would have to be a really unusual flaw. WebGL itself stops almost all invalid input (and some unsupported valid input) from being sent to the driver, so you'd have to find a perfectly reasonable set of polygons that still triggered an exploit. It would be similar to finding an mp3 that, when played, hacked your sound card driver. It's not impossible, but it's getting into tinfoil hat territory.
Well there is the case where you were redirected to a page you are not interested in (like popups). If confirmation is required, users will mostly close them without being exposed.
It would be still useful to ask users before enabling WebGL on a site the first time. I would certainly think twice before enabling webgl if a site doesn't seem to need it. It could work like flash content with flashblock extention.
Don't forget they were already supporting the same things in Java and Flash.
I really hope IE11 will integrate WebRTC.
I have to give credit to IE10 though...a cool feature that I have only seen in safari (through quicktime), is IE10 allows multi audio track support for html5 mp4...great for multi-language videos, and adapting a single video to play on multiple devices (like some that don't support 5.1 audio).
I have to give credit to IE10 though...a cool feature that I have only seen in safari (through quicktime), is IE10 allows multi audio track support for html5 mp4...great for multi-language videos, and adapting a single video to play on multiple devices (like some that don't support 5.1 audio).
It would be extremely useful for getting Skype in Outlook.com.
Seriously who's using IE nowadays?
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted...
Shaming link 1: http://arstechnica.com/information-technology/2011/06/micros...
Shaming link 2: http://www.extremetech.com/computing/87696-webgl-is-fundamen...
Shaming link 2: http://www.extremetech.com/computing/87696-webgl-is-fundamen...
What are we supposed to take away from those links? The latter isn't even written from the perspective of Microsoft, it's just another generic {Open/Web}GL rant (if anything, you've granted MS legitimacy here by acknowledging other legitimate complaints about the spec).
Yes, I was annoyed when they boldly claimed they wouldn't be supporting it at all. I'm also gracious enough to say "Thanks" when handed a gift. The IE team is clearly making an effort.
Yes, I was annoyed when they boldly claimed they wouldn't be supporting it at all. I'm also gracious enough to say "Thanks" when handed a gift. The IE team is clearly making an effort.
My takeaway is simple, just exposing the BS from Microsoft's original stance wrt OpenGL. One thing is saying "WebGL is right now hard to secure because current OpenGL drivers are buggy, or IE's sandboxing tech is not good enough, whatever". A different thing is, "WebGL is fundamentally flawed, will never work, IE will not and should not support it ever".
Of course the same people are already changing the discourse and claiming that _now_ WebGL is safe, and IE11's WebGL will have the upper hand in security because MS controls the whole stack, etc.
This doesn't mean I don't appreciate the change, I'm really happy that IE11 is apparently going to be an awesome improvement (over IE10 which is already pretty good, even if dated).
Of course the same people are already changing the discourse and claiming that _now_ WebGL is safe, and IE11's WebGL will have the upper hand in security because MS controls the whole stack, etc.
This doesn't mean I don't appreciate the change, I'm really happy that IE11 is apparently going to be an awesome improvement (over IE10 which is already pretty good, even if dated).
I, for one, welcome our new WebGL overlords. Seriously though, it's good to see Microsoft reversed their stance on WebGL no doubt their hand was forced by Mozilla and Webkit (probably Mozilla more so). And SPDY support as well? Looks like IE11 might actually be a decent contender in the browser race. The future of web development doesn't look so bad after all.
Typical stubborn child.
It's going to "support" WebGL.
Now that's good news.
I feel this whole "but IE won't ever support it!" argument was seriously holding WebGL back. IE still has very significant market share, and since they arguably got their act together lately, I doubt it's going to get smaller in the short term.
Considering that existing C++/OpenGL code bases can be ported to the web relatively easy with Emscripten, my bet is that we'll see a bunch of games come to the browser over the next ~3 years.
I feel this whole "but IE won't ever support it!" argument was seriously holding WebGL back. IE still has very significant market share, and since they arguably got their act together lately, I doubt it's going to get smaller in the short term.
Considering that existing C++/OpenGL code bases can be ported to the web relatively easy with Emscripten, my bet is that we'll see a bunch of games come to the browser over the next ~3 years.
IE has a lot of market share with IE7, IE8 and possibly IE9. They don't have a lot of marketshare with IE11 - and possibly never will.
So the argument that "WebGL is not supported by IE so I'll never use it" was pretty bogus anyway, since the people using those versions of IE were probably never in your target market anyway.
So the argument that "WebGL is not supported by IE so I'll never use it" was pretty bogus anyway, since the people using those versions of IE were probably never in your target market anyway.
You're right. Last time I checked, IE8 was still the most popular IE version. However, since IE9, it's being updated automatically, so I have some hopes that most IE users will end up using the latest version, just as with Chrome and Firefox.
The main reason for IE8's popularity is probably that it's the last IE version available on Windows XP, which is still popular. I really hope Microsoft gives up on the idea that new browser versions can only come with new OS versions.
But still, even if only 10% of all IE users use IE11, that percentage can only grow. Previously, IE was a dead end for WebGL. Now there's a perspective, and that's probably good enough.
The main reason for IE8's popularity is probably that it's the last IE version available on Windows XP, which is still popular. I really hope Microsoft gives up on the idea that new browser versions can only come with new OS versions.
But still, even if only 10% of all IE users use IE11, that percentage can only grow. Previously, IE was a dead end for WebGL. Now there's a perspective, and that's probably good enough.
Will Microsoft support the full OpenGL on Windows, too, now? Or will they just run WebGL through Google's ANGLE project?
At least Google had the "excuse" to use it because they couldn't put OpenGL on Windows themselves, so they had to translate DirectX to OpenGL to make WebGL work.
What's Microsoft's excuse? They should support OpenGL and allow Google and Mozilla to use the OpenGL API's directly, too. Then we'll all get faster, and possibly richer WebGL.
At least Google had the "excuse" to use it because they couldn't put OpenGL on Windows themselves, so they had to translate DirectX to OpenGL to make WebGL work.
What's Microsoft's excuse? They should support OpenGL and allow Google and Mozilla to use the OpenGL API's directly, too. Then we'll all get faster, and possibly richer WebGL.
OpenGL on Windows is a driver issue. Some hardware manufacturers make opengl drivers, of varying quality. I'm not clear what you want Microsoft to do?
Microsoft should control Windows like Apple controls OSX except when I don't want them to! If something is wrong with Windows, it's Microsoft's fault for not controlling third party vendors! When Microsoft controls third party vendors, they're being anti-competitive!
Does this imply that those features will be henceforth natively available to windows 8.1?