W3C home > Mailing lists > Public > public-tracking@w3.org > March 2012

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

From: Nicholas Doty <npdoty@w3.org>
Date: Fri, 23 Mar 2012 13:33:20 -0700
Cc: Jonathan Mayer <jmayer@stanford.edu>, Sid Stamm <sid@mozilla.com>, Tracking Protection Working Group WG <public-tracking@w3.org>
Message-Id: <BDCC01DB-483A-4F86-B5BF-F40CA92E38B3@w3.org>
To: Kevin Smith <kevsmith@adobe.com>
On Mar 23, 2012, at 9:58 AM, Kevin Smith wrote:

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

I could certainly imagine a bad enough browser UI that presenting a long list of domains to a user would be less usable than a request for a blanket exception. But I also have faith in all the browser vendors actively participating in this group that they are well-placed to develop good UI that their users understand. In some cases the UI for a list of specific domains might collapse into the same UI for requesting a blanket exception. In other cases a browser extension could use pre-defined configuration to determine whether to highlight certain domains on the list, or perhaps answer for the user without additional prompts.

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

I'm not sure I understand this point. In either situation, the first party is requesting that the user grant exceptions directly to the third parties, right? Why would a first party have less pressure to vet its third parties if it didn't know who they were and never explicitly listed them for the user agent? Is the concern that if a user had possibly seen a list of domains when they granted an exception then a first party would be willing to list domains it wouldn't otherwise contract with?

> 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'm not aware of any situation (other than really bad UI choices by implementers) where only having the functionality to request blanket exceptions would result in stronger privacy practices; and we agree that there are cases where requesting a specific list is better for user privacy. I do agree that there may be some sites and some users for which requesting a long list of domains is not substantially different than requesting a blanket 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.

As I mentioned before:
>> 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.

For the academic sites that I personally run at the University of California Berkeley, I know all the third parties and would be willing to manage the expense of listing them in a JS call. (For a concrete example, we've recently developed http://privacypatterns.org which uses Disqus for comments and Google Analytics.) I hope that would be a common practice for universities, especially since many of them are public institutions and may have legal requirements about sharing citizen data. There are certainly numerous small web sites (like personal blogs, say) where the list of third party services would likely be a manageable size. I would imagine that some ad networks that serve these small publishers would provide documentation on how to insert their advertising and the line of JavaScript code to use to request an exception if necessary for higher monetization.

Again, I can't speak for most publishers, but hopefully these examples of smaller web sites are useful.

Thanks,
Nick
Received on Friday, 23 March 2012 20:33:28 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:26 UTC