Re: Disparity between time bases in HighResolutionTime and ResourceTiming

On Thu, Aug 30, 2012 at 5:59 PM, Jatinder Mann <jmann@microsoft.com> wrote:

>  In the current design, you have easy access to both the time measured
> from the start of navigation of your context and your parents. The proposed
> change makes it difficult to measure time relative to just the start of
> your context’s start of navigation.
>

Agreed.


> **
>
> ** **
>
> *Security*
>
> Now suppose for a moment iframe B is cross-origin and iframe A is
> same-origin. With the proposed definition, iframe B will now know the
> amount of time since the parent document was created, data which was not
> available prior. The current definition protects from that leakage by not
> measuring time relative to the root document’s start.****
>
> ** **
>
> I know we don’t want to create new data leakages, so we could update the
> proposed definition to measure time relative to the root document start of
> navigation for same-origin documents and relative to its own start of
> navigation when cross-origin.
>

Yes, this is what I meant all along. It's in my definition of "root"
earlier in this thread. I should've given it a different name.

Here the proposed design has an inconsistent behavior between cross-origin
> iframes and same-origin iframes, which may be confusing to developers. The
> current design is consistent in that it uses the same origin reference
> point: start of the context’s navigation.
>

I'd be interested in an example where a developer is working on iframe
content that would intentionally end up both on the same domain and on
another domain. They'd be the only ones who'd notice.

****
>
> ** *Timing Spec Impact*
>
> The impact on the Timing specs is shown in the figure attached. The
> current definition keeps all timelines independent. If one wants to view
> the timeline relative to the root document, the sub-documents have already
> been represented by their Resource Timing data. The proposed definition
> would push out all iframe timelines to be relative to the root document. *
> ***
>
> ** **
>
> **
>
> ** **
>
> **
>

This points out that Navigation Timing and Resource Timing become redundant
for iframes. That's a good point.


> It will be interesting to understand the use cases of wanting to share
> data between frames. For the case of comparing Timing spec data for
> sub-documents, the current definition already gives that representation in
> the root document’s Resource Timing (above figure). For the case of
> synchronizing animations, you would probably measure the deltas in time,
> not the absolute time (though you can use parent.performance.now() to
> measure the absolute times).
>

I'm mostly thinking about web apps that make use of same-origin iframes.
Google, Gmail, Bing, and Hotmail come to mind. Anytime you execute script,
you need to be careful about which context you're in and possibly apply
offsets to your now() values, lest you accidentally pass them across a
document boundary. This is doubly messy with closures.

In all of the cases I'm thinking of, a same-origin iframe is always part of
the same app. In that case, developers want them all to use the same time
domain. I'd be interested in examples to the contrary; where you have a
same-origin iframe and _do_ want it treated as an independent entity. But,
that's what <iframe sandbox> does.

****
>
> ** Also I should add, though we may not want to encourage it, developers
> can always compare High Resolution Time with Date.now() by just adding
> performance.navigationStart to the performance.now() call. (In the current
> definition, they would add their document’s performance.navigationStart and
> with the proposed definition, they would add the
> parent.performance.navigationStart). This time will only be accurate to the
> millisecond, but will truly be comparable.
>

Is this spec'd somewhere? I was always under the impression Date.now()
should change if the user's clock changes. That's how Chrome works anyway.


> ****
>
> *Summary*
>
> Since this change mainly impacts sub-documents, thinking about this from
> an ad developer’s point of view makes sense – most ads are in iframes. If
> the developer is looking at the time the server responded with the ad’s
> document (Navigation Timing 2’s responseStart attribute), the developer
> would expect it to be relative to the document’s start, not the root. E.g.,
> if responseStart attribute is 101.123ms, wouldn’t you think it took
> 101.123ms for the response to start? It would seem confusing that the data
> point actually reflects the time since the root document’s start of
> navigation.
>

Ads aren't interesting because they'll be cross-origin.


> ****
>
> ** There is no loss in functionality using the current design compared to
> the proposal (said another way, proposal does not provide any additional
> functionality), current design does not have the privacy leak issue, and
> the Performance Timeline looks cleaner.
>

I think the current design is optimized for a non-existent use case and the
proposal makes it usable for actual web apps.

James