Why are documents with insecure frames treated as secure contexts?

[arturjanc]

In example 4 the spec says:

If the non-secure context can obtain a reference to the secure context, or vice-versa, then the new window is not a secure context.

However, in example 6 an HTTPS origin with an insecure frame is treated as secure, despite the fact that the HTTP frame can get a handle on its top document. In the scenario with an active network attacker it seems these two situations are equivalent when it comes to security, yet the spec makes different decisions about the security of the HTTPS document.

Perhaps this should be made consistent (likely erring on the side of being more restrictive).

[mikewest]

We generally allow user-override to trump theoretical soundness. Since non-secure frames are blocked by default, the user would have to do something intentionally to allow the frame to load. In the same way that we treat clicking through a TLS interstitial as validating the site's cert, we treat explicitly allowing non-secure frames as totally cool. shrug

(FWIW, in Chrome, we don't even show UI for this scenario anymore; we just block the frame without visible recourse. To load the frame, you'd have to set a command-line flag at startup.)

[arturjanc]

This works for me :)