Re: Can P3P work in the real world?

> Thanks for your response.  It's not that I don't like P3P, but I just
wonder
> if a smaller, simpler first step might have been better.

I can certainly understand why a smaller simpler spec would
be appealing. Believe it or not, the spec used to be much
more complicated -- one of the problems of designing technology
by committee is that everyone has features they want to
be included and you end up with a big bloated mess. So what
we have now is much scaled back, but even so people are
still asking us why we left out various things that they wanted.
Getting the vocabulary any simpler would have required
getting more of a consensus on what the important
fields were to include. Because we could not get such a
consensus, our approach was to make the vocabulary
expressive enough that almost anything can be expressed
(although we are still criticized for not being expressive
enough in some areas).

Incidently, compact policies were added to the spec late in
the process at the request of some working group members
who thought they would help simplify things and make
implementation easier. They are completely optional.
But since IE6 relies on them so heavily, if you use third-party
cookies you pretty much have to use them. Unfortunatly, they
are causing a large number of problems for people.

> > Deploying P3P requires each web site to add one or
> > two files to the site. It does not require changes to every
> > page, nor the installation of any new web site software.
>
> Well, sort of.  Compact policies are returned in HTTP headers, so each
page
> either needs to send that header, or the web server needs to be tweaked to
> always send them out.  If the web server does it, generally that means the
> same compact policy must be sent for all pages in the web site.

Well it varies greatly depending on what kind of web
server you are running.

> The complexity is not with the XML or the tool, but understanding what all
> of the attributes really mean so that we are correctly converting our
> standard privacy policy into the attributes defined in P3P.  There are
lots
> of categories and options that make it more complex to know what's going
on.
>
> > > 4) Who enforces that the policy.xml or compact policy are accurate for
a
> > site?  What's the fallback if the site says they do X to allow a user
> agent
> > such as IE 6 to believe they don't track you, etc., but then do Y
instead?
> >
> > This is the same problem we have enforcing human-readable
> > privacy policies. How do you know that they are accurate?
> > Depending on what country or jurisdiction a web site is in,
> > there is probably a government agency that would investigate
> > accusations of false claims in privacy policies. We expect that
> > such agencies would also be interested in false claims in
> > P3P policies.
>
> Agreed, but why create a solution that has the same pitfalls?  At least
> people could read the regular policy, but they generally can't read the
P3P,
> so if I spoof the P3P -- and especially the compact policies in the HTTP
> headers -- the user would be tricked without even knowing it.  And privacy
> policies are easy to print if you are concerned, but the others less so.

Hopefully there will be good software tools that can read P3P
policies and present them in a standard format to users so that
users can understand them. Part of the problem with many privacy
policies is that they are very long and difficult for consumers
to understand. They also tend to contain a lot of fuzzy language.
P3P forces companies to make multiple choice statements that
can't be fuzzy. Over time it should make it easier for consumers
to understand privacy policies. You might look at the AT&T
WorldNet Privacy Tool (http://privacy.att.net) for an example of
what a P3P-enabled policy summary can look like. There's still
room for improvement, of course.

> > > 6) It's rather hard for a user agent to make sense of such policies.
> >
> > Actually, since user agents are computer programs, they can
> > be developed to do all sorts of interesting things with P3P policies,
> > including functioning exactly as you describe in your next point.
>
> Agreed, though the user-agent needs to let a person know what they are
> trying to accomplish in order to parse it out.  And it's one thing to say
> "don't share with a third party" is what I want, but if I enter a credit
> card, then a third party is guaranteed since you want to validate the
card.
> But this is dramatically different from sharing information to a third
party
> marketing company which creates spam and is often what people want to
avoid.

Right, which is why the P3P vocabulary distinguishes different
types of third party sharing and a good user interface would give users
sensible choices (such as don't share with comapnies other than
those that help the company process my order).

> logged in site: CP="ALL DSP COR DEVa TAIa IVAa IVDa OUR BUS UNI STA OTC"
> public site: CP="NOI DSP COR DEVa OUR BUS UNI STA"

And to translate these into English try
http://www.davidjonathangrant.info/p3p/

> I'll continue to struggle with this, to ensure that these things really
> represent our cookie policies.  In general, we don't require any cookie
> other than a session cookie to track the user while logged on, yet we're
> blocked by IE6 in HIGH mode, but are fine in MEDIUM-HIGH.  I'm not
entirely
> sure why.

My guess is that IE6 is not reading the compact policies on
your session cookies. In medium high this doesn't matter
but in high this would cause them to be blocked. But that is just
a guess.

Lorrie

Received on Tuesday, 13 November 2001 13:44:53 UTC