Feature: Exposing redirectCount (and redirectStart / redirectEnd) on PerformanceNavigationTiming for TAO opted-in cross-origin redirect chains.
Specs:
- HTML: whatwg/html#12513
- Fetch: whatwg/fetch#1931
- Issue: w3c/navigation-timing#215
This feature exposes the timing of cross-origin redirects in a navigation's redirect chain (the number of redirects, and the start/end timestamps of the redirect phase) if and only if all the responses in the redirect chain explicitly opt in to such exposure.
The opt-in is done using the Timing-Allow-Origin response header, with values
of either * or the explicit destination navigation origin (i.e. the origin
of the document being navigated to).
The purpose is to give developers visibility into where time is being spent during navigations that involve redirects, which is a common and frequently significant contributor to navigation latency. Today, this information is hidden for cross-origin redirect chains, which means real-world navigation performance regressions caused by redirect hops are invisible to the destination site, even when both ends of the chain would be perfectly fine with surfacing them.
Since the opt-in requires the redirector to explicitly call out the
destination origin (or *), it is safe to assume that no content will
accidentally opt-in to exposing its redirect times.
This behavior is similar — but more restrictive — than what WebKit are already shipping, which exposes redirect counts based on the source origin TAO opt-in.
02. Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
Yes. Only the redirect count and the redirect phase start/end timestamps
are exposed. Intermediate redirect URLs, headers, status codes, and per-hop
timings are not exposed. If even one response in the chain does not opt in
(or if the navigation's referrer was suppressed via noreferrer /
Referrer-Policy), redirectCount collapses to 0 and redirectStart /
redirectEnd are zeroed.
03. Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
No. The data exposed is timing information about the redirect phase of a navigation that the user themselves initiated, gated on a server-controlled opt-in.
The feature does not expose sensitive information. Redirect timing for
cross-origin chains is gated on an explicit server opt-in (Timing-Allow-Origin
matching the destination origin, or *) on every response in the chain.
05. Does data exposed by your specification carry related but distinct information that may not be obvious to users?
No. Only aggregate redirect timing of the user's own navigation is exposed, and only when servers in the chain explicitly opt in.
No. The exposed values live on a PerformanceNavigationTiming entry tied to
the current document; they are not persisted.
07. Do the features in your specification expose information about the underlying platform to origins?
No. The values are purely about the network behavior of the current navigation (redirect count, redirect-phase timestamps) — not about the user agent, OS, hardware, or other platform attributes.
No.
No.
No.
No.
12. Do features in this specification allow an origin some measure of control over a user agent's native UI?
No.
None.
14. How does this specification distinguish between behavior in first-party and third-party contexts?
The feature exposes navigation timing data on PerformanceNavigationTiming
entries, which only exist for top-level navigations and same-origin iframe
navigations the embedder can already observe. The exposure is gated on
opt-in from every cross-origin response in the redirect chain (via
Timing-Allow-Origin matching the destination origin or *), so a third
party participating in a redirect chain cannot have its timing exposed
without explicitly choosing to.
15. How do the features in this specification work in the context of a browser's Private Browsing or Incognito mode?
The feature behaves identically in private browsing / incognito modes. It exposes no information about the user, only server-opted-in timing about their own navigation, so it does not create a vector for correlating normal-mode and private-mode sessions.
16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
The Navigation Timing specification has both sections; the change introduced here is wholly within the existing model (Timing-Allow-Origin opt-in for cross-origin timing exposure) and is described in the prose of the relevant HTML and Fetch PRs. The opt-in mechanism — and its rationale — is documented in those specs.
No. The default remains "do not expose cross-origin redirect timing". This
feature only enables servers to raise the exposure, by explicitly opting
in via Timing-Allow-Origin keyed on the destination origin.
18. What happens when a document that uses your feature is kept alive in BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document?
PerformanceNavigationTiming entries reflect the original navigation that
created the document. They are not mutated on BFCache restore (BFCache
restores surface their own back-forward-cache-restoration entries
separately). No additional considerations are introduced by this change.
No additional considerations beyond the existing behavior of
PerformanceNavigationTiming for non-fully-active documents.
No new errors are introduced. When the opt-in conditions are not met,
redirectCount is exposed as 0 and redirectStart / redirectEnd as
0, matching the pre-existing behavior for opaque cross-origin redirect
chains.
No.
No additional concerns identified.