Re: [Issue-71] Proposed Text for Issue 71

I think it is very tough to write a rule that constrains bad actors and does not affect good ones.  I sense there are many in this group who think the only way to prevent companies from building profiles from data they collect is to prevent companies from collecting the data in the first place.  Especially in the absence of any audit function.  It is a HUGE compromise for them to move in the direction of "use" exceptions.  And I think 5 or more are on the table.   So the question is whether is it possible to place reasonable limits on a use exception.  

You can limit the type of info (geo, referer, IP)
You can limit the time period of retention (24-48 hours)
You can limit the entity (First parties)
You can limit the uses (specific purposes)
You can create an audit (maybe via response header or something else)

But it seems like you want "Any type of info can be collected for as long as needed by any party that needs it for any purpose to avoid breaking the internet and there is no way to tell whether someone violates this."

In law, usually in a situation like this you might have extraordinary damages to deter violations, but since this is a voluntary standard, that piece cannot be included.

So is there any piece of this you would be willing to compromise on?  Looking at this through the lens of a company who has to comply it seems like there is a ton of wiggle room, which is great for me as the lawyer but I'm not sure it really gets the group where it is trying to go with its mission.




On Feb 8, 2012, at 4:38 PM, JC Cannon wrote:

> David,
> 
> It seems like are closer to each other in what is needed than the text bears out. I agree that bad actors will attempt to skirt the rules. I don't think the spec will stop bad actors. However, those of us who want to protect online privacy should not be lumped with them. That said, I would love to see the language adjusted to make sure that the loopholes are closed and complying with the spirit of this rule is made simpler.
> 
> JC
> 
> -----Original Message-----
> From: David Singer [mailto:singer@apple.com] 
> Sent: Wednesday, February 08, 2012 4:25 PM
> To: JC Cannon
> Cc: Jonathan Mayer; Ninja Marnau; Nicholas Doty; Amy Colando (LCA); Frank.Wagner@telekom.de; public-tracking@w3.org
> Subject: Re: [Issue-71] Proposed Text for Issue 71
> 
> 
> On Feb 8, 2012, at 16:17 , JC Cannon wrote:
> 
>> You call it a record as if it's in a database and easily accessible by all parts of the business, which is not the case. My concern is that logs are really difficult to manage when you get large quantities like we do. Going back through historical logs to remove data would be an enormous task. We discussed having a shorter retention period for logs designated with a DNT:1 and not processing those logs as well, which seems acceptable.
> 
> OK, thanks. Two points:
> 
> First, DNT is about the present transaction; it never affects data recorded from other transactions. (You may be restricted from using it, but its existence and retention are not affected).  So you're never asked to go 'back through historical logs to remove data'.
> 
> Secondly, I think there is a real anxiety that operators will record all the same data, only not run the process 'immediately' that reduces that data to the additions to the per-person records when DNT is on.  However, since the raw input is retained, that process could be run at any time later, it's just been deferred (possibly indefinitely, possibly not).  I may be wrong, and would like to hear from others.
> 
>> What would be nice is to get clarification over the expectation for websites based on this rule.
>> 
>> Thanks,
>> JC
>> 
>> -----Original Message-----
>> From: David Singer [mailto:singer@apple.com]
>> Sent: Wednesday, February 08, 2012 3:03 PM
>> To: JC Cannon
>> Cc: Jonathan Mayer; Ninja Marnau; Nicholas Doty; Amy Colando (LCA); 
>> Frank.Wagner@telekom.de; public-tracking@w3.org
>> Subject: Re: [Issue-71] Proposed Text for Issue 71
>> 
>> 
>> On Feb 7, 2012, at 15:18 , JC Cannon wrote:
>> 
>>> I'm still concerned with this language:
>>> 
>>> "<When DNT:1> A third party MUST NOT retain data from a HTTP request that could be associated with an existing profile, except as permitted by exceptions stated elsewhere in this specification."
>>> 
>>> Is this acceptable:
>>> 
>>> "<When DNT:1> A third party MUST NOT use data from a HTTP request to update an existing profile, except as permitted by exceptions stated elsewhere in this specification."
>>> 
>>> I am also happy to entertain a retention period on data collected when DNT:1.
>> 
>> can you elaborate on your concern?  The point of first sentence is that keeping a separate record that can be re-connected with a profile is not enough.  You're still keeping data about a person.
>> 
>> 
>>> 
>>> JC
>>> 
>>> -----Original Message-----
>>> From: Jonathan Mayer [mailto:jmayer@stanford.edu]
>>> Sent: Tuesday, February 07, 2012 12:35 PM
>>> To: Ninja Marnau
>>> Cc: Nicholas Doty; Amy Colando (LCA); David Singer; JC Cannon; 
>>> Frank.Wagner@telekom.de; public-tracking@w3.org
>>> Subject: Re: [Issue-71] Proposed Text for Issue 71
>>> 
>>> There are two separate issues surrounding collection of information that could be linked to an old profile.
>>> 
>>> First, how do we handle the first time a browser contacts a site after DNT is enabled?  Assuming an ID cookie is in place, we'll necessarily have to say something about retention instead of collection.
>>> 
>>> Second, how do we handle subsequent communication between the browser and the site?  Is the site required to delete its ID cookie?  Modify the cookie?  Replace the cookie?  If you believe (as I and others do) that collection of a user's browsing history across unrelated sites is a central privacy issue for Do Not Track, then deletion would seem to be the right answer.
>>> 
>>> On Feb 7, 2012, at 7:14 AM, Ninja Marnau wrote:
>>> 
>>>> Thanks Jonathan for pointing out your concerns regarding the data collection. I agree with Nick that it may be easier to deal with this as a matter of retention rather than collection (e.g. for necessary reception of data).
>>>> 
>>>> I like Nick's and Shane's proposed solutions. I try my hand at merging these two.
>>>> 
>>>> <When DNT:1> "A third party MUST NOT retain data from a HTTP request that could be associated with an existing profile, except as permitted by exceptions stated elsewhere in this specification. Data collected under these exceptions MUST NEVER be profiled independently or associated with previous or future user profiles."
>>>> 
>>>> -Ninja
>>>> 
>>>> Am 30.01.2012 12:04, schrieb Nicholas Doty:
>>>>> When a user first turns on DNT:1, the user agent will likely 
>>>>> continue to send existing third-party cookies, which might include 
>>>>> cookies with unique identifiers. If "collection" implies receiving 
>>>>> a request with a unique identifier that could be associated with an 
>>>>> old profile, this text seems difficult to comply with.
>>>>> 
>>>>> Perhaps we could change this to "When a third party receives a DNT 
>>>>> signal, it MUST NOT retain data from that HTTP request that could 
>>>>> be associated with an existing profile, except as permitted by 
>>>>> exceptions stated elsewhere in this specification." That would 
>>>>> allow the third party to retain most of the data from the request 
>>>>> if they stripped identifiers and I think it would also address Jonathan's concern (2).
>>>>> 
>>>>> We could also add some non-normative best practices text that 
>>>>> suggests that the server clear a unique identifier cookie for 
>>>>> future requests, to avoid any uncertainty over whether data could 
>>>>> be associated to an existing profile.
>>>>> 
>>>>> -Nick
>>>>> 
>>>>> On Jan 29, 2012, at 9:48 PM, Jonathan Mayer wrote:
>>>>> 
>>>>>> #1 is a *use* limitation - new third party data may not be *used* 
>>>>>> with an old profile. Your text provides this.
>>>>>> #2 is a *collection* limitation - new third party data may not be
>>>>>> *collected* if it *could be used* with an old profile. Your text 
>>>>>> does not provide this, and JC suggested he was not in favor.
>>>>>> 
>>>>>> Here's possible text on #2: "A third party may not collect 
>>>>>> information that could be associated with an existing user profile."
>>>>>> 
>>>>>> On Jan 29, 2012, at 6:49 AM, Amy Colando (LCA) wrote:
>>>>>> 
>>>>>>> Thanks Jonathan, its very helpful to separate the issue into 
>>>>>>> these sub topics.
>>>>>>> 
>>>>>>> On (2), could you propose revised text? If I am understanding you 
>>>>>>> correctly, I thought Ninja and I had attempted to address this 
>>>>>>> concern through the following: "(third party) MUST NOT relate 
>>>>>>> additional data from that HTTP request to existing profiles 
>>>>>>> associated with that user-agent..."
>>>>>>> 
>>>>>>> Sent from my Windows Phone
>>>>>>> -----------------------------------------------------------------
>>>>>>> -
>>>>>>> ------
>>>>>>> From: Jonathan Mayer
>>>>>>> Sent: 1/29/2012 9:55 AM
>>>>>>> To: David Singer
>>>>>>> Cc: JC Cannon; Amy Colando (LCA); Frank.Wagner@telekom.de 
>>>>>>> <mailto:Frank.Wagner@telekom.de>; public-tracking@w3.org 
>>>>>>> <mailto:public-tracking@w3.org>
>>>>>>> Subject: Re: Proposed Text for Issue 71
>>>>>>> 
>>>>>>> To take a step back, there are at least five separate design 
>>>>>>> decisions here:
>>>>>>> 
>>>>>>> 1) May a third party merge a DNT user's information into an old profile?
>>>>>>> This text says no, and I imagine that's a point of consensus or 
>>>>>>> near-consenus in the group.
>>>>>>> 
>>>>>>> 2) May a third party collect data from a DNT user that could be 
>>>>>>> merged into an old profile?
>>>>>>> This text says yes. I strongly disagree. (In general I share the 
>>>>>>> view Brett Error from Adobe advocated in Cambridge: if a Do Not 
>>>>>>> Track user can get tagged with a unique identifier cookie, we've 
>>>>>>> probably done something wrong.)
>>>>>>> 
>>>>>>> 3) May a third party retain the ability to resume profiling a DNT 
>>>>>>> user if he or she ever disables DNT?
>>>>>>> This text says yes. I'm ok with it. Note that this design 
>>>>>>> decision is independent of the one just before. Here's a quick 
>>>>>>> sketch of a technical approach: if the user enables DNT, stash 
>>>>>>> old tracking cookies in HTML5 local storage. If the user disables 
>>>>>>> DNT, pull the cookies back out.
>>>>>>> 
>>>>>>> 4) Must a third party delete old profile data if a user enables DNT?
>>>>>>> This text says no. I'm ok with that.
>>>>>>> 
>>>>>>> 5) Must a third party delete or scrub historical non-profile data 
>>>>>>> if a user enables DNT?
>>>>>>> This text says no. I'm also ok with it.
>>>>>>> 
>>>>>>>>> Here is text that Ninja and I worked on. Ninja, I incorporated  
>>>>>>>>> most of your edits, but please feel free to comment and suggest  
>>>>>>>>> text, as should others.
>>>>>>>>> **
>>>>>>>>> *Issue number:*71
>>>>>>>>> *Issue name:*Does DNT also affect past collection or use of  
>>>>>>>>> past collection of info?
>>>>>>>>> 
>>>>>>>>> *Issue*URL:http://www.w3.org/2011/tracking-protection/track/iss
>>>>>>>>> ues/71  *Section number in the FPWD*: 4.3  *Contributors to 
>>>>>>>>> this text*:
>>>>>>>>> Ninja Marnau
>>>>>>>>> Amy Colando
>>>>>>>>> *Description:*
>>>>>>>>> This is particularly of interest in Europe, where consent may  
>>>>>>>>> only apply to information that will be collected in the future,  
>>>>>>>>> not retrospectively. If DNT does affect prior data collection,  
>>>>>>>>> how does that work in practice? What are companies responsible for?
>>>>>>>>> DNT signal affects the HTTP request that it accompanies, and  
>>>>>>>>> may be modified by the user. As such, the DNT signal is  
>>>>>>>>> transactional and granular in nature, and should not affect  
>>>>>>>>> data previously gathered.
>>>>>>>>> *Specification:*
>>>>>>>>> *When a third party receives a DNT signal, it MUST NOT relate  
>>>>>>>>> additional data from that HTTP request to existing profiles  
>>>>>>>>> associated with that user-agent that are based on data that the  
>>>>>>>>> third party has previously collected across sites over time;  
>>>>>>>>> this is except as permitted by Exceptions stated elsewhere in  
>>>>>>>>> this specification (e.g., user override, frequency capping,  
>>>>>>>>> billing, silo-ed analytics).
>>>>>>>>> *Additionally, the entity MUST NOT use identifiers that it can  
>>>>>>>>> determine were collected from the same user agent before the  
>>>>>>>>> DNT signal was received, except as permitted by Exceptions, for  
>>>>>>>>> as long as it continues to receive a DNT signal from that  
>>>>>>>>> user-agent.
>>>>>>>>> *The entity MAY take additional steps with respect to  
>>>>>>>>> previously collected DNXT data such as deleting data before its  
>>>>>>>>> usual expiration. However, as DNT signal affects only HTTP  
>>>>>>>>> request that it accompanies and may be modified by the user, it  
>>>>>>>>> is not recommended that special deletion take place without  
>>>>>>>>> some notice to user(s).
>>>>>>>>> *Examples and Use Cases:*
>>>>>>>>> 1.User visits Site A, to which Ad Network B delivers  
>>>>>>>>> advertisements. Ad Network B has accumulated transactional  
>>>>>>>>> information about User from User's visits to Site A and other  
>>>>>>>>> non-affiliated sites in the past. However, User now sends DNT  
>>>>>>>>> signal with HTTP request during this session on Site A. Ad  
>>>>>>>>> Network B cannot add information from current HTTP request from  
>>>>>>>>> Site A session to any profile it maintains on User. Since it  
>>>>>>>>> must not collect and any data from this session and relate it  
>>>>>>>>> to previously collected data, Network B must regard and treat  
>>>>>>>>> him like completely unknown user to them, absent any Exceptions  
>>>>>>>>> or override from user.
>>>>>>>>> 2.Same as above scenario. Based on transactional information  
>>>>>>>>> collected about User's visits to non-affiliated sites in the  
>>>>>>>>> past, Ad Network B has placed User into Technology Shopper  
>>>>>>>>> Segment. Since Ad Network B must not recognize User during  
>>>>>>>>> sessions in which User is sending DNT signal via that browser,  
>>>>>>>>> it cannot deliver Technology Shopper advertisement to User's  
>>>>>>>>> browser, absent obtaining override from user. Ad Network B may  
>>>>>>>>> instead choose to deliver a random ad, an ad based on the  
>>>>>>>>> context of Site A, or an ad based on general location based on  
>>>>>>>>> IP address transmitted with HTTP
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> David Singer
>>>>>>>> Multimedia and Software Standards, Apple Inc.
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> 
>>>> Ninja Marnau
>>>> mail: NMarnau@datenschutzzentrum.de - 
>>>> http://www.datenschutzzentrum.de
>>>> Telefon: +49 431/988-1285, Fax +49 431/988-1223 Unabhaengiges 
>>>> Landeszentrum fuer Datenschutz Schleswig-Holstein Independent Centre 
>>>> for Privacy Protection Schleswig-Holstein
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>> 
>> 
>> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
> 
> 
> 

Lauren Gelman
BlurryEdge Strategies
415-627-8512
gelman@blurryedge.com
http://blurryedge.com

Received on Thursday, 9 February 2012 01:15:21 UTC