- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Tue, 4 Dec 2012 16:37:21 -0000
- To: "'David Wainberg'" <david@networkadvertising.org>
- Cc: <public-tracking@w3.org>
- Message-ID: <04a801cdd23d$bc98a210$35c9e630$@baycloud.com>
Hi David, The UGE API at the moment does not have a parameter to identify what origin is the intended top-level domain, so it has to assume the implicit document origin. If the script is inside a frame the document origin is the frame's document origin, so that is where the exception is applied. Script in windows/frames with different origins are strictly limited from accessing variables in other windows, because of the same origin policy, so it would be hard to specify the parent window's origin anyway (other than doing something like bouncing the Referer header back from the server). Mike From: David Wainberg [mailto:david@networkadvertising.org] Sent: 04 December 2012 15:42 To: Mike O'Neill Cc: David Singer; public-tracking@w3.org Subject: Re: ISSUE-187 - What is the right approach to exception handling & ISSUE-185 On 12/2/12 6:28 AM, Mike O'Neill wrote: The sentence in 6.4.1 (The execution of this API and the use of the resulting permission (if granted) use the 'implicit' parameter, when the API is called, the document origin. This forms the first part of the duplet in the logical model, and hence in operation will be compared with the top-level origin) makes it clear that only script in the context of the top-level origin can register a UGE for the site. If script in third-party embedded iframe makes a SS UGE call, the implicit document origin points to the third-party domain so the exception applies there and not at the parent window's origin. Can someone clarify? Is this true? A party in an iFrame should be able to request a UGE for the top level page context, not the iFrame that it's in.
Received on Tuesday, 4 December 2012 17:06:17 UTC