Re: [whatwg] Proposal: Event.creationTime
On Thu, May 8, 2014 at 2:33 AM, Brian Birtles wrote: > (2014/05/08 0:49), Glenn Maynard wrote: > >> Can you remind me why this shouldn't just use real time, eg. using the >> Unix >> epoch as the time base? It was some privacy concern, but I can't think of >> any privacy argument for giving high-resolution event timestamps in units >> that are this limited and awkward. >> > > [1] has some justification for why we don't use 1970. As does [2]. > I'm not sure what the privacy concerns raised in the past were with > regards to 1970. > Okay, I remember. It's not that using the epoch here is itself a privacy issue, it's that the solutions to the monotonicity problem introduce privacy issues: if you add a global base time that isn't per-origin, that's a tracking vector. Maybe a solution would be to make DOMHighResTimeStamp structured clonable (or a wrapper class, since the type itself is just double). If you post a timestamp to another thread, it arrives in that thread's own time base. That way, each thread can always calculate precise deltas between two timestamps, without exposing the actual time base. (You still can't send it to a server, but that's an inherent problem for a timer on a monotonic clock.) If you treat Date.now() as your global clock, you can roughly convert > between different performance timelines but with the caveat that you lose > precision and are vulnerable to system clock adjustments. (There is > actually a method defined for converting between timelines in Web > Animations but the plan is to remove it.) > That would defeat the purpose of using high-resolution timers in the first place. -- Glenn Maynard
Re: [whatwg] Proposal: Event.creationTime
(2014/05/08 0:49), Glenn Maynard wrote: Can you remind me why this shouldn't just use real time, eg. using the Unix epoch as the time base? It was some privacy concern, but I can't think of any privacy argument for giving high-resolution event timestamps in units that are this limited and awkward. [1] has some justification for why we don't use 1970. As does [2]. I'm not sure what the privacy concerns raised in the past were with regards to 1970. If you treat Date.now() as your global clock, you can roughly convert between different performance timelines but with the caveat that you lose precision and are vulnerable to system clock adjustments. (There is actually a method defined for converting between timelines in Web Animations but the plan is to remove it.) Best regards, Brian [1] https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html#introduction [2] http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0031.html [3] https://bugzilla.mozilla.org/show_bug.cgi?id=579652#c2
Re: [whatwg] Proposal: Event.creationTime
On Wed, May 7, 2014 at 10:08 AM, Boris Zbarsky wrote: > On 5/7/14, 6:43 AM, Anne van Kesteren wrote: > >> Is there a good reference somewhere for what the time would be relative >> to? >> > > https://w3c.github.io/web-performance/specs/HighResolutionTime2/Overview. > html#sec-time-origin seems like the right thing. > This seems to make it impossible to get the time of an event in real time, so you can compare it to external events or send it to shared workers. Can you remind me why this shouldn't just use real time, eg. using the Unix epoch as the time base? It was some privacy concern, but I can't think of any privacy argument for giving high-resolution event timestamps in units that are this limited and awkward. -- Glenn Maynard
Re: [whatwg] Proposal: Event.creationTime
On Wed, May 7, 2014 at 4:34 PM, Adam Barth wrote: > It seems worth experimenting with. If the experiment fails, we can try > another approach. Fair enough, once it succeeds I'll update the specification. -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Event.creationTime
On Wed, May 7, 2014 at 3:43 AM, Anne van Kesteren wrote: > On Wed, May 7, 2014 at 7:00 AM, Adam Barth wrote: > > Can we just change timeStamp to be a DOMHighResTimeStamp rather than > > introducing a redundant property? > > http://lists.w3.org/Archives/Public/www-dom/2012OctDec/thread.html#msg8 > is the previous thread on this topic. In that thread bz pointed out > that changing Date.now() to return sub-milliseconds as an experiment > failed. > > If people want to do the experiment for Event.prototype.timeStamp I'd > be happy with that. > It seems worth experimenting with. If the experiment fails, we can try another approach. Adam Is there a good reference somewhere for what the time would be relative to? > > (I previously had a problem with doing this in DOM as it would depend > on page load time which is defined by HTML, but I have since accepted > that HTML and DOM are intertwined.) > > > -- > http://annevankesteren.nl/ >
Re: [whatwg] Proposal: Event.creationTime
On 5/7/14, 6:43 AM, Anne van Kesteren wrote: Is there a good reference somewhere for what the time would be relative to? https://w3c.github.io/web-performance/specs/HighResolutionTime2/Overview.html#sec-time-origin seems like the right thing. -Boris
Re: [whatwg] Proposal: Event.creationTime
On Wed, May 7, 2014 at 7:00 AM, Adam Barth wrote: > Can we just change timeStamp to be a DOMHighResTimeStamp rather than > introducing a redundant property? http://lists.w3.org/Archives/Public/www-dom/2012OctDec/thread.html#msg8 is the previous thread on this topic. In that thread bz pointed out that changing Date.now() to return sub-milliseconds as an experiment failed. If people want to do the experiment for Event.prototype.timeStamp I'd be happy with that. Is there a good reference somewhere for what the time would be relative to? (I previously had a problem with doing this in DOM as it would depend on page load time which is defined by HTML, but I have since accepted that HTML and DOM are intertwined.) -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Event.creationTime
On Tuesday 2014-05-06 23:00 -0700, Adam Barth wrote: > Can we just change timeStamp to be a DOMHighResTimeStamp rather than > introducing a redundant property? I'd certainly be happy to see such a change; I argued that Event.timeStamp be based on a monotonic clock previously, in: http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0071.html http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0098.html I'm not sure if there would be compatibility problems from changing from "unsigned long long" [1] to "double" [2], though. The type change seems like the biggest compatibility risk in content that works today across browsers, given that browsers on whether the time is epoch-based or monotonic. I don't have any data on how or how often Event.timeStamp is used, though. -David [1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-DOMTimeStamp [2] http://www.w3.org/TR/hr-time/#sec-DOMHighResTimeStamp -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] Proposal: Event.creationTime
On 5/7/14, 1:51 AM, Brian Birtles wrote: This time is measured from navigationStart It's probably better to say that it's measured from the same 0 point as performance.now(), since there is no navigationStart in workers but there are events there. -Boris
Re: [whatwg] Proposal: Event.creationTime
Can we just change timeStamp to be a DOMHighResTimeStamp rather than
introducing a redundant property?
Adam
On Tue, May 6, 2014 at 10:51 PM, Brian Birtles wrote:
> Hi,
>
> Gecko's implementation of Event.timeStamp does not conform to the spec[1]
> since it reports the number of milliseconds since system start rather than
> 00:00:00 UTC on 1 January 1970. This is tracked as Mozilla bug 77992 [2].
> DOM Level 2 allowed this[3] but the spec has since changed.
>
> One reason for not updating to match the spec has been concern about using
> a non-monotonic clock as a time source. This can lead to bugs when the
> system clock is adjusted.
>
> Now that we have a DOMHighResTimeStamp that provides a monotonically
> increasing time, I propose we add it to the Event interface.[4]
>
> This time is measured from navigationStart which removes some of the
> security concerns raised regarding using system start.[5] navigationStart
> is also the point of reference being using for Performance.now(),
> requestAnimationFrame and Web Animations.
>
> As for use cases for event timestamps, apparently Youtube uses the
> timeStamp on progress events to estimate download bandwidth. Another use
> case is that of SMIL which seems to want to overload the timestamp from
> being strictly creation time to when the event *should* have been created
> in order to avoid synchronization slew.[6]
>
> Proposal:
>
> partial interface Event {
> readonly attribute DOMHighResTimeStamp creationTime;
> };
>
> (Alternative naming suggestions are obviously most welcome.)
>
> Semantics are as with 'timeStamp' but based on navigationStart.
>
> Given that 'timeStamp' is currently implemented inconsistently, it might
> be possible to eventually deprecate it.
>
> Best regards,
>
> Brian
>
> [1] http://dom.spec.whatwg.org/#dom-event-timestamp
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=77992
> [3] http://www.w3.org/TR/DOM-Level-2-Events/events.html#
> Events-Event-timeStamp
> [4] http://www.w3.org/TR/hr-time/
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=579652#c2
> [6] http://www.w3.org/TR/SMIL/smil-timing.html#q135
>
