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

Re: Documenting Timing Attacks in Rendering Engines

From: Chris Marrin <cmarrin@apple.com>
Date: Tue, 13 Dec 2011 16:51:10 -0800
Cc: "Gregg Tavares (wrk)" <gman@google.com>, Adam Barth <w3c@adambarth.com>, Vincent Hardy <vhardy@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>
Message-id: <72CEFFFE-6DAE-4E9C-8140-97AE2024AFDF@apple.com>
To: James Robinson <jamesr@google.com>

On Dec 12, 2011, at 5:47 PM, James Robinson wrote:

> 
> 
> On Mon, Dec 12, 2011 at 2:56 PM, Chris Marrin <cmarrin@apple.com> wrote:
> 
> On Dec 12, 2011, at 1:06 PM, Gregg Tavares (wrk) wrote:
>> 
>> In this particular case I think the problem boils down to requestAnimationFrame. It's only going to give you frames as fast as it takes to render and one way or another you can use that to get your timing. (I don't think setInterval/setTimeout would be any different). At some point the JavaScript or HTML renderer will be throttled waiting for this other process to do work. You just need to figure out how much work to give it to find that throttling point and then use that to adjust how long rendering takes.
> 
> rAF need not know anything about the rendering process. As far as the author knows the system is running at 60fps no matter how complex the page. In fact nothing that the author can see needs to know about it. As far as the author is concerned he is rendering to a display list at 60hz (or whatever the display rate is), and as long as creating that list doesn't give back any timing information (which it shouldn't), there should be no way to know how long a given rendering operation will actually take.
> 
> In addition to the issues Adam has talked about, it also sounds like you are describing a very poor quality implementation of requestAnimationFrame.  rAF needs to scale with the time that the scene takes to render so that the author's script does not do unnecessary work.  If, for example, the page can only render at 15Hz on a given piece of hardware then the rAF callbacks should only fire 15 times a second, or the author will be doing a potentially large amount of work in script that will only be thrown away.  This is one of the key advantages of rAF over setTimeout-based scheduling which has no insight into the rest of the rendering pipeline which, as you point out,  may be deeply pipelined.  Good backpressure mechanisms are essential to building high-quality animated and interactive experiences.

I believe hiding timing information from a an author will require "lying" about aspects of the system timing. But I can imagine basing rAF on an average framerate, measured over many frames, which may give you the throttling you want while still giving insufficient timing information to attackers for any practical purposes.

-----
~Chris
cmarrin@apple.com
Received on Wednesday, 14 December 2011 00:51:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 14 December 2011 00:51:48 GMT