On Fri, Aug 22, 2014 at 4:03 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 8/22/14, 9:58 AM, Mike West wrote: > >> Frames can be navigated to 'about:blank' across origins (via >> window.opener, for instance). >> > > Sure. So for about:blank the origin is what matters. And for sandboxed > about:blank you're really not quite sure where it came from, is that the > issue? Ok. I see your point. We'd allow 'about:blank' for non-sandboxed frames because it inherits the origin. Why wouldn't we then allow it for sandboxed frames. That's a fair question. I don't think there's a relevant difference between those cases. We should treat them the same. Using location won't work, as you've noted. Walking up the chain in a similar way to about:srcdoc would work. > Frames can't be navigated to an effective >> 'about:srcdoc' (I think). >> > > Well, by setting the srcdoc attribute on the iframe, right? Is the claim > that this is ok because only code that's same-origin with the iframe > element can do that? But I thought we were talking about transports, not > origins... If an insecure origin could modify the content of a secure origin by setting the srcdoc attribute, that would be bad. Happily, I don't think that can happen. An insecure origin that's opened by a secure origin can navigate the opener's frames to about:blank, which, if you squint, means that those 'about:blank' frames weren't securely transported. I'm not sure there's much impact to this, as the HTTP origin can't populate that frame. Still. A better example of that situation comes up with content that's been postMessage'd into an HTTPS frame from an HTTP origin (which happens on about 0.1% of page loads according to http://www.chromestatus.com/metrics/feature/popularity#PostMessageFromInsecureToSecure ). -mike
Received on Friday, 22 August 2014 14:22:32 UTC