Re: ISSUE-187 - What is the right approach to exception handling & ISSUE-185

On Dec 5, 2012, at 3:49 , Mike O'Neill <michael.oneill@baycloud.com> wrote:

> Hi David,
>  
> What I meant was that the site specific call only makes sense to be executed by script running in the context of the top-level window,

I still don't get why you say that.  It seems to me that a site like Yahoo! that has a resonably small set of owned domains with distinct names ought to be able to build a page that has frames from those domains, each of which requests a site exception (when agreed by the user).  I don't see any upside to requiring that only the top-level domain can ask.

remember, this won't be a content page, but a page specifically built to ask for and obtain and register exceptions.

> because a call made in the context of a frame would, in use, only create an exception when the domain in the frame document origin was accessed as a first-party i.e. the URI in the address bar contained the frame’s domain.

That's true, but still useful.

> So even if the call (in the frame’s context ) was made erroneously, any downside would be limited because it would only apply to that particular domain.
>  
> What I was suggesting was that in the web-wide case the UA would only grant the exception if the document origin (of the API caller) was the same as the top-level origin, so limiting the exception grant to script running in first-party context.

Again, if a social network got into the same state as Yahoo here, and had multiple domains that are affiliated but had unrelated names, why should it not be able to make a page of frames for each of them?

> My only further point was that the site specific call might as well have the same restriction, because the ability for frames to make exceptions for their own domains (when they are later accessed as first-parties) appeared to be not very useful.

I think it's hugely useful in both cases.

>  
> This issue only arises because the new API is synchronous so there can be no check with a UA UI that the exception actually does reflect the user’s wishes, and bad actors may wish to secretly acquire web-wide exceptions for their domains – especially if, as we hope, it becomes the standard way consent is signalled.

If that happens, I am quite sure UAs will start flagging it.

>  
> Third-party content providers can always supply script that is executed in the top-level context, in fact that is how many third-party elements are added now, so this should not be a problem for the advertisers.
>  
> Mike
>  
>  
>  
>  
>  
>  
>  
> From: David Singer [mailto:singer@apple.com] 
> Sent: 05 December 2012 00:45
> To: Mike O'Neill
> Cc: public-tracking@w3.org
> Subject: Re: ISSUE-187 - What is the right approach to exception handling & ISSUE-185
>  
>  
> On Dec 4, 2012, at 2:05 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> 
> David,
>  
> The SS and WW UGE  situations are different because in the former a  frame can get an exception for itself but only in the context of the frame’s domain when (later) it is the top-level origin. In the WW case the exception applies everywhere so the effect is greater.
>  
> Letting a frame make an exception for itself when it is accessed later as a first-party is relatively benign, but seems a bit pointless.  Maybe the top-level origin compare should be for both (if we decide we need it).
>  
> The top-level origin compare is only at time of USE of an exception, and doesn't make sense for web-wide, as web-wide means it's for any top-level origin.
>  
> Maybe I am not with you.
> 
> 
>  
> Mike
>  
>  
>  
> From: David Singer [mailto:singer@apple.com] 
> Sent: 03 December 2012 23:03
> To: public-tracking@w3.org
> Subject: Re: ISSUE-187 - What is the right approach to exception handling & ISSUE-185
>  
> Hi Mike
>  
> this is an aspect that didn't actually change in this re-write, but responding nonetheless.
>  
> On Dec 2, 2012, at 3:28 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> 
> 
> David,
>  
> I think the new API is fine for site-specific exceptions, because we are putting the responsibility to get user agreement on sites where it is legally anyway.
>  
> 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.
>  
> No, that's not quite it.
>  
> To *register* the exception, in either case, the call is made from a document whose *document origin* is the site registering.  The top-level origin is not considered at the time of the *call*.
>  
> For site-wide exceptions, that origin is entered into the database as the first parameter, which is later compared to the *top-level origin* when an HTTP request is being made.
> 
> 
> 
> 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.
>  
> Correct.  It's possible for, for example, a consortium of web sites to make a page of frames, each of which gets user-consent and then registers their exceptions.
> 
> 
> 
>  
> Unfortunately this is not true for the web-wide API so it is possible that script inside a child iframe could register an exception, which may not reflect a user’s intention.
>  
> You can always use a frame, in either case, to register; the security is the same.
> 
> 
> 
>  
> If we decide to keep web-wide exceptions under the new UI-less regime it would be safer to limit them to script in the context of top-level origin, which effectively is the situation for site-specific exceptions. I suggest we put a sentence like the following into 6.5.1 (and similar in 6.5.2),
>  
> The web-wide exception is only granted if the document origin host of the calling script is the same as the top-level origin host.
>  
>  
> Mike
>  
> David Singer
> Multimedia and Software Standards, Apple Inc.
>  
> David Singer
> Multimedia and Software Standards, Apple Inc.

David Singer
Multimedia and Software Standards, Apple Inc.