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

So what are the different options for loading `<iframe>`?

## Option 1: Block `<iframe>`, similar to `COEP:require-corp`

Ensure `<iframe>` have a policy stricter or equal to its parent, in this order:
`none` < `credentialless` < `require-corp`.

| Parent \ Child | None  | Credentialless | Require-corp |
|----------------|-------|----------------|--------------|
| None           | Allow | Allow          | Allow        |
| Credentialless | Block | Allow          | Allow        |
| Require-corp   | Block | Block          | Allow        |

**Pros**:
- Easy to implement.
- Similar to existing `COEP:require-corp` mechanism.

**Cons**:
- Hard to deploy. The document must wait for all of its `<iframe>` to deploy `COEP` first.

## Option 2.a: Force `COEP:credentialless` into `<iframe>`

Force at least `COEP:credentialless` in `<iframe>`.

**pros**:
- Easy to deploy

**cons**:
- The `<iframe>` has a small chance of being broken. The main resource was requested with Cookies, but every cross-origin non-cors request made won't have credentials. Maybe a parent might try to abuse this behavior somehow? This doesn't sounds very harmful to me, especially because it influences only cross-origin non-cors requests.

## Option 2.b: Force `COEP:credentialless` + Reverse-XFO.

Same as 2.a, but require the iframe to explicitly opt-in being embedded
cross-origin via `XFO` or `CSP:frame-ancestor`.

**pros**:
- By default, documents that do not wish to be embedded won't have to deal with an embeder breaking them by forcing `COEP:credentialless`

**cons**:
- Moderately difficult to deploy. This still require every embedder to opt-in being embedded. Anyway, this will have to happen either now or after https://github.com/w3ctag/design-reviews/issues/578

## Option 3. Load the `<iframe>` without credentials (navigation + subresources)

Load the `<iframe>` main resource without credentials. In the `<iframe>`, load every subresources (including CORS and same-origin) without credentials.

**pros**:
- Easy to deploy.

**cons**:
- The <iframe> is not able to make credentialled requests at all, even the same-origin or CORS one. It might be broken. This is very impactful compared to touching only cross-origin non-cors requests.
- Harder to implement. A new "credentialless" iframe mode must be introduced, in addition to the policy applied to the parent.

-----------------------

**My opinion:**
(1) is easy to implement. It is the strictest option. It will still be possible in the future to make it laxer. The opposite would be harder.

However, if our motivations is to ease deploying `crossOriginIsolated`, then I believe the bar is still very high. Option (2.a) seems like a good choice. I don't really believe "forcing" COEP can be used in a very harmful way.

I don't think option 2.b with Reverse-XFO bring much. Especially if we want to bring this behavior globally, as part of:
https://github.com/w3ctag/design-reviews/issues/578.

Option 3 from @arturjanc is also a good solution that would make deployment very easy. (2.a) is easier to implement however.

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