Proposal: CORS means TAO by default

[noamr]

See this conversation

I think it's time we consider CORS resources as if they have TAO by default. This will allow the document to receive timing information of resources for which the document can already read the data.

Since the intention of CORS is usually to protect user-private information, and in this case the user data is already passed to the document, there is no particular reason to hide the timing information.

We can consider having an opt-out (Timing-Allow-Origin: none ?) which preserves the current "Give me the data but not the timing" option for servers that wish to specifically hide their user-specific timing information while allowing user data.

[noamr]

@yoavweiss @annevk @mikewest @achristensen07
thoughts?

[mikewest]

I think CORS can/should imply TAO for resource-level information around timing and size, but my comment in that previous thread still feels relevant:

I think we also questioned whether TAO can be reasonably interpreted as giving you access to network-level data. That still seems strange to me, given that it reveals data about conditions well beyond a given server's control.

CORS can't enable that (and, IMO, neither should TAO), as it isn't under the server's control, nor is it philosophically within the server's power to reveal. As Anne noted in that thread, this is a more fundamental concern about the access TAO provides.

[yoavweiss]

I agree with @mikewest. When we discussed this, we concluded that resource-level timings are fair game, while origin-level timings need to remain TAO-opted, and network-level timings may be something that even TAO shouldn't expose.

So, I'm supportive of CORS implying resource-level timing exposure.

[noamr]

I agree with @mikewest. When we discussed this, we concluded that resource-level timings are fair game, while origin-level timings need to remain TAO-opted, and network-level timings may be something that even TAO shouldn't expose.

So, I'm supportive of CORS implying resource-level timing exposure.

Which attributes would you considered as "resource-level timing"?

[achristensen07]

My initial thought is that we already have a way for a server to expose its timing information, and if the server chooses not to expose that information we should respect that as is the status quo. I'm skeptical of what would motivate making CORS imply TAO.

[yoavweiss]

@achristensen07 - The monitoring benefits of making CORS imply TAO are that there's a lot of content out there that's CORS enabled but not TAO enabled, and while we could urge developers to also add TAO to it, the odds of success for that aren't great.
At the same time, CORS support already enables attackers to get all that timing information about the resource by other means (by fetching it), so requiring a TAO opt-in on top of CORS seems like it doesn't add any user protections.

[yoavweiss]

Which attributes would you considered as "resource-level timing"?

@noamr - from my perspective, resource-level timings include: redirectStart, redirectEnd, requestStart, responseStart, transferSize, encodedBodySize and decodedBodySize.

[noamr]

Which attributes would you considered as "resource-level timing"?

@noamr - from my perspective, resource-level timings include: redirectStart, redirectEnd, requestStart, responseStart, transferSize, encodedBodySize and decodedBodySize.

Why should redirectStart be more protected than secureConnectionStart? How is one of them more/less revealing about the user?

Note that CORS/TAO only protects user-specific information - you can connect to the server yourself (from your server) to probe anonymous connection information.

redirectStart, for example, can reveal in some cases if the user is logged in, while in the data retrieved via CORS the server can decide whether or not to reveal that information depending on the caller, or to send an error in the JSON instead of a CORS failure.

[noamr]

OK, I see a point here.

• transferSize, encodedBodySize and decodedBodySize are all observable as part of the resource anyway
• redirectStart, redirectEnd, requestStart, and responseStart are also observable today - you can create a fetch to the resource with {redirect: manual} or with sending/receiving a stream rather than a full resource and measure them yourself.

So really all these attributes (anything outside the connection info) are observable as long as you can fetch the resource (CORS-same-origin), and TAO-hiding them doesn't add a layer of protection, only some inconvenience.

[noamr]

See w3c/resource-timing#220 (comment), proposed a more elaborate plan to allow some of the attributes in CORS/CORP and remove some attributes from cross-origin resources altogether.