Re: Deidentification (ISSUE-188)

David Singer <singer@apple.com> , 7/25/2014 4:33 PM:
 
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. 

So this sounds like a stricter version of the red-yellow-green discussion from before.  What do you envision requiring regular deidentification, and what would require persistently de-identified (really deidentified + promises/liability)?  Would it be just for sharing?  So there wouldn't need to be an internal promise not to reidentify, but if you release, you either get a promise or take responsibility?

What would "responsibility" look like?  We can't really create a cause of action with a technical standard.

 
>  
>  
>  
 
David Singer 
Manager, Software Standards, Apple Inc.