Intent to implement: Frame Timing API

105 views
Skip to first unread message

Hiroyuki Ikezoe

unread,
Apr 27, 2015, 5:28:23 AM4/27/15
to dev-pl...@lists.mozilla.org
Summary: Provides an interface for receiving frame performance timing
including composites happening on a separate thread/process. This can
be used to calculate measures of smoothness that incorporate the
effect of async pan and zoom and off-main thread animation.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1158032

Link to standard: https://w3c.github.io/frame-timing/

Platform coverage: all platforms

Estimated or target release: Firefox 43 although we might hold off
shipping depending on the state of the spec at that time (there has
been discussion of replacing the buffer-based interface with an
observer interface).

Preference behind which this will be implemented: dom.enable_frame_timing

DevTools bug: No specific bug yet but the DevTools team is aware of
our intention to implement and indicated they could use this API.

Other browser support: Blink: in development, soon to reach Canary.[1]

[1] https://code.google.com/p/chromium/issues/detail?id=120796#c53

Thanks,

hiro

Jonas Sicking

unread,
Apr 27, 2015, 9:44:35 PM4/27/15
to Hiroyuki Ikezoe, dev-platform
Please make sure to do a security review so that this doesn't expose
any sensitive information accidentally. In particular, is there any
way to use this API to use :visited hacks along with timing
information to see if a user has visited a particular URL?

/ Jonas
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Brian Birtles

unread,
Apr 28, 2015, 1:39:04 AM4/28/15
to dev-pl...@lists.mozilla.org, Jonas Sicking
On 2015/04/28 10:43, Jonas Sicking wrote:
> Please make sure to do a security review so that this doesn't expose
> any sensitive information accidentally. In particular, is there any
> way to use this API to use :visited hacks along with timing
> information to see if a user has visited a particular URL?

I think we're ok since :visited only affects colors which shouldn't
affect render or composite times? Is there someone we should loop in who
can give a more informed appraisal?

Ehsan Akhgari

unread,
May 11, 2015, 3:32:55 PM5/11/15
to Brian Birtles, dev-pl...@lists.mozilla.org, Jonas Sicking
On 2015-04-28 1:38 AM, Brian Birtles wrote:
> On 2015/04/28 10:43, Jonas Sicking wrote:
>> Please make sure to do a security review so that this doesn't expose
>> any sensitive information accidentally. In particular, is there any
>> way to use this API to use :visited hacks along with timing
>> information to see if a user has visited a particular URL?
>
> I think we're ok since :visited only affects colors which shouldn't
> affect render or composite times? Is there someone we should loop in who
> can give a more informed appraisal?

You can have style like:

<a href="...">some content that is expensive to paint/composite</a>

and then have;

a {
display: none;
}

a:visited {
display: inline;
}

And then time the painting/compositing of the said content. However, I
believe this timing side channel already exists in Gecko. Please double
check with the security team.

Boris Zbarsky

unread,
May 11, 2015, 3:58:13 PM5/11/15
to
On 5/11/15 3:32 PM, Ehsan Akhgari wrote:
> You can have style like:
>
> <a href="...">some content that is expensive to paint/composite</a>
>
> and then have;
>
> a {
> display: none;
> }
>
> a:visited {
> display: inline;
> }
>
> And then time the painting/compositing of the said content.

No, you can't. We explicitly forbid that, precisely because of
side-channel timing attacks. dbaron has a good writeup about how the
:visited mitigation works at http://dbaron.org/mozilla/visited-privacy
but the upshot is that in the above testcase the <a> will be
display:none whether it's visited or not.

-Boris

Ilya Grigorik

unread,
May 11, 2015, 7:04:24 PM5/11/15
to Boris Zbarsky, dev-platform
FWIW, we have a tracking issue for this on GH:
https://github.com/w3c/frame-timing/issues/40

On Mon, May 11, 2015 at 12:58 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> No, you can't. We explicitly forbid that, precisely because of
> side-channel timing attacks. dbaron has a good writeup about how the
> :visited mitigation works at http://dbaron.org/mozilla/visited-privacy
> but the upshot is that in the above testcase the <a> will be display:none
> whether it's visited or not.
>

Boris, any chance you can also take a look at scenario in:
https://github.com/w3c/frame-timing/issues/40#issuecomment-97888895

Thanks!
ig

Brian Birtles

unread,
May 11, 2015, 7:10:06 PM5/11/15
to dev-pl...@lists.mozilla.org
On 2015/05/12 4:58, Boris Zbarsky wrote:
> On 5/11/15 3:32 PM, Ehsan Akhgari wrote:
>> You can have style like:
>> ...
>> And then time the painting/compositing of the said content.
>
> No, you can't. We explicitly forbid that, precisely because of
> side-channel timing attacks. dbaron has a good writeup about how the
> :visited mitigation works at http://dbaron.org/mozilla/visited-privacy
> but the upshot is that in the above testcase the <a> will be
> display:none whether it's visited or not.

There does appear to be at least one possible attack vector which
involves detecting if a PerformanceRenderTiming event is fired or not
within a certain time window after changing a link's URL.

Mitigation is being discussed here:

https://github.com/w3c/frame-timing/issues/40#issuecomment-97888895

Best regards,

Brian

Boris Zbarsky

unread,
May 12, 2015, 12:02:29 AM5/12/15
to
On 5/11/15 7:03 PM, Ilya Grigorik wrote:
> Boris, any chance you can also take a look at scenario in:
> https://github.com/w3c/frame-timing/issues/40#issuecomment-97888895

For the situation described there, it seems like the right mitigation,
conceptually, is to repaint the link when the href changes regardless of
whether it's visited, no? Otherwise you have a timing attack available
even without frame timing: just make the repaint expensive and see if
you end up delaying timers too much or not.

-Boris

Paul Rouget

unread,
May 12, 2015, 12:50:25 AM5/12/15
to dev-platform
DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1163901
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform



--
Paul
Reply all
Reply to author
Forward
0 new messages