- From: Rob van Eijk <rob@blaeu.com>
- Date: Wed, 26 Jun 2013 18:29:05 +0200
- To: <public-tracking@w3.org>
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