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

/cc @ArthurSonzogni, who's been thinking hard about this proposal over the last week or three.

> since the explainer is a little light on the details about the risks that push us towards an explicit opt-in for credentialless iframes, could you share some of your reasoning here?

If we posit a world in which frames are _always_ either out of process or sufficiently segregated from their top-level state (via partitioning, or storage blocking, or etc), then I agree with you that forcing them to opt-in to embedding would be superfluous. I also agree that there's some precedent for breaking a frame's ability to access storage it might have expected to be able to access, and I don't actually see much risk in doing so. That is, I think the explainer's option 2 isn't unreasonable.

That does create some complexity, though, regarding requests from the framed page to its own origin. If A frames B, it's straightforward enough to not send credentials along with that request, and to deny B the ability to access cookies and other site data via JavaScript. It's also straightforward to shift the `no-cors` credentials mode default to `omit` to prevent B from sending credentialed requests to B by default. What about `cors` requests, though? It doesn't seem like the server would have any expectation of risk around sending data to itself (and, as written, I think CORS requests would automatically pass, given the same-originness?). That seems like a potential for leakage that isn't well-explored, especially in the status quo world without OOPIF. We could resolve it with a partitioning scheme as you've suggested, but that's a good deal of work for third-party storage that we generally assume is on the way out.

I think my general stance here is that once we are solidly in an OOPIF-all-the-time world, we have a lot more flexibility to remove constraints than to add them. We ought to be working towards that world, and construct threat models that allow us to shift into it, but for the time-being, it seems necessary for us to avoid assuming that such a boundary exists.

-- 
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-774975216