Re: Merging CSS Shaders proposal into Filter Effects

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.


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

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


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

~TJ

Received on Tuesday, 1 November 2011 00:19:08 UTC