W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2012

Re: Summary of CSS shader security issues and proposals

From: Vincent Hardy <vhardy@adobe.com>
Date: Wed, 4 Jan 2012 14:55:53 -0800
To: "robert@ocallahan.org" <robert@ocallahan.org>
CC: "public-fx@w3.org" <public-fx@w3.org>, Adam Barth <w3c@adambarth.com>
Message-ID: <CB2A17E2.299AD%vhardy@adobe.com>
Hi Robert,

From: Robert O'Callahan <robert@ocallahan.org<mailto:robert@ocallahan.org>>
Reply-To: "robert@ocallahan.org<mailto:robert@ocallahan.org>" <robert@ocallahan.org<mailto:robert@ocallahan.org>>
Date: Sun, 18 Dec 2011 21:05:28 -0800
To: Adobe Systems <vhardy@adobe.com<mailto:vhardy@adobe.com>>
Cc: "public-fx@w3.org<mailto:public-fx@w3.org>" <public-fx@w3.org<mailto:public-fx@w3.org>>, Adam Barth <w3c@adambarth.com<mailto:w3c@adambarth.com>>
Subject: Re: Summary of CSS shader security issues and proposals

On Sat, Dec 17, 2011 at 2:05 PM, Vincent Hardy <vhardy@adobe.com<mailto: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 C is a fallback and I think most agree it is not ideal.

For Method B, are you saying that it is not practical to detect cross origin usage and thus we cannot do either of B.1 and B.2?


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.

My understanding is that some of Method A may be difficult with current drivers but that with the hardening work happening on 3D drivers and new architectures, it will be possible.

Vincent
Received on Wednesday, 4 January 2012 22:58:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 4 January 2012 22:58:57 GMT