Re: A few comments on the custom shaders spec

On Mar 7, 2013, at 1:05 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

> The spec says:
> A study of the security issues has led to the requirement that vertex shaders and fragment shaders do not get access to the rendered content in order to prevent timing attacks. If a custom filter primitive does not fulfill these requirements, the primitive is a pass through.
> These requirements need to be fully specified.

This part specifies the scope of the security for extensions like Shaders. It says that custom filters are not allowed to provide direct or indirect access to user data (e.g. by timing attacks).

The section "Fragment Shaders Differences with GLSL"[1] describes the security steps Shaders need to take to fulfill this requirement:

""
A normal GLSL shader requires that the fragment shaders computes a gl_FragColor value which is the color value for the processed fragment (pixel).
Because of the security restrictions, fragment shaders are not allowed to access rendered content pixel values directly.
""

> 
> I thought that to compensate for the lack of access to rendered content, we were going to allow fragment shaders to generate a per-pixel color matrix which would then be applied to the content. But I don't see any sign of that. Is that coming?

In the same section "Fragment Shaders Differences with GLSL"[1] it is defined how to influence pixel colors. There are at lest thee ways to influence the pixel color of the input. With per pixel compositing and blending there are different possible variations.

* gl_FragColor
Even if it is not possible to read color values from primary inputs of shaders, it is still possible to set the color directly. In some situations this might still be useful.

* css_MixColor
Allows to specify a color the input pixel color gets blended and composited with.

* css_ColorMatrix
This allows setting a color matrix. The input pixel color is multiplied by this color matrix.

css_MixColor and css_ColorMatrix can be combined together with blending and alpha compositing. The interaction is defined in "Shader Processing Model"[2]. The last graphics in this section gives a visual presentation how to influence the input pixel color.

> 
> Section 17.2 is totally unclear. In particular, what does "input" mean here? I thought the whole point of section 17.1 was to eliminate the need to track the origins of rendered content.
> 

In the last WD it was possible to pass a previous filter primitive result as texture parameter into the shader (as secondary input) under the condition that it is not the direct or indirect result of the pages web content. This requires tracking which filter primitive counts as "dirty". I removed it in this version. I am looking forward to add it again to allow generators like feTurbulence as input.

Greetings,
Dirk

[1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#fragment-shaders-differences-with-glsl
[2] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#shader-processing-model

> Rob
> -- 
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]

Received on Friday, 8 March 2013 04:54:30 UTC