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

Re: Update on CSS shaders security issue

From: Benoit Jacob <jacob.benoit.1@gmail.com>
Date: Fri, 20 Apr 2012 08:41:11 -0400
Message-ID: <CAJTmd9o=AToWc47U9qGcOFivDHf_zaAs=NbJeXFXfYGwmO3=Lw@mail.gmail.com>
To: David Sheets <kosmo.zb@gmail.com>
Cc: Vincent Hardy <vhardy@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>
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>:
> 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.
>
> 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
>
>
Received on Sunday, 22 April 2012 13:07:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 April 2012 13:07:35 GMT