[w3ctag/design-reviews] "credentialless" embedder policy. (#582)

Guten TAG!

I'm requesting a TAG review of a "credentialless" cross-origin embedder policy mode.

Today, `COEP: require-corp` exists, and is used to enable cross-origin isolation (and therefore `SharedArrayBuffer`, etc). It is functional and solid, but turns out to be difficult to deploy at scale, as it requires all subresources to explicitly opt-in. This is fine for some sites, but creates dependency problems for sites that gather content from users (Google Earth, social media generally, forums, etc). https://github.com/mikewest/credentiallessness/ suggests an alternative that might have better deployment characteristics: strip credentials from outgoing requests by default, and send them only for CORS-enabled requests. In this model, resources would either explicitly opt-into sharing themselves with the requestor, or would be low-risk, insofar as it's less likely to contain personal information if browser-controlled identifiers like cookies aren't included.

  - Explainer¹ (minimally containing user needs and example code): https://github.com/mikewest/credentiallessness/

  - Security and Privacy self-review²: _Let me get back to this when we're further along... It should be strictly positive._
  - Primary contacts (and their relationship to the specification):
      - Mike West (@mikewest), Camille Lamy (@camillelamy), Ian Clelland (@clelland)
  - Organization/project driving the design: Google
  - External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): Nope.

Further details:

  - [X] I have reviewed the TAG's [API Design Principles](https://w3ctag.github.io/design-principles/)
  - The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG, or just WHATWG PRs, as it might not be complicated enough for an entirely separate doc.
  - The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG (this would live in HTML (and maybe bits in Fetch?))
  - Existing major pieces of multi-stakeholder review or discussion of this design: This is it. Being my favourite standards review body, y'all are first on my list.
  - Major unresolved issues with or opposition to this design: None (yet!).
  - This work is being funded by: Google

You should also know that: the subresource bits of this proposal seem pretty clear to me, and I have some reasonable amount of confidence that they make sense. Frames are harder, and I'd appreciate y'all's thoughts. I'd also appreciate your help weighing the impact of non-cookie based ACLs, and the potential dependency upon CORS-RFC1918 (which y'all are reviewing in https://github.com/w3ctag/design-reviews/issues/572. It might also be helpful to review conversations like https://github.com/whatwg/html/issues/4175#issuecomment-466047231 where @clelland originally surfaced this suggestion.

We'd prefer the TAG provide feedback as:

  💬 a **comment in this issue** and @-notify the folks above.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/582