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

Thanks for your comments, @rniwa and @othermaciej:

> I don't think we can let cross-origin content be loaded from local network as @annevk pointed out earlier.

As noted above, the soon-to-be-renamed [CORS-RFC1918 proposal](https://wicg.github.io/cors-rfc1918/) seems like a reasonable solution to this problem, creating an opt-in mechanism similar conceptually to the CORP/CORS mechanism we accept today. If y'all have opinions about that proposal's shape, I'm sure @leitz, et al. would love your feedback in #572.

> What are the key differences? If the intent of this proposal is to opt into a mode that blocks all third-party cookies, then I would be skeptical of the value.

Excellent question! There are two distinctions that seem most relevant:

1. Similar to `COEP: require-corp`, this proposal operates on origins, not sites or "parties". In this mode, `www1.example.com` would not send credentialed `no-cors` requests to `www2.example.com`, meaning that a vulnerability in one application on a site wouldn't create vulnerabilities in another (consider `mail.google.com` and `docs.google.com`, which are insufficiently isolated today).
2. Depending on the framing behavior we end up with, this might be a restriction above and beyond the `requireStorageAccess` mechanisms shipping in Safari, Firefox, and Edge, disallowing credentials for `no-cors` requests even with storage access has been granted.

I take the point about setting developer expectations, however, and I agree that we shouldn't imply that credentials would be sent in violation of a given vendor's policy. Perhaps that boils down to a question of naming? `credentialless-nocors` might promise less?

> Chrome team announced a year ago that they'd do so by default in two years (i.e. a year from now)

We also announced that we're locking `SharedArrayBuffer` behind cross-origin isolation in Chrome 91 (i.e. ~May). This proposal is aimed at addressing a category of sites using `SharedArrayBuffer` today that have difficulty deploying `COEP: require-corp` due to their dependencies.

-- 
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#issuecomment-768919036