Re: Deidentification (ISSUE-188)

On Jul 25, 2014, at 13:24 , Justin Brookman <jbrookman@cdt.org> wrote:

> 
> On Jul 23, 2014, at 3:01 PM, David Singer <singer@apple.com> wrote:
> 
>> 
>> On Jul 23, 2014, at 11:49 , Roy T. Fielding <fielding@gbiv.com> wrote:
>> 
>>> On Jul 23, 2014, at 10:22 AM, David Singer wrote:
>>>> I understand your hesitation and share some of it.  However, I feel that
>>>> * de-identification has been defeated often enough that we cannot be sure people will always succeed
>>>> * a user who is harmed should be able to work out who has responsibility: someone who defied a restriction on the data, or someone who made it available without that restriction.
>>>> 
>>>> There are, alas, enough people out there who would try to engineer a situation in which it appears no-one is responsible ("we did our best to make it de-id’d”, “no-one said we couldn’t try to re-id”) that I think we need to close that chink somehow, formally.
>>> 
>>> The right way to do that is with an accurate definition and a separate
>>> formal requirement on any party (or third party).   Mixing the two results
>>> in an incorrect definition due to the false negatives.
>> 
>> I think I am fine with that;  where we talk of de-identifying the data, we say that the party doing so commits to taking responsibility, or passing on the responsibility, that it is not re-identified.
> 
> So David, are you OK with Roy’s definition:
> 
> A data set is considered de-identified when there exists a reasonable
> level of justified confidence that none of the data within it can be
> linked to a particular user, user agent, or device.
> 
> Do either of you want to suggest language for the spec to bind parties to
> not try to reidentify?

The concept appears 3 times in the TCS, and in each place, a requirement to keep it de-identified would seem tricky to write. (Someone is welcome to try).

Perhaps it would be cleaner to have two definitions:

* de-identified

* persistently de-identified

with the first being a definition of the state (as above), and the second has the data carrying the requirement requirement that the originator not attempt to re-identify, and that any sharing with another party by the originator or anyone receiving the data with this restriction, either pass on the restriction, or accept the responsibility if re-identification in fact occurs.

then we can use the one or the other in the document, as appropriate.

> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Friday, 25 July 2014 20:32:26 UTC