[shaver]

My point is that those technologies have been added to browsers, and we've been able to deal with the security surface. Microsoft's position is that WebGL is inherently unsecurable, and therefore somehow qualitatively and fundamentally different from doing hardware accelerated 2D graphics, JS JITs, or -- as they brag about in IE9 literature -- handing off H.264 content straight to drivers and hardware to decode.

WebGL absolutely needs care taken from a security perspective, as do video and RTC capabilities, new network protocols, and support for unicode. (The "text-display facilities" I mention were some OS-supplied ones that crashed out if given the right -- wrong -- sequence of characters to display.) Especially in light of the impending support in SL5, I don't think MSFT has made a case that this facility is actually as world-ending as they make it sound. I believe that WebGL can be secured, and am disappointed that MSFT is throwing up their hands and saying "can't be done! all gonna die!" about WebGL while they've obviously invested to the point of comfort in the equivalent SL5 APIs. On Windows, in fact, we map GL to D3D and use the same shader-compilation and API pipeline as SL5.

Advice and input from Microsoft on this would be very welcome. They know a lot about the whole (Windows) stack, though perhaps not OpenGL, and like us they had to deal with driver and D2D bugs while accelerating the 2D portions of their browser. But if they're going to raise security concerns about things, a conversation rather than a blog-post broadside would probably contribute more to the security of the web.

(People point at the Context IS bug reports, but they had nothing to do with access to fragile driver code or unsuspecting hardware. They were origin-management problems in the spec, and a straight up C-pointer-mgmt-claims-more-toes bug in our implementation.)

[extension]

My point is that those technologies have been added to browsers, and we've been able to deal with the security surface.

Is merely repeating these past mistakes a high enough standard for a new technology? Particularly for one that would arguably be the worst of the lot? And for one that is getting a very late start in the arms race of exploit sophistication?

Is there not a suitable middle ground between <canvas> and OpenGL? An abstraction layer that is sufficiently powerful to not be the bottleneck, while permitting a secure implementation without the help of driver vendors and avoiding all the legacy cruft of OpenGL to boot?

[kkowalczyk]

First, it's not even close to being "worst of the lot".

Second, there might or might not be a middle ground, but you're not proposing it, Microsoft isn't proposing it and no one else is proposing it. In that context, bringing up non-existent, maybe-or-maybe-not better solution isn't advancing the discussion. In theory everything is possible but in practice WebGL implements a well understood model that has been in use for decades (just like canvas implemented a well understood model for 2D graphics). If we want fast 3D graphics in the browser, and we do, building on top of well understood technology is definitely the way to go (compared to trying to reinvent extremely complex technology that took years to perfect in the currently dominant standards (Direct3D and OpenGL)).

[extension]

I disagree with the notion that it's OK to adopt a flawed standard just because no better proposal exists. A better proposal could most certainly exist if it was agreed that it should exist and resources were committed.

The OpenGL API has a ton of legacy baggage. Nearly all of GL 1.0 is deprecated and some parts of the API have endured multiple cycles of deprecation. Improving on it would not be difficult.

[ootachi]

WebGL is OpenGL ES. The deprecated stuff in GL 1.0 is not present.

See for yourself: http://www.nihilogic.dk/labs/webgl_cheat_sheet/WebGL_Cheat_S...

[extension]

GLES is even cruftier than OpenGL, because they removed a bunch of functionality but didn't simplify the API. So you have all sorts of parameters and options that literally have no purpose. The documentation frequently says things like "The blah parameter controls yada yada. It's value must be zero." That's gotta be mighty confusing for a web developer doing 3D graphics for the first time.

The design of OpenGL is optimized for stateful, fixed pipeline, immediate mode drawing, an extinct paradigm that is unsupported in GLES and WebGL. The modern paradigm of shaders and GPU objects is radically different and demands an API tailored for it.

The continuity of OpenGL has been justified by its established ecosystem. Game developers prefered one patched up API to a new API for every generation of graphics hardware. But now hardware architecture has more or less stabilized and it's the developers that are new. Let's give them a fresh start instead of a badly mutilated API that, frankly, I think most of them will find impenetrable.

[nitrogen]

Is merely repeating these past mistakes a high enough standard for a new technology?

In a word, yes. Computing needs to be dragged kicking and screaming into the future of platform independence, and powerful 3D acceleration is an important component of a modern desktop system. The lessons learned in the previous rounds of new technology can be applied to mitigate some of the risks associated with WebGL.

[JoachimSchipper]

I'd like to point out that we have not been able to deal with the security surface: you list "font engines, video codecs, OS text-display facilities (!) and image libraries", and browser-based access to each of these has led to horrific security bugs.

Yes, most of the bugs in those components eventually got fixed; yes, 3D access via Silverlight is scary too; but let's not pretend that this isn't going to get people 0wned.