Ilya: registry discussion
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> When are new entries delivered to observer?
Ilya: We'll followup on GH with an issue with use-cases, and look into the fetch registry
<plh> Timing attacks
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> HRT Privacy and 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
<plh> getEntries
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
<plh> Clarify "zero time" in Workers
<Ilya> rough proposal
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
Todd: Next item issue 14 - Resource timing should also account for secure non-HTTPS
<Todd> secureConnectionStart should account for non-HTTPS secure transports
<Todd> Convert HTTPS to secure transport to ensure it is recorded for secure transport
Todd: Reworded the spec to account for that
... so we can close the issue
<Todd> Make secureConnectionStart a mandatory attribute
Ilya: Any objections to making this attribute mandatory?
plh: no objections from me
yoav: no objections from me
<Todd> What value should secureConnectionStart have when using preexisting connection?
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