Intent to Ship: User Timing L3

[n...@chromium.org]

Contact emails

ma...@chromium.org, n...@chromium.org, tdre...@chromium.org

Explainer

https://docs.google.com/document/d/1hltt8z9C4PaI5Qu1YMIp1wOGdbJPJPoJwBarEeCY6xQ/edit

Spec

https://w3c.github.io/user-timing/

We’re skipping TAG review because we’re only adding additional support for arbitrary timestamps and metadata.

Summary

UserTiming allows developers to annotate the performance of their website via marks() and to measure key events via measure(). With User Timing Level 2, a developer can only mark the current point in time, which makes it impossible to mark retroactively. User Timing L3 fixes this problem by allowing mark() and measure() using arbitrary timestamps, and it also allows developers to annotate by having a ‘detail’ field where they can store metadata.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/intent$20to$20ship$20user$20timing|sort:date/blink-dev/T-DgYf79sFU/RxDZXCc-AwAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Risks

Interoperability and Compatibility

We discussed this in the Web Perf WG. We addressed some feedback and there was no opposition to us shipping.

Edge: Positive https://github.com/w3c/user-timing/issues/43#issuecomment-435926092

Firefox: No signals (but was present in calls where we presented)

Safari: No signals (but was present in calls where we presented)

Web developers: positive, as this increases the flexibility of User Timing.

Ergonomics

No concerns here.

Activation

No challenge.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

There are 4 tests that test User Timing L3 behavior in https://github.com/web-platform-tests/wpt/tree/master/user-timing

Entry on the feature dashboard

https://www.chromestatus.com/feature/5149401886490624

[Boris Zbarsky]

On 4/3/19 4:28 PM, n...@chromium.org wrote:
> We’re skipping TAG review because we’re only adding additional support
> for arbitrary timestamps and metadata.

I have a few concerns about the details of this API as currently present
in the spec. In order of importance to me:

1) I'm a little confused by the invalid IDL in the spec. The spec has:

PerformanceMeasure measure(DOMString measureName, optional
(DOMString or PerformanceMeasureOptions)? startOrMeasureOptions,
optional DOMString endMark);

That second argument type is not allowed per IDL.
https://heycam.github.io/webidl/#idl-nullable-type says:

The inner type must not be
...
a union type that itself includes a nullable type or has a
dictionary type as one of its flattened member types.

What processing model does Blink actually implement here when null is
passed? I can't tell what the spec expects to happen here, because IDL
literally does not allow this syntax and does not define a processing
model for it. The behavior before this spec change was to look for the
mark named "null", as far as I can tell, right? (Note that I tried just
testing the behavior myself, but this change does not seem to be enabled
by default in Chrome 75 dev yet.)

I'm a little worried that Blink's IDL parser accepted the invalid IDL.
:( Is there a known Blink issue tracking that?

2) The new spec algorithms are using
https://heycam.github.io/webidl/#syntaxerror for invalid input of
various sorts. The Web IDL spec says that this should be reserved for
errors parsing text input. The normal error type to use for "your
arguments are invalid" is
<https://heycam.github.io/webidl/#exceptiondef-typeerror>. Is there a
reason a SyntaxError DOMException is used here instead?

3) Is there a reason that detail defaults to null instead of defaulting
to undefined? I know that's what CustomEvent does, but that was because
specification of CustomEvent postdated implementation and
implementations happened back when UAs didn't really have good ways of
representing undefined in APIs as far as I can tell.

-Boris

[Tom Jones]

While it is hard to tell from the details on this threat - it appears that there is a severe security exploit opened. This is known as a side-channel, or timing attack where the attacker asks for the time immediately before and after a decryption or signing event. Enough of these timings can expose the value of the private key. There are ways around this that could have been included in the full spec. If i knew where to find the full implementation, including the security considerations, i would be able to tell.

Peace ..tom

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/51e9c118-ca12-4bbb-aa4b-4c66f07bfe12%40chromium.org.

[Boris Zbarsky]

On 4/3/19 5:14 PM, Boris Zbarsky wrote:
> 1) I'm a little confused by the invalid IDL in the spec.  The spec has:
>
>     PerformanceMeasure measure(DOMString measureName, optional
> (DOMString or PerformanceMeasureOptions)? startOrMeasureOptions,
> optional DOMString endMark);

One other major issue here that I noticed while going back over this
today. Per Web IDL:

If the type of an argument is a dictionary type or a union
type that has a dictionary as one of its flattened member
types, and that dictionary type and its ancestors have no
required members, and the argument is either the final
argument or is followed only by optional arguments, then the
argument must be specified as optional. Such arguments are
always considered to have a default value of an empty
dictionary, unless otherwise specified.

This means that the startOrMeasureOptions argument is always present,
and the algorithm steps that say "If startOrMeasureOptions is present"
are a little confused.

This also means that the spec as currently written makes a
single-argument measure() call throw, because that leads to
startOrMeasureOptions being an empty dictionary, which throws in
https://www.w3.org/TR/user-timing-3/#dom-performance-measure step 2.
That doesn't seem desirable...

-Boris

[Nicolás Peña]

I’ll update this thread once the concerns have been resolved.

On Wed, Apr 3, 2019 at 5:14 PM Boris Zbarsky <bzba...@mit.edu> wrote:

On 4/3/19 4:28 PM, n...@chromium.org wrote:
> We’re skipping TAG review because we’re only adding additional support
> for arbitrary timestamps and metadata.

I have a few concerns about the details of this API as currently present
in the spec.  In order of importance to me:

Thanks for the feedback, it's very helpful. Consider monitoring the corresponding GitHub repos or joining the Web Perf WG calls where this API has been discussed :)

 

1) I'm a little confused by the invalid IDL in the spec.  The spec has:

     PerformanceMeasure measure(DOMString measureName, optional
(DOMString or PerformanceMeasureOptions)? startOrMeasureOptions,
optional DOMString endMark);

That second argument type is not allowed per IDL.
https://heycam.github.io/webidl/#idl-nullable-type says:

    The inner type must not be
    ...
    a union type that itself includes a nullable type or has a
dictionary type as one of its flattened member types.

This was originally not nullable but changed due to https://github.com/w3c/user-timing/issues/48. I think this should be easy to resolve. I've filed https://github.com/w3c/user-timing/issues/54.

 

What processing model does Blink actually implement here when null is
passed? 

It seems we're currently treating null as undefined right now (more discussion at the GitHub issue).

 

I can't tell what the spec expects to happen here, because IDL
literally does not allow this syntax and does not define a processing
model for it.  The behavior before this spec change was to look for the
mark named "null", as far as I can tell, right?  (Note that I tried just
testing the behavior myself, but this change does not seem to be enabled
by default in Chrome 75 dev yet.)

Replied on GitHub issue.

 

I'm a little worried that Blink's IDL parser accepted the invalid IDL.
:(  Is there a known Blink issue tracking that?

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=949672

 

2) The new spec algorithms are using
https://heycam.github.io/webidl/#syntaxerror for invalid input of
various sorts.  The Web IDL spec says that this should be reserved for
errors parsing text input.  The normal error type to use for "your
arguments are invalid" is
<https://heycam.github.io/webidl/#exceptiondef-typeerror>.  Is there a
reason a SyntaxError DOMException is used here instead?

I'm happy to change it to a more appropriate error, filed https://github.com/w3c/user-timing/issues/55.

 

3) Is there a reason that detail defaults to null instead of defaulting
to undefined?  I know that's what CustomEvent does, but that was because
specification of CustomEvent postdated implementation and
implementations happened back when UAs didn't really have good ways of
representing undefined in APIs as far as I can tell.

I don't know, it was added at some point to the explainer and I didn't bother to ask why. Is there an advantage of null over undefined here?  I’ll change the spec to remove the null default.

Regarding your additional comment:

"This also means that the spec as currently written makes a 

single-argument measure() call throw, because that leads to 

startOrMeasureOptions being an empty dictionary, which throws in 

https://www.w3.org/TR/user-timing-3/#dom-performance-measure step 2. 

That doesn't seem desirable..."

I'll change the wording to be more precise, as discussed in the GitHub issue.

On Wed, Apr 3, 2019 at 5:18 PM Tom Jones <thomascli...@gmail.com> wrote:

While it is hard to tell from the details on this threat - it appears that there is a severe security exploit opened. This is known as a side-channel, or timing attack where the attacker asks for the time immediately before and after a decryption or signing event. Enough of these timings can expose the value of the private key. There are ways around this that could have been included in the full spec. If i knew where to find the full implementation, including the security considerations, i would be able to tell.

Peace ..tom

The granularity of time used is the same as performance.now, so you can look at the section in HR Time https://w3c.github.io/hr-time/#sec-privacy-security 

[Boris Zbarsky]

On 4/4/19 5:49 PM, Nicolás Peña wrote:
> This was originally not nullable but changed due to
> https://github.com/w3c/user-timing/issues/48. I think this should be
> easy to resolve. I've filed https://github.com/w3c/user-timing/issues/54.

Thank you.

> Filed https://bugs.chromium.org/p/chromium/issues/detail?id=949672

Again, thank you.

> I'm happy to change it to a more appropriate error, filed
> https://github.com/w3c/user-timing/issues/55.

Lovely.

> I don't know, it was added at some point to the explainer and I didn't
> bother to ask why. Is there an advantage of null over undefined
> here?

I don't think there is one, honestly. But I also don't feel too
strongly about this, so if people feel defaulting to null is better, I
can live with it too.

-Boris

[Joe Medley]

Nicolás,

Do you have a tracking bug for this?

Thanks,

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

On Wed, Apr 3, 2019 at 1:28 PM <n...@chromium.org> wrote:

[n...@chromium.org]

https://crbug.com/758385 is the tracking bug.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[n...@chromium.org]

The concerns have been addressed by https://github.com/w3c/user-timing/pull/57 so now I'd like to request API_OWNER approvals for shipping.

[Chris Harrelson]

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/51e9c118-ca12-4bbb-aa4b-4c66f07bfe12%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a01fe005-2685-440b-93cc-4e9b65f67e5e%40chromium.org.

[bratell]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-rExRKv2Hc6YL10rN6aovVbXR8xgE0FpZqzaK%2BG5XQBg%40mail.gmail.com.

[Boris Zbarsky]

On 4/25/19 11:25 AM, n...@chromium.org wrote:
> The concerns have been addressed by
> https://github.com/w3c/user-timing/pull/57

I'd just like to say thank you for dealing with those concerns. It's
very much appreciated!

-Boris

[Alex Russell]

LGTM3, but would like to note that the rationale for skipping TAG review is not reasonable. It's only because Boris caught major issues with the design that I feel comfortable approving.