Provide clear guidelines for what Timing-Allow-Origin should expose

[noamr]

Timing-Allow-Origin (defined in the fetch spec) is a header that signals the user agent that particular timing-related characteristics of fetching a resource should be visible to the requesting origin, irrespective of whether it was requested via CORS.

Since its inception, several new additions were proposed to resource timing, and more often than not it was unclear whether this opt-in is a sufficient signal that it's OK to expose this particular bit of information.

Those so far include exposing content-type, the status code, and content-encoding (see w3c/resource-timing#411 and whatwg/fetch#1796 for the latter).

With each of these, and potentially with future additions in mind, we would like to have a clear general guidelines of what is "OK" to expose for cross-origin resources that are served with the appropriate Timing-Allow-Origin header, what requires CORS, and what has to be same-origin.

There are roughly three ways to go about it (from conservative to relaxed)

1. We don't add more things that Timing-Allow-Origin can expose, as to not overload new meanings on old opt-ins.
2. Timing-Allow-Origin can expose only values that are specifically timing values, as in durations and timestamps.
3. Timing-Allow-Origin can expose anything that is information about the fetch, but is not information about the resource itself. i.e., if the response was cached and retrieved in a service worker you'd get a different result.

Would love to have some collective thoughts about it and reach a guideline before we ship anything new in resource timing.

/cc @yoavweiss @annevk @achristensen07 @camillelamy @arturjanc @ddworken

[annevk]

I think 3 is okay, but note that would make Content-Type and Content-Encoding not okay.

[noamr]

I think 3 is okay, but note that would make Content-Type and Content-Encoding not okay.

For content-type, sure. For content-encoding, gzip etc is resolved in the network fetch and the service-worker saved response shouldn't keep that content encoding (though might still have the header).

[annevk]

It is handled by fetch internally (and at the moment you cannot configure yourself out of that), but it is very much a property of the resource.

[arturjanc]

A while ago we talked about something similar in the context of the Cross-Origin-Resource-Policy header in the Notes on the threat model of cross-origin isolation doc (specifically, the Subresources discussion and the summary).

My simplified mental model of what we landed on is that setting CORP (or, specifically setting CORP cross-origin) can implicitly expose metadata of resource loaded in no-cors mode (say, the Content-Type, or dimensions for images), but not the data (e.g. it shouldn't tell the embedder anything about the contents of the resource itself - that should require CORS).

Extending this logic to TAO, I think it would make sense for it to give access to information related to loading of the resource (e.g. timestamps/durations and potentially cache status), but not the metadata of the resource (such as Content-Type, status code, etc). This seems similar to @annevk's conclusion above, except that I'm less sure about not exposing Content-Encoding because it's not clearly metadata intrinsic to the resource itself and could be seen as information about the fetch of the resource.

OTOH it would a bit strange if Timing-Allow-Origin exposed non-timing information about the resource - this could be a footgun from a security perspective. So I think I land on something between options 2 and 3 above.

[noamr]

Note that TAO already exposes non-timing information about the resource, e.g. nextHopProtocol. However, the fact that we're doing this doesn't mean that we should keep doing it.

@annevk Regarding content-encoding: I see it as 100% something that's to do with the fetch and not the resource. A JSON file or a font has the same content and metadata whether it's downloaded via a gzip stream or a brotli stream or directly. For the browser it's the same resource and content-encoding is a detail relating to how to resource was acquired and not about the resource itself. So I think that saying that content-encoding should be CORS-protected and not TAO-protected is essentially going with (2) rather than with (3) (which I'm fine with).

[annevk]

Pretty sure all Content-* headers are about the resource. In any event, if 2 is also limited to the a fetch, then yes, I guess I'd argue for that.

[noamr]

Pretty sure all Content-* headers are about the resource. In any event, if 2 is also limited to the a fetch, then yes, I guess I'd argue for that.

Yea, (2) is a subset of (3). It's limited to the fetch, and within that only to things that are particularly related to timing.