Change proposal (Re: ACTION-412, Naming R/Y/G)

posted under 
http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0279.html

repost including 'change proposal' in the subjectline

Rob

> Rob van Eijk <rob@blaeu.com> wrote:
> 
>> Hi Peter, Dan, Shane,
>> 
>> I am neutral on a 3 state or 2 state approaDear Peter, Dan, Shane,
>> 
>> * On the naming of the end-state:
>> For me the Y is not the end-state and should therefore not be named 
>> de-identified. In a 3 state model, the G is the de-identified 
>> end-state. In a 2 state model, de-identified is the second state.
>> 
>> * On the definition of de-identified:
>> I support the more open definition of de-identifed of Dan/Lee.: Data 
>> can be considered de-identified if it has been deleted, modified, 
>> aggregated, anonymized or otherwise manipulated in order to achieve a 
>> reasonable level of justified confidence that the data cannot 
>> reasonably be used to infer information about, or otherwise be linked 
>> to, a particular user, user agent, or device.
>> The definition draws a clear line in the sand with regards to the 
>> quality of the data in the end state of a data scrubbing process. This 
>> mail is written with this definition in mind.
>> 
>> * Non-normative remark 3, June draft change proposal 
>> de-identification:
>> If data is de-identified, is can be shared with other parties 
>> regardless of the DNT expression, but with one condition: the 
>> obligation to regularly assess and manage the risk of 
>> re-identification. This is addressed by Dan in the non-normative 
>> remark 3
>> 
>> * On the issue of a 2 or 3 state approach:
>> The issue at hand is to add permitted used to the states. This has 
>> not been identified yet in the change proposal. I share the view of 
>> Dan, that hashing a hash is a null. But there are many elements in raw 
>> data that are not hashed, even elements that may be derived from the 
>> protocol. Having an intermediary step has it's merit in my view, since 
>> scrubbing the data reduces the risk of data disclosure in case of e.g. 
>> a data breach. Scrubbing data into an intermediary format addresses a 
>> reasonable level of protection.
>> Another reason is that having a 3 state approach allows for mapping 
>> permitted uses to either the RAW state or the intermediary state.
>> 
>> * On the issue of unique ID's for permitted uses an linkability 
>> versus de-identified:
>> Mapping a permitted use to a state of de-identified data is not 
>> logical to me. If you have a permitted use, it's data purpose must be 
>> well defined. I work under the assumption that new data should be able 
>> to be linked to data on file for a permitted use. In a truly 
>> de-identified end state this functionality would not be possible. In a 
>> truly de-identified state, data can no longer be linked to data 
>> already collected on file. If DNT:1 no data, except for the permitted 
>> uses must be shared in linkable form.
>> 
>> <text>
>> Mapping of permitted uses to a 3 state approach: 
>> R: (RAW state, still linkable): Security/Fraud
>> Y: (Intermediary state, and still linkable): other permitted uses
>> G: (de-identified), no longer linkable: no permitted uses, data may 
>> be shared under the obligation to manage the risk of 
>> re-identification.
>> </text>
>> 
>> * On the issue of key concepts:
>> Text amendment/proposal of key concepts under the definition of 
>> de-identified by Dan:
>> <text>
>> * De-identification: a process towards un-linkability.
>> * Linkability: the ability to add new data to previously collected 
>> data.
>> </text>
>> 
>> Thanks,
>> Rob

Received on Wednesday, 26 June 2013 16:29:34 UTC