Re: A First-Party List API for Site-Specific Exceptions (ISSUE-59, ISSUE-109, ISSUE-111, ISSUE-113, ISSUE-114)

On Mar 15, 2012, at 9:18 AM, Kevin Smith wrote:

> I was really looking for more concrete scenarios rather than a restatement of the business or privacy incentives.  For example, are there examples of static short ad serving chains or single 3rd party services that handle ad serving from beginning to end and do not redirect?  If so, what percentage of publishers use this type of service (enough that we want to complicate our docs to serve this niche?).  Real sites, or at least types of actual sites or business models would really help here.  
> 
> Because even if the ideas below make sense, are we implying that these publishers do not advertise?  If they do, then they would use a '*' to make the advertising chain function, and the points below are moot.
> 
> Regardless, there were some good thoughts below, so I did reply inline as well  prefaced with **- 
> 
>> -----Original Message-----
>> From: Jonathan Mayer [mailto:jmayer@stanford.edu] 
>> Sent: Wednesday, March 14, 2012 4:15 PM
>> To: Sid Stamm
>> Cc: Kevin Smith; Tracking Protection Working Group WG
>> Subject: Re: A First-Party List API for Site-Specific Exceptions (ISSUE-59, ISSUE-109, ISSUE-111, ISSUE-113, ISSUE-114)
>> 
>> Here are a few concrete use cases:
>> 
>> 1) A publisher wants to distinguish itself as having good privacy practices.  Instead of requesting a blanket exception, it wants to request exceptions for a small number of well-known third parties.
> **I strongly disagree with the implication that allowing partial exceptions is a superior privacy practice.  It may offer some benefits which is why we are willing to explore it, but I do not see it as a way to differentiate on privacy practices.  

I'm not sure I understand your disagreement here. For any definition of privacy that includes either user control or transparency over which parties collect my information, specifying a list of known parties that will collect and use data about the user seems like a differentiable and generally more privacy-preserving practice than a blanket exception for an unknown set of parties.

I agree with Jonathan that this is a plausible use case; a publisher may want to distinguish itself from its competitors and provide encouragement to the user to accept the requested tracking exception by specifying a short and defined list of parties to receive an exception. 

I do agree with you above, Kevin, that it may be an open question whether there are many publishers for whom specifying a list of parties is a live option, though I had thought from Shane's earlier statements that this was the case. I can't give evidence from large publishers, obviously, but for the small sites that I personally run (mostly for academic or educational purposes) I could specify the third–parties that I use to run analytics, comments, social-sharing widgets and the like. Those educational sites tend not to use advertising.

>> 4) A user wants to blacklist a third party in a manner that trumps a site-specific exception.
> ** this is a user scenario, not a site scenario.  This seems like the TPL discussion again.  If we decide we want to do TPLs then we clearly have to decide how they interact with exceptions.  However, this does not require partial exceptions.  We would have to decide whether blacklist trumped exception or vice versa, but regardless, for a 1st party wide exception, they would just get a DNT:1 instead of a DNT:0.  The decision tree is identical.

I think the "blacklist" in this case was not blocking a request, just that a user may configure their user agent never to send DNT:0 (and always send DNT:1) to a particular third party because they specifically do not want to be tracked by that party. If a publisher requested a "*" exception, a user agent configured to never grant an exception to some third parties would be obligated to deny the request. That's why this is a use case for the publisher: publishers that want to increase the chance that their exception request will be granted may not wish to ask for a blanket exception since such a request might be automatically denied.

Received on Sunday, 18 March 2012 02:37:57 UTC