RE: linked

Some comments:
1. I don't think the requirement that it be stored as a particular database
record is valid. I think that linkability should be described independently
of the technical architecture used. This is why I tried to describe it in
terms of the intentions and proportionality.
2. You do not mention the use of referers to link cookies together.
3. I think the examples given are simpler than those I gave.


>**
>**I propose that we remove the last 3 paragraphs of 1.3.2 that 
>**pertain to "linked" data and change the title of that 
>**section to "Non-identifiable" Data. Then add a new section 
>**1.3.4 as follows:
>**
>**
>**1.3.4 Linked and Linkable Data
>**
>**<p>Cookies often store a unique number or database key that 
>**links to a database record, rather than storing the complete 
>**database record. Web sites that use P3P must disclose not 
>**only the types of data stored directly in a cookie, but also 
>**all data linked to a cookie. A large amount of data may be 
>**"linkable" to a cookie without actually being "linked" to 
>**that cookie. </p>
>**
>**<p>A piece of data X is said to be <i>linkable</i> to a 
>**cookie Y if a key stored in cookie Y can be used to retrieve 
>**X either directly or indirectly. A direct retrieval might 
>**happen, for example, if the key is associated with a 
>**database record in which X is stored. An indirect retrieval 
>**might happen, for example, if the key is associated with a 
>**database record that contains a piece of data that may be 
>**used, in turn, as a key to retrieve a record in a second 
>**database, and X is stored in the second database. 
>**Furthermore, if cookie Y is stored in a server log file, the 
>**log file may facilitate further linking. For example, 
>**imagine a web site that sets two cookies, Y and Z. Cookies Y 
>**and Z may get replayed in the same HTTP request and 
>**subsequently recorded side-by-side in the server log file. 
>**Thus all data associated with cookie Y are also linkable to 
>**cookie Z. Indeed, unless precautions are taken to minimize 
>**server log files and severely restrict the use of 
>**identifiable data, almost all data an entity stores about an 
>**individual are likely to be linkable to any cookies they 
>**have set on that individual's computer.</p>
>**
>**<p>A piece of data X is said to be <i>linked</i> to a cookie 
>**Y if at least one of the following activities may take place 
>**as a result of cookie Y being replayed:</p>
>**
>**<ul>
>**
>**<li>X is retrieved from a database.</li>
>**
>**<li>Information collected about the user during the current 
>**session -- including data entered into forms, IP address, 
>**clickstream data, client events, or other data associated 
>**with the user's visit to the web site -- is added to a 
>**record in which X is stored.</li>
>**
>**</ul>
>**
>**<p>
>**If either of these activities happen immediately upon cookie 
>**replay or at some future time (perhaps as a result of 
>**retrospective analysis of server logs), then the piece of 
>**data X is considered linked to cookie Y. </p>
>**
>**<p>Entities should consider their data collection and 
>**storage architectures carefully to determine what data may 
>**be linkable to their cookies and what data will actually be 
>**linked to each cookie. If data is linkable but does not 
>**actually get linked to a particular cookie, it does not have 
>**to be disclosed in a P3P statement concerning that cookie. 
>**However, should the entity associated with that P3P policy 
>**ever link the data for any reason other than to comply with 
>**law enforcement demands, they would be in violation of their 
>**stated policy. </p>
>**
>**

Received on Monday, 16 February 2004 04:59:27 UTC