Re: [css-shaders] CSS shaders for custom filters (ACTION-3072)

On Oct 3, 2011, at 6:51 AM, Vincent Hardy wrote:

> Hello,
> 
> The Filter Effects 1.0 draft contains an open issue about supporting "a filter primitive that would reference a programmable operation, similar to an OpenCL kernel or GLSL fragment shader":
> 
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#feCustomElement
> 
> During the last FX task force meeting in Seattle, I got the action to prepare a detailed proposal for supporting custom filters in the Filter Effects 1.0 (http://www.w3.org/Graphics/SVG/WG/track/actions/3072). 
> 
> The detailed proposal can be found at:
> 
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html
> 
> We (at Adobe) have worked on a prototype implementation. The proposal reflects the work done on the prototype to get a better understanding of the various issues involved when using fragment and vertex shaders for custom effects. It also reflects on the feedback and suggestions of several people, in particular the co-editors for the proposal, Dean Jackson and Erik Dahlström.

This is a very exciting proposal, thanks for the doing it and the implementation. As editor of the WebGL spec, I'd like to suggest you rephrase the shading language choice. You mention "OpenGL ES for alignment with fragment shaders in WebGL". I think it's important to more tightly specify the language as the exact subset of OpenGL ES that is used in WebGL. We've done quite a bit of work to narrow the accepted language to a subset of OpenGL ES that is appropriate for the web, makes it easier to deal with the security issues, and makes it possible to implement on top of ANGLE (to allow WebGL to run on top of Direct3D). Making that clear here allows you to take advantage of those same features.

Also, why do you just mention fragment shaders? The intent it to adopt both fragment and vertex shaders from WebGL, right?

Finally, it's good that you include section 6.3 on security. That is obviously the main sticking point of WebGL, and of WebCL if and when it becomes available. But I don't think you should characterize Denial of Service as the only real security concern. WebGL represents the first exposure of an API of the complexity of OpenGL to the web. GLSL is a programming language which, unlike JavaScript, executes instructions directly on the host machine. Exposing this kind of functionality to content authors is unprecedented, and opens up brand new avenues for malicious exploits. For that reason these drivers need to be hardened against attacks like never before.

As you say, this work is ongoing and I believe that WebGL and related technologies will ultimately be as safe as any that are exposed to the web today. But we're not there yet, which is why Apple includes the functionality in its browsers, but leaves it disabled. On desktop it can be turned on with a developer switch and on iOS it is only available to iAd developers. 

We found that when we shipped WebGL 1.0 we should have erred on the side of expressing greater concern about these issues, rather than making them an aside. I think the same is true of CSS Shaders.

I'll have more detailed comments later. I just wanted to mention these high level issues.

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