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

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?

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

Received on Wednesday, 23 January 2013 11:29:24 UTC