RE: action-334, issue-112, a summary on sub-domains for exceptions

Nick,

Thank you for capturing all of the suggestions to date.

My concern is that Site-Wide exception listings could become excessive if we don't allow for a suffix wild-card (as you and Ian have pointed out).  In my original proposal there were allowances for both suffix and sub-domain wildcards to cover these cases.  For example, *.yahoo.* would cover the imaginable world of non-sub-domain use cases and disallow bad actors (a root domain will always be required to avoid the *.* outcome).  There will always be the risk that a Server submits an exception in either direction (sub or suffix) that is inappropriate but as this creates a formal record of the exception I believe this risk is low (and highly addressable if ever discovered).

- Shane

-----Original Message-----
From: Nicholas Doty [mailto:npdoty@w3.org] 
Sent: Wednesday, November 28, 2012 9:09 AM
To: public-tracking@w3.org (public-tracking@w3.org)
Subject: action-334, issue-112, a summary on sub-domains for exceptions

To summarize a little on ISSUE-112 [0] and the applicability of exceptions to subdomains:

User-granted exceptions follow the model of origin pairs, a first party and a third party (as determined by their domains/document origins). For a site-wide exception, a user is granting an exception (subsequently sending DNT:0) for some or all third-party requests for the corresponding first party. For a web-wide exception, a user is granting an exception for all requests to a particular third party.

Because parties (as defined in the Compliance doc) don't and won't match perfectly to domain origins, there have been requests to extend the breadth of these exceptions (measured in domains) to sub/sibling domains or other origins altogether. 

For defining the breadth of the first-party part of a site-wide exception:
Ian argued against using the cookie rules for sub-domains (because of the uncertainty of the domain registry model) [1] and for similar reasons I had suggested (based on our conversations in Bellevue) that we use origins, as defined in rfc 6454 [2]. Sub-domains can be both too broad and too narrow to match a party, and they often indicate different contexts.

Shane suggested that we instead add a parameter to the site-wide exception request so that first parties can indicate whether they want the exception to cover a all sub-domains or a list of sub-domains [5]. To pick up on Ian's suggestion, that could even be a list of entirely separate origins (google.de as well as google.com, say) in the same party. I believe that in addition to being harder to implement and potentially confusing users (to which context does this request apply?), similar functionality could be better implemented by user agents through use of the same-party parameter. As Ian pointed out, that list may change, perhaps frequently. 

For defining the breadth of the third-party part of a Web-wide exception:
Vinay has pointed out that third parties may want to ask for a Web-wide exception for their tracking services across the Web and that those services might use different sub-domains, perhaps specifically to provide a level of privacy based on cookie siloing [3]. To address that use case, I suggested in August (and still suggest!) that we add an optional parameter to the request for Web-wide exceptions to include sub-domains of the calling origin, with the explanation that it be used only to include other subdomains of the same party [4]. I believe that is a relatively small change.

Suggested changes:
* Add an optional, default=false parameter `includeSubdomains` on the Web-wide exception method.
* Indicate in non-normative text that user-agents can extend a site-wide exception request to a broader first party, and explain how.

To implement Shane's suggestion (which per the above I believe to be unnecessary at this time), we would additionally change:
* Add an optional, list parameter `partyDomains` (or something that sounds better), and adjust the requirements on sending DNT:0 to include those domains in the pairs additionally.

Thanks,
Nick

[0] http://www.w3.org/2011/tracking-protection/track/issues/112
[1] http://lists.w3.org/Archives/Public/public-tracking/2012Jul/0137.html
[2] http://lists.w3.org/Archives/Public/public-tracking/2012Jul/0104.html
[3] http://lists.w3.org/Archives/Public/public-tracking/2012Aug/0145.html
[4] http://lists.w3.org/Archives/Public/public-tracking/2012Aug/0191.html
[5] http://lists.w3.org/Archives/Public/public-tracking/2012Jul/0165.html

Received on Wednesday, 28 November 2012 17:46:21 UTC