Establishing consistent opt-ins to expose resource metadata

*[Apologies for the broad distribution of this email. I included several
people with whom we've touched upon this topic over the past year and
cc'ed public-webappsec@w3.org <public-webappsec@w3.org>]*

Hey everyone,

I'd like to start a discussion about an area that has so far been fairly
inconsistent, and could use some collective brainpower to clean up; namely,
the issue of allowing the embedder of a resource loaded in `no-cors` mode
to learn some metadata about the resource, such as its size, load timings,
or the resource's intrinsic properties like image dimensions or orientation.

In brief:
For the last decade, CORS
<https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS> has allowed
exposing the contents of a resource to allowlisted cross-origin requesters.
With the launch of CORP
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)>,
we've gained a switch that lets sites control the embedding of no-cors
resources (e.g. images, scripts, or stylesheets); we're requiring an opt-in
via either of these two mechanisms for a resource to be available to
crossOriginIsolated <https://web.dev/coop-coep/> pages with access to
powerful features such as `SharedArrayBuffer` via the COOP+COEP
<https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit>
restriction.

However, a case that we haven't entirely figured out is how a resource can
opt into exposing metadata about itself to a cross-origin requester: CORS
reveals the entire response contents, and CORP gives permission to be
embedded, but doesn't automatically mean that the loader should be able to
learn anything about the resource via web-level APIs. A few examples of
this:

- The recent discussion about the `image-orientation` property in CSS (
https://github.com/w3c/csswg-drafts/issues/5165) outlined several possible
cross-origin information leaks and proposed gating image metadata on
header-based opt-ins (either purpose-specific, or a more general
`Metadata-Allow-Origin` header proposed by Camille).

- During a review of the `performance.measureMemory()
<https://web.dev/monitor-total-page-memory-usage/>` proposal -- meant to be
gated behind COOP+COEP -- Nasko asked whether a resource opt-in via CORP is
sufficient to reveal its size via an explicit API.

- The Resource Timing API defines the `Timing-Allow-Origin` header (
https://w3c.github.io/resource-timing/#sec-timing-allow-origin) which lets
a resource reveal its detailed load timings via `window.performance`. Yoav
covered this in his recent talk (https://www.youtube.com/watch?v=xVtli3mmBc4);
in related conversations we also threw around the idea of adding
`Size-Allow-Origin` to similarly opt into revealing resource sizes.

I'm worried that leaving the decision to individual features will result in
compounding inconsistency, which we should try to avoid. I can think of a
few ways to tackle this:

1. Use individual, per-feature HTTP headers to allow exposing individual
properties of the response, or a single header (e.g. `Metadata-Allow-Origin
<https://github.com/w3c/csswg-drafts/issues/5165#issuecomment-660008702>`
to collect opt-ins into a single header. If we do this, we could merge
`Timing-Allow-Origin` into this header.

2. Use the presence of CORP as a signal that (some) metadata about the
resource can be revealed. This seems scary at first glance, but setting
CORP already serves as an opt-in to allow the resource to be embedded in
COOP+COEP contexts, which may be able to read the whole resource from their
process memory -- developers shouldn't set CORP: `cross-site` on
authenticated responses that they're worried about leaking cross-origin.

3. Extend Mike and Kinuko's Resource Policy proposal (
https://github.com/mikewest/resource-policy/blob/master/README.md) to
combine the two approaches above. Specifically, with an extended syntax, we
could have the header specify both _who_ can embed a resource, and _how_
the resource can be used.

It would be nice to see if others who've thought about this have opinions
about if and how we could improve this.

Cheers,
-Artur