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.
"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."
"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.
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 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.
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.
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).
> 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.
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.
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.
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).
As of right now, with WebGL enabled, there is no confirmation of execution... it just happens. One time confirmation of execution per domain per code load might be a good option.
> 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).
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.
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.
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 ...").
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.
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.
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]
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 :)
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.
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.
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. :(
> 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.
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.
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.
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.
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!
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.
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.
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).
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).
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.
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?
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.
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
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.