Re: Update on CSS shaders security issue

2012/4/20 David Sheets <>:
> On Fri, Apr 20, 2012 at 5:41 AM, Benoit Jacob <> 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 <>:
>>> On Wed, Apr 18, 2012 at 10:54 PM, Vincent Hardy <> 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?
> Your discussion medium uses the same web technologies as the World
> Wide Web but inside a paywall...

Hey, everyone agrees that standards must be discussed/decided on
public lists. But we didn't discuss standards there. That was just a
pie-in-the-sky discussion among a few people about the possibily or
impossibility of defeating timing attacks by shading language
limitations. I don't think it was particularly wrong to have that
discussion privately. If you're interested in what we said, the CSS
shaders wiki + my previous email (see below) sum up the conclusions
and key argument.

>> 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:
>>>> Kind regards,
>>>> Vincent Hardy

Received on Sunday, 22 April 2012 13:07:18 UTC