Microsoft Brands WebGL a 'Harmful' Technology 503
An anonymous reader writes "Microsoft has announced that it has no plans to support WebGL — a cross-platform low-level 3D graphics API designed for web use — in its future browsers, citing numerous security concerns over the technology and branding the basic principles as 'harmful.'"
They can't even spell (Score:4, Insightful)
"Although mitigatinos such as ARB_robustness [...]"
Nice Microsoft, nice.
Whilst I believe that WebGL _could_ become a vector for attack, I think this is actually "We want to push DX not GL, let's stick to NIH by saying it's dangerous instead"
Microsoft should get out of browsers ASAP (Score:4, Insightful)
Microsoft has no business building browsers. The open architecture of the web will always conflict with IE being closed source and the EEE tactics Microsoft is constantly trying on various web technologies. In the past, Microsoft's hegemony over computer technology gave them enough influence that they might actually have a chance at "de-commoditizing" (as they say) some popular open web technologies, but that's over, they aren't the 800lb gorilla in the room anymore, they're just another dog in a fight with at least 2 other dogs (the Open dog and the Apple dog - and no they're not the same. Look at Safari's special HTML5 rendering. Familiar? Don't forget that an open web also poses a threat to Apple's mobile apps).
By continuing to work on browsers, Microsoft is fighting a war they can't win, but like all wars this one is still harmful to the other combatants and various innocent bystanders.
They're right (Score:5, Insightful)
You really want websites to be able to freeze and possibly crash your graphics subsystem, possibly overheat reboot your machine?
Besides that, it's just sloppy, just like WebSQL is sloppy. It's just "hey lets compile opengl ES into our browser" or "lets compile SQLite into our browser" and neither are even half-hearted attempts at a proper standard. I originally said this as a joke, but it makes more sense to just link in the quake engine and support a "quake" tag, that takes a link to a PAK file as its .src attribute. That'd at least solve the (very real) security problems. Executing arbitrary shader code from random websites isn't a good idea.
Aside: apparently noone else supports WebGL either. The implementations in both FF and Chrome are broken. I've had problems with multiple textures, framebuffers, the list goes on. It's simply not working yet.
Of course, webGL would be trivial to reimplement in IE with a partial trust Silverlight plugin, which could just execute the GL natively, though that would be a much bigger security hole.
Re:Microsoft should know... (Score:4, Insightful)
To this day it is still easy to make Word Documents that phone home to a server with user info every time they are opened. But WebGL is harmful.
It is a problem; but... (Score:5, Insightful)
Allowing the internet to do things to your machine is dangerous. It is also among the top reasons why most people bother to own a computer. Letting pages run Javascript opens you up to vulnerabilities in your JS engine. Support for images in webpages means that a bug in any of your image format renderers(and there have been a few of these) will allow the attacker to own you. Even HTML rendering isn't safe. People from the internet are running code on your CPU, through assorted layers of indirection, virtually continually... We put up with this blatantly dangerous situation because we want the functionality.
Other than the (im)maturity of OpenGL as something that is subject to maliciously crafted input, rather than just error by well-meaning application designers, I'm not seeing a fundamental difference. Everything that happens in your browser happens because filthy, possibly dangerous, 3rd party instructions are executed, through some number of intermediate interpreters and libraries and codecs, right on your hardware.
Now, I can definitely see the case to be made for "You really shouldn't enable WebGL, except for websites that you would also trust enough to download and execute with admin permissions executables from, until the OpenGL ecosystem has had time to finish wetting itself from pure fear and start improving things", it is quite likely the case that the large, complex, more-focused-on-speed-than-security, mass that is GPU firmware, GPU drivers, etc is a mass of potentially serious issues, having historically been sheltered from the more hostile side of things. However, that doesn't seem fundamentally different from the state of the stack sitting on top of the CPU that was inherited from a more innocent time before widespread network malice. Ultimately, we just had to fix that; because the alternative involved not being able to do what we wanted to do.
I tend to agree (Score:4, Insightful)
For once don't bash M$, read the article instead (Score:5, Insightful)
An essential factor in security is trust. You cannot trust a website you have never seen before to load code of its choosing to be executed on a driver supplied to you by third-party which may or may not have a stellar security record themselves. Especially when "modern" operating systems like Linux run drivers as part of their monolithic kernel and so probably WILL crash when the website code messes up the driver runtime. Windows is heading in all the right directions moving their graphics driver supporing infrastracture out of the kernel into userspace. At least that way, your entire OS won't crash bringing everything down with it. At worst, smart people will figure out doing their favourite things - injecting their code through good old buffer overflows and what not.
This is what you get when you pair three poorly isolating systems to eachother. Microsoft may have done a lot of their own mess during the years with their products' security, but for once, they are right. Not the least, becaue they probably have gotten so much flak for it they finally decided enough is enough and started going by security checklist documets and automated programs that eliminate all the obvious bugs. I sincerely hope they're getting it, for I for one am tired of hearing everyone bash them. Look into your own backyard when you get 20 million lines of code running wildly on a several hundred million computers around the globe, thanks. Or reduce your SLOC, but that, again, is another discussion.
Re:Microsoft should know... (Score:5, Insightful)
Re:Microsoft should know... (Score:5, Insightful)
I'm really surprised that everyone is jumping on the "lawl microsoft security" bandwagon here, rather than the "well of course it's dangerous tech – it's OpenGL based, not D3D based... it's dangerous for MS's market share" bandwagon.
Re:Microsoft should know... (Score:2, Insightful)
Even a stopped clock can be right once or twice a day. Concerns for the security of this popped up on slashdot not long ago, and seemed to be accepted, but now that MS has concerns, it's a great tech?
They should treat it like they treat all of their other insecure tech (scripting in word, html in emails with outlook, activex, silverlight that wants to do risky things) - prompt the users "Hey, do you want to do this, it's probably not a bright idea unless you really trust the source"
Re:Microsoft should know... (Score:5, Insightful)
Yup.
If it were WebDirectX they'd be all over it. Since it's WebGL, however, there are security concerns.
Which isn't to say that the security concerns aren't valid... If you're giving a web page low-level access to your hardware there's certainly a possibility for abuse. But I suspect that Microsoft's concern here is more about market share than security.
Re:Microsoft should know... (Score:5, Insightful)
They must do everything they know how to keep profits rolling and 3D is finally catching on so it's back to their form of business. FUD before crud.
LoB
Re:Microsoft should know... (Score:2, Insightful)
Bugs in the OpenGL stack are no more plausible than bugs in the rest of a web client stack. Arguably they are less likely in OpenGL because the semantics are more tightly defined and the set of commands is smaller and less complex than in (say) HTML 5. Heck, the Canvas element is almost as complex in a lot of ways as WebGL, and has equal scope for exploiting graphics driver bugs.
Re:For once don't bash M$, read the article instea (Score:5, Insightful)
Can you explain to me, from your security point of view, how this is any different than using flash or silverlight on the web? Using those technologies, you're loading code form a website to be executed on a driver supplied to you by a third party which does NOT have a stellar security record.
Re:Microsoft should know... (Score:4, Insightful)
Except video drivers are about as secure and stable as IE4.
Re:Microsoft should know... (Score:5, Insightful)
LoB
Re:Microsoft should know... (Score:2, Insightful)
It's like the Republicans and Libya. Sure, they have a point, it's a bad idea. But when it was their turn with the bad idea, they ran a lot farther with it. It's clear that they're not opposed to it because it's a bad idea, but because it's not their bad idea.
WEBGL makes the drivers more visible. (Score:5, Insightful)
Anything that gets drawn in a browser is controlled by the browser. After 10 years of failure that part mosty is sandboxed into safety. The Code of web gl has almost complete access to the video driver. The video driver was never written for security. Speed and picture quality were the number one priorities. Since the application that ran them was alrady a local application that had a lot of access security was not really an issue. The application that access the drivers did not have to be checked extra, because they had already full access to the machine.
Display drivers are complex software, that might show the same level of vulnerabilities that plagues the browser.
However a subset of WEBGL that is more easy check could be implemented safely i think.
Re:Microsoft should know... (Score:4, Insightful)
A good faith reaction would be to work with others to fix the security issues.
The problem is, a lot of the security problems with WebGL need fixing in silicon. With most GPUs currently out there, a small bug anywhere in the OpenGL stack - a huge chunk of code that was designed to run trusted code and so optimised heavily for speed, and not really designed with security in mind - can let shader code completely compromise the system, or at least let malicious code perform a DoS attack. This isn't much of a problem at the moment, because most users don't run OpenGL code that they don't trust. You rarely see GLSL code on servers, it's either running on compute nodes (where compromising the node isn't seen as a problem because you want the user to be able to get as much out of the hardware as possible) or on machines that are basically single-user, so it's already trusted by the only user with any important data on the system.