On Sat, Jul 18, 2020 at 10:42 PM Yoav Weiss <yoavweiss@google.com> wrote:
> +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>]*
>>
>>
>> 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.
>>
> This seems scary for a different reason: developers might set CORP on a
resource in order to enable the embedder to read its metadata, and will
then be exposed to the resource contents being read in COOP+COEP context,
which might not be what they intended to permit. For example, a site
serving a cookie-protected profile photo might be OK with the embedder
reading the image's orientation to display it correctly, but that doesn't
mean they intended to allow Spectre or a similar side channel to read the
contents of the image.
>
>> 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.
>>
> I like how comprehensive it is, but the more use cases it tackle, the more
subtle differences it may create in the way different browsers and
browser versions handle this declarative header-value language. Mistakes we
make in the design of such a header would be harder to mitigate than using
simpler more atomically-defined headers.
To summarize, I believe any of these will do for the purpose of protecting
image metadata like orientation/resolution, which is what I'm currently
involved in, but I lean towards some version of (1) as it states the
permissions more clearly than (2), and is simpler than (3).