Repository navigation
Using navigationStart as a baseline may expose cross-origin timing information #160
Description
When we have a navigation with cross-origin redirects, we're hiding redirectStart and redirectEnd from the final document.
However, because the timeOrigin for all the navigation timing entries is the navigation start, the redirect timing info can (somewhat) easily be inferred.
Consider the following:
- User clicks a link to domain A at timestamp
ts1(e.g. a search engine click handler URL or an ad broker like outbrain) - Domain A takes a while to handle the request
- The request redirects to domain B at timestamp
ts2 - Domain B handles the request and serves the document
ts1is available to the document, directly or indirectly, as it's thenavigationStartwhich is the base timestamp for all navigation timing / resource timing entries (as well as thetimeOrigin).
I believe we have three ways to go about it (but maybe there are more):
- Enable all the navigation timing properties, based on the notion that the cross-origin information is already exposed by navigationStart.
- Change
navigationStartto be the timestamp of the first redirect in the current origin redirect chain - Make use of
TAO(in its current form or with some amendments) to give redirect chains the opportunity to expose their timing to the destination.
This came from discussing whether to enable or zero-out navigation timing properties.
See previous discussions here, here and here.
Thoughts?`
Activity
[-]Using navigationStart as a base line may expose cross-origin timing information[/-][+]Using navigationStart as a baseline may expose cross-origin timing information[/+]noamr commentedon Sep 30, 2021
@yoavweiss @annevk @npm1 @sefeng211 @achristensen07
yoavweiss commentedon Sep 30, 2021
Also @bdekoz @mikewest @arturjanc
annevk commentedon Sep 30, 2021
If "current origin redirect chain" means the origin boundary is not crossed therein, that option seems reasonable to me. The current model does indeed seem problematic.
w3c/resource-timing#220 is also related.
noamr commentedon Sep 30, 2021
Yes, it means something like "after all the redirects that are not same-origin as the document's final origin are complete"
achristensen07 commentedon Sep 30, 2021
This does need fixing. I oppose the first option. The third option seems most like what we do with other cross-origin timing exposure.
mikewest commentedon Sep 30, 2021
I think I agree with @annevk and @achristensen07. This does seem like something we ought to change, and the third option seems like the most robust (and consistent) way of doing so. I think the second is justifiable from a security standpoint as well, but I'm not sure the complexity it introduces is worthwhile.
noamr commentedon Sep 30, 2021
Note that (3) includes (2) inside it, in the cases where TAO headers are not there.
With option 3 I want to be careful when we overload the meaning of TAO (see concerns here). Though it could be that since TAO was ignored inside redirects so far it's not a problem since it's new usage of an existing header.
Perhaps a good way to go about it would be that the TAO Header would have to specify the same origin as the
Locationheader, rather than*, like this:Not having the above in a cross-origin redirect would push the navigation start time (and
timeOrigins) to the beginning of the next fetch after this redirect, and having it would act as if this redirect is same-origin for the purposes of navigation timing.annevk commentedon Sep 30, 2021
As I noted in w3c/resource-timing#220 accounting for TAO here is in essence a new model and therefore also a source of complexity. For Resource Timing we have a document A that fetches B which redirects to C. B and C need to consent. Here we have a document A that is navigated to B which redirects to C. B needs to consent? I think it's acceptable, but it's quite a bit different.
yoavweiss commentedon Sep 30, 2021
I have to say that the second and third options are not mutually exclusive - we could set navigation time at the first same-origin redirect and extend it backwards pending on an opt-in from the cross-origin redirects.
Note that in any case, we'd need some point in time for navigation start even if there's no opt-in. At worst, we can have that be the request to the eventual request for the document, but setting it to the first request in the last same-origin portion of the redirect chain doesn't seem overly complex.
yoavweiss commentedon Sep 30, 2021
I agree that TAO may not be the opt-in we want here.
noamr commentedon Sep 30, 2021
Opting for a new opt-in? 😬
jyasskin commentedon Sep 30, 2021
Yoav pointed out that in cases where the redirection domain is trying to help the source and destination track the user, and the user agent has blocked the query parameters they had been using to do this, this timing information might help them continue to transfer at least a partial identifier. I don't think the navigational-tracking threat model (privacycg/nav-tracking-mitigations#12) is developed enough to be much help in making decisions here, but heads up that the Privacy CG might come back to this later.
noamr commentedon Sep 30, 2021
Hmm this makes it more interesting - it means that if we accept this as a threat to be mitigated, the user agent should have a say in this for the purpose of tracking prevention and not just the two domains, which means something along option (2) would be the (only?) way to go (the "navigation" starts from the last same-origin chain).
Note that if we go with option (2), some value will be lost for RUM. Sites that load "slowly" will only know what happened from the point the redirect chain arrived at their domain, and they would have no insight into delays caused by 3rd party redirects.
yoavweiss commentedon Oct 1, 2021
Indeed. As long as query parameters are allowed to be passed with the navigation URLs, acting against this doesn't matter much. So for now, I don't think we should take that into account.
But if and when we start mitigating query parameters as an information-passing channel, we'd need to also mitigate the redirection timing channel, either by not exposing it entirely, or have browsers lie about those times in smarter ways (e.g. for known trackers, when they're highly variable, etc).
56 remaining items
RByers commentedon Nov 12, 2025
FWIW my opinion for Chromium is that we wouldn't want to regress in terms of making this important navigation timing information available to the page without a credible real-world attack or alternate (possibly aggregated) means of sharing the information. As such, I don't see an urgent need to change Chromium's behaviour at the moment.
At the same time, it makes sense that we'd want to spec
timeOriginsuch that it does not include any cross-origin timing, and that we'd want a consistent implementation of that across engines. Perhaps we can find a way to do this without necessarily breaking the existing users of this information from Chromium?yoavweiss commentedon May 7, 2026
WebKit/WebKit#63781 (comment) changes how I thought about this, as apparently WebKit doesn't change the timeOrigin to the last redirect on the destination origin, but instead nullifies most attributes when TAO is not present across the entire redirect chain.
I think we have a few options:
timeOriginto the final navigation, and add aredirectDurationattribute. The latter could require an opt-in, at least in some implementations.redirectStartandredirectEndtimeOriginto the first request in the redirect chain on the destination origin.I think (1) results in both confusion (developers not knowing that their metrics are influenced by redirects) and interop (missing attributes). (2) seems to me less confusing than (1).
mmocny commentedon May 8, 2026
It sounds like the results of WebKit/WebKit#63781 (comment) are that the current situation is more interoperable than we previously thought.
There remain gaps (such as missing redirect values), but those were already there previously, and at least the current
timeOriginvalue indirectly gives some insights (via "UNO")noamr commentedon May 8, 2026
(4) expose responseStart, but hide everything between startTime and responseStart when there are cross origin redirects without TAO.
responseStart is already observable by other means, like scripts or link headers.
This would keep TTFB as well as LCP etc interoperable, while not exposing how much time is spent in cross origin redirects in a way that's easily discernable from same-origin request preparation, DNS, connection etc.
For webkit this would means keeping the current implementation but always unhiding responseStart for navigation timing.
Set timeOrigin to align with spec, even when BCG switches take place.
yoavweiss commentedon Sep 3, 2026
Thinking about this again.. I suspect that (4) is the fastest (only?) path to interop here.
A few things we need to figure out:
responseStartin case of an no-TAO cross-origin redirect? /cc @nicjansma @krzksz @andydaviesresponseStartfor no-TAO cross-origin redirects? /cc @noamr @mmocny @Bas-mozOne more thing to think about - For the redirect timestamps, we also excluded them in the case of a
no-refererrequest. Should we do the same for the rest of the attributes here?noamr commentedon Sep 3, 2026
I think I am OK with the behavior but cannot commit on a timeline for doing the work. Are you taking it on @yoavweiss ?
yoavweiss commentedon Sep 3, 2026
Not a hard commitment, but assuming we all agree on an interoperable path, I could most probably take on the Chromium/WebKit work.