Intent to implement: Frame Timing API

[Hiroyuki Ikezoe]

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]

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]

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]

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]

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]

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]

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]

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]

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