Re: Merging CSS Shaders proposal into Filter Effects

On Oct 31, 2011, at 5:18 PM, Tab Atkins Jr. wrote:

> On Mon, Oct 31, 2011 at 4:47 PM, Vincent Hardy <vhardy@adobe.com> wrote:
>> On Oct 31, 2011, at 4:34 PM, Tab Atkins Jr. wrote:
>>> On Mon, Oct 31, 2011 at 10:30 AM, Vincent Hardy <vhardy@adobe.com> wrote:
>>>> Tab: you mention that more things than the shading language are contentious.
>>>> Can you explain what these contentious issues are?
>>>> Are you referring to the issues raised on the mailing list:
>>>> http://www.w3.org/Graphics/fx/wiki/Custom_Filters#Issues_List
>>>> or something else?
>>> 
>>> I'm specifically referring to the issue of selecting through a vertex
>>> filter, and the security issues with using a fragment shader to
>>> extract information through a timing channel.  Both of these are
>>> unaddressed and probably difficult to deal with, and may take a decent
>>> amount of time to deal with.
>> 
>> The issue of selection in a shader (vertex and/or fragment) is the same as with other filter effect. It may be more obvious with vertex shaders, but essentially, the issue is the same.
> 
> I disagree.  Fragment shaders can do arbitrary pixel transformations.
> There is no way, even theoretically, to make pointing respond to that.
> Some existing Filters *could* so so (like feOffset), but we've
> resolved to keep them consistent and have them not affect pointing.
> 
> Vertex shaders, on the other hand, can theoretically affect pointing.
> They are affecting geometry, which is what pointing works on.

When I talk about the issue, I mean that the end result is the same for both fragment shaders and vertex shaders. Both affect the rendering and, in the end, where pixels end up on the screen. Both can bias the rendering and in effect, interfere with interactivity.

It seems that your point is that we may be able to find a solution for vertex shaders but that there is a resolution to not do anything about filters (or fragment shaders). 

I am all for trying to find a solution for vertex shaders and interactivity, but I do not think this should necessarily be resolved right away because even if we resolve it, it will only be a partial solution. By just combining the vertex shader with filter primitive or another fragment shader, we will still run into the same issue.

> 
> 
>> There has been a lot of discussion on the timing attack, but I would note two important things:
>> 
>> a. it is much harder to time the processing time in a CSS shader than in WebGL. You can basically time a shader the same way to time any rendering in HTML/CSS/SVG.
> 
> Incorrect.  You time rendering the same, yes, but you cannot
> *manipulate* render time in normal HTML/CSS like you can in a Shader.
> It's possible to get fairly predictable manipulations in Shaders that
> you can't easily get with arbitrary content.

My point was about timing how long it takes to apply the shader. I was saying the attacker is down to the same toolset as for timing render time of any HTML/CSS. The fact that the shader has an impact on the render time is the core of the timing attack discussion, this is not what I was talking about with point a. 

> 
>> b. from discussions with Dean on the webkit-dev mailing list (I think Dean will forward his points), it is possible to mount a timing attack with regular filters.
>> 
>> My point here is that these issues are important but not unique to CSS shaders. They apply to filter effects in general and I think they should be addressed together, one more reason to want to keep filter effects and shaders together.
> 
> feComponentTransfer is the only one that works, I think.  I believe it
> also has a lower theoretical bit rate than Shaders can have.
> 

Essentially, it is the same problem. The risk may be lower, but it exists, and may be we have not thought through all the possibilities. This should be addressed as a whole. As we were discussing earlier, the heart of the issue is that shaders/filters have an impact on rendering time and it is possible with both to mount an attack that exploits that characteristic. This is the issue to address and that seems common to both filters and shaders.

> 
>>>> The CSS shaders proposal responds to the feCustom 'question' in the 'Filter
>>>> Effects' specification and it seems more natural to integrate it than keep
>>>> it a separate specification.
>>> 
>>> Or we can just move the definition of <feCustom> to Shaders.
>> 
>> Sure, but my point was that CSS shaders are in the scope of Filter Effects.
> 
> Yes, and <image> is a type of value, but we still have a whole spec
> for it rather than shoehorning it into Values & Units.  It sometimes
> makes sense to calve things off.

I agree it sometimes makes sense to do that, but in this particular case, my preference is to keep these things together because they are very related.

Vincent

Received on Tuesday, 1 November 2011 00:44:39 UTC