Re: Establishing consistent opt-ins to expose resource metadata

On Tue, Jul 21, 2020 at 4:54 PM Camille Lamy <> wrote:

> On Tue, Jul 21, 2020 at 11:02 AM Anne van Kesteren <>
> wrote:
>> On Mon, Jul 20, 2020 at 10:46 PM Artur Janc <> wrote:
>> > This is a good point -- it's definitely difficult for developers to
>> understand the impact of revealing a particular bit of metadata about a
>> resource.
>> > I wonder if we could have a tiered embedding model where a more
>> powerful mechanism implies all the capabilities of the less powerful ones.
>> As a strawman, ignoring the reasonable concerns about CORP from above:
>> > CORS >> CORP >> [header(s) to expose individual bits of metadata] >>
>> [regular no-cors loads without any opt-ins]
>> >
> The issue I see with this model is that it is not clear that having access
> to metadata is a less powerful  privilege than setting CORP. To me that
> could be different for each specific resource. Therefore, it seems to me
> that access to metadata is in many ways orthogonal from having access to
> the resource bytes themselves, and doesn't fit well in a linear model.

An example for this is resource-timing. The fact that you're allowing a
resource to be available to an embedder, doesn't mean that you want the
embedder to know the details of how long it took to retrieve it.

I see this as OK, however, if we describe CORP in a very permissive way -
something along the lines of "This is an open resource and the embedder can
know everything about it", applicable for a lot of the content on the web
like CDN-delivered images and common JS libraries.
If CORP (or a different header) is described in this way, An "open"
resource, then the linear approach can still work IMO.


Received on Wednesday, 22 July 2020 06:43:46 UTC