Re: June change proposal: permitted uses

On 06/28/2013 11:36 AM, Nicholas Doty wrote:
> Hi Dan,
>
> I've tried to split out this proposal into what seem to be two key
> changes: 
> (1) limitations on the retention and use of unique identifiers
> (2) retention limits, extensible with justification
>
> ISSUE-199 was already created and closely tracks the first; I've moved
> it to the June Compliance product. I've also created ISSUE-211 for the
> second: Should we specify retention periods (extended with
> transparency) for permitted uses?
>
> And I've added two change proposals to the wiki to capture these two
> changes. I'm hopeful that splitting them up in this way will help the
> group understand the parts of the proposal and let us combine
> proposals that address the same questions.
>
> http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Unique_Identifiers
> http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Retention_Permitted_Uses
>
> Your proposal used the same language on unique identifiers in several
> sections, and I've tried to just add that sentence and describe where
> it applies -- did you intend it for all permitted uses, or just all
> except for debugging?

Thanks for your continuous hard work, Nick. I apologize for the delay
responding -- was on vacation. If debugging is sufficiently limited in
scope and data retention is short, then I don't think there's a need for
that extra sentence on unique identifiers. While the vast majority of
debugging likely does not need to use unique identifiers, some forms of
debugging might, for example if a site is doing short-term debugging on
the process of setting ordinary cookies itself on a small subset of test
users. What I want to avoid is the continued use of unique id cookies in
general under the auspices of this or any permitted use. Therefore, if
the scope of the debugging exception is expanded in certain unacceptable
ways, I may suggest that that sentence be added for debugging as well.


>
> Thanks,
> Nick
>
> On Jun 25, 2013, at 11:38 PM, Dan Auerbach <dan@eff.org
> <mailto:dan@eff.org>> wrote:
>
>> Short-term use and debugging
>>
>> A third party MAY also use protocol information (e.g. HTTP header
>> information and IP information) for any purpose, subject to a one
>> week retention period. Limited retention of data beyond this period
>> for debugging purposes may occur, provided the data is only used for
>> debugging purposes and only retained as long as necessary for those
>> purposes. If data is being retained for more than 6 months for
>> debugging purposes, notice must be given in the privacy policy that
>> some data is being retained for greater than 6 months for debugging.
>>
>> Frequency capping
>>
>> Regardless of DNT signal, protocol information may be collected,
>> retained and used for up to 4 weeks to limit the number of times that
>> a user sees a particular advertisement, often called frequency
>> capping, as long as the data retained do not reveal the user’s
>> browsing history. Parties must not collect or use unique identifiers
>> of users, user agents or devices in association with this data.
>> Parties must not construct profiles of users or user behaviors based
>> on their ad frequency history, or otherwise alter the user’s experience.
>>
>> Billing and auditing
>>
>> Regardless of DNT signal, protocol information may be collected,
>> retained and used for billing and auditing for up to 6 months, or
>> longer if notice is given in the privacy policy with an explanation
>> of why the extra retention is necessary. Parties must not collect or
>> use unique identifiers of users, user agents or devices in
>> association with this data. This may include, for example, counting
>> ad events, verifying positioning and quality of ad impressions, or
>> data that an auditor explicitly requires to be held.
>>
>> Security and Fraud
>>
>> To the extent proportionate and reasonably necessary for detecting
>> security risks and fraudulent or malicious activity, parties may
>> collect, retain, and use protocol data regardless of a DNT signal for
>> up to 6 months, or longer if notice is given in the privacy policy
>> with an explanation of why the extra retention is necessary. Parties
>> must not collect or use unique identifiers of users, user agents or
>> devices in association with this data. This includes data reasonably
>> necessary for enabling authentication/verification, detecting hostile
>> and invalid transactions and attacks, providing fraud prevention, and
>> maintaining system integrity. In the context of this specific
>> permitted use, this information may be used to alter the user's
>> experience in order to reasonably keep a service secure or prevent
>> fraud. Data may be kept beyond 6 months or the published retention
>> period for a specific ongoing investigation or for legal purposes,
>> but general data collection for security and fraud must be limited to
>> 6 months or the published retention period.
>>
>> It is a best practice to approach security and fraud issues with a
>> graduated response where appropriate, retaining the minimal amount of
>> data that is necessary for security and fraud purposes, and expanding
>> the scope of data retention only when it becomes necessary to do so
>> once a particular issue has been discovered.
>>
>> On 06/25/2013 11:34 PM, Dan Auerbach wrote:
>>> De-identified data use
>>>
>>> A third party MAY use de-identified data for any purposes whatsoever.
>>>
>>> Short-term use and debugging
>>>
>>> A third party MAY use protocol information (e.g. HTTP header
>>> information and IP address information) for any purpose, subject to
>>> a one week retention period. Limited retention of data beyond this
>>> period for debugging purposes may occur, provided the data is only
>>> used for debugging purposes and only retained as long as necessary
>>> for those purposes. If data is being retained for more than 6 months
>>> for debugging purposes, notice must be given in the privacy policy
>>> that some data is being retained for greater than 6 months for
>>> debugging.
>>>
>>> Frequency capping
>>>
>>> Regardless of DNT signal, protocol information maybe collected,
>>> retained and used for up to 4 weeks to limit the number of times
>>> that a user sees a particular advertisement, often called frequency
>>> capping, as long as the data retained do not reveal the user’s
>>> browsing history. Parties must notcollect or use unique identifiers
>>> of users, user agents or devices in association with this data.
>>> Parties must notconstruct profiles of users or user behaviors based
>>> on their ad frequency history, or otherwise alter the user’s experience.
>>>
>>> Billing and auditing
>>>
>>> *Regardless of DNT signal, protocol information maybe collected,
>>> retained and used for billing and auditing for up to 6 months, or
>>> longer if notice is given in the privacy policy with an explanation
>>> of why the extra retention is necessary. Parties must notcollect or
>>> use unique identifiers of users, user agents or devices in
>>> association with this data. This may include, for example, counting
>>> ad events, verifying positioning and quality of ad impressions, or
>>> data that an auditor explicitly requires to be retained.*
>>>
>>> Security and Fraud
>>>
>>> To the extent proportionate and reasonably necessary for detecting
>>> security risks and fraudulent or malicious activity, parties
>>> maycollect, retain, and use protocol data regardless of a DNT signal
>>> for up to 6 months, or longer if notice is given in the privacy
>>> policy with an explanation of why the extra retention is necessary.
>>> Parties must notcollect or use unique identifiers of users, user
>>> agents or devices in association with this data. This includes data
>>> reasonably necessary for enabling authentication/verification,
>>> detecting hostile and invalid transactions and attacks, providing
>>> fraud prevention, and maintaining system integrity. In the context
>>> of this specific permitted use, this information maybe used to alter
>>> the user's experience in order to reasonably keep a service secure
>>> or prevent fraud. Data maybe kept beyond 6 months or the published
>>> retention period for a specific ongoing investigation or for legal
>>> purposes, but general data collection for security and fraud mustbe
>>> limited to 6 months or the published retention period.
>>>
>>> It is a best practice to approach security and fraud issues with a
>>> graduated responsewhere appropriate, retaining the minimal amount of
>>> data that is necessary for security and fraud purposes, and
>>> expanding the scope of data retention only when it becomes necessary
>>> to do so once a particular issue has been discovered.
>>> -- 
>>> Dan Auerbach
>>> Staff Technologist
>>> Electronic Frontier Foundation
>>> dan@eff.org
>>> 415 436 9333 x134
>>
>