Using navigationStart as a baseline may expose cross-origin timing information about navigation-timing HOT 69 OPEN

Hey folks!

As someone working in performance full-time, I have some concerns regarding this proposal, and its impact on well-established metrics like TTFB.

Unless I'm misunderstanding the proposal, wouldn't option 2 ("Change navigationStart to be the timestamp of the first redirect in the current origin redirect chain") mean that we would be redefining TTFB and all metrics that build upon it to mean different things on different situations? That is:

• In-origin redirects only if there's no TAO or alternatively proposed header
• Both in-origin redirects and cross-origin redirects if TAO or alternatively proposed header are present

This seems inconsistent and difficult to account for, given that RUM libraries don't have any visibility into the HTTP headers on the document.

Furthermore, would this also change the definition of TTFB and all metrics that build upon it for native browser measurements, such as the ones taken for the Chrome User Experience Report? If not, this could be even worse, as it would remove the last bit of visibility we have into what happens before a request gets to the ultimate origin.
At Automattic, we've relied on this information in the past to understand what is happening before a request gets to the origin, so that we can find unnecessary redirects where it's impractical or impossible to set up TAO across authentication chains, URL shortening services, etc.

It's extremely important for us to be able to account for every portion of the time that goes into TTFB or a higher-level metric, when we're being ranked for it via CrUX.

In general, Navigation Timing is a well established API that is relied upon by every RUM library out there, so it seems dangerous to redefine the meaning of the most fundamental value that the entire API relies on.

from navigation-timing.

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.

from navigation-timing.

This issue is scheduled to be discussed at TPAC on Monday Oct 25 9am PST. Full agenda: https://docs.google.com/document/d/1GQpM8IvL4feXQ0oQdCQIPKhZZkMLNTYJQhBUntMxPkI/edit#heading=h.tx59951gswac

from navigation-timing.

This does need fixing. I oppose the first option. The third option seems most like what we do with other cross-origin timing exposure.

from navigation-timing.

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.

from navigation-timing.

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.

from navigation-timing.

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.

from navigation-timing.

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).

from navigation-timing.

Just to clarify, sounds like this applies to https://w3c.github.io/hr-time/#dfn-time-origin as well? If it does then this would be a pretty big change impacting any high resolution timestamps received by developers.

Indeed! We'll definitely have to be careful about rolling this out.

from navigation-timing.

Thank you @sgomes, yes, this voice has to be heard to.
Seems like the implications of this on RUM metrics would be pretty big. That would have to be weighed against the current breach of same-origin policy. Hoping for a lively discussion at TPAC.

from navigation-timing.

I would add that this information can be crucial when working on some performance aspects of user experience. If we define user experience performance metrics based on how long it takes for something to happen after the user clicks a link (or otherwise triggers a navigation), then cross-origin redirects are an intrinsic part of that. And they can be a substantial portion of it too, since cross-origin redirects can involve establishing new connections that may have to go through DNS, TCP and TLS, to the tune of 4 or 5 roundtrips.

Removing that information from the Nav Timing API by effectively starting the clock later would make it look like users are getting a good experience, when in fact they could be waiting for a long time.

Now, I definitely acknowledge the need for privacy, and the fact that it can be argued that knowing about the existence of cross-origin redirects is a breach of that privacy. But it's important to weigh the magnitude of that privacy breach against the inability to discover some issues and ultimately work on performance aspects of user experience, were things to change.

For context, cross-origin redirects often happen within the space of a single organisation, and those are the ones I'm most concerned about being able to discover and reason about. This is particularly frequent for services where customers have their own subdomains or TLDs, such as those provided through web hosts, but where admin services are hosted in a different origin. While TAO or other headers would give us a path to getting those numbers, as proposed, the main issue as I see it is discoverability; it would be difficult to find out about the issues in the first place, as it may not be practical to set up these headers in advance, in expectation of a potential problem, and across all possible combinations of origins.

Ultimately, it would be important for there to be a mechanism that would allow an organisation to find out that users are spending large amounts of time before getting to the final origin, even if it's not clear exactly how long, nor where they're coming from. We can only mitigate the problems we know about, and the proposed change could hide an entire class of problems from us.

from navigation-timing.

@noamr yes I agree, that it's not an attack. The word attack in my response was to convince myself that it's not a side channel that could be used, but rather potential privacy leak about past. Speaking of past, a website B could potentially infer the information: "There was at least one unexpected redirect and it took X time", but it doesn't know exactly about other origins? It knows that something like this occurred, but it doesn't give more information at first glance?

From the adversary point of view, I could argue that the time it takes for a page to load leaks, with a high likelihood, what redirector was used to load a page. (e.g. facebook redirectors could take 79ms, while twitter 10ms), which then leaks information from what origin the user visited the page, even if document.referrer was supposed to be hidden. That indeed might seem problematic.

from navigation-timing.

Based on the discussion in the meeting and what is written above what I think makes sense here is to apply masking the moment the Sec-Fetch-Site request header would report cross-site.

By way of examples:

• If you navigate from A to B and A and B are cross-site, we give B the "fetch start time", not the "navigation start time". If A and B are same-site, we give B the "navigation start time".

• If you navigate from A to B which redirects to C, we give C the "fetch start time" of B, if A and B are cross-site and B and C are same-site. If they are all same-site, we give C the "navigation start time". If they are all cross-site, we give C the "fetch start time" of C.

What this means for Fetch/HTML:

To account for this we probably want to change request's tainted origin flag to become a tri-state so it can also support Sec-Fetch-Site (this is needed for other reasons as well). And HTML's navigate could use the current value of that member to adjust its timing info accordingly.)

Why use site as a boundary?

This seems like the most reasonable tradeoff between privacy/security and utility. I could see supporting an opt-in to further reduce this to origin, but given that we're largely aiming for the cookie boundary for various cross-site leaks, this should be a good enough starting point.

from navigation-timing.

I think that providing a negative value in a new field (which would default to 0 if the privacy-guarding criteria weren't met) would serve as a good way of both being able to retrieve the data when available, and determining which of the two strategies the current browser is following 👍

This would give us three states:

• Missing field: old strategy
• 0: new strategy, with either no pre-final-origin redirects, or no insight into them because of privacy reasons
• Negative value: new strategy, with the time spent in pre-final-origin redirects provided as the value

I would be sad to see the cross-origin data disappear by default, because it is a great discovery tool for cross-origin redirects within an organisation (as it would be difficult to ensure that the required headers would always be present across a potentially wide variety of systems). If that is to happen for privacy concerns, though, the above approach seems like a good way for RUM libraries to be able to make sense of the situation.

from navigation-timing.

I would be sad to see the cross-origin data disappear by default, because it is a great discovery tool for cross-origin redirects within an organisation (as it would be difficult to ensure that the required headers would always be present across a potentially wide variety of systems). If that is to happen for privacy concerns, though, the above approach seems like a good way for RUM libraries to be able to make sense of the situation.

I am a little bit confused about this statement. The highlighted sentence would only prove that this is something we should fix? We don't want to provide great discovery tools for a cross-origin redirects in general.

From the security & privacy side, I think we should be fine by providing some kind of tool that allows to measure the time from user-click to loading a final page, because this already should be possible if website A registers the click time, and then a website B measures the current time, then the navigation-time could be measured while ignoring all the redirects that occurred in the meanwhile. But for this to work, website A and website B must have mutual agreement about exposure of those timings.

I am confused how TAO could help here, because if you click on a link, you don't necessary control the headers of it while you still can perform the measurement mentioned above. What would work I think would be to add a new token to rel="allow-navigation-timing" but this way, website A exposures the timing to all websites, not only to B (which maybe is acceptable, and if not, the workaround with manual measurement can always be used).

from navigation-timing.

@andydavies - I think the use case for having visibility to these cross-origin redirects is clear. At the same time, this is a cross-origin leak, as it is exposed right now. We'd need to find an alternative, privacy-preserving way to expose this information to developers. (e.g. aggregated reporting)

from navigation-timing.

@yoavweiss @annevk @npm1 @sefeng211 @achristensen07

from navigation-timing.

Also @bdekoz @mikewest @arturjanc

from navigation-timing.

If "current origin redirect chain" means the origin boundary is not crossed therein, that option seems reasonable to me.

Yes, it means something like "after all the redirects that are not same-origin as the document's final origin are complete"

from navigation-timing.

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 Location header, rather than *, like this:

Location: my-site.com/page.html
Timing-Allow-Origin: my-site.com

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.

from navigation-timing.

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.

I agree that TAO may not be the opt-in we want here.

from navigation-timing.

I agree that TAO may not be the opt-in we want here.

Opting for a new opt-in? 😬

from navigation-timing.

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.

from navigation-timing.

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.

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.

from navigation-timing.

There are user agents doing experiments around query parameters (and some might have shipped?) so we might as well account for it now.

from navigation-timing.

I agree this is an area we should remain vigilant on to see how it develops, but I don't believe we have consensus on the threat model and what the solutions to this threat would look like. So it seems premature to e.g. eliminate an opt-in option before that settles.

from navigation-timing.

Maybe, I have to say that since we have some tentative plans in this area, I'm actually hesitant now to support an opt-in model here.

from navigation-timing.

^^ @miketaylr

It's true that we could go with option (2) and expand it later with an opt-in, once things in that area settle.

It may also be interesting to think about the incentive model here - if this would make redirectors unaccountable for their performance, that'd not be a great outcome. An opt-in model may not be effective in driving such accountibility.

from navigation-timing.

^^ @miketaylr

It's true that we could go with option (2) and expand it later with an opt-in, once things in that area settle.

Feels to me from this discussion that this might be the way forward as a first step, while contemplating the opt-in. Interesting if something else would come up in TPAC.

It may also be interesting to think about the incentive model here - if this would make redirectors unaccountable for their performance, that'd not be a great outcome. An opt-in model may not be effective in driving such accountibility.

I'm not sure a redirecting URL is accountable for timing to its destination... Maybe it's accountable to the domain that started the navigation, e.g. where the banner was?

Maybe the interested party in this information is neither domain, but rather the user (and the user agent), and user agents should be encouraged to show some UI indication during a cross-origin navigation redirect ("You are now redirected via Outbrain" or such), to show the user that the delay comes from an ad broker etc and not from the originating domain / destination domain, rather than counting on the origin/destination URLs to do something about it? </Thoughts.>

from navigation-timing.

Just to clarify, sounds like this applies to https://w3c.github.io/hr-time/#dfn-time-origin as well? If it does then this would be a pretty big change impacting any high resolution timestamps received by developers.

from navigation-timing.

See demo here. A minimal use case without an intermediate domain.

The originating domain does some form processing of POST before redirecting to a URL at a different domain.
Because the timeOrigin includes the time it took to process the POST at the originating domain, in this case the destination domain can detect whether the user subscribed to a newsletter.

from navigation-timing.

It's unclear to me how excluding redirect time in the timeOrigin prevents any realistic attack.

For this attack to work today, we need:

• a redirector which forwards to a site we own
• which leaks privacy / security sensitive info through it's redirect time
• and has users which navigate to our pages via that redirector

Suppose we exclude redirect time from the timeOrigin. For the above attack to work, I already need users on a site I own. If I then modify links on my site to:

• record the click timestamp
• forward to the redirector which forwards back to the site I own

then I'm still able to measure the redirect time and execute the attack.

from navigation-timing.

I think the bigger problem is that when navigating from A to B, B gets to learn when the action on A happened, in quite some precision.

While currently there are many side channels through which A and B can keep tabs on the user, at some point this timing channel might be all that's left and it seems rather unfortunate that it's there.

from navigation-timing.

Another possible solution(?) is to do some extreme coarsening on the time between navigation start and the first redirect of the last origin. It would keep the time base roughly the same and would still measure some heavy redirect delays, but without exposing high resolution timing information to third parties.

from navigation-timing.

I think it's important to understand if this is exposing cross-origin information that's a problem that's putting users at risk today, or if it's a side-channel that would become a problem once we would block all other side-channels that enable navigations from A to B to currently communicate. @tdresser's example countered my scenario I had for the former, showing that this will not block it.

from navigation-timing.

Exposing cross-origin redirects in navigationStart violates the spirit of cross-origin policy regardless of those attacks, as it exposes time the user spent at the original domain or intermediate domains.
It's like saying to websites: "by redirecting to a different origin location, you're also sending timing information as part of the redirect".

I see it less as "exposing to attacks", but rather volunteering usage information to domains without permission.

from navigation-timing.

The description of the issue looks complicated and some folks in the thread seem to understand the leak differently. From what I understand, the attack scenario here is that a final website B could infer some information about redirectors used on a website A. E.g. clicking on google search, twitter links, facebook since these all are proxied through. This indeed seems like too much information for a website B to have.

Change navigationStart to be the timestamp of the first redirect in the current origin redirect chain

Which means

Yes, it means something like "after all the redirects that are not same-origin as the document's final origin are complete"

Seems reasonable to me.

Though, I can't come up with any useful attack that would abuse this inferred information. We don't expose any information about how many redirects occurred, so for a website B to guess that a redirect occurred, and how many times, is rather tough without other side-channels (maybe potentially document.referrer). I don't think that it's a side channel on its own.

It looks weird though that we expose the information about load time including all the redirects that occurred. This could provide false information about performance.

from navigation-timing.

Though, I can't come up with any useful attack that would abuse this inferred information. We don't expose any information about how many redirects occurred, so for a website B to guess that a redirect occurred, and how many times, is rather tough without other side-channels (maybe potentially document.referrer). I don't think that it's a side channel on its own.

It would be very easy to know that a redirect has occurred. If fetchStart or one of the other metrics is not close to zero, a redirect (or more) have occurred in high likelihood.

I wouldn't call this exactly an "attack". It's rudimentary information that website A forwards along to all of its redirect destinations it has no knowledge of. It's basically saying "When you click on a link or submit a form, the final document you get to would know when you clicked/submitted, even if you pass through redirects".

from navigation-timing.

The issue with any strategy that involves different behaviour depending on which headers are set, is that we no longer have a consistent definition of any of the client-side metrics that performance tracking relies on.

As of right now, they are all calculated based on when the user started navigation, by e.g. clicking a link. This is consistent, clear, and a good reflection of user experience. With the proposed changes, it could either be based on that or e.g. when the user first entered the final origin, and there is no easy way for a RUM library to tell the two apart, since it doesn't have access to the headers that would allow it to make sense of what the situation is.

I would suggest that, if changes are to be made so that time from other origins is not included, then it should never be included under any circumstances. A separate mechanism could then be provided to retrieve this pre-final-origin time, for the situations where we deem it to not be a privacy breach, whatever criterion determines that.

from navigation-timing.

To add to my last comment, the presence of that newer mechanism could also serve as a signal to distinguish between browsers that implement the older strategy vs browsers that implement the newer one, which would help to solve one of the open questions around how a migration would happen.

from navigation-timing.

That mechanism could be including a negative redirectStart, unloadEventStard etc. while keeping the zero point at fetchStart or same-origin redirectStart for all cases ("the point in which the user reached your origin").

from navigation-timing.

That could work. So navigationStart would always return "fetch start time" of the last fetch for the document in question (to keep the values consistent) and sameSiteNavigationStart would potentially represent an earlier point in time that is the current "navigation start time" unless masked at some point. However, that would have to be a negative value then since navigationStart is the time origin.

from navigation-timing.

btw there are cases where the navigation start time doesn't measure the user-experience, e.g. in the case of HTML redirect (refresh meta-tag with a different location). The user wouldn't know the difference between this and an HTTP redirect, but the navigation timing would be completely different.

from navigation-timing.

That's probably best tracked in a separate issue. It might be addressable if needed.

from navigation-timing.

Sure, it's more to make a point that currently the navigationStart epoch doesn't capture all the "user experience" cases, and is specific to the technique used to redirect.

from navigation-timing.

@sgomes I'm not sure what you mean with "required headers". We would not offer something like TAO here as that would go against the privacy/security concerns.

from navigation-timing.

@annevk I apologise for the confusion, this is likely due to my flawed understanding of what it would take to flip the Sec-Fetch-Site request header to report something other than cross-site across different origins.

Is that only achievable through First Party Sets?

from navigation-timing.

It's not achievable. (Apart from same-site of course, see https://html.spec.whatwg.org/multipage/origin.html#same-site for that.)

from navigation-timing.

It's not achievable. (Apart from same-site of course, see https://html.spec.whatwg.org/multipage/origin.html#same-site for that.)

For a web host, that could pose some difficulties. Consider a scenario where a user gets redirected from the host's platform domain (host.example) to a site that is served by that host. There would now be a distinction depending on whether that site uses a subdomain (mysite.host.example) or a custom domain (mysite.example), although presumably the same privacy concerns apply in both cases.

from navigation-timing.

mysite.host.example has security implications for host.example, due to the boundary of cookies (and document.domain). But to the user these are often presented as the same "entity" due to them sharing a registrable domain, so the privacy implications are different from mysite.example.

from navigation-timing.

I would be sad to see the cross-origin data disappear by default, because it is a great discovery tool for cross-origin redirects within an organisation (as it would be difficult to ensure that the required headers would always be present across a potentially wide variety of systems). If that is to happen for privacy concerns, though, the above approach seems like a good way for RUM libraries to be able to make sense of the situation.

I am a little bit confused about this statement. The highlighted sentence would only prove that this is something we should fix? We don't want to provide great discovery tools for a cross-origin redirects in general.

I apologise, I should have provided more context. My concern is ensuring that these cross-origin issues are visible when they happen within the context of the same organisation, or a context of trust, in general. I understand that's difficult to define.

from navigation-timing.

mysite.host.example has security implications for host.example, due to the boundary of cookies (and document.domain). But to the user these are often presented as the same "entity" due to them sharing a registrable domain, so the privacy implications are different from mysite.example.

Thank you, I can understand the distinction with your explanation 👍

I'm not sure there's a good solution to meet all of the concerns expressed. The proposal we're discussing would make some categories of performance problems undiscoverable to the organisations that would be able to fix them, but I don't see a good mechanism for preserving that ability in the context of the current proposal.

from navigation-timing.

I apologise, I should have provided more context. My concern is ensuring that these cross-origin issues are visible when they happen within the context of the same organisation, or a context of trust, in general. I understand that's difficult to define.

@sgomes I am curious how could this be applied? Does "within the context of the same organisation" change the difficulty on making such measurement (e.g. in contrast to two non-related websites)? Without having some backend information, it's hard to imagine that this is indeed that simple in the current state. With backend information at the other hand, it's easier and without calling the client side API - you just compare two timings on your side (well, you have to somehow fingerprint the initial request).

from navigation-timing.

What would work I think would be to add a new token to rel="allow-navigation-timing" but this way, website A exposures the timing to all websites, not only to B

Do you mean that if we A adds a link to B with rel=allow-navigation-timing, it's exposing the timings to B as well as any redirects B would trigger?

from navigation-timing.

What would work I think would be to add a new token to rel="allow-navigation-timing" but this way, website A exposures the timing to all websites, not only to B

Do you mean that if we A adds a link to B with rel=allow-navigation-timing, it's exposing the timings to B as well as any redirects B would trigger?

I think that would work, with maybe some meta to limit exposing this to certain origins/sites, also to avoid this as a side-channel for fingerprinting.

from navigation-timing.

What would work I think would be to add a new token to rel="allow-navigation-timing" but this way, website A exposures the timing to all websites, not only to B

Do you mean that if we A adds a link to B with rel=allow-navigation-timing, it's exposing the timings to B as well as any redirects B would trigger?

@yoavweiss this would work basically the same as "opener" (or however it is done nowadays) to preserve the window.opener reference that is now lost because of "noopener" by default. Meaning, that the opened document would be able to access this timing API and get the true value, so that doesn't matter where the link points to and whether there are any redirects.

And I think we could do that because similarly to window.opener the potential information leak is only about website A, and as mentioned, if website A is willing to provide such timing it already can send the request time in window.name or simply embedded into the URL.

from navigation-timing.

@sgomes I am curious how could this be applied? Does "within the context of the same organisation" change the difficulty on making such measurement (e.g. in contrast to two non-related websites)? Without having some backend information, it's hard to imagine that this is indeed that simple in the current state. With backend information at the other hand, it's easier and without calling the client side API - you just compare two timings on your side (well, you have to somehow fingerprint the initial request).

@terjanq My concern is mostly around discoverability.

In the current scenario, we can discover problematic pages at the RUM level by simply looking for high values of domainLookupStart, which statistically will catch both problematic in-origin and cross-origin redirects. We can then analyse each situation and try to understand what's happening through either HTTP-level request logs or manual experimentation.

In a scenario where cross-site information is not available to RUM libraries and there exists no mechanism to retrieve it, we would need to rely exclusively on HTTP-level server logs for the discovery phase as well. Not only that, we would have to ensure that the logs for all systems involved are present in the same location, that requests can be correlated, and that an understanding of flow can be established so that we could calculate for each flow what the timing of the first request and the timing of the final one were. It's theoretically doable, yes, but non-trivial in the context of logging systems that are designed to handle each request as a separate entry. Not to mention much more difficult to scale, given the complexity involved.

Hope this provides some extra context!

from navigation-timing.

Makes sense. I am not an expert, but isn't this actually problematic for measurements as well? Suppose that you indeed rely on these measurements and now user visits your website from another website that use redirectors, and these redirectors tend to be really slow. Doesn't it provide false signal to your website? Normally links clicked within the same organisation would be faster than from another in the example.

For me, it looks like both parties in this discussion would benefit from fixing this. For your case it would always provide the wanted signal via opt-in, and from the security & privacy it would mask the potential leaks.

from navigation-timing.

For me, it looks like both parties in this discussion would benefit from fixing this. For your case it would always provide the wanted signal via opt-in, and from the security & privacy it would mask the potential leaks.

Yes, I agree. The information is ambiguous in the status quo, and we're only able to distinguish between problematic external redirectors and internal ones by manually looking at things case-by-case. That is sufficient for some needs, but not others.

If an opt-in mechanism were to exist for unambiguously determining that a user spent too much time being redirected across an organisation's various hosted origins, then that would be an improvement over the status quo, as long as the mechanism is practical to deploy.

from navigation-timing.

I see such opt-in to be similar in spirit to referrer policy, e.g. <meta name="referrer-timing" content="same-site" /> with some more detailed semantics and a per-element override like the referrerpolicy attribute

from navigation-timing.

I see such opt-in to be similar in spirit to referrer policy, e.g. <meta name="referrer-timing" content="same-site" /> with some more detailed semantics

from navigation-timing.

I don't think Firefox would implement such a mechanism as it enables precisely the thing we want to avoid. (See also statements upthread.) Having sites move things into the URL would be vastly preferable and would ultimately allow for tackling this as part of https://github.com/privacycg/nav-tracking-mitigations (if sites indeed decide to go to those lengths).

from navigation-timing.

In the meantime, added a PR to move time origin computation to HTML, this would hopefully make it easier to see how it works and make changes in this in the future.

from navigation-timing.

Metrics such as LCP are trying to represent the user's experience and if navgiationStart is changed to be before the first redirect for the current origin then it will no-longer represent the user's experience for many cases

Visitors clicking from search engines / social media sites are typically routed through redirect, in the worst case clicking on a Ad in Google results leads to three redirects that consume nearly a second for example

The time before the first redirect on the current origin is important as it reflects the visitors actual experience

from navigation-timing.

Metrics such as LCP are trying to represent the user's experience and if navgiationStart is changed to be before the first redirect for the current origin then it will no-longer represent the user's experience for many cases

Visitors clicking from search engines / social media sites are typically routed through redirect, in the worst case clicking on a Ad in Google results leads to three redirects that consume nearly a second for example

The time before the first redirect on the current origin is important as it reflects the visitors actual experience

Understood, but nonetheless the cross-domain leak is there, and the fact that removing it would hinder this valuable metric doesn't make it less of a leak.

from navigation-timing.

Suggesting to start tackling this by adding an opt-in.
Something similar to TAO but specific to Redirect to avoid loading new meanings on old headers.

How about: Redirect-Timing-Allow-Origin: same-origin | same-site | [url list] | * (default same-origin)
Not sure if we want it closer to TAO or to only allow same-origin/same-site.

At first, it would allow exposing redirectStart/redirectEnd when there are cross-origin redirects in navigation, and later on we can make this as the only way to expose cross-origin redirects at start-of-navigation.

from navigation-timing.

Suggesting to solve this in the context of w3c/resource-timing#220

from navigation-timing.

I don't see how an opt-in header helps with the attacks? See also #160 (comment).

from navigation-timing.

I don't see how an opt-in header helps with the attacks? See also #160 (comment).

You're right, it doesn't help with that aspect.

from navigation-timing.