W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2011

Re: Summary of CSS shader security issues and proposals

From: Gregg Tavares (wrk) <gman@google.com>
Date: Fri, 16 Dec 2011 18:18:44 -0800
Message-ID: <CAKZ+BNo8Pi9dZh5tWYOMeNtW+9+SRKsQWcRM7OePTqXP0WJWbA@mail.gmail.com>
To: Ralph Thomas <ralpht@gmail.com>
Cc: Vincent Hardy <vhardy@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>, Adam Barth <w3c@adambarth.com>
I don't see how your Method A is supposed to work.

1) how do you do effective timing? Any change to any parameters can
massively influence timing. Set the Z to something far way it gets rendered
2x2 pixels, then set it close so it's 1000x1000 pixels.  Even if you could
some how keep a timing for every set of inputs it's unclear how the thing
would get any descent perf. Every time you go to page expect lots and lots
of hiccups as timing is done for every set of inputs on every element using
CSS shaders.

2) You can't allow variation in timing. In your Method A you give 120%
leeway. All the attacker needs is ANY difference in timing. How does giving
them 100% to 120% fix this problem? I'll just make my shader take 100% and
101% for some other and find the difference.

The first paragraph to Method B seems unrelated to anything that's been
discussed. It's certainly not related to the 2nd paragraph.

On Fri, Dec 16, 2011 at 5:29 PM, Ralph Thomas <ralpht@gmail.com> wrote:

> Hi Vincent,
>  Could it be possible to use WebGL (timing rendering continuously to
> texture) to observe page composition times in Method A in spite of
> rounding rAF up to MSET?
> Ralph
> On Fri, Dec 16, 2011 at 5:05 PM, Vincent Hardy <vhardy@adobe.com> wrote:
> > Hello,
> >
> > 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.
> >
> > Thanks to all who have commented on the issue and in particular to Adam
> > Barth for working with Dean and I to put together this summary and
> proposal
> > together.
> >
> > Kind regards,
> > Vincent Hardy
> >
> > P.S: I will be out of the office for the next two weeks and will have a
> > limited or no ability to respond to email during that period.
> >
Received on Saturday, 17 December 2011 02:19:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:39 UTC