This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 167 - explanation of identified, identifiable, and linked
Summary: explanation of identified, identifiable, and linked
Alias: None
Product: P3P
Classification: Unclassified
Component: Clarifications needed (show other bugs)
Version: unspecified
Hardware: Other other
: P2 normal
Target Milestone: P3P1.1
Assignee: Ari Schwartz
QA Contact:
Depends on:
Blocks: 172
  Show dependency treegraph
Reported: 2003-03-10 21:28 UTC by Lorrie Cranor
Modified: 2008-12-02 22:41 UTC (History)
0 users

See Also:

Draft explanation for Inclusion in next update (4.41 KB, text/plain)
2003-06-23 12:37 UTC, Ari Schwartz

Description Lorrie Cranor 2003-03-10 21:28:49 UTC
Use of the terms identified, identifiable, and linked are still somewhat confusing in the 
spec. We need additional explanations and clarifications of the meanings of these terms 
and the history of why we are using them this way. Some of this might be added to the 
1.1 spec or included in an appendix; however, we should consider drafting a W3C Note 
on this. 

This will be assigned to Ari as soon as he creates an account.
Comment 1 Rigo Wenning 2003-04-30 12:18:11 UTC
<quote>all information linked to a cookie</quote> in section 4
First, we don't require that for full policies. This sounds strange to me. 
Second, as we use linking all the time for the URI to the human readable policy, 
it might be good to change the wording of linked here to: 
also data that shares the same identifier with the cookie or data where the 
cookie serves as a common identifier.

For identified vs identifiable, I think there was an assumption that we 
understand identifiable as laid out in the EU-Directive whereas 26:
<a href="!celexapi!prod!
CELEXnumdoc&lg=EN&numdoc=31995L0046&model=guichett">link to directive</a>
(26) Whereas the principles of protection must apply to any information 
concerning an identified or identifiable person; whereas, to determine whether a 
person is identifiable, account should be taken of all the means likely 
reasonably to be used either by the controller or by any other person to 
identify the said person; whereas the principles of protection shall not apply 
to data rendered anonymous in such a way that the data subject is no longer 
identifiable; whereas codes of conduct within the meaning of Article 27 may be a 
useful instrument for providing guidance as to the ways in which data may be 
rendered anonymous and retained in a form in which identification of the data 
subject is no longer possible; 

while identified means, that one has already made (identified) the person, e.g. 
stored all information in a database together with personal information so that 
the whole record can easily be digged up.

Comment 2 Lorrie Cranor 2003-04-30 13:44:20 UTC
Actually, we do require this for full policies if the full policy makes disclosures about 
Comment 3 Rigo Wenning 2003-06-23 09:28:17 UTC
But we don't require it for any uniqueID. We included the information linked to 
a cookie to make clear that the property of a cookie as an identifier in a 
database table was the technics mostly used and the information in the cookie 
itself were not really relevant. 
But this counts for any uniqueID. So perhaps the Specification might be 
inconsistent to this.
Comment 4 Ari Schwartz 2003-06-23 12:37:46 UTC
Created attachment 18 [details]
Draft explanation for Inclusion in next update
Comment 5 Rigo Wenning 2004-01-21 05:00:21 UTC
The final wording is not the one in the attachement, this is the initial 
wording. The final wording is of September 2003 and in the mailing-list. I will 
put together a consolidated draft and put it here.
and the following thread.
Comment 6 Rigo Wenning 2004-01-21 06:00:43 UTC
Consolidated Draft at:
Comment 7 Rigo Wenning 2004-01-22 09:43:36 UTC
The text is now in Annex 8 of the P3P 1.1 Specification