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

Is it common that retargeting is done this way? 

>>   It cannot ask for a separate exception for each of its customers (could be in the hundreds).

Is this the "too many pop-ups" concern, or is it something different.  I could see as a user that I might give Website A (e.g NYT) an exception and not want to grant the same exception to all the clients of Acme.  Though I do not want to discourage contractual arrangements where the client owns and limits use of the data.

Lauren Gelman
BlurryEdge Strategies
415-627-8512

On Aug 23, 2012, at 9:29 AM, David Singer wrote:

> 
> On Aug 23, 2012, at 8:32 , Vinay Goel <vigoel@adobe.com> wrote:
> 
>> Hi David,
>> 
>> Not sure if anyone followed-up on this.  Here is the link to the archives: http://lists.w3.org/Archives/Public/public-tracking/2012Jul/0165.html
> 
> Yes, got it.
> 
> I should be clear, I am not opposing keeping the issue open, just trying to give some background. I am quite happy with debate. :-)
> 
>> 
>> As both David W and Shane pointed out, this is still an open issue that we'd like to further discuss.  I don't think its sufficient to allow for the exception to cover the fully qualified domain only.  I know there are some concerns of abuse with the expansion of ICAAN policy, but by limiting the exception to fully qualified domains we'd be limiting significantly how a trusted third party ad services provider could use an exception.
>> 
>> Take the scenario of Acme, a site retargeting advertising firm.  It has three clients that it collects data on; but each client's data is owned by the client; not Acme.  Acme cannot combine/use data from Website A with data from Website B.  Acme uses the domain acme.net.  For data collected on Website A, it uses a.acme.net; for Website B it uses b.acme.net; for Website C it uses c.acme.net.  If Acme is asking for an exception, it needs it to cover all of its retargeting services for each client.  It cannot ask for a separate exception for each of its customers (could be in the hundreds).  By limiting the exception to fully qualified domains only, you would be encouraging retargeting firms to move away from cookie-based silos.
>> 
>> We should change the language of the current draft such that www.acme.net can make an exception request for *.acme.net or (*.)www.acme.net.  I would suggest we allow for a domain to ask for an exception for itself and its subdomains, but restrict how a subdomain can ask for an exception.  Specifically: acme.net can ask for an exception for acme.net and a.acme.net; a.acme.net can ask for an exception only for  (*).a.acme.net, but not acme.net.
> 
> Interesting.  I think we should probably compare with the cookie rules, so we at least learn from them, if not use what's appropriate there.
> 
>> 
>> -Vinay
>> 
>> Vinay Goel | Privacy Product Manager | Adobe Systems | Office: 917.934.0867
>> 
>> From: David Singer <singer@apple.com>
>> Date: Monday, August 20, 2012 12:59 PM
>> To: David Wainberg <david@networkadvertising.org>
>> Cc: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
>> Subject: Re: RESENT: Batch Closing of Issues against TPE [Deadline for validating can-live-with consensus: August 20]
>> Resent-From: <public-tracking@w3.org>
>> Resent-Date: Monday, August 20, 2012 12:59 PM
>> 
>> 
>> On Aug 19, 2012, at 8:32 , David Wainberg <david@networkadvertising.org> wrote:
>> 
>>> ISSUE-112 (How are sub-domains handled for site-specific exceptions?) should not be closed. I agree with Shane's last post on the issue. We should not toss out the *.domain.com model for speculative fear of misuse. And, we have not adequately explored the repercussions of not providing that option. The issue should remain open pending further exploration.
>> 
>> I fear I may have missed Shane's last post.  Do you have a link to it in the archives?  Sorry!
>> 
>> The issue was two-fold.  If we allow suffix names, rather than fully-qualified names, then (a) the matching process is more complex and (b) we need rules such as in cookies to control (against) the use of public suffixes (see http://publicsuffix.org). These complicate both the specification and the implementation (though it's true that any UA has to do the public suffix control in their cookie code already).
>> 
>> 
>>> 
>>> Thanks,
>>> 
>>> David
>>> 
>>> On 8/15/12 12:16 PM, Matthias Schunter (Intel Corporation) wrote:
>>>> Hi Team,
>>>> 
>>>> 
>>>> in preparation for tomorrow's TPE call, I started assessing the status of our TPE-related ISSUES:
>>>> 
>>>> I'd like to thank Roy and David for preparing the next major revision of the TPE spec! They have performed a huge push towards implementing all our prior discussions and draft agreements as updates to the TPE spec. As a consequence, many of our informal agreements are now documented in the text and we have the opportunity to make a large leap towards closing the remaining TPE issues.
>>>> 
>>>> Enclosed is a list of issues that I believe satisfy the following criteria:
>>>>    - Have been discussed before
>>>>    - Proposed text is in TPE spec
>>>>    - I believe that all participants can live with the current text
>>>> 
>>>> I would like to double-check that my perception is correct and then close these issues.
>>>> 
>>>> PLEASE:
>>>> - Double check that you can live with the proposed resolution and the current corresponding text in the TPE
>>>> - Send any comments and clarifying questions to the mailing list
>>>> - Send a note if you cannot live with one of the proposed resolutions to the chairs and editors at:
>>>>   team-tracking-editors@w3.org [In this case, some of the issues will be discussed further]
>>>> 
>>>> DEADLINE: August 20
>>>> - If I do not get further input on any of the issues below, I plan to close them by August 20
>>>> 
>>>> 
>>>> Regards,
>>>> matthias
>>>> 
>>>> -----------------------------------------8>--- ISSUES to be closed + proposed Resolutions ---------------------
>>>> 
>>>> http://www.w3.org/2011/tracking-protection/track/issues/47
>>>> ISSUE-47: Should the response from the server indicate a policy that describes the DNT practices of the server?
>>>> RESOLUTION: 
>>>> - A policy attribute at the well-known URI may point to a site-wide policy (Section 5.4.1)
>>>> - The response header may identify a more specific policy at a different URL (Section 5.3.2)
>>>> 
>>>> http://www.w3.org/2011/tracking-protection/track/issues/61
>>>> ISSUE-61: A site could publish a list of the other domains that are associated with them
>>>> RESOLUTION:
>>>> - "partners" attribute at the well-known URI identifies partner sites (Section 5.4.1)
>>>> 
>>>> http://www.w3.org/2011/tracking-protection/track/issues/84
>>>> ISSUE-84: Make DNT status available to JavaScript
>>>> RESOLUTION: 
>>>> - Revised text in section 4.3.3
>>>> 
>>>> http://www.w3.org/2011/tracking-protection/track/issues/107
>>>> ISSUE-107: Exact format of the response header?
>>>> RESOLUTION:
>>>> - Revised response header values in Section 5.2 and syntax in 5.3
>>>> 
>>>> http://www.w3.org/2011/tracking-protection/track/issues/112
>>>> ISSUE-112: How are sub-domains handled for site-specific exceptions?
>>>> RESOLUTION:
>>>> - Exceptions are granted for fully qualified domain names (Section 6.3.1)
>>>> 
>>>> http://www.w3.org/2011/tracking-protection/track/issues/124
>>>> How shall we express responses from a site to a user agent (headers, URIs, ...)?
>>>> RESOLUTION:
>>>> - Well-known URI + Headers where the essential information needs to be provided with one of the mechanisms
>>>> 
>>>> http://www.w3.org/2011/tracking-protection/track/issues/128
>>>> ISSUE-128: HTTP error status code to signal that tracking is required?
>>>> RESOLUTION:
>>>> - "409" ;-)
>>>> 
>>>> http://www.w3.org/2011/tracking-protection/track/issues/130
>>>> ISSUE-130: User-granted Exceptions b) Web-wide Exception for Third Parties (thisthirdparty, anywhere)
>>>> RESOLUTION:
>>>> - We agreed that web-wide exceptions shall be possible. Text in Section 6.5
>>>> 
>>>> http://www.w3.org/2011/tracking-protection/track/issues/155
>>>> ISSUE-155: Remove the received member from tracking status
>>>> RESOLUTION:
>>>> - Removed attribute has been removed
>>>>   since we assume reliable communication
>>> 
>> 
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>> 
>> 
>> Confidentiality Notice: The contents of this e-mail (including any attachments) may be confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited. <ACL>
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
>