W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2013

Re: [whatwg] `window.location.origin` in sandboxed IFrames.

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 23 Jul 2013 20:06:47 +0000 (UTC)
To: Mike West <mkwst@google.com>
Message-ID: <alpine.DEB.2.00.1307231953030.9685@ps20323.dreamhostps.com>
Cc: whatwg@whatwg.org, Adam Barth <w3c@adambarth.com>
On Thu, 10 Jan 2013, Mike West wrote:
> In WebKit, loading '<iframe sandbox="allow-scripts" 
> src="frame.html"></iframe>' with a framed document containing 
> '<script>alert(window.location.origin);</script>' alerts the actual 
> origin of the document, which wasn't what I expected. I'm not sure 
> what's intended, but I expected that treating the framed document as 
> existing in a unique origin would have some effect on the string output 
> as it's location's origin.
> Adam explained that WebKit currently treats the 'origin' attribute as 
> the origin of the document's location, not the origin of the 
> document[1]. This is generally benign, but surprised me in the sandboxed 
> case.
> What should the expected behavior in this case be? Given the way that 
> MessageEvent sets the origin of a message from a sandboxed frame to the 
> string "null", that seems like a reasonable option here as well.

I guess we have to decide whether "location.origin" is exposing 
information about the location, or information about the page. Since it's 
on Location, I think it'd make sense to be information about the location; 
document.origin would be where I'd expect information about the page 

When the page's origin doesn't match the URL's origin, the page's origin 
will always just serialise as "null", so it's not clear that it's actually 
useful to expose that really anyway. What would the use cases be?

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 23 July 2013 20:07:14 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC