Re: Action for ISSUE-112: Sub-domain and cookie-like rules

On Jan 23, 2013, at 12:28 , Aleecia M. McDonald <aleecia@aleecia.com> wrote:

> To pop to conceptual for a moment, the reason I was interested in this issue is because in the Compliance spec we were careful not to define the edges of a site based on what lives under, say, acme.*.com  (aka "cookie-like rules," as Adrian has suggested.)
> 
> There are two reasons for this. 
> 	0. Some sites have domains with different names, but they are all part of the same site and should not be treated as third parties. For example, img-acme.com and acme.img.com _should_ be treated the same in any sane universe, but would not be if we blindly follow scoping. Specifically, img-acme.com would be treated as a third party when it is not. Of note: this detail is one of the top frustrations with P3P CPs, and has caused real problems in real life. Let us please use that implementation experience as we design DNT.
> 	1. Some sites are actually in fact third parties, but do not appear to be based on sub-domain names. One example offered here is that analytics.apple.com turns out to actually be (Google? Adobe? I've forgotten, sorry) rather than Apple. I know of other non-Apple examples, with at least one case not from an analytics provider. Bottom line, we cannot assume that acme.*.com is all Acme, and ought find a way for Acme to say "not me" when making promises about privacy.
> 
> Our answer on the Compliance side was to let sites figure out for themselves where their edges are. Roy has repeatedly suggested a list of subdomains so we could still programmatically deal with the edges of a site. This is a fine idea, IMHO. JC has, at various times, voiced concern that an array of subdomains would not work for Microsoft because they have so many they could not possible keep track of changes over time. I think there may be ways to address JC's concerns with a tiny bit more complexity. Rather than an array of all sites, why not list the exceptions to the general rule? That is, define your site as acme.*.com by default, and then have syntax for + img-acme.com and - analytics.acme.com for those sites that need them. Browsers can then rely on that list and away we go. 
> 
> JC, Roy, Adrian, and David Singer -- would this work well enough for you?

I think that the lists in the well-known resource are useful, yes, but the presumption of same-party if two sites share a non-public-suffix is reasonable.  I think it would be onerous to require explicit declaration of all sub-domains when they share a non-public-suffix.

The case you cite of analytics.X.com is, in fact, a case where that site is under a strict service agreement, and Roy has vehemently and repeatedly argued that it should not be required to identify itself as a service provider, and I agree.  From the user's point of view, it is functionally the same as the owning party.

The suggestion I wrote actually avoids many of the cookie problems, specifically, the public suffix database.  It has the slight downside that the document that loads the script that registers the exception has to come from a site that is 'as high as needed' in the sub-domain hierarchy of the publisher, but in return for that we get to avoid public suffix checking.

So, for example, www.example.com would register the exception from example.com, and thereby automatically include www.example.com, images.example.com, teenagefantasy.example.com, and so on.

If an explicit list of 'treat these as part of my party' is supplied, the risk that a public suffix is included rises.  But I tried to express that it should be possible to verify by fetching same-party resources, and indeed I should have written that the UA can reject requests with public suffixes in the list.

So, I think my proposal and yours are very close.  Register from x.y.com, and you get, free *.x.y.com as well.  Add a list of q.com, d.org, and y.net, and (subject to verification) you get *.q.com, *.y.net and *.d.org free as well.  Verification can involve (a) confirming same-partiness and/or (b) non-public-suffixness.


> 
> 	Aleecia
> 
> On Jan 22, 2013, at 1:22 AM, David Singer <singer@apple.com> wrote:
> 
>> 
>> On Jan 21, 2013, at 19:20 , Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>> 
>>> * David Singer wrote:
>>>> interface NavigatorDoNotTrack
>>>> {
>>>> integer storeSiteSpecificTrackingException (optional sequence<DOMString> arrayOfSameParty, optional sequence<DOMString> arrayOfTargets, optional optional siteName, optional optional explanationString, optional optional detailURI);
>>>> };
>>> 
>>> For what it is worth, you can expect to be told to use a "dictionary"
>>> parameter instead of positional arguments for this, so authors can call
>>> this like `storeSiteSpecificTrackingException({ siteName: ..., ... })`.
>> 
>> yes, good idea.  Nick may also help me on the best practices for script design.  I hope.
>> 
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>> 
>> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 23 January 2013 11:42:47 UTC