

Mozilla VP Mike Shaver responds to Microsoft's WebGL security concerns - mbrubeck
http://shaver.off.net/diary/2011/06/17/a-three-dimensional-platform/

======
tptacek
"Adding new capabilities can expose parts of the application stack to
potentially-hostile content for the first time. Graphics drivers are an
example of that, as are _font engines, video codecs, OS text-display
facilities (!) and image libraries._ "

These are all technologies that have, in fact, been a continuing source of
terrible security vulnerabilities. I'm not sure of the point he's making;
surely, he has to know that font and image libraries --- and even just new
ways of gluing those things together, like the new CSS font goo --- actually
_are_ security threats.

I don't have much of an opinion here. Microsoft is right that WebGL is scary
from a security perspective. Maybe Mozilla is right that it's worth the risk.
But this is a bit of a weird post.

~~~
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...](http://www.nihilogic.dk/labs/webgl_cheat_sheet/WebGL_Cheat_Sheet.htm)

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

------
CoffeeDregs
I _did_ appreciate that Microsoft gave reasons along with their snub, but
their analysis felt pretty NIH-and-not-going-to-help-with-the-inventing to me.

Shaver says:

    
    
        >I also suspect that whatever hardening they applied to the
        >low-level D3D API wrapped by Silverlight 3D can be applied 
        >to a Microsoft WebGL implementation as well.
    

Nice point. Whether Microsoft engages with and helps improve WebGL could be
seen as a proxy for whether they will in fact engage with Web Standards in IE
1X. Or is WebGL so broken that it's impossible to contribute?

I'm also surprised since the next battleground for browsers seems to be in
mobile and pushing forward a unified and seriously advanced browser strategy
could be a serious advantage for MSMobile (whatever the hell it's called now).
Instead, they seem to be re-fighting battles in a war that's already been
semi-lost (the PC browser).

~~~
kenjackson
One thing to keep in mind though is that while MS is one company I don't think
the IE team and the Silverlight team see eye-to-eye on everything.

It could well be the case that the IE team thinks that what SL does is
something they wouldn't put into Windows.

~~~
shaver
The post wasn't from the IE team, but from MSRC, the company-wide security
research group.

~~~
kenjackson
I missed that, thanks. In that case they pretty clearly know the delta between
the XNA in SL support and OpenGL. Do you know what the big differences are in
how shaders are handled between XNA and OpenGl? Can we work to get them to be
more similar?

~~~
shaver
The shader models in XNA D3D and WebGL are pretty similar. One travels as pre-
compiled bytecode and the other as text, and there are some differences in how
loop constructs work, but they're both basically shader model 2.

But the argument I read from MSRC wasn't about the capabilities of the system
when working as intended, it was about weaknesses in OEM/IHV drivers causing
_unintended_ behaviour that is qualitatively harder to fix than bugs in the
drivers for hardware H.264 decoding. I haven't yet found a way that HLSL/XNA
is more robust than GLSL/WebGL, and I've been in threads about those shader
models for quite a while now. Of note, perhaps, is that on Windows we compile
GLSL _into_ HLSL and then effect bytecode (with Microsoft's compiler) and feed
it through Direct3D. It's a very very similar pipeline.

The claim is that driver blacklisting hasn't been used to address recent
vulnerabilities, but...the recent vulnerabilities have had nothing whatsoever
to do with problems in a driver.

------
extension
_I think that there is no question that the web needs 3D capabilities. Pretty
much every platform has or is building ways for developers to perform low-
level 3D operations_

This is assuming that the web needs to be a competitive app platform, but that
is a wole other debate. Regardless, it's immaterial to the security issue. No
matter how badly we need it, if WebGL really is as insecure as some have
suggested then it will only sabotage the underlying goal.

 _Adding new capabilities can expose parts of the application stack to
potentially-hostile content for the first time. Graphics drivers are an
example of that, as are font engines, video codecs, OS text-display facilities
(!) and image libraries_

Web video (and audio) have been effectively phased in over a good 10 to 15
years. Ditto Flash and PDF. These technologies have had the luxury of evolving
security gradually along with the threat and their record is still far from
spotless. I don't know a lot about font engines, but I doubt they compare in
complexity and diversity to 3D graphics drivers.

GL drivers will be thrown right into the deep end. I am skeptical that driver
makers can really understand what they are getting into, or that they really
have the incentive to care.

 _I also suspect that whatever hardening they applied to the low-level D3D API
wrapped by Silverlight 3D can be applied to a Microsoft WebGL implementation
as well_

That is a huge assumption. Here, you're talking about Microsoft's own 3D API
bound to their own VM, running on their own OS. Or in the case of cross-
platform Silverlight, a 3D API wrapping a completely different 3D API. I would
like to know the details of how that works and how it is secured. But without
knowing, I wouldn't assume it was at all applicable to WebGL.

And anyway, even if Microsoft _can_ do a secure implementation on Windows,
what about every other browser on every other platform? Conspiracy theories
aside, this is not about Microsoft.

 _our conversations with the developers of the drivers in question make us
confident that they’re as committed as us and Microsoft to a robust and secure
experience for our shared users_

If WebGL is to be a true web standard that works everywhere, then that's a
_lot_ of different developers, present and future. The responsibility to keep
browsers secure is being spread awfully thin, across some parties that aren't
very accountable.

So far, I haven't seen any response to the WebGL security issues stronger than
"don't worry, we'll try really hard" and that is not very reassuring.

With regards to web security in general, everything that could conceivably go
wrong up until now _has_. We have to assume that the same principle will hold
for future technologies and make sure they are air tight from the start. If we
accept compromise with WebGL then we won't know for sure if there is a problem
until it's too late -- that is, until it is widely deployed and difficult to
change or abandon.

~~~
patrickaljord
> This is assuming that the web needs to be a competitive app platform

This is one of the goals of HTML5.

> That is a huge assumption. Here, you're talking about Microsoft's own 3D API
> bound to their own VM, running on their own OS.

Whenever you have code that has access to low level API and hardware, you'll
encounter the same issues. Look at the history of windows with running native
code and all the security issues it has enabled, there is no question they
will meet the same issues with 3D on silverlight.

> this is not about Microsoft.

It is about Microsoft. They also had tons of reasons not implement SVG because
SilverLight was better and SVG had flaws according to Microsoft... until they
added it to IE9 because it was turning popular. They'll try the same with
WebGL, this is typical Microsoft behavior.

> So far, I haven't seen any response to the WebGL security issues stronger
> than "don't worry, we'll try really hard" and that is not very reassuring.

They said they will improve the specs to fix the issue. What else do you want?

> With regards to web security in general, everything that could conceivably
> go wrong up until now has.

The same could be said about native apps security. The real story here is that
Microsoft doesn't want to implement WebGL for two very known reason:

1) It competes with Silvernight 3D

2) WebGL is based on OpenGL while Microsoft is pushing hard for Direct 3D. If
webgl gets popular they'll have to implement WebGL on windows and developers
might want to develop against it instead of D3D, although they could limit it
to IE. Either way, it's not appealing to them, like SVG was when they still
believed Silvernight would take off.

~~~
extension
_It is about Microsoft. They also had tons of reasons not implement SVG
because SilverLight was better and SVG had flaws according to Microsoft...
until they added it to IE9 because it was turning popular. They'll try the
same with WebGL, this is typical Microsoft behavior._

Microsoft is not the only party criticizing WebGL and the motives of any such
party are a separate issue. The technical problems with WebGL have been made
clear and appeasing Microsoft or questioning their motives does not address
those problems.

 _They said they will improve the specs to fix the issue. What else do you
want?_

Who said they will improve the specs and in what way? There are fixes for
specific bugs, like cross-domain image loading. ARB_robustness is in the
works, which is an implementation detail that might help somewhat. But I've
seen nothing that claims to fix issues of the sort mentioned by Microsoft,
just claims that they aren't really a problem.

And if WebGL is being fixed then why is it enabled in production browsers
_today_?

------
aw3c2
John Carmack said:

<https://twitter.com/ID_AA_Carmack/status/81732190949486592>

 _I agree with Microsoft’s assessment that WebGL is a severe security risk.
The gfx driver culture is not the culture of security._

<https://twitter.com/ID_AA_Carmack/status/81745430152609793>

 _They are orthogonal technologies, but NaCl is much, much easier to make
secure than WebGL, even though it sounds scarier._

~~~
leoc
There's a marked contrast between Mozilla's eagerness to press ahead with
WebGL and tidy up the problems later, and the abundance of caution it displays
when facing NaCl, a technology that threatens its own ricebowl.

------
becomevocal
\+ 1 for Mozilla working in WebGL and moving the web forward.

\+ 1 for Microsoft keeping them accountable.

\- 2 for Microsoft keeping yet another awesome technology out of their browser

Mozilla wins. We're back to zero.

------
getsat
To be completely honest, it doesn't matter what their response is (and the
site isn't loading, anyways). If Microsoft refuses to implement WebGL, the
technology will have been effectively hamstringed.

Edit:
[http://webcache.googleusercontent.com/search?sclient=psy&...](http://webcache.googleusercontent.com/search?sclient=psy&hl=en&site=&source=hp&q=cache%3Ahttp%3A%2F%2Fshaver.off.net%2Fdiary%2F2011%2F06%2F17%2Fa-
three-dimensional-platform%2F&aq=f&aqi=&aql=&oq=&pbx=1)

~~~
younata
Not precisely. Firefox and Chrome have enough marketshare that games with
WebGL can just detect IE, then throw up a message "your browser does not
support WebGL, click here to download a browser that does.".

~~~
hakl
Google Chrome Frame could also be helpful here. Macromedia somehow managed to
get most people to install their terrible plugin.

~~~
yuhong
Long before Chrome Frame even existed.

------
smallblacksun
>but our conversations with the developers of the drivers in question make us
confident that they’re as committed as us and Microsoft to a robust and secure
experience for our shared users

ATI and NVidia have never cared about driver stability (or anything other than
benchmark performance), and now we're supposed to believe that they will start
caring about security?

~~~
lambda_cube
ATI and NVidia surely cares about driver stability. Who would buy their
graphics cards if the games kept crashing all the time?

ATI and NVidia didn't have to care about security before, since the only
applications that could access the drivers and graphics cards were trusted
applications. Now we have a new situation where they they have to start to
care about security. I don't think AMD or NVidia want to be blacklisted in
WebGL implementations because their driver isn't secure enough.

~~~
seabee
_I don't think AMD or NVidia want to be blacklisted in WebGL implementations
because their driver isn't secure enough._

Only one or the other could get blacklisted. If it was both of them, what
remains? The Sandy Bridge GPU? WebGL needs them more than they need WebGL.

