Re: Update on CSS shaders security issue

Hi Benoit, Robert,

Thanks for your review and positive feedback.

I'll work with the other editors to update the spec. to reflect the proposal in the draft.

Cheers,
-v

From: Benoit Jacob <jacob.benoit.1@gmail.com<mailto:jacob.benoit.1@gmail.com>>
Date: Fri, 20 Apr 2012 05:41:11 -0700
To: David Sheets <kosmo.zb@gmail.com<mailto:kosmo.zb@gmail.com>>
Cc: Adobe Systems <vhardy@adobe.com<mailto:vhardy@adobe.com>>, "public-fx@w3.org<mailto:public-fx@w3.org>" <public-fx@w3.org<mailto:public-fx@w3.org>>
Subject: Re: Update on CSS shaders security issue

Thanks Vincent for the very nicely written wiki page. I can't see any
security flaw in the solution you've arrived at.

2012/4/20 David Sheets <kosmo.zb@gmail.com<mailto:kosmo.zb@gmail.com>>:
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.

What is the URL of the discussion on the WebGL mailing list at Khronos?

This was on the private '3dweb' mailing list.

https://www.khronos.org/members/login/list_archives/3dweb/1204/msg00059.html

In short, we discussed whether restrictions on the shading language
could be sufficient to make the use of cross-origin images safe in
WebGL and in CSS Shaders, and we agreed that that was unfortunately
not the case because even basic arithmetic operations (like
multiplication) can take much longer depending on input values (for
example on Intel CPUs operations on NaN values can be hundreds of
times slower than on finite values).

But all the important conclusions for CSS Shaders are in Vincent's
public wiki page.


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