RE: Deidentification (ISSUE-188)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For collected data to be retained under 3.3 (third-party compliance – “3. or, the data is de-identified as defined in this recommendation” ) it should have a stricter requirement i.e. it has to be impossible to link it back to an individual.

How about we have a different definition for this out-of-scope data i.e. call it “anonymised”, something like “has been deleted, aggregated or otherwise processed to make it impossible to link to a person”.

We then leave the definition for de-identified (the existing set of CfO proposals) for the permitted use and unknowingly collected cases.

Mike

From: Justin Brookman [mailto:jbrookman@cdt.org]
Sent: 30 July 2014 03:12
To: David Singer
Cc: public-tracking@w3.org List
Subject: 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJT2LP8AAoJEHMxUy4uXm2JvngIAKNKS7IK3wwF8mvpqClI9ILe
KA5MrubNiUEnKOh4FdU9NMJNQyOr3rmKXquY5tcht8Y1AwId0VEH3SbpkWyB7q27
S8lIPrAVd9RCzNLcXcI1ZzEF8vFL8Odm9RUJ1bDUdXQJdU5ZugszQb24Q6jvNWFa
OOCXQOGY7WjraWkoPiRuQ8sajnF4tYrrIvH1wp3U7XKEmPe+MB174q8pU4qP/Z0h
/b6LBSHOxh2yFWkc54m626R08jf5OytRA8Fy5x/P3vDgFnOA+2ZU1KhS9nz/EUJL
RmFz4xIEmNjX2ZXaW3oSEmK7SYfXDiZEhvUAkYiwUdUfHKrLfR1oDOKO68D7qZM=
=qM1i
-----END PGP SIGNATURE-----