Participants

• Yoav Weiss, Nic Jansma, Noam Helfman, Franco Vieira de Souza, Andy Luhrs, Michal Mocny, Carine Bournez, Barry Pollard, Elad Alon, Luis Flores

Admin

• Next meeting: June 18th, 2026
• Charter vote + Charter extension

Minutes

(Re-)Expose redirectCount, redirectStart and redirectEnd for TAO opted-in cross-origin redirects

• Yoav: Investigation from Safari and NavigationTiming
• … timeOrigin set as first redirect on chain as same as final destination
• … What WebKit is doing is omitting the internal values from NT other than startTime and responseEnd (similar to no-TAO)
• … TAO opt-ins do re-surface those values in WebKit
• … When we have X-O redirects that all pass TAO checks, then WebKit exposes all values including redirectCount, Start and End.
• … Valuable thing for developers at Shopify, only browser exposing that information
• … Odd that only seen in WebKit
• … Let me to some exploration of reasons.  Used to be this behavior everywhere, but as part of spec alignments we changed it a few years back
• … Changed from a TAO opt-in to allow exposure only of same-origin redirects (in spec + Chromium)
• … I believe this is a mistake
• … No way in that model, there’s a way for redirects to opt-in for that decision
• … Makes sense to align on WebKit’s behavior, properly specified
• … One of the original reasons for this change, TAO in specified algorithm only works “backwards”.  If a specific origin is checked against origin from initial request, in navigation we may want to check against destination origin.
• … Doesn’t fundamentally change the model
• … During discussions, Anne brought up issue with same-origin
• Franco: Not yet aligned on this
• Nic: question on backward/forward. In RT, TAO is of the page.  In NT, TAO is of the “next” page that you’re redirected to.
• Yoav: Yes, and in Shopify case most destination origins are preknown
• Michal: Is TAO: * common or uncommon
• Nic: I think in 99%+ cases we’ve seen TAO:*
• Michal: TAO:* is common because it’s not often a concern to it being exposed
• Yoav: Threat model for resources and redirects is different, and would expect redirects to often not want to expose themselves, as it could e.g. expose logged-in case
• … I suspect when it’s OK to expose, it’s OK to expose to all. As the destination is controlled.
• Michal: We don’t break down how much time in each redirect right? Just total?
• Yoav: Yes
• Yoav: I suspect redirectCount is most salient piece of data that can expose information about the user
• Barry: Don’t they leak anyway, if redirect is zero you know there’s at least one cross-origin redirect anyway
• Yoav: Sure
• … If the site knows it’s doing a X-O redirect,
• Barry: This is already a problem, redirecting back and forth between login domains, information is exposed
• Michal: Some features were tied to TAO header, that we’ve later regretted tying to
• … In this case, TAO header is designed for this use-case
• … Feels exactly right solution to this problem in my mind
• Nic: Why was the change a few years ago, context?
• Yoav: Issues around edge-cases, and we concluded there wasn’t a use-case at the time for exposing X-O redirects, to simplify things by removing TAO from the occasion
• … From compat perspective, adding that exposure won’t break anything as Safari already exists
• … From interop, this will improve things
• Michal: If you don’t have TAO header, you still get start and responseEnd
• … What we’re exposing sum of all redirect starts and ends
• … You get sum total from original start, through end, and now we can just give those values
• Yoav: redirectCount is extra
• Michal: With infrastructure you might be able to plumb thru ServerTiming responseStart etc, but much of the value hidden is the first party origin’s timing data about itself, in order to hide redirect times, you could somewhat polyfill that with effort
• Yoav: How?
• Michal: Final destination origin would plumb through
• … You don’t have all of the time, network overhead parts may be missing
• … If you’re spending seconds in redirects, then a second in server latency, small number of missing ms may not matter
• Noam: Don’t think we can assume network is slow or fast
• Michal: If you think this is a leak, some number of users you can already most of what you want to measure here today with the status quo
• Noam: Except counts
• Michal: Correct
• Yoav: Looking at Alex Christensen’s comment, still need some clarifications
• … Move forward with a more complete proposal

Should we be exposing same-origin redirects?

• Yoav: Exposing same-origin redirects goes against fetch spec and can expose e.g. the existence of http-only cookies in some scenarios
• … Should we require TAO also for same-origin redirects?  Zero out values when those timings are missing
• … Default behavior in all browsers for last 15+ years
• … Not sure if there’s a lot of damage in requiring TAO:* or self, where same origin redirects can be controllable by TAO
• Michal: No opinion on exposing that information
• … If you did enforce TAO here, a user not needing to redirect because of cookie state, they’d see there was no redirect times
• … If they did redirect there’d be enough information (even zero’d) – even protecting against this exposes some information
• Yoav: If you had a redirect or didn’t, you’d get a value of zero here
• Barry: Are we losing other values that Safari does?  Do we not get responseStart/end?
• Yoav: responseStart exposes something
• Barry: Significant gap that exposes or not
• Yoav: responseStart doesn’t differentiate between redirects and back-end time
• Noam: With current state, can you consider an opt-out instead of an opt-in
• Yoav: Breaking change in sense that things would stop working (not user facing)
• … We’d have to be careful for how things are done
• … Considering threat model vs. breakage pain
• … Opt out not as useful here.  Origin sets its HttpOnly cookies on purpose, I want them to stay out of JavaScript.  But endpoint exposes this information somehow.
• … Endpoint not allows attacker to extract that information
• … Those endpoints should be fixed then
• … If we decide this is an actual threat, we can decide if implementations want to do this breaking change
• Barry: My experience is you want to hide the value rather than there is a cookie
• … Not much value in breaking change closing this gap
• Franco: The idea is we could already time redirects, is there no new information here?
• Yoav: Whether this is new information or not depends on your site’s structure.  Exposing redirects can expose secrets to the site.  Because we’re not exposing redirects or URLs or header contents, only that they happened, so any information we’re exposing here is around existing HttpOnly cookies, or URL-related secrets that are a function of that.
• … State that the server is aware of that the site is not, mostly HttpCookies
• … Whether they’re exposed is if a site’s endpoints do different things based on the existence of HttpCookies.  Doesn’t expose their value in any way.
• Franco: We only have timing?
• Yoav: redirectCount and timing information, that’s already something web developers should protect against
• … Only exposes existence of HttpOnly cookies
• … We could summarize saying this threat model isn’t exposing novel new problems, it may not be worthwhile going through with a breaking change.

Misc

• Michal: For same-origin navigation we had discussed exposing more information
• … Whether we can redefine navigationStart
• … I wonder if any of today' s discussion helps illuminate what was discussed there
• … https://github.com/w3c/navigation-timing/issues/190 
• Yoav: This is all same-origin data that can be put into e.g. localStorage
• … This will increase usefulness of redirect data
• Michal: If you redefine startTime, all timestamps will change.
• … But just adding new attribution (opaque duration or negative timestamp) is less difficult
• Yoav: We talked about #160 as a way to expose redirect time as a duration
• … Pain in compat
• … Pre-navigation time as a duration, shouldn’t be significantly impacted by discussion today
• ... One way to solve #160 is to align WebKit on not exposing responseStart on any cross-origin redirects
• Barry: But that exposes there’s at least one X-O redirect
• … responseStart can be proxied as the very first thing in the head
• Michal: Soft Navs project, should we align with existing behavior which is more complex.