mikewest
commented
7 years ago The intro mentions how an insecure opener can make a settings object insecure. However I can't find this check in the normative sections.
https://w3c.github.io/webappsec-secure-contexts/#settings-object, step 5.2 checks the creator browsing context, which is either the parent browsing context or opener browsing context, depending on what exists.
Note also that there is some subtlety here with regard to window.opener = null. That disowns the opener, but does not null it out; the browsing context still has an opener browsing context.
Right. window.opener = null does not make a context secure. The intent is to not modify a context's state after it's created.
Also, if you want to capture the disowning-ness at navigation time (i.e. not allow settings objects to become secure by disowning their opener) you'll need to do some shenanigans, since the "is secure context" algorithm is run many times, not just on navigation.
As you note above, I don't think there's a way to get rid of an opener browsing context at runtime, so it's not clear to me that caching the result is necessary (though I agree that it's a totally reasonable optimization). Have I misunderstood the mechanisms here?
domenic
The intro mentions how an insecure opener can make a settings object insecure. However I can't find this check in the normative sections.
Note also that there is some subtlety here with regard to window.opener = null. That disowns the opener, but does not null it out; the browsing context still has an opener browsing context.
Also, if you want to capture the disowning-ness at navigation time (i.e. not allow settings objects to become secure by disowning their opener) you'll need to do some shenanigans, since the "is secure context" algorithm is run many times, not just on navigation.
Apologies for brevity and if I missed something; my plane's about to take off...