Re: Summary of CSS shader security issues and proposals

On Sat, Dec 17, 2011 at 2:05 PM, Vincent Hardy <vhardy@adobe.com> wrote:

> We have put a summary of the CSS shaders security issues at:
>
> http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security
>
> I hope this captures the problem properly and that the proposed methods
> will provide a way forward on the issues. If issues are not summarized
> properly or fail to represent a particular point of view, please comment so
> that we can improve this summary and/or proposal.
>
> Feedback from other implementors and GPU experts on "Method A" would be
> very helpful.
>

Method B seems difficult to implement fully. There are so many ways that
cross-origin resources can affect rendering. Try enumerating them! Thus,
neither method B nor C seem attractive.

Method A sounds interesting. At least it's a more contained problem than
method B. However, it's not clear to me that it's implementable at all. If
you're compositing the Web page and you hit a shader that takes "too long"
to run, AFAIK it's not generally possible to abort the shader and continue
compositing the page. It seems that "behave as if the shader had completed
its operation" can't be done. On the other hand "If a shader executes in
less that MSET, then the implementation must wait until MSET has ellapsed
[sic]" also seems difficult to achieve since GPU execution is highly
asynchronous and pipelined.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]