Re: Update on CSS shaders security issue

Hi Fabrice,

On Apr 21, 2012, at 4:23 PM, Fabrice Robinet wrote:

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

When in comes to combining a source and destination, the most complete approach I know of would be to allow all the compositing and blend modes as defined in CSS compositing and blending:

https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html

this would include source over, clear, etc.. in addition to blend modes. We could allow control over both the blend mode and the compositing (Porter-Duff) modes.


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.

Yes it is limited, compared to full blown 3D lighting models. However, I think it would still bring a wealth of features. I propose we do the following for now:

a. restrict the shaders as we propose.
b. work on how restricted fragment shaders can be made as useful/powerful as possible. We can work on giving more control over blending/compositing, may be add more powerful ways to combine lights (as you suggest), provide ways to specify convolution kernels in the shader etc..
c. check whether or not the concerns over arithmetic operations performance are valid.

We should do b and c. in parallel and I propose we start with a simple feature set for fragment shaders that is useful, even though limited. I guess I'd like to avoid spending a lot of time on defining how to make fragment shaders more powerful with the limitation we are imposing if it turns out we can lift that limitation.

As an aside, we still need the new matrixes to be adopted in the SPEC to make this test case work :).


Yes the issue is at https://www.w3.org/Bugs/Public/show_bug.cgi?id=16838. Thanks for the reminder, because this was not captured as an issue in Bugzilla.

Cheers,
-v

Best,
Fabrice.


On Wed, Apr 18, 2012 at 10:54 PM, Vincent Hardy <vhardy@adobe.com<mailto: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