Re: RESENT: Batch Closing of Issues against TPE [Deadline for validating can-live-with consensus: August 20]

So, a quick review.  We currently have it that a site can request an exception for either (a) a specific list of other sites or (b) all other sites (targets).  In addition, sites can claim to be 'part of the first party' or 'acting a siloed service provider to the first party' in their well-known resource.

HTTP requests to other than the first party might occur through two distinct routes, as well; they might be HTTP URLs embedded in the markup (or written into it by script), or they might be the result of re-directs of those original URLs.

1) What we do not have is a way to signal a whole set of sub-domains of third-parties (targets), such as the *.exampledomain.com example that Shane uses.  
2) Nor do we ask the UA to check the 'same party' status of the well-known-resource of every target, to see if it's in the same party as one who has an exception.
3) Nor do we discuss 'passing the exception'; it's possible for the site in the original URL, when generating the re-direct, to pass on "we have an exception" in the redirected URL.

As Nick points out, the 1st approach has the tarpit of public suffixes to handle.  It's do-able, and user-agents already have the code in their cookie-handling, but it is an ugly tarpit, both in specification and implementation.

The 2nd approach has the huge obvious downside that, before I send the first HTTP request of a given transaction to the target, I have to fetch one or more well-known resources to find out if it's in the party as one who has an exception in this context.  I think it's a non-starter; in the obvious case where there is only one resource requested from each target, we'll double the number of HTTP transactions per page.  Not good.

The 3rd approach does nothing to handle 'original URLs' on the page; it only handles re-directs.   But it is simple, and I think neither expressly permitted nor expressly forbidden by the current spec., and hence implicitly permitted.


Do we expect to need exceptions to cover lots of target sub-domains because the markup or script makes those URLs, or is it more for the case that we ask from an ad from ad-example.com, and it re-directs to us1.ad-example.com, and it re-directs to robin122.ad-example.com?  If it's all re-directs, maybe (3) handles it?

On Aug 20, 2012, at 10:15 , Shane Wiley <wileys@yahoo-inc.com> wrote:

> 
> From: Shane Wiley <wileys@yahoo-inc.com>
> Subject: RE: ACTION-201 (ISSUE-112)
> Date: July 26, 2012 21:51:28 PDT
> To: 'Nicholas Doty' <npdoty@w3.org>, "'ifette@google.com'" <ifette@google.com>
> Cc: "'public-tracking@w3.org Group WG'" <public-tracking@w3.org>
> 
> 
> Wouldn’t it be possible for the 1st party to request the sub-domain breadth of site-specific exception that meets the 1st party definition in the argument of the request? 
>  
> Site-Wide Exception (one domain, all subs):  *.exampledomain.com
> Site-Wide Exception (one domain, single sub):  sub.exampledomain.com
> Site-Wide Exception (one domain, multiple subs):  [list].exampledomain.com
>  
> This somewhat follows the multi-domain list concept in the TPE.
>  
> Most websites will rely on the first structure and the 2nd two structures can be collapsed to the [list] approach (example #2 could be supported by a list of one entry).
>  
> This does create a window of opportunity to “over request” for an exception but we can hold the 1st party accountable for an inappropriate request.  I don’t want to be hampered by the fear of misuse by bad actors in creating a solution that appropriately matches the real-world.
>  
> I don’t believe an exception would need to branch at the protocol level (HTTP vs. HTTPS) – does anyone have a real-world example where the secure element of a sub/domain pair is not owned & operated by the same 1st party of the non-secure element?
>  
> - Shane
>  
> From: Nicholas Doty [mailto:npdoty@w3.org] 
> Sent: Thursday, July 26, 2012 7:04 PM
> To: ifette@google.com
> Cc: public-tracking@w3.org Group WG
> Subject: Re: ACTION-201 (ISSUE-112)
>  
> On Jul 25, 2012, at 8:36 AM, Ian Fette (イアンフェッティ) wrote:
> 
> 
> "How are sub-domains handled for site-specific exceptions?" - from a browser standpoint, I don't wish to further propagate the notion of "registry controlled domains" which is an unfortunate reality that we currently have with cookies, where browsers try to keep a list of what is a "public suffix" (contains multiple unrelated entities beneath it, such as .com). We have ~6,800 entries in there so far (http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1) - this is only getting worse now that ICANN has, in a rather questionable move (personal opinion), decided to make the top-level domain namespace a wild west. 
>  
> So, I don't want to say "all subdomains" because we have no idea what that means.
>  
> Rather, I would prefer to say "A site can request a site-wide exception for its own origin and any other origins that it considers to also be in the same party, e.g. http://www.example.com could request a site-wide exception for http://www.example.com, https://www.example.com, https://example.com, https://mail.example.com,https://www.example.de, http://www.example.de"
>  
> Sadly, I fear this is going to become nightmarish as sites add and delete origins over time ("Hey, now we're http://search.google!" or "Hey, we just launched example.az" or "newproduct.example.com"). That said, I've got nothing better to offer... 
>  
> I certainly agree this could get nightmarish. What if we indicate that as a semantic matter, an exception is requested for the effective script origin (a la [0]) and then note that user agents might provide users with the option to automatically extend/persist such permissions on other affiliated origins? We could note the use of the "same-party" field in the tracking status resource (or, for that matter, OUR-HOST [1]) and if browsers implement this technique, that would provide an incentive for sites to document their party relationships.
>  
> It sounds like there's agreement that exception requests should not extend to sub-domains, given the uncertainty over what a sub-domain implies.
>  
> Thanks,
> Nick
>  
> [0] http://lists.w3.org/Archives/Public/public-tracking/2012Jul/0104.html
> [1] http://www.w3.org/P3P/2004/03-domain-relationships.html
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.