Intent to implement: Frames timing functions

[Boris Chiou]

*Summary*:
A frames timing function is a type of timing function that divides the
input time into a specified number of intervals of equal length, each of
which is associated with an output progress value of increasing value. The
difference between a frames timing function and a step timing function is
that a frames timing function returns the output progress value 0 and 1 for
an equal portion of the input progress value in the range [0, 1]. This
makes it suitable for using in animation loops where the animation should
display the first and last frame of the animation for an equal amount of
times as each other frame during each loop.

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

*Link to standard*: FPWD:
https://www.w3.org/TR/css-timing-1/#frames-timing-functions

*Platform coverage*: All platform.

*Estimated or target release*: Not yet determined.

*Preference behind which this will be implemented*: I'm not sure. I think
we don't need it because it is just a variant of the step timing function,
and so it is safe to turn it on. If there is any other concerns, I can add
a preference for this.

*DevTools bug*: Not sure.

*Do other browser engines implement this?* No

*Tests* - web-platform/tests/timing-functions/frames-timing-functions

[Jeff Muizelaar]

The linked bug suggests that Chrome implements this but this email suggests
it doesn't. What's the truth?

-Jeff

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

[Brian Birtles]

On Fri, Feb 24, 2017 at 12:35 AM, Jeff Muizelaar <jmuiz...@mozilla.com> wrote:
> The linked bug suggests that Chrome implements this but this email suggests
> it doesn't. What's the truth?

There used to be a steps-middle timing function which is what the
linked bug originally covered. Chrome implemented it and shipped it
(but exposed it only to the Web Animations API, I believe). We
implemented it in that bug, but before we shipped it the standards
discussion progressed and revealed that steps-middle didn't really
solve the problem authors were facing, and as a result we decided on
creating a frames() timing function instead.

I spoke with Chrome engineers in January this year and they wanted to
remove steps-middle but were reluctant to do so without providing a
replacement. That's why I went ahead and specced frames() (and dropped
steps-middle at the same time). In Bugzilla we just morphed the
steps-middle bug into the frames() bug, hence the confusion.

[tri...@mozilla.com]

On Thursday, February 23, 2017 at 9:09:58 AM UTC-6, Boris Chiou wrote:
> *Preference behind which this will be implemented*: I'm not sure. I think
> we don't need it because it is just a variant of the step timing function,
> and so it is safe to turn it on. If there is any other concerns, I can add
> a preference for this.

Given our (and all browsers') painful history with people finding novel ways to bypass security by abusing any and all timers we expose, I would feel much better if this had a pref.

-tom

[Brian Birtles]

As Boris mentioned, adding a pref is no problem, but I'm curious to
learn about the specific security concern here. This doesn't expose
any new timing information. It's just a variation on the steps timing
function. Perhaps the 'frames' name suggests something about exposing
the browser's animation frames, but there's no connection between
frames() and actual animation frames in the browser.

[Boris Chiou]

OK, sure. I will add a pref to protect it. Thanks for suggestion.

[Tom Ritter]

On Sun, Feb 26, 2017 at 5:12 PM, Brian Birtles <bbir...@mozilla.com> wrote:
> On Sat, Feb 25, 2017 at 1:09 AM, <tri...@mozilla.com> wrote:

> As Boris mentioned, adding a pref is no problem, but I'm curious to
> learn about the specific security concern here. This doesn't expose
> any new timing information. It's just a variation on the steps timing
> function. Perhaps the 'frames' name suggests something about exposing
> the browser's animation frames, but there's no connection between
> frames() and actual animation frames in the browser.

Sure. I would not characterize the security concern as "This new thing
might be dangerous but the old thing isn't" but rather "All of these
things might be dangerous, but Boris is only talking about one of them
so I only mentioned one of them." I'd be overjoyed if we added a pref
for the old stuff too! =)

If the engineering effort to add a pref is particularly burdensome,
I'm sure I or someone else in Security could perform a deep-dive, but
if it's not then yea.

(And if there _is_ a pref that disables _all_ related animation timing
that this new feature would be covered by, then I'd suggest that this
existing pref may be sufficient _unless_ you feel it would be overly
painful to hypothetically disable N features when only 1 of them might
be a source of concern.)

In general, anything that aids someone in performing timing
measurements is concerning, because fine-grained timing measurements
enable cache attacks which can enable history disclosure, activity
disclosure, or even crypto key disclosure. In animation's particular
area - I could imagine an attack that measures an animation's movement
to get a higher resolution timer than one that may be exposed
otherwise. (I know there's the High Res API, but consider if it were
disabled. Plus in general, I think we should avoid arguments that go
"X isn't as bad as Y so we shouldn't care about X" ). Anyway, there
are probably a couple reasons why my example isn't feasible, but as I
mentioned this isn't a deep dive, and I get the impression that the
pref isn't burdensome.

HTH,
-tom