Re: Establishing consistent opt-ins to expose resource metadata

Hey WebAppSec folks,

The WebPerfWG plans to discuss this on Thursday
PT/6pm CET), and we'd love for y'all to join us! (video link

Cheers :)

On Wed, Jul 22, 2020 at 8:45 AM Noam Rosenthal <>

> 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 Monday, 19 October 2020 07:06:06 UTC