Re: Action 32 -- Proposed language for site-specific exception

Here I am summarizing a conversation that Rigo, Thomas, Karl, and I had last week, to share it with the group. 

A few notable problems with opt-in cookies are similar to the issues that make a DNT header attractive in the first place. Namely:
	- Not all user agents support setting cookies
	- Not all user agents are terribly fingerprintable, and these are often the same as not supporting cookies (for example, a not-so-smart phone)
	- Many users either block or manage (that is, some how delete) cookies. In Princeton, Jules suggested this may be something like 40% in the US and 50% in Europe. This is from memory; I leave Jules to correct me if I'm off.
	
And for me the biggie:
	- The users who have DNT on (which is a superset of users who will opt back in) are far more likely to be among the subpopulation of users who manage their cookies. Designing a solution that is least likely to work for the population most likely to use it seems like a problem to me.

So while I very much agree with Nick that having a standard way to add site-specific exceptions is highly desirable, I hope we can find a mechanism that works better than cookies. 

	Aleecia

On Nov 9, 2011, at 2:26 PM, Nicholas Doty wrote:

> One advantage of a tech-specific requirement (placing an opt-in cookie) would be the relative simplicity for users to clear all of their tracking opt-ins — just clear your cookies. If some sites use fingerprinting and other sites use localStorage and yet others use cookies to store a user's opt-back-in status, then a user would have to manually manage on a site-by-site basis if they decided they wanted to opt-out again.
> 
> We might be able to address this concern with some variation of the Tracking response header / well-known location such that user agents could detect when a user is being tracked because of an opt-back-in and give the user a pointer on how to clear it. This is also an advantage of the user-agent-managed list of site-specific exceptions: the user agent could make it easy for users to see and modify the list of site-specific exceptions.
> 
> Thanks,
> Nick
> 
> On Nov 9, 2011, at 8:14 AM, Shane Wiley wrote:
> 
>> Thank you John – helpful starting point.  I’d suggest we not assert only a cookie as the “exception” memory mechanism but a recommended one.  It could be equally viable and appropriate to store this information in a registration key, a browser setting, or some other technical mechanism.
>>  
>> - Shane
>>  
>> From: John Simpson [mailto:john@consumerwatchdog.org] 
>> Sent: Wednesday, November 09, 2011 8:00 AM
>> To: Aleecia M. McDonald; Nicholas Doty
>> Cc: public-tracking@w3.org Group WG
>> Subject: Action 32 -- Proposed language for site-specific exception
>>  
>> Proposed language for a site-specific exception using a cookie:
>>  
>> When a DNT enabled user agent grants a site-specific exception, the site places a site-specific opt-in cookie on the user agent allowing the site to respond as a First Party.  The DNT header must remain enabled so that if the user returns to the site, both the user's general preference for DNT and the site-specific exception will be clear.  This could enable the site to provide a higher level of privacy than if DNT were not enabled, but less than if the exception had not been granted. Opt-in site-specific exception cookies should expire within three months, enabling the site to determine periodically whether the user intends to continue to grant an exception.
>>  
>> ----------------
>> John M. Simpson
>> Consumer Advocate
>> Consumer Watchdog
>> Tel: 310-392-7041
>>  
>