Re: Establishing consistent opt-ins to expose resource metadata

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.
>
> It's probably worth having some exposition of this in the eventual
> standard that hopefully makes its way onto MDN and StackOverflow.
>
>
> > As an aside, I like the current formulation of CORP partly because it's
> somewhat underdefined; the header tells you what can happen ("this
> requester can / cannot access the resource") but doesn't imply anything
> else about the resource or its security properties. In a lot of cases, this
> granularity is perfectly fine, because I'd guess that the bulk of resources
> loaded in no-cors mode are static or otherwise not sensitive; attaching a
> security model to this would overcomplicate things. Individual switches
> will be simpler conceptually, but ironically may be harder to reason about
> than "is this a static/boring resource or not?".
>
> Well, you also have to set it for documents.
>
> I definitely see the attraction of a single switch and even having
> that switch be CORP (though we'd need to do some refactoring to track
> it for responses across redirects similar to Timing-Allow-Origin,
> rather than it only being a check for each response we get), but then
> we're getting in the business of having to categorize safe and unsafe
> metadata. Maybe that's going to be the case with the other solutions
> too though. We should write down what this is for and what it is not
> for.
>
>
> > 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.

Of course the linear model is easier to use for developers, and having
finer grained controls might only be useful for developers with a lot of
resources, and confusing for many others...

> In this model, if a resource can be loaded via CORS or opts into CORP, it
> would also let the embedder access resource metadata. Such a model would be
> "uni-directional" and allow developers to expose resource metadata without
> requiring them to set CORP.
> >
> > This is likely a bad idea because it's making assumptions that aren't
> necessarily true (for example that a resource loaded via CORS should reveal
> fine-grained timing metadata). But if *something* along these lines was
> workable, it could make the developer story simpler; e.g. if you have a
> resource that isn't sensitive and allow embedding it via CORS/CORP, that
> would save developers from setting a bunch of different headers for
> different kinds of metadata.
> >
> > But this runs into the concerns mentioned above and I imagine Anne can
> find some flaws in this logic :)
>
> I actually don't mind this model and we in fact reached a similar
> agreement around Timing-Allow-Origin (before CORP, but if everyone is
> okay slotting CORP in I won't stand in the way per above). My more
> general concern is where to draw the line. This is also a problem with
> the same-origin policy (and continues to be, as earlier arguments
> around these features demonstrate) and other policies such as secure
> contexts as everyone deems their feature exception worthy. So basic
> web platform security requires ongoing vigilance by what appears to be
> very few people.
>
> In conclusion, I wouldn't mind starting out with CORP and attempting
> to define safe and unsafe metadata and leave more granular control for
> another day. It'd be great to get input on this from some of the other
> stakeholders.
>