Re: P3P Specification Ambiguity: Cookies

First suggestion.  Think this through a little more and
be very careful how you phrase things.  Incorporate a
slightly better explanation into your draft spec.  You
need to really be clear in telling people why the spec
requires what it requires, or they won't adopt P3P.

2nd; You need to make sure that you're not confusing the
potential for a practice with the actual practice.  If
I use a cookie as a state preservation mechanism and I
do not, in practice, link that to user data in order to
track individual user behavior, then I should not be
required to disclose that the cookie could potentially
be used for that purpose.  If we disclose all potential
uses for a cookie, web clients will be making decisions
that are based on potential uses and not actual uses,
and pretty much every site that uses cookies as a state
preservation mechanism will take issue with that.

3rd; You need to write something into the spec that will
regulate how P3P is intended to be used in clients like
IE 6.  It seems obvious that they are using it too early
and in a way that doesn't jibe well with the intent of
the specification.  They are making basic assumptions
about whether cookies are 'satisfactory' or not which
could be detrimental to web sites that use cookies, and
they are using your specification draft recommendation
as justification for their actions.

4th; If you don't have a team of lawyers working on your
specification, you need to get some.  P3P touches deeply
on legal matters, and poses a liability danger to anyone
who adopts it in practice.  The more work you do to really
clarify the language used and the rationale behind parts
of the specification now, the less work companies will
have to do in order to adopt P3P.  I'm looking at P3P now
and thinking it would take a team of lawyers working with
a team of software engineers for months to draft a really
compliant P3P policy for a large existing web site that
will not create an immediate legal liability.  That is an
incredible barrier to adoption in time, money, and the
potential for litigation based on varying interpretations
of P3P and the policies that are created using it.

I'm assuming that your goal is to get companies to
voluntarily adopt P3P and you aren't going to rely on
companies that produce web clients to force companies
that offer web services to adopt P3P.  That would be
very bad for the industry.

What are you doing to address these issues?

What are the milestones for your specification?  How
far along do you think you are?

How closely are you working with Microsoft regarding
issues with Internet Explorer's use of P3P?

-Chris



Lorrie Cranor wrote:
> The intent behind the 2.3.2.7 text about data linked via
> a cookie is to make sure that sites disclose the data
> practices enabled by a cookie. If the spec limited 
> disclosures to just the data stored in a cookie, most
> cookies would be labelled simply as storing a unique
> identifier. This doesn't tell the user very much. The
> important information is what this identifier gets linked
> to, and the resulting actions that may be taken. 
> For example, I may not mind if a site uses cookies
> to monitor my browsing behavior and serve me
> customized content or ads. But if the cookies that
> are used to link to gether information about my
> web browsing in turn get linked to a database with
> my personally identifiable information, I might object,
> because I don't want my browsing behavior linked
> to my name. What data is contained in the cookie
> vs. in the linked databases, and whether or not
> any of it is encrypted does not matter from the
> perspective of trying to figure out what the cookie
> is actually enabling.
> 
> Does this help make things clearer?
> 
> Lorrie
> 
>

Received on Wednesday, 6 March 2002 13:24:06 UTC