- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Mon, 19 Dec 2011 18:05:28 +1300
- To: Vincent Hardy <vhardy@adobe.com>
- Cc: "public-fx@w3.org" <public-fx@w3.org>, Adam Barth <w3c@adambarth.com>
- Message-ID: <CAOp6jLbidockiE=LBBezXLq2Dvm4WsUkQk4SmKXD=C6XPi0=gw@mail.gmail.com>
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]
Received on Monday, 19 December 2011 05:05:56 UTC