On Tue, Jul 21, 2020 at 4:54 PM Camille Lamy <clamy@google.com> wrote:
>
>
> On Tue, Jul 21, 2020 at 11:02 AM Anne van Kesteren <annevk@annevk.nl>
> wrote:
>
>> On Mon, Jul 20, 2020 at 10:46 PM Artur Janc <aaj@google.com> 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.
>