W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2012

Re: Update on CSS shaders security issue

From: Fabrice Robinet <cmg473@motorola.com>
Date: Sat, 21 Apr 2012 16:23:37 -0700
Message-ID: <CAPam9Rrk5f6AtdACiWi8XfO572TwUx3WLEy-iGe8j0wnt08jJQ@mail.gmail.com>
To: Vincent Hardy <vhardy@adobe.com>
Cc: "public-fx@w3.org" <public-fx@w3.org>
Hi Vincent,

First, thanks for sharing all this information and all the work on the WIKI.

Could you provide more information about the "combination" that you refer
to i.e blending ?
I believe the importance of this topic become very important now.
In the WIKI you refer to overlay & screen, I was expecting something more
like blending mode as additive, , replace, modulated and such... (possibly
in line with GL blending).

Regarding the test cases for fragment shaders, I have to disagree a bit
about the lighting.
For a typical lighting you may have diffuse parts of the image dimmed while
the one hitting a specular spot will be highlighted so I am not sure how
this can be "faked" efficiently with a simple combine.
But yes, for *very very* limited lighting this will work.
As an aside, we still need the new matrixes to be adopted in the SPEC to
make this test case work :).


On Wed, Apr 18, 2012 at 10:54 PM, Vincent Hardy <vhardy@adobe.com> wrote:

> Hello,
> Since the original proposal on CSS shaders, there have been discussions on
> this list and some related discussion on the WebGL mailing list at Khronos.
> Following the most recent findings in efforts to make CSS shaders secure,
> I have updated the page that summarizes the proposed security measure that
> looks the most reasonable. The other measures that were considered are also
> documented and a summary of why there did not fully meet the needs is also
> provided.
> The short description of the proposal is that it removes access to the
> rendered content from the shaders. This is not an issue for vertex shaders
> (at least for a wide set of use cases). For fragment shaders, the result
> produced by the shader will be combined with the rendered content, but this
> combination step is not controlled by the shader, it is controlled by the
> implementation.
> For example, a vertex shader that produces a flapping flag effect will not
> be affected by the restriction because it does not need access to the
> texture. A fragment shader that computes a lighting effect will compute a
> light map that the implementation will then multiply with the original
> texture. Here again, the shader does not access the rendered texture.
> I believe that this is a good approach and while it reduces some of the
> functionally, it also addresses the new security concerns CSS shaders
> raised.
> Please see the detailed description of the approach and examples of how a
> technology like ANGLE could be used for an efficient implementation:
> http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security
> Kind regards,
> Vincent Hardy
Received on Saturday, 21 April 2012 23:24:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:47 UTC