Re: Establishing consistent opt-ins to expose resource metadata

+public-web-perf <public-web-perf@w3.org>

On Sat, Jul 18, 2020, 18:42 Artur Janc <aaj@google.com> wrote:

> *[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
>