Re: Update on CSS shaders security issue

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

Best,
Fabrice.


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
>