Surprising inheritance behavior for opened windows

[letitz]

Hi there,

I've stumbled across a corner case in the spec and find the defined behavior surprising.

Example 4 in the spec states:

if a non-secure context opens https://example.com in a new window, that new window will be a secure context, even through its opener was non-secure

This makes some sense - the new window was delivered from a potentially-trustworthy origin, after all.

Now consider the following, slightly modified scenario:

• frame A is a non-secure context, e.g. http://example.org
• frame A embeds a child frame B from a potentially-trustworthy origin, e.g. https://example.org
• frame B opens a new window (frame C) using window.open("");
• frame C's URL is about:blank
• frame C inherits its opener's origin, hence its origin is https://example.org
• frame C has no parent, thus it is a secure context

It seems that frame C should rather inherit its parent's secure context bit?

[annevk]

Note that example 4 is about frame A (i.e., http://example.org) opening https://example.com. Your variant seems like a subset of that case so I'm not sure why it should behave differently?

If this is about https://github.com/antosart/policy-container-explained in some way btw I don't think we should try to shoehorn secure contexts in there. They have a good standalone definition in HTML these days, with some dependencies on this specification. There's just some cleanup work that still needs to happen.

[letitz]

I guess it feels strange to have the new window inherit the origin of its parent but see itself upgraded in terms of security.

Since javascript: URLs commit an about:blank URL, I believe any iframe that sees itself in that situation can circumvent the secure context bit by opening a window with a javascript: URL and executing things there, then sending the results back to the opener window via postMessage().

After having spent some time looking into integrating secure contexts and a policy container, I feel similarly to you.

[annevk]

That's true, popups/new tabs can be used to circumvent some privacy measures as well. They require user activation though and are very much in the user's face. No great solutions there yet other than spreading COOP more.

[annevk]

Closing this as this is by design. Do comment if you disagree and I'll reopen.

[letitz]

I have a follow-up question. Now that #84 has landed and the HTML spec speaks only in terms of creation URLs, I am curious about the following scenario:

• frame A is a non-secure context, e.g. http://example.org
• frame A opens a new window (frame B) to about:blank
• frame B is a secure context, because its creation URL is potentially trustworthy

Am I understanding this correctly? What makes this even odder is that frame B inherits frame A's origin, which is not potentially trustworthy.

[annevk]

Can you file a bug on that against whatwg/html? That needs a fix.

[letitz]

Note that in Chrome 88, frame B is a non-secure context. This behavior is also asserted by web platform tests.

[letitz]

Oh, our comments crossed in the ether. Sure thing, I can file an issue there.