[minutes] 20150603 Web Performance

Available at
  http://www.w3.org/2015/06/03-webperf-minutes.html


                             Web Performance

03 Jun 2015

Attendees

    Present
           Ilya, Yoav, Michael, NicJ, Todd, Plh

    Regrets

    Chair
           Ilya

    Scribe
           yoav

Contents

      * [2]Topics
          1. [3]When are new entries delivered to observer?
          2. [4]Timing attacks
          3. [5]Extend getEntries to allow attribute filtering
          4. [6]workerStart
          5. [7]secureConnectionStart should account for non-HTTPS
             secure transports
          6. [8]Make secureConnectionStart a mandatory attribute
          7. [9]What value should secureConnectionStart have when
             using preexisting connection?
      * [10]Summary of Action Items
      __________________________________________________________

    Ilya: registry discussion

    <Ilya> [11]Is there a plan to add content type (e.g webp) and
    content length in the performance resource timing records?

      [11] https://twitter.com/annevk/status/605503229292453889

When are new entries delivered to observer?

    NicJ: Soasta are interested in getting an event when resource
    timing entry has started

    Todd: that may have privacy implications for third party
    content

    Todd/Ilya: Although it may be privacy implications, we already
    reveal duration for TOR.

    yoav: You'd get TAO headers after the event started, so that's
    an issue

    <plh> [12]When are new entries delivered to observer?

      [12] https://github.com/w3c/performance-timeline/issues/13

    Ilya: We'll followup on GH with an issue with use-cases, and
    look into the fetch registry

Timing attacks

    <plh> [13]Timing attacks

      [13] https://github.com/w3c/hr-time/issues/4

    plh: Did you guys talk to your security teams?

    Todd: timing attack come out quite often and require a lot of
    effort
    ... They're usually very difficult since they're related to
    specific HW and SW

    so difficult to use en masse

    Ilya: one of the security folks is in touch with that team and
    has a dialog with them
    ... perhaps we should acknowledge that in the spec, but it's
    not clear we should change the precision of the timer

    Todd: As long as we didn'tprove there's a real attack here, the
    timer shouldn't change
    ... "real attack" == "without controlling the HW"

    Ilya: should we reference that in the spec?

    Todd: I don't know if we should reference it

    <plh> [14]HRT Privacy and Security

      [14] http://w3c.github.io/hr-time/#sec-privacy-security

    plh: HR time does reference the subject in general

    Ilya: Maybe this section is enough

    plh: we can close the issue for now, and see if there's further
    information later on

    Todd: I'll take care of it and reply on the list

Extend getEntries to allow attribute filtering

    <plh> [15]getEntries

      [15] 
https://github.com/w3c/performance-timeline/pull/11#issuecomment-107695115

    Ilya: Most of the attributes are timestamps, and getting
    entries based on them makes little sense

    plh: It would make sense to group based on initiatorType

    Ilya: we would also have fetchID that we would be able to
    filter by, which would also apply to server timing

    <scribe> ACTION: Ilya to update PR to use a type dictionary and
    mail the list for feedback before landing

workerStart

    <plh> [16]Clarify "zero time" in Workers

      [16] https://github.com/w3c/resource-timing/issues/23

    <Ilya> [17]rough proposal

      [17] 
https://lists.w3.org/Archives/Public/public-web-perf/2015Jun/0019.html

    Ilya: There's a proposal to move the start time to the time
    that the worker was first referenced from the page
    ... so that the workerStart for the same sharedWorker would be
    different for different referencing pages
    ... would appreciate some more feedback and more eyes on this

secureConnectionStart should account for non-HTTPS secure transports

    Todd: Next item issue 14 - Resource timing should also account
    for secure non-HTTPS

    <Todd> [18]secureConnectionStart should account for non-HTTPS
    secure transports

      [18] https://github.com/w3c/resource-timing/issues/14

    <Todd> [19]Convert HTTPS to secure transport to ensure it is
    recorded for secure transport

      [19] https://github.com/w3c/resource-timing/issues/15

    Todd: Reworded the spec to account for that
    ... so we can close the issue

Make secureConnectionStart a mandatory attribute

    <Todd> [20]Make secureConnectionStart a mandatory attribute

      [20] https://github.com/w3c/resource-timing/issues/16

    Ilya: Any objections to making this attribute mandatory?

    plh: no objections from me

    yoav: no objections from me

What value should secureConnectionStart have when using preexisting
connection?

    <Todd> [21]What value should secureConnectionStart have when
    using preexisting connection?

      [21] https://github.com/w3c/resource-timing/issues/17

    Todd: ConnectionStart says this: If a persistent connection
    [RFC7230] is used or the resource is retrieved from relevant
    application caches or local resources, this attribute MUST
    return value of domainLookupEnd.
    ... We could use the same language for secureConnectionStart.
    I'll take that upon myself

Summary of Action Items

    [NEW] ACTION: Ilya to update PR to use a type dictionary and
    mail the list for feedback before landing

    [End of minutes]

Received on Thursday, 4 June 2015 13:10:12 UTC