Use "cross-origin-resource-policy: cross-origin" for timing-allow-origin

[yutakahirano]

https://w3c.github.io/resource-timing/#sec-cross-origin-resources specifies the timing-allow-origin HTTP header. This is similar to cross-origin-resource-policy with "cross-origin" value (specified for cross-origin-embedder-policy; see the spec draft).

Do folks think it is good to use cross-origin-resource-policy instead of timing-allow-origin?

One difference is that you can specify an origin to timing-allow-origin, but you cannot with cross-origin-resource-policy. I don't know whether this is a deal breaker.

• pros (for using cross-origin-resource-policy)
  • Simpler model, simpler spec
  • Better integration with the fetch spec
  • Simpler implementation
• cons
  • compatibility issue
  • cannot specify an origin

@npm1 @yoavweiss @hiroshige-g @annevk @mikewest

[yoavweiss]

We've been thinking about making sure that Timing-Allow-Origin is a subset of CORS. It would be interesting to also think how CORP fits into that.

At the same time, the lack of defining a specific origin seems like a big drawback. While most of TAO usage is just "*" (63.8% of page views), we still see a lot of usage specifying a single origin (7.2%), or several ones (1.2%).

Those numbers would also make removing TAO hard, but that doesn't mean we can't alias those 2 concepts, if that makes sense.

I guess my questions are:

• Is there a reason that CORP cannot define a specific list of origins that it agrees to be embedded into?
• Are there differences in semantics between TAO and CORP? Are there scenarios where it would be scary expose the specific resource size, while being comfortable with its loading in another high-risk process?

For the latter question, I'd naively assume that developers would be more comfortable with CORP than with TAO (and with TAO vs. full CORS access). Do you have a sense if that assumption is an accurate one?

[annevk]

I think what we want to do is add TAO to Fetch and expose on a response (probably through a new internal field) whether a user agent can expose timing information for it. And then we can more easily see if other headers are supposed to give equivalent privileges (and add the relevant tests).

I don't think it makes much sense to remove TAO given that all user agents implement it. Doesn't seem worth the churn.

You'll find issues for expanding CORP in the Fetch repository.

[yoavweiss]

I think what we want to do is add TAO to Fetch and expose on a response (probably through a new internal field) whether a user agent can expose timing information for it. And then we can more easily see if other headers are supposed to give equivalent privileges (and add the relevant tests).

That makes perfect sense!

[npm1]

I agree - we cannot use CORP at the moment. Should this issue be closed then?

[yutakahirano]

SG, I'm closing this.