Questions about COOP/COEP and secure context

[zcorpan]

In COOP there's this statement

This should only work over a secure context.

COEP doesn't have an equivalent statement.

Although I first just wanted to file this to ask whether the inconsistency is intentional, I have a few more questions:

• Why does COOP have that statement?
• Where is it enforced in the processing?
• Can secure context change during the lifetime of a Document (due to mixed content or so)?

cc @jugglinmike @annevk @mikewest

[mikewest]

Why does COOP have that statement?

I assume COOP has that statement because of https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/. We should probably lock COEP to secure contexts too if we haven't already. It's a clear minimum bar for security.

Can secure context change during the lifetime of a Document (due to mixed content or so)?

As currently defined, no. Mixed Content doesn't affect secure contextness. I have some ideas about improvements we can make over time, but I would expect them to have the same property: we make decisions about secureness at the time we commit the document, and lock it for the document's lifetime.

[zcorpan]

Thanks, @mikewest!

Although I support disallowing new powerful features in non-secure HTTP, I'm not convinced that it always makes sense. For COEP and CORP, you get to opt in to blocking things. If we apply "this is a new feature, pretend it doesn't exist for HTTP", couldn't that allow an attacker to embed an HTTPS resource that had opted in to disallow embedding?

The secure context question is also discussed a bit here: Cross-Origin-Opener-Policy explainer

[mikewest]

Assuming that the HTTPS resource sends either Cross-Origin-Resource-Policy: same-site; or Cross-Origin-Resource-Policy: same-site;, it can't be loaded by an HTTP context (as no HTTP context will be match either of those declarations (see step 5 of the existing https://fetch.spec.whatwg.org/#cross-origin-resource-policy-check and the note in step 7 of https://mikewest.github.io/corpp/#abstract-opdef-cross-origin-resource-policy-check).

If the response sets CORP: cross-site, then you're right, but it's a resource that's explicitly not restricted. That seems less risky (and wouldn't be prevented by enabling COEP for non-secure contexts).

[zcorpan]

OK, so it seems important to do the CORP check also when the fetch originated from an non-secure context.

[mikewest]

I think that boils down to the question of how much security we should allow HTTP sites to pretend to have. If I could go back in time and kick myself in the butt about allowing SRI and CSP for HTTP pages, I would. :)

[annevk]

I think it's a valid point that CORP cannot be restricted to secure contexts as that would make secure resources less secure.

Not convinced that COOP or COEP should not require secure contexts though. (This thread did make me wonder whether we should have X-Frame-Options: secure-only or some such.)

[zcorpan]

Not convinced that COOP or COEP should not require secure contexts though.

I think it's OK for COOP and COEP to require secure context. But it seems to me it increases overall complexity a bit.

[annevk]

Keeping this as a tracking issue to add the secure context requirement to COEP. And yes, slight secure context branching complexity will exist until everything is a secure context or a network error.

[annevk]

Let's merge this into #4930.