Re: Update on CSS shaders security issue

On Fri, Apr 20, 2012 at 5:41 AM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
> 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.

Are you making World Wide Web standards or Khronos Members standards?

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

Your discussion medium uses the same web technologies as the World
Wide Web but inside a paywall...

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

Unless I am misreading the wiki page, this proposal only applies to
rendered content textures?

>From the wiki:

"Access to other textures from CSS shaders should be considered. The
security measures should be the same as for WebGL access to textures
and the same usage of CORS should apply in that context."

Will CORS texture access via texture() be allowed? If both parties consent...

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

The wiki page contradicts (and leaves undecided) the issue of
cross-origin texture access. I understand the need for the rendered
content texture restriction as the browser security model lacks the
facility to track taintedness. I do not see an issue with direct CORS
texture access.

With access to the actual discussions that took place regarding this
issue, I could probably answer these questions myself by reading with
my eyes. Unfortunately, a decision was made to keep those discussions
private without justification. Here are some effects of that decision:

1. I have to ask you about it and have this meta-discussion on a list
that should be talking about technical subjects.
2. Interested competent peer observers (of which there are thousands)
are immediately made to be second-class by withholding information
resulting in..
3. Social and technical domination by the entrenched parties through
enforced ignorance on the public which leads to...
4. Resentment and a discouragement of cooperation resulting in...
5. Weaker standards and more work for you.

I think the FXTF and WebGL WG have been doing important work that will
sit at the foundation of hypermedia for decades should their standards
find adoption and provide means for evolution. Withholding important
general technical discussion from the public forum does not encourage
adoption or safeguard against evolutionary stagnation.

The Web is bigger than any collection of us,

David Sheets

>>> 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 Friday, 20 April 2012 20:12:49 UTC