Re: Update on CSS shaders security issue

I just wanted to toss my 2 cents in here. First let me say that while I'm still editor of the WebGL spec, I'm no longer in the WebKit group. So my observations about CSS shaders are as an interested 3rd party. And let me also say that I have great respect for all the work this group has done.

If I am reading your proposal right you're saying that we will have no access to the texture we're filtering in the shaders. If so, that would seem to nullify the usefulness of this feature. The two examples you give (vertex shader-based image warping and fragment shader "lighting") are really the only two effects that would be practical. Vertex shader warping is mildly interesting, but will need very dense meshes to get really interesting effects. But you're really only allowing fragment shaders to be image generators which are then blended with the source image. That doesn't seem interesting at all. With this restriction you lose out on any fragment shader based image warping, blurring, and almost all interesting (IMHO) use cases.

That leads me to ask, is it worth it? Maybe the energies of this group would be better spent focusing on more advanced fixed function shaders. For instance, adding the majority of the CoreImage filters and the ability to combine filters with a graph topology would at least give you access to a wide variety of advanced filtering techniques.

Moving down this path takes away an incredibly powerful tool from web authors. Another implication is that WebGL will never be able to access rendered page content, cutting out many interesting and powerful effects, which have already been demoed. It is, in effect, stifling advancement of the web platform due to non-technical privacy concerns. 

On several occasions I've brought up the point that all these concerns are based on unproven attack vectors. That point has been repeatedly shot down with claims that it has been proven, referencing some vague numbers that show it's possible for a shader to take different amounts of time based on a pixel's color. All that might be true, but never have I seen an actual example of an attack. Where is the site I can go to where I can type a string into a text box and within a few seconds the site tells me what I typed merely by examining the image of what I typed? Maybe such a thing is possible, but it seems wrong to cut out a powerful feature like this before proving it. Once it is proven, some browser vendor might come up with a technique to thwart such an attack. Then it becomes an arms race between clever attackers and clever defenses. But isn't that what the web has been all about for many years?

And maybe this group, rather than looking at ways to make it impossible to deduct the value of pixels from a shader, should instead look at making it impossible for an attacker to get at the pixels of a legitimate site in the first place. Would preventing frame based content from running shaders solve that problem? I don't know, but it seems like its important to understand how an attack would work end-to-end and then stop it somewhere other than in the fragment shader.

I understand that these points probably won't be any more well received now than they have in the past. But I felt the need to say them. This really is the future of the web. If these problems can't be solved now, it doesn't bode well for things to come.

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

-----
~Chris
cmarrin@apple.com