Live data from Hacker News

IE11 to support WebGL

microsoft-news.com

131–136 of 136 posts

Re: IE11 to support WebGL

#131
post #101
post #65

Earlier quoted context omitted.

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.

Re: IE11 to support WebGL

#132
post #106

Earlier quoted context omitted.

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...

Good point: re multithreading. I wonder if web workers could be used to resolve that?

Re: IE11 to support WebGL

#134
post #47

Earlier quoted context omitted.

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, l…

> 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…

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.

Re: IE11 to support WebGL

#135
post #40

Earlier quoted context omitted.

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?

IE has had auto-update since IE9. IE9 is in the process of being auto-updated to IE10, unless auto-update has been disabled.

Re: IE11 to support WebGL

#136

Earlier quoted context omitted.

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…

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.

Post reply on HN