Ok, I know this is going to sound like heresy, but I'm thinking a window opened by a non-secure context via window.open or <a target="_blank"> should still be considered a secure context.

I agree that an HTTPS iframe embedded in an HTTP page should not be considered secure, since that gives you an invisible and automatic way of creating a channel between the two, but window.open and <a target="_blank"> are visible, and both require a user interaction.

Imagine https://example.com contains:

<iframe src="https://secure-proxy.example.com/proxy">
<a href="https://secure-proxy.example.com/worker" target="_blank" rel="noopener">Click me</a>

The iframe is non-secure, but the opened tab is secure. The secure opened tab can perform secure actions, and send it to the non-secure iframe via any origin storage, BroadcastChannel, or in a hacky way SharedWorker (since its security is decided by the document which creates it).

If we drop the parts of the spec that take opener into account when deciding if the context is secure users get a more consistent experience when following links, as their seemingly top-level contexts are consistently able to access powerful features.

The alternative, to combat the above, is to add isSecureContext to the origin identifier. Meaning otherwise secure contexts opened via target="_blank" are a different origin to contexts opened to the same URL via target="_blank" rel="noopener". But that exacerbates the weird user experience.