- From: Mike West <notifications@github.com>
- Date: Thu, 28 Jan 2021 01:24:43 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/582/768919036@github.com>
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
Received on Thursday, 28 January 2021 09:24:56 UTC