Re: Establishing consistent opt-ins to expose resource metadata

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]
>
> 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.

Received on Tuesday, 21 July 2020 09:02:34 UTC