Using navigationStart as a baseline may expose cross-origin timing information

[noamr]

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
• ts1 is available to the document, directly or indirectly, as it's the navigationStart which is the base timestamp for all navigation timing / resource timing entries (as well as the timeOrigin).

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 navigationStart to 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?`

[sgomes]

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.

[terjanq]

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

[yoavweiss]

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?

[noamr]

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.

[terjanq]

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.

[sgomes]

@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!

[terjanq]

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.

[sgomes]

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.

[noamr]

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

[noamr]

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

[annevk]

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

[noamr]

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.

[andydavies]

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

[noamr]

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.

[yoavweiss]

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

[noamr]

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.

[noamr]

Suggesting to solve this in the context of https://github.com/w3c/resource-timing/issues/220

[annevk]

I don't see how an opt-in header helps with the attacks? See also https://github.com/w3c/navigation-timing/issues/160#issuecomment-952000354.

[noamr]

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.