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

Shane & David,

 

I agree that is a valid use-case. I wonder if it would be possible to only
allow the frame WWUGE if it was in the context of an onclick handler, i.e.
when someone clicked on it. Safari does something similar to let through
third-party cookies on responses to POSTS only after user interaction, when
they are disabled by default. This would led advertisers handle it inside
their frame, but stop it happening invisibly.

 

 

Mike

 

From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
Sent: 05 December 2012 15:55
To: Mike O'Neill; 'David Singer'
Cc: public-tracking@w3.org
Subject: RE: ISSUE-187 - What is the right approach to exception handling &
ISSUE-185

 

Mike and David,

 

It makes sense to me that Site-Wide Exception calls occur from the top-level
domain (but can come with a list of domains under the 'same party' resource
and/or use wildcards).  For web-wide exceptions, we'll need to allow calls
to occur from within iFrames for the requesting domain.  For example,
AdNetworkABC should be able to produce an overlay on their ads requesting an
exception and if users grant the exception they should be able to register
that with the UA immediately (all while not requiring the user to leave the
current page and not requiring the 1st party to intermediate the
transaction).

 

- Shane

 

From: Mike O'Neill [mailto:michael.oneill@baycloud.com] 
Sent: Wednesday, December 05, 2012 3:50 AM
To: 'David Singer'
Cc: public-tracking@w3.org
Subject: RE: ISSUE-187 - What is the right approach to exception handling &
ISSUE-185

 

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, 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. 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. 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. 

 

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. 

 

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 <
<mailto:michael.oneill@baycloud.com> 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.