RE: potential requirement/guidelines on acceptable Purpose / Cate g ory combinations

Okay we are closer but not quite there.  The requirement is "linked" not
"used".  If you use it or not you still need to declare it (what stops you
in the future?).  What my initial point is, is if you in fact USE it, it is
prima facie evidence that you have it linked.

So to follow our example.  If you have a cookie set to a Loyalty # abc123.
And the company's internal DB looks like this:

client_table
loyalty_id (loyalty #)  PRIMARY KEY
lname
fname
address
phone_number
ssn
political_party 

purchase_table
order_id  PRIMARY KEY
loyalty_id FORIEGN KEY --> client_table.loyalty_id
value
sku

And the initial web transaction log may look like:

WebLog
IP
TimeStamp
Remote_User
User_agent
URL_requested
Refer
RequestStatus
FileSize
Cookie


Here we have an architecture where loyalty_id is either the foreign or
primary key to 3 tables.  If I have a loyalty_id, what can I look up?  what
is "linked"?

There may be *some* argument (not mine) that it doesn't link data elements
within the WebLog as they may or may not be directly queriable (still there
is a static link between e.g. Cookie and URL_requested).

However, IMHO, in the example above the data controller doesn't have to act
upon the political_party field to need to declare it.  Why?  In the example
above polital_party has the exact same relationship to loyalty_id as does
phone_number.  The fact that you USE one or the other has no impact on
whether it is linked or not.


-Brooks

Brooks Dobbs
Director of Privacy Technology
DoubleClick, Inc.

office: 404.836.0525
fax: 404.836.0521
email: bdobbs@doubleclick.net


-----Original Message-----
From: Humphrey, Jack [mailto:JHumphrey@coremetrics.com]
Sent: Tuesday, May 20, 2003 8:35 AM
To: 'public-p3p-spec@w3.org '
Subject: RE: potential requirement/guidelines on acceptable Purpose /
Cate g ory combinations



I think I understand now. I always think about the cookie policy declaring
what data is being collected for what purposes (maybe because that's how
user agents tend to express it), but it also has to declare what other data
will be used for those purposes.

Let's say that my user agent allows me to express that:
1. I don't want to accept or send cookies containing sensitive personal
information.
2. I don't want to accept or send any cookies whose purpose is to enable
someone to contact me by phone or email for marketing purposes.

In the example I gave, if a site sets a cookie containing a loyalty number
(UNI) and declares that it is for indiv. analysis (IVA), then as I
understand it now it should also declare purchase (PUR) since that's what
the the loyalty # will be used to look up for the analysis. The fact that
the company could also look up my phone number and email address is not
relevant since that's not the purpose of this cookie, right? Okay, that
makes sense, and the user agent implementation might allow that cookie if it
didn't map UNI and PUR to "sensitive personal information."

But I don't think the user agent could allow you to express #1 but not #2
(say you don't mind telemarketing and online contact). Then if the loyalty #
was being collected for telemarketing, the policy would have to include PHY
in addition to UNI and TEL, and the user agent couldn't allow the cookie,
even though it doesn't violate the expressed preferences, because it
couldn't distinguish that the cookie doesn't contain a phone number. That
troubles me, but it's something of an orthogonal issue to the points you
raise.

Jack

-----Original Message-----
From: Rigo Wenning
To: public-p3p-spec@w3.org
Sent: 5/20/2003 5:06 AM
Subject: Re: potential requirement/guidelines on acceptable Purpose / Cate
g ory combinations


On Mon, May 19, 2003 at 02:25:42PM -0400, Dobbs, Brooks wrote:
> What this all boils down to is, if the data collector declares a
purpose
> that requires identity, then they obviously HAVE the identity.  If you
claim
> that you are going to telemarket to me, you have my phone number.  I
think
> that it is now generally understood that the actual phone number won't
be
> stored as the clear text value within the cookie but rather referenced
> through a UNI value of the cookie.  To the data subject it doesn't
matter if
> you reference using phone #, loyalty #, credit card # or a SSN so long
as
> the intent or the data construct is to use the value to reference
other data
> (though clearly for some these you may need to go past simply UNI even
for
> the reference string itself).

http://www.w3.org/TR/P3P/#cookies

I think we specified that already by saying in 2.3.2.7 The
COOKIE-INCLUDE and COOKIE-EXCLUDE elements:

A cookie policy MUST cover any data (within the scope of P3P) that is
stored in that cookie or linked via that cookie. It MUST also reference
all purposes associated with data stored in that cookie or enabled by
that cookie. In addition, any data/purpose stored or linked via a cookie
MUST also be put in the cookie policy. In addition, if that linked data
is collected by HTTP, then the policy that covers that GET/POST/whatever
request must cover that data collection.

Best, 

Rigo

Received on Tuesday, 20 May 2003 10:29:55 UTC