Rationalize Resource-Timing opt-ins with CORS/CORP

[yoavweiss]

Following a mailing list discussion and TPAC session, I'm opening up this issue to continue discussion.

At the TPAC session, we:

• Discussed the different categories of information Timing APIs expose and how we can reason about unifying the opt-ins for them.
• Concluded that while CORS does give you access to resource-level information (timing + size), it doesn’t currently provide origin-level or network-level information, so we shouldn’t extend its semantics to include those.
• Discussed whether CORP should enable exposure of resource size, which devolved into a discussion of the semantics of CORP, and whether it implies that a resource can be just embedded or embedded and read.

/cc @arturjanc @mikewest @camillelamy @annevk

[mikewest]

• Concluded that while CORS does give you access to resource-level information (timing + size), it doesn’t currently provide origin-level or network-level information, so we shouldn’t extend its semantics to include those.

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.

• Discussed whether CORP should enable exposure of resource size, which devolved into a discussion of the semantics of CORP, and whether it implies that a resource can be just embedded or embedded and read.

I believe @arturjanc and @camillelamy remain convinced of the position that cross-origin isolation (e.g. COOP+COEP+CORP) should be seen as enabling both embedding and reading no-cors responses that pass through CORB. I'm more skeptical, but my arguments aren't as convincing as I'd like them to be.

I think the question becomes a little harder if we try to push for a cross-origin isolation mechanism that doesn't require opt-in (e.g. the credentiallessness proposal we floated a ~week ago).

We should probably summarize this discussion somewhere public.

[annevk]

Hmm, there's a reason COEP uses CORP and not CORS. Or does "reading" not mean what I think it does?

And on the other side, I'm surprised that TAO would not a subset of CORS. That always seemed fairly okay to me. But maybe the concern here is indeed more about what TAO should give access to, as Mike indicates.

[camillelamy]

Our reasoning is abased on the fact that most of the information about CORP mentions that if you set it to cross-origin, cross-origin resources can read your resource.

Eg. MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP) "cross-origin Requests from any origin (both same-site and cross-site) can read the resource."

So at that point, it would seem that the expectations for a developer that were set is that CORP cross-origin does allow other origins to read the resource.

There's a caveat to that with subframes in SiteIsolation world, where CORP clearly doesn't grant readability. However, for regular subresources, we found that the line between readability and just embeddability was hard to draw and maintain.

[annevk]

Shouldn't the documentation be fixed? As it doesn't really give you the same level of access as CORS. You cannot paint a CORP cross-origin image on canvas and then export it, for instance. The ability to embed/use seems exactly right.

[arturjanc]

Everyone on this thread has already seen and contributed to the doc, but for completeness: The question of whether CORP should be treated as legibility or embeddability, and the consequences of each interpretation, is currently being discussed in the Notes on the threat model of cross-origin isolation doc (PDF).