RE: ACTION-406: Propose a new set of names around yellow state

Thanks Mike,

I am not ready to make the next step, the goal for this text proposal 
is to allow for a discussion to find out which permitted uses (if any) 
and under which requirements are permitted in the yellow state. Deletion 
or aggregation after short term use may be one of such requirements.

Rob

Mike O'Neill schreef op 2013-05-27 13:34:
> +1. I would add that the "partly de-identified" (yellow) category,
> although important for managing retained datasets is not all that
> relevant to tracking protection. Tracking is the collection of an
> individual's web history over time and if the DNT:1 signal means
> anything it is that linking with UIDs (akin to sticking a post-it note
> on their back)  should not occur.
> 
> I would also add (again) that unlinking does not require the non-use
> of unique identifiers or their immediate deletion when DNT:1, but only
> that identifiers are deleted after a short period  i.e. no longer than
> is required for a permitted use.
> 
> The HTTP cookie mechanism already allows for this with the expires
> component. We could recommend that the same ability should be
> available with localStorage (i.e. localStorage.setItem could have
> another parameter specifying an expires datetime such that calling
> getItem (or enumeration) after the datetime removes the item) and that
> data controllers limit the duration of localStorage to that required
> for permitted uses when tracking consent has not been given.
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Rob van Eijk [mailto:rob@blaeu.com]
> Sent: 27 May 2013 11:01
> To: public-tracking@w3.org
> Subject: ACTION-406: Propose a new set of names around yellow state
> 
> 
> For the PII definition, I use the ISO 29100 (privacy framework) 
> definition.
> 
> We discussed a 3 state process of de-identification at the last F2F.
> In order to take away any confusion on the difference between partly
> de-identified (yellow state) and fully de-identified (red state), I
> propose the following text:
> 
> <TEXT>
> In terms of unlinkability versus de-identification it remains
> important to seperate the two concepts:
> - de-identification helps in the event of a data breach, when a
> dataset is out on the street due to e.g a databreach. It is a way to
> address the reasonable requirements of an adequate level of
> protection.
> - an adequate level of protection is completely different from
> unlinkability. Unlinkability is connected to the notion of personally
> identifieable information (PII).
> 
> This standard refers to the ISO 29100 (privacy framework) definition
> of personally identifiable information (PII):
> any information that (a) can be used to identify the PII principal to
> whom such information relates, or (b) is or might be directly or
> indirectly linked to a PII principal.
> NOTE To determine whether a PII principal is identifiable, account
> should be taken of all the means which can reasonably be used by the
> privacy stakeholder holding the data, or by any other party, to
> identify that natural person.
> 
> The red state data may contain (a) and (b). In order to go from the
> red state to the yellow state, direct identifiable information MUST be
> removed, e.g. an email address or a phone number.
> The yellow state data is partly de-identified, and MAY contain
> information indirectly linked to an individual, computer or device,
> e.g.
> a linkable unique identifier or a hashed pseudonym.
> The green state data is fully de-identified data and SHOULD NOT
> contain personally identifiable information (PII). Any risk for
> re-identification of fully de-identified data MUST be regularly
> assessed and mitigated through Privacy Risk Management.
> </TEXT>

Received on Monday, 27 May 2013 12:26:24 UTC