RE: ACTION-406: Propose a new set of names around yellow state

Thanks, Shane.

I believe it is not about the risk to re-engineer, it is about the 
ability to link new data to previously collected data.

The two are very different things. The first (risk to re-engineer) 
adheres to a reasonable level of protection. The ability to link is 
connected to the notion of personally identifieable information (PII).

We have gone full circle with this discussion. Time to leave it up to 
the chair.

mvg::Rob


Shane Wiley schreef op 2013-05-27 16:44:
> Rob,
> 
> To your example, our core disconnect is that Yahoo! has made public
> declarations of its commitment to maintain this data in a
> de-identified state using technical, operational and administrative
> controls and is accountable for that outcome.  While I agree there is
> some risk technically, this accountability framework in combination
> with all of the controls discussed fairly positions this data as
> de-identified - even to Yahoo! (in EU Data Protection terms - we've
> reached the "likely reasonable" bar that this data will not be reverse
> engineered).
> 
> - Shane
> 
> -----Original Message-----
> From: Rob van Eijk [mailto:rob@blaeu.com]
> Sent: Monday, May 27, 2013 6:57 AM
> To: Shane Wiley
> Cc: public-tracking@w3.org
> Subject: RE: ACTION-406: Propose a new set of names around yellow 
> state
> 
> 
> Shane,
> 
> 
> Let me describe my concern in an example:
> 
> Yahoo! takes out direct identifiable information from raw data such
> that it becomes data that we describe to be yellow data.
> The yellow data remains however linkable data for Yahoo!. Linkable
> data does not meet the NAI definition. I believe that linkability is
> the core added value of the yellow state. Organizational  guidelines
> may prevent that new collected data can not be linked to already
> collected data. But the fact remains, that the yellow data is not
> fully de-identified for Yahoo!. It may be for other parties if this
> yellow data would be shared.
> But the perspective of other parties is not relevant in the
> determination whether partly de-identified meets the NAI definition.
> To me the perspective of the party that controls the de-identification
> process is important and leading. In this example Yahoo!.
> 
> Where do we disconnect?
> 
> mvg::Rob
> 
> 
> Shane Wiley schreef op 2013-05-27 15:37:
>> Rob,
>> 
>> That is the core issue as I believe the de-identified approach we've
>> documented meets that definition (as do other NAI members).
>> 
>> - Shane
>> 
>> -----Original Message-----
>> From: Rob van Eijk [mailto:rob@blaeu.com]
>> Sent: Monday, May 27, 2013 6:33 AM
>> To: Shane Wiley
>> Cc: public-tracking@w3.org
>> Subject: RE: ACTION-406: Propose a new set of names around yellow
>> state
>> 
>> 
>> Shane,
>> 
>> It is fine to hold it off to a live engagement. For now I would like
>> to add that the NAI defines de-identified as 'data that is not linked
>> or reasonably linkable to an individual or to a particular computer 
>> or
>> device' [1].
>> 
>> If the NAI can, in the Code of Conduct, I do not see why you can't.
>> After all, Yahoo! is one of the NAI members.
>> 
>> mvg::Rob
>> 
>> 
>> [1] page 4 of the NAI Code of Conduct URL:
>> http://www.networkadvertising.org/2013_Principles.pdf.
>> 
>> Shane Wiley schreef op 2013-05-27 15:16:
>>> Rob,
>>> 
>>> So close...  Let's hold on the "partly de-identified" vs. "fully
>>> de-identified" discussion for a live engagement.  I believe you're
>>> equating "de-identified" to be equal for the most part to
>>> "unlinkable"
>>> from a definition perspective whereas they are slightly different to
>>> me.
>>> 
>>> We are indeed on the same page conceptually and simply struggling to
>>> use terms we both agree with so I see this as very positive.
>>> 
>>> - Shane
>>> 
>>> -----Original Message-----
>>> From: Rob van Eijk [mailto:rob@blaeu.com]
>>> Sent: Monday, May 27, 2013 6:13 AM
>>> To: Shane Wiley
>>> Cc: public-tracking@w3.org
>>> Subject: RE: ACTION-406: Propose a new set of names around yellow
>>> state
>>> 
>>> 
>>> Shane,
>>> 
>>> Thanks for friendly ammendment. If you are ok with the following
>>> added precision, you and I have reached consensus. This way we do 
>>> not
>>> have to get into the linguistic difference between the partly and
>>> full de-identified state versus the 2-step process of
>>> de-identification.
>>> 
>>> 
>>> (...) e.g. a partly de-identified but still linkable unique
>>> identifier, such as a hashed pseudonym.
>>> 
>>> 
>>> mvg::Rob
>>> 
>>> Shane Wiley schreef op 2013-05-27 14:39:
>>>> Rob,
>>>> 
>>>> I believe this well stated but am caught up on the following 
>>>> phrase:
>>>> "...MAY contain information indirectly linked to an individual,
>>>> computer or device, e.g. a linkable unique identifier or a hashed
>>>> pseudonym."  Use of a "linkable unique identifier" in this sense
>>>> makes it appear like  we're back in the red state.  Perhaps it 
>>>> would
>>>> be better stated as "...MAY contain information indirectly linked 
>>>> to
>>>> an individual, computer or device, e.g. a de-identified but still
>>>> linkable unique identifier, such as a hashed pseudonym."
>>>> 
>>>> Are you okay with that modification?
>>>> 
>>>> - Shane
>>>> 
>>>> -----Original Message-----
>>>> From: Rob van Eijk [mailto:rob@blaeu.com]
>>>> Sent: Monday, May 27, 2013 4:07 AM
>>>> To: public-tracking@w3.org
>>>> Subject: Re: ACTION-406: Propose a new set of names around yellow
>>>> state
>>>> 
>>>> 
>>>> To avoid confusion, repost as a whole (thanks Mike!):
>>>> 
>>>> 
>>>> For the PII definition, I use the ISO 29100 (privacy framework)
>>>> definition.
>>>> 
>>>> We discussed a 3 state process of de-identification at the last 
>>>> F2F.
>>>> In order to take away any confusion on the difference between 
>>>> partly
>>>> de-identified (YELLOW state) and fully de-identified (GREEN state),
>>>> I propose the following text:
>>>> 
>>>> <TEXT>
>>>> In terms of unlinkability versus de-identification it remains
>>>> important to seperate the two concepts:
>>>> - de-identification helps in the event of a data breach, when a
>>>> dataset is out on the street due to e.g a databreach. It is a way 
>>>> to
>>>> address the reasonable requirements of an adequate level of
>>>> protection.
>>>> - an adequate level of protection is completely different from
>>>> unlinkability. Unlinkability is connected to the notion of
>>>> personally identifieable information (PII).
>>>> 
>>>> This standard refers to the ISO 29100 (privacy framework) 
>>>> definition
>>>> of personally identifiable information (PII):
>>>> any information that (a) can be used to identify the PII principal
>>>> to whom such information relates, or (b) is or might be directly or
>>>> indirectly linked to a PII principal.
>>>> NOTE To determine whether a PII principal is identifiable, account
>>>> should be taken of all the means which can reasonably be used by 
>>>> the
>>>> privacy stakeholder holding the data, or by any other party, to
>>>> identify that natural person.
>>>> 
>>>> The RED state data may contain (a) and (b). In order to go from the
>>>> red state to the yellow state, direct identifiable information MUST
>>>> be removed, e.g. an email address or a phone number.
>>>> The YELLOW state data is partly de-identified, and MAY contain
>>>> information indirectly linked to an individual, computer or device,
>>>> e.g.
>>>> a linkable unique identifier or a hashed pseudonym.
>>>> The GREEN state data is fully de-identified data and SHOULD NOT
>>>> contain personally identifiable information (PII). Any risk for
>>>> re-identification of fully de-identified data MUST be regularly
>>>> assessed and mitigated through Privacy Risk Management.
>>>> </TEXT>
>>>> 
>>>> 
>>>> Rob van Eijk schreef op 2013-05-27 12:15:
>>>>> s/fully de-identified (red state)/fully de-identified (GREEN
>>>>> state)/
>>>>> 
>>>>> sorry for typo. Green is fully de-identified.
>>>>> 
>>>>> Rob
>>>>> 
>>>>> Rob van Eijk schreef op 2013-05-27 12:01:
>>>>>> For the PII definition, I use the ISO 29100 (privacy framework)
>>>>>> definition.
>>>>>> We discussed a 3 state process of de-identification at the last
>>>>>> F2F.
>>>>>> In order to take away any confusion on the difference between
>>>>>> partly de-identified (yellow state) and fully de-identified (red
>>>>>> state), I propose the following text:
>>>>>> <TEXT>
>>>>>> In terms of unlinkability versus de-identification it remains
>>>>>> important to seperate the two concepts:
>>>>>> - de-identification helps in the event of a data breach, when a
>>>>>> dataset is out on the street due to e.g a databreach. It is a way
>>>>>> to address the reasonable requirements of an adequate level of
>>>>>> protection.
>>>>>> - an adequate level of protection is completely different from
>>>>>> unlinkability. Unlinkability is connected to the notion of
>>>>>> personally identifieable information (PII).
>>>>>> This standard refers to the ISO 29100 (privacy framework)
>>>>>> definition of personally identifiable information (PII):
>>>>>> any information that (a) can be used to identify the PII 
>>>>>> principal
>>>>>> to whom such information relates, or (b) is or might be directly
>>>>>> or indirectly linked to a PII principal.
>>>>>> NOTE To determine whether a PII principal is identifiable, 
>>>>>> account
>>>>>> should be taken of all the means which can reasonably be used by
>>>>>> the privacy stakeholder holding the data, or by any other party,
>>>>>> to identify that natural person.
>>>>>> The red state data may contain (a) and (b). In order to go from
>>>>>> the red state to the yellow state, direct identifiable 
>>>>>> information
>>>>>> MUST be removed, e.g. an email address or a phone number.
>>>>>> The yellow state data is partly de-identified, and MAY contain
>>>>>> information indirectly linked to an individual, computer or
>>>>>> device, e.g. a linkable unique identifier or a hashed pseudonym.
>>>>>> The green state data is fully de-identified data and SHOULD NOT
>>>>>> contain personally identifiable information (PII). Any risk for
>>>>>> re-identification of fully de-identified data MUST be regularly
>>>>>> assessed and mitigated through Privacy Risk Management.
>>>>>> </TEXT>

Received on Monday, 27 May 2013 15:26:25 UTC