Re: Can P3P work in the real world?

Lorrie,

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.

> > 1) It's too complex, allowing policies to vary page by page.
>
> This is an option -- but most web sites seem to be
> declaring one policy for the whole site. Sites do not have
> to take advantage of this complexity.

I wonder if this has more to do with the complexity than anything else.
After all, most privacy policies were written to cover the entire site
because it would be way to confusing to visitors to have policies that vary
page by page.  In our world, our policy actually does vary page by page, but
we chose to say our policy covers the entire site because it's easier to
understand.  (For example, we don't track users at all while on our public
site, but we do as soon as they go to the registration/signup page.)

> > 2) It requires changes to all existing web sites/pages.
>
> 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.


> > 3) Generating an accurate policy.xml file is quite complex compared to
> describing the situation in the human readable privacy policy.
>
> If you use a P3P policy generator tool the problem should
> not be that complex. Furthermore, we hope it will become
> easier as better documentation becomes available over
> the next few months.

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.

> > 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.

> > Is this standard just something to make people feel good, but the
> implementation will be so complex that it's ignored by the masses?
>
> No. We realize it will take some time for implementers to
> figure out what the best ways are to present these complicated
> concepts to users in a useful way, but we do believe that over
> time P3P will become something truely useful. If your company
> focusses on the privacy of the individual, then I think you
> should be able to appreciate this. There are a lot of different
> opinons about what are the important privacy issues, and
> these vary from country to country as well as from person to person.
> We developed P3P to be very flexible, but we expect that user
> agent tools will be developed that will simplify this complexity
> for users.

I guess time will tell.  I'd have preferred a simpler model up front so that
most sites could easily setup their policies using a limited set of
information that are perhaps the most critical for web users.  Complexity
could grow over time as people came up to speed.  If I have a hard time
understanding what the various options mean in a privacy policy and in the
compact policy, for sure a typical end-user won't have a clue, and many web
site administrators won't know either.  We just trust that the info pumped
out by tools like IBM's P3P tool are correct and reflect what we really do.

> You may find
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpriv/html
> /ie6privacyfeature.asp
> useful for better understanding IE6. You may also be interested
> in joining the www-p3p-policy mailing list
> to discuss your questions with other folks working on
> implementing P3P
> http://lists.w3.org/Archives/Public/www-p3p-policy/

Thanks. The links were useful, though even reading how IE6 works continues
to confuse me.  Our current compact policies show up as:

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"

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.  Obviously, we customize the user's view when logged in so that
they see their data (what would the privacy be if we showed them other
people's data? <wink>), and because they are customers, they have provided
us credit card information, so we have contact and financial info that they
are free to update.  But if they were not our customer and were just a
recipient of a document from our customer, they don't need to provide us any
of that information, yet they are on the same site.  So the use of a cookie
depends -- even if the cookie just as a session id in it.  The cookie does
have financial info related to it -- though not stored in the cookie! -- for
customers, but not for others, and sending out different compact policies
for that means I have to change every page to emit the right CP depending on
the customer's mode of use.  Yikes!

Best of luck, and thanks for your reply....

David

Received on Monday, 12 November 2001 17:35:17 UTC