IE11 to support WebGL(microsoft-news.com) |
IE11 to support WebGL(microsoft-news.com) |
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.
"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."
I've bumped into Mike a few times at Facebook; he's one of the most knowledgeable people I've ever met.
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.
[1] http://lists.w3.org/Archives/Public/public-fx/2012JulSep/007...
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.
I wouldn't tar the entire organisation with the same brush.
There is hope yet!
>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...
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.
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.
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.
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.
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.
Would also love for IE 11 to be available on Windows 7.
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."
But who knows, MS seem to think ie is some carrot to lure people to them. It could as such be crippled to w8.
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.
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...
Shaming link 2: http://www.extremetech.com/computing/87696-webgl-is-fundamen...
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.
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 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).
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?
Perhaps there are others who have to support IE as a target and would like to debug/verify front ends in-browser?
Always 2 years at least late to the party, so that using the latest technologies across all browsers remains constantly (also considering adoption) 3-4 years in the future.
Oh, and enable it in iOS Safari too - which I rather suspect they wnt any time soon unfortunately.
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
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).
https://bug614678.bugzilla.mozilla.org/attachment.cgi?id=493...
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.
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)
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.
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.
Typical way: Download game -> Confirm execution -> Play
WebGL way: Confirm execution -> Play
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).
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.
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.
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.
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. :(
They've apparently reversed that stance.
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 :)
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...
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.
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.
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
#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.
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.
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.
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.
Isn't it incredibly easy to bypass that check by using a randomly generated url segment?
[Edit: Formatting + isn't]
tl;dr No, its not that easy.
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.
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.
