Use Timing-Allow-Origin to determine same-origin on redirects

[bmaurer]

Currently it is difficult to understand the timing of cross origin redirects. For example, if https://facebook.com redirects to https://www.facebook.com, any information regarding that redirect is obscured from navigation timing.

Could we use the Timing-Allow-Origin header from resource timing to address this? A request that returned a redirect to another origin could include a Timing-Allow-Origin for that origin to specify that the final document is allowed to see timing information for the cross origin redirect.

[igrigorik]

This is duplicate of w3c/performance-timeline#29 (comment), let's continue this discussion there.

[toddreifsteck]

@igrigorik , I think you may have referenced the wrong duplicate. Could you review?

[igrigorik]

Woops, apologies, that should have been: w3c/resource-timing#21

See the bug on fetch referenced in above issue as well.

[toddreifsteck]

My take is that resolving navigation-timing redirect will depend on us first resolving w3c/resource-timing#21 but is not technically identical and I'm not 100% certain we should combine the discussion. Any objection to keeping this open as a tracking item?

[igrigorik]

I think they're blocked on same issue: https://fetch.spec.whatwg.org/#atomic-http-redirect-handling. That is, we need a mechanism (or change the policy) about surfacing redirects and other background fetches to the application.

Once we can surface redirects, we can then talk about role of TAO.. E.g. a redirect may be surfaced without revealing detailed timing data (just duration), but with TAO we might make all timestamps available.

[igrigorik]

Taking another run at this... So, say we have A.com -> B.com, and both return the TAO header with * policy. Today because the redirect is cross-origin, redirectStart, redirectEnd, and redirectCount are all 0.

redirectStart: If there are HTTP redirects or equivalent when navigating and if all the redirects or equivalent are from the same origin, this attribute must return a DOMHighResTimeStamp with a time value equal to the starting time of the fetch that initiates the redirect. Otherwise, this attribute must return a DOMHighResTimeStamp with a time value equal to zero.

The above is due to the fact that Nav Timing is not TAO-aware. By contrast, Resource Timing handles this differently:

redirectStart: If there are HTTP redirects or equivalent when fetching the resource and if any of the redirects are not from the same origin as the current document, but the timing allow check algorithm passes for each redirected resource, this attribute must return the starting time of the fetch that initiates the redirect. Otherwise, this attribute must return zero.

So, I think this looks plausible (for redirects in particular) and doesn't need to block on w3c/resource-timing#21.. We'd just need to make NT TAO-aware and update redirectStart/End, and redirectCount logic.

Aside... Assuming we get w3c/resource-timing#21 in place though, this whole thing becomes a no-op. That said, getting there might require quiet a few changes (NT3 + RT2? :). Do we want to pursue both, or should be concentrate on fixing the larger problem (not just redirects but all the other timestamps too).

[toddreifsteck]

I agree that approach is both plausible and fairy well understood in terms of security risk.

[igrigorik]

As discussed on the webperf call, we may automatically inherit this behavior once #11 is done.

[plehegar]

See #36

[igrigorik]

Resolved via #36, closing.