Re: [Paint Performance] - Exposing paint rects to the DOM

This recent paper explored timing attacks based on painting -
http://www.contextis.com/files/Browser_Timing_Attacks.pdf

"Both Internet Explorer and Firefox perform an asynchronous database lookup
for each link. If
the database query has not completed before the link is rendered, the
browser will first use
the ‘unvisited’ style to render the link. Once the database query has
returned, the link will be
redrawn if the URL is found to have been previously visited. If this
‘redraw’ event can be
detected by a webpage, then it could tell if the link had been previously
visited."

Andy


On 13 August 2013 20:31, Patrick Meenan <pmeenan@webpagetest.org> wrote:

> I'll do a bunch of testing to see if I can find a way it could leak state
> but as best as I can tell you can't toggle visibility based on visited
> state (at least in Chrome) so the paint information should be the same for
> visited/not links.  The paint information is also too broad to provide a
> timing-based attack (I'll need to check and see if we post-process the
> history and change the color after initial paint but at least in my initial
> testing it looks like we have the state on the initial paint).  The paint
> events we're looking to expose are aggregated rects that cover the whole
> area that changed, not when every element gets changed so that may be part
> of it.  If there's another vector in there that I'm not thinking about I'd
> love pointers.
>
> Thanks,
>
> -Pat
>
>
> On 8/13/2013 2:40 PM, Jonas Sicking wrote:
>
>> Gecko used to have something similar. One problem that was hard to
>> solve was avoiding when :visited links were matched. I.e. avoiding
>> enabling history sniffing.
>>
>> / Jonas
>>
>> On Tue, Aug 13, 2013 at 10:14 AM, Patrick Meenan
>> <pmeenan@webpagetest.org> wrote:
>>
>>> I'm working on exposing Chrome's paint events to the DOM so that sites
>>> can
>>> report visual metrics back as part of their RUM.  I know there is a lot
>>> of
>>> controversy around paint events but it would be great if we could at
>>> least
>>> define how they could be exposed should a browser vendor decide to expose
>>> them.
>>>
>>> I can write up a full proposal in the formal template but I wanted to
>>> throw
>>> out a straw-man that basically mimics the behavior of the resource timing
>>> interface.
>>>
>>> - The paint events will consist of a rectangle (left, top, width, height)
>>> and a DOMHighResTimeStamp relative to the start of navigation
>>>
>>> - The array of events would be fetched through
>>> window.performance.**getPaintEvents()
>>>
>>> - The number of events to be tracked can be set by
>>> window.performance.**setPaintEventsBufferSize(#of events) and defaults
>>> to
>>> something reasonable given the events are quite small (actual numbers TBD
>>> but 1500 as an initial default would not be unreasonable)
>>>
>>> - The accumulated paint events can be cleared by calling
>>> window.performance.**clearPaintEvents()
>>>
>>> - An event (onpainteventsbufferfull) will fire when the buffer is full
>>> (TBD,
>>> should this be a rolling window and always drop from the head instead of
>>> failing to insert?)
>>>
>>> - The paint events will be bound to the document that they belong to
>>> (paint
>>> events for frames are tied to that specific frame).  Otherwise there
>>> will be
>>> all sorts of opportunity for privacy leakage (embedding an iFrame to a
>>> bank
>>> page and watching where it paints for example).
>>>
>>> A couple of other nice-to-have's:
>>> - Standardize a firstPaint attribute on the Navigation Timing interface
>>> - Standardize a bodyStarted attribute on the Navigation Timing interface
>>> (technically easy to capture in js anyway but I'm planning on filtering
>>> out
>>> all of the bogus paint events before the browser hits the body and
>>> thought
>>> it might be useful for RUM to get for free)
>>> - Provide an interface for helper calculations (I'm planning for a simple
>>> way to get SpeedIndex without everyone having to implement the algorithm
>>> against the raw paint rects for example)
>>>
>>> I know that browsers can't necessarily expose the exact time when pixels
>>> hit
>>> the screen because they pay offload a lot of that to hardware but the
>>> plan
>>> is to get as close to that as possible.  In the case of Chrome there
>>> could
>>> be a difference of 10's to 100's of ms between when blink passes a rect
>>> off
>>> to be rendered and when it hits the screen but the information available
>>> from blink is still worth exposing (and matches what you get in the dev
>>> tools when you show paint rects and in the timeline).
>>>
>>> Thanks,
>>>
>>> -Pat
>>>
>>
>
>