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

On Aug 23, 2012, at 12:52 , Vinay Goel <vigoel@adobe.com> wrote:

> Hi Lauren,
> 
> I can't speak for all retargeting firms, but I know of at least 3 that do it that way (including one recently acquired by Adobe).
> 
> I agree — a user that might want to give NYT an exception, but not give the vendor of NYT's other clients an exception.  In that situation, NY Times should be responsible for using the nytimes.retargeting.com domain and not *.retargeting.com.  That only works though if that retargeting firm uses client-specific subdomains.  Not all do.

Hi Vinay

don't forget that site exceptions are, well, tied to a site.  So if the NYT uses retargeting.com as a vendor, and asks for an exception for it, it's only a potential problem if another party present on the NYT's site also uses retargeting.com, and the NYT does not need/want an exception for that use.  (If I am reading the example correctly).

Web-wide exceptions are different, they are not tied to sites; but I don't think that we're discussing those here.

> In that situation, realizing that NY Times likely uses multiple targeting companies, NYT would prefer to ask the user only once for an exception; and apply it to all of the targeting companies it uses.  I know — many are hoping that there are privacy-friendly websites that will use server-explicit exceptions at the site level; but practically, NY Times will ask for one exception that covers all of its vendors.  It does not want to have two separate pop ups.  

Don't forget that the exception call also allows a list (as currently proposed), so, for example, there would be a request

"I [the current script-document-origin, let's say NYT.com] need an exception for {myAdService.com, images.myAdService.com, reTargeting.com, analysis.NYT.com}"

> In this situation, if NY Times is going to ask for one exception, how would they distinguish to the user that some vendors don't respect IE10 and others do?  Are they expected to?

Isn't it easier for the NYT to detect a visit it's not happy with (exception needed but not granted, suspect signal, browser that doesn't implement required HTML5, and so on), and deal with it before it gets to the other parties (e.g. with a re-direct)?

- - - - -

On your suggestion that we look at wild-cards, which half of the 'duplet' would benefit from that?  At the moment, the APIs avoid having to check public suffixes and for cross-site scripting, by using 'implicit parameters' and explicit FQDNs.

I suspect that it's for the 'target' (the second part of the duplet);  in the example above, we had to have both myAdService.com and images.myAdService.com, and this is an over-simplified example, I think; actual ad services can use a variety of host names.  We could allow target host names in the list that (a) start with a dot and (b) are not a public suffix;  but the question is whether this is necessary and/or worth it.  I rather suspect someone should work through a real-world example to enlighten us.

>  The third parties themselves can't communicate this to the user.  What NY Times would likely do (in my opinion) is just make a blanket lower common denominator saying that the vendors don't respect IE10.  If the unknown-to-user vendors are already being described to refuse the IE10 header, what's their motivation to recognize it?
> 
> I don't want these questions to sound rhetorical.  I honestly don't know the answers.

Questions are good, thanks for sending them.  They help us understand what we need to understand and do!

> 
> -Vinay
> 
> From: Lauren Gelman <gelman@blurryedge.com>
> Date: Thursday, August 23, 2012 3:29 PM
> To: David Singer <singer@apple.com>
> Cc: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>, "Matthias Schunter (Intel Corporation)" <mts-std@schunter.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: Thursday, August 23, 2012 3:30 PM
> 
> 
> 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.
>> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.