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

>>> 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'm sorry.  I was unclear here.  I was not arguing in any way against transparency or listing 3rd parties.  I was arguing that giving the ability to selectively pick which 3rd parties for whom to grant an exception is by default a stronger privacy option than placing the trust level at the 1st party level.  In some cases it may be, but as I have said on other threads, spreading out the trust level across so many entities combined with the difficulty in user's ability to make informed decisions about those entities will not often lead to improved privacy controls for the user.  In fact, the primary affect I can see is that it would alleviate some of the pressure on the 1st party to safeguard privacy since the user granted permission directly to the 3rd parties.  Again, I am sure there are simple scenarios in which this method would result in a stronger privacy practice.  It was the implication that this would always be the case to which I took exception.

> 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 don't disagree that this is a plausible use case, it's just still too abstract for me.  Are there examples of publishers that neither advertise nor require a subscription that know all of its 3rd parties and are willing to accept the expense of handling exceptions to those 3rd parties independently because they believe they can differentiate themselves for strong privacy practices by doing so?  I am sure the answer is yes,.  I would just like to understand what type of site that is, and how common the use case is.










-----Original Message-----
From: Nicholas Doty [mailto:npdoty@w3.org] 
Sent: Saturday, March 17, 2012 8:37 PM
To: Kevin Smith
Cc: Jonathan Mayer; Sid Stamm; 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)

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 Friday, 23 March 2012 16:59:20 UTC