RE: Data append?-transactional?

A first party has no direct visibility into what DNT signal its 3rd parties receive.  Therefore the only reliable outcome is that 3rd parties must receive the DNT signal and not pass information to 1st parties any longer for that specific UA.  This is what I meant by "sender vs. recipient" earlier in the chain.  As a 1st party, if I receive DNT:1, this only means to me that the user has generally turned on this preference but does not tell me what individual 3rd parties have received and I'm not going to query 3rd party lists on every single call (far too expensive).  Let's please agree to place the burden on the sender in this case as that's the clearest, fastest signal and not unduly burden the recipient since they are generally hindered direct access to 3rd party signals (expensive to find out).

- Shane  

-----Original Message-----
From: Rob van Eijk [] 
Sent: Wednesday, April 03, 2013 7:27 AM
To: Alan Chapell
Cc: Shane Wiley; Jeffrey Chester; John Simpson; (
Subject: Re: Data append?-transactional?

I share your view on the loophole, Alan.

If DNT is going to be a consent mechanism, data append by 1st parties of data that originates from 3rd parties (not being data processors) can not be excluded from the legal assessment of the processing of personal data.
If DNT is going to be a use limitation tool, then disallowing the practice of data append (of data that originates from 3rd parties not being data processors) makes sense to me.

I have no additional arguments for the moment.


Alan Chapell schreef op 2013-04-02 18:49:
> Seems like we've gone down one of our infamous ratholes here.
> I agree that DNT should not apply to first parties' OFFLINE 
> advertising and content customization activities. However, I do think 
> that if we allow offline data to be utilized to tailor first party 
> ONLINE advertising and content customization activities, we are 
> creating a significant loophole in the DNT standard.
> We haven't heard yet from the regulators in the working group on this. 
> Ed / Rob - any thoughts?
> I look forward to discussing tomorrow.
> Alan
> From: Shane Wiley <>
> Date: Tuesday, April 2, 2013 10:55 AM
> To: Jeffrey Chester <>
> Cc: John Simpson <>, " 
> (" <>
> Subject: RE: Data append?-transactional?
> Resent-From: <>
> Resent-Date: Tue, 02 Apr 2013 14:57:04 +0000
>> Jeff,
>> This is a perfect example of attempting to overuse DNT to solve 
>> tangential privacy issues. A user's decision comes with each and 
>> every page request and will be recognized for each of the page responses.
>> Attempting to stretch DNT to now be recognized outside of this 
>> context is inappropriate. I understand the desire to use this single 
>> signal to cover all possible privacy situations but I would continue 
>> to recommend we avoid that approach and keep our focus locked in on 
>> the original intent of the working group.
>> - Shane
>> FROM: Jeffrey Chester []
>> SENT: Tuesday, April 02, 2013 4:58 AM
>> TO: Shane Wiley
>> CC: John Simpson; (
>> SUBJECT: Re: Data append?-transactional?
>> Shane:
>> I don't believe the DNT signal should be considered transactional by 
>> First parties. They should register that preference and operate 
>> accordingly. Users won't expect their DNT decisions to be temporal, 
>> fleeting, concerns. The first party server should acknowledge that 
>> decision unless it receives a signal otherwise. All data flow 
>> decisions should be adjusted to that choice, unless otherwise 
>> instructed by the user.
>> Jeffrey Chester
>> Center for Digital Democracy
>> 1621 Connecticut Ave, NW, Suite 550
>> Washington, DC 20009
>> [2]
>> [3]
>> 202-986-2220
>> On Apr 1, 2013, at 10:47 PM, Shane Wiley wrote:
>> John,
>> I believe I see the disconnect. There is no responsibility for any 
>> party (1st or 3rd) to "remember" a user's DNT setting - it is 
>> transactional - meaning it can change from moment to moment per each 
>> transaction (in reality I hope that's not the case but its 
>> technically possible). So in the use case of offline appends, you're 
>> asking a 1st party to "remember" the last DNT setting it received for 
>> a user and then apply that offline. I do not agree with that proposal 
>> and don't feel it's appropriate to store a user's DNT setting on the 
>> Server side since this will come with each page request. I hope this 
>> makes sense on both sides - that DNT is at its essence: online 
>> (real-time) and transactional (not a setting Servers must remember 
>> for the next transaction which will have a page header request of its own). Fair?
>> - Shane
>> FROM: John Simpson []
>> SENT: Monday, April 01, 2013 3:50 PM
>> TO: Shane Wiley
>> CC: (
>> SUBJECT: Re: Data append?
>> Shane,
>> Thanks for responding. Questions in line below.
>> On Mar 31, 2013, at 8:26 PM, Shane Wiley <>
>> wrote:
>> John and Alan,
>> Thank you for taking the first pass at normative text for "data 
>> append" exercises from the 1st party perspective and how these 
>> interrelate to DNT.
>> A few comments:
>> _-- A 1st Party MUST NOT combine or otherwise use identifiable data 
>> received from another party with data it has collected while a 1st 
>> Party._
>> [I believe the DNT signal should be directed to the sender, not the 
>> recipient. In this case, I would expect the 3rd party to receive the 
>> signal and appropriate not convey information within the context of 
>> DNT. This sentence should either be dropped or rewritten to focus on 
>> the sender (3rd party in this context).]
>> I'm sorry, I'm not sure I understand what you mean by sender and 
>> recipient. By sender do you mean the party that has data and "sends"
>> it to the 1st party (the recipient)? I think you're saying that the 
>> 3rd party would receive the DNT signal and could not send data to the 
>> 1st Party. I believe that's true under the current draft of the TCS 
>> spec *IF* the sender is present on the website as a 3rd Party. What I 
>> am specifically calling out is the use case where the "sender" (I say 
>> "another party") has no presence on the site. If DNT:1 is enabled, 
>> the 1st Party could not go beyond the 1st Party experience and 
>> request data from another source. It's likely the case that this 
>> other party would not have received a DNT:1 message, so it is 
>> necessary for the 1st Party to honor the request.
>> _ _
>> _-- A 1st Party MUST NOT share identifiable data with another party 
>> unless the data was provided voluntarily by the user and is necessary 
>> to complete a business transaction with the user._
>>> [DNT is transactional. I could see this prohibition working if the 
>>> data being passed occurred online in the context of the DNT signal 
>>> being in the header but for purely offline data matches I hope we 
>>> agree this could not work. I would also struggle to understand a 
>>> business case where a user has "shared identifiable data 
>>> involuntarily" - could you please give an example?]
>> Why wouldn't this work with offline matches? I used "provided 
>> voluntarily" to get at the idea that consent had been given.
>> [Of course all of these are trumped by user consent.]
>> Agree, if it is informed consent.
>> Finally, what's your reaction to the third element:
>> _A Party MUST NOT use data gathered while a 1st Party when operating 
>> as a 3rd Party. _
>> Are you comfortable with that?
>> Regards,
>> John
>>> - Shane
>>> FROM: John Simpson [ [1]]
>>> SENT: Sunday, March 31, 2013 8:13 PM
>>> TO: (
>>> SUBJECT: Data append?
>>> Colleagues,
>>> Alan Chapell and I have agreed on text that should cover the 
>>> situation regarding "data append" when DNT is received. I look 
>>> forward to discussing.
>>> The text is below.
>>> Regards,
>>> John
>>> ----
>>> _Normative:__ _
>>> _When DNT:1 is received:_
>>> _-- A 1st Party MUST NOT combine or otherwise use identifiable data 
>>> received from another party with data it has collected while a 1st 
>>> Party._
>>> _-- A 1st Party MUST NOT share identifiable data with another party 
>>> unless the data was provided voluntarily by the user and is 
>>> necessary to complete a business transaction with the user._
>>> _-- A Party MUST NOT use data gathered while a 1st Party when 
>>> operating as a 3rd Party._
>>> _Non-Normative:__ _
>>> When DNT:1 is received, a 1st Party retains the ability to customize 
>>> content, services, and advertising only within the context of the 
>>> first party experience. A 1st party takes the user interaction 
>>> outside of the 1st party experience if it receives identifiable data 
>>> from another party and uses that data for customization of content, 
>>> services, or advertising.
>>> When DNT:1 is received the 1st Party may continue to utilize user 
>>> provided data in order to complete or fulfill a user initiated 
>>> business transaction such as fulfilling an order for goods or a 
>>> subscription.
>>> When DNT:1 is received and a Party has become a 3rd Party it is 
>>> interacting with the user outside of the 1st Party experience. Using 
>>> data gathered while a 1st party is incompatible with interaction as 
>>> a third party.
> Links:
> ------
> [1]

> [2]

> [3]

Received on Wednesday, 3 April 2013 15:48:44 UTC