Latest editor draft: https://w3c.github.io/hr-time/ HR-Time-3 introduced this attribute, which is useful for developers to be able to compare timings of entries sourced from different time origins (like windows or workers). It has already been implemented in Firefox, Edge has it in Preview, and will also be shipped by Chrome[1]. [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ck9M6Ev21lo
<rdar://problem/33575468>
Created attachment 430926 [details] patch
Comment on attachment 430926 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=430926&action=review > Source/WebCore/page/Performance.h:78 > + DOMHighResTimeStamp timeOrigin() const; Is this time origin varied across origins? Otherwise, it can create cross-origin tracking vector, right?
Comment on attachment 430926 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=430926&action=review >> Source/WebCore/page/Performance.h:78 >> + DOMHighResTimeStamp timeOrigin() const; > > Is this time origin varied across origins? > Otherwise, it can create cross-origin tracking vector, right? This time stamp is in milliseconds since 1970, so it doesn't identify the user that way. The value is from the time the DocumentLoader started loading the Document (seen in DOMWindow::performance) or the time that the Worker was created (seen in WorkerGlobalScope::WorkerGlobalScope) which should not lead to a tracking vector. This value is already indirectly exposed through Performance::now, which is the number of milliseconds since this time. I'm hoping this is covered by tests. Waiting on EWS. If it isn't, I'll write some.
Created attachment 430935 [details] Patch
http://trac.webkit.org/r278665