CCing folks involved in the conversations around this feature.

Nasko, can you triage this into your backlog?

Early thoughts:

- I think CORP is sufficiently different from CORB (also looks at intermediate redirects I think, results in a network error), that it might make sense to
    1) implement a separate //services/network/cross_origin_resource_policy.h/.cc
       that would expose ShouldBlock(net::URLRequest& request,
                                     const ResourceResponse& response,
                                     ...excluded_initiator_scheme???...).
    2) hook it up to URLLoader::OnReceivedRedirect and URLLoader::OnResponseStarted
       as well as equivalents in the ResourceHandler world

- When implementing cross_origin_resource_policy.h might need to reuse some things
  from cross_origin_read_blocking.h (e.g. IsValidCorsHeaderSet) - they should be
  easy to extract into something like cross_origin_policy_helpers.h

- QUESTION: Should CORP apply to requests initiated by
    1) content scripts / extensions
    2) plugins
    3) file: origins
    4) browser process
  I think the answer to all of these should be "yes!".

+rdevlin.cronin@ for the extensions discussion above

mkwst@ can you help me understand the priority of when we want this implemented? Our team is currently lacking any spare cycles, so I'm not sure we will be able to get to this in the near term. In comment #3, lukasza@ has provided enough guidance that I think any other team/dev should be able to implement it and we will be happy to review/consult.

nasko@: I think the priority depends a bit on whether developers are actively going to implement this based on the support that Apple's implemented, and Mozilla's apparently looking into. There's a WebAppSec call tonight, and I'll ask whether any developers are lined up already.

Speaking of developers: Artur! You've suggested in the past that Google's security team probably wouldn't implement this unless it had origin-based lists. Are there endpoints where your team would actually be able to use the `same-origin`/`same-site` distinction? Or do you need more before you can ship it on Google properties?

Actually adding Artur, sorry. Wrong LDAP. :)

We don't have immediate plans to deploy CORP, not so much for the lack of origin-based lists but the underlying problem with visibility of the requesters of resources. Basically, for an arbitrary application on foo.google.com it's possible that its resources are loaded cross-site in the following scenarios:
- ccTLDs (foo.google.co.uk)
- Other Google-owned domains (youtube.com)
- Test / staging instances loading production resources (localhost, other custom domains)  

To use CORP, even with origin-based flexibility, we would first need to enumerate cross-origin requesters of all resources in a given application, which is difficult and doesn't always work; e.g. we could try to collect the Referer header, except that we don't get it from applications which hide it with the Referrer Policy.

I imagine our ongoing work on Sec-Metadata will give us some visibility into which applications have resources which are only loaded same-origin/same-site. In the unfortunate event of not all browsers immediately shipping Sec-Metadata we could use information we get from the request header to set a CORP response header with corresponding logic.

Overall, as a developer, I would be happy to see both CORP and Sec-Metadata broadly supported by browsers. So I think Chrome should implement CORP, Anne should implement Sec-Metadata in Firefox and everyone wins ;-)

 Issue 837379  has been merged into this issue.

Sounds like lukasza@ is looking into implementing this.  Thanks!

I have a WIP CL @ https://chromium-review.googlesource.com/c/chromium/src/+/1416813
(note that it depends on not-yet-landed https://github.com/web-platform-tests/wpt/pull/14907)