Web DevCenter    
 Published on Web DevCenter (http://www.oreillynet.com/javascript/)
 See this if you're having trouble printing code examples

Web Privacy with P3P

A Webmaster's Guide to Troubleshooting P3P

by Lorrie Faith Cranor, author of Web Privacy with P3P

The www-p3p-policy mailing list gets a steady stream of messages from frustrated Webmasters who are trying to P3P-enable their Web sites and have run into difficulties. In some cases these Webmasters do not understand fundamental concepts about how P3P works. However, in many cases they actually have come pretty close to successfully P3P- enabling their sites, but something is still not quite right. In this article I review some troubleshooting strategies and list some of the frequent mistakes I have seen people make. For more detail about the entire process of P3P-enabling a Web site as well as examples of how to write policies that cover a variety of common Web site scenarios, check out my book, Web Privacy with P3P.

Test, Test, Test

The first thing you should do after P3P-enabling a Web site is to test it to make sure your P3P implementation is correct and that it works. This should be done using the W3C's P3P Validator and using at least one P3P user agent.

You can use the P3P Validator to check to make sure your P3P files are syntactically correct and placed in the appropriate location on your Web server. If the validator reports any errors, read them carefully, and work through them one at a time until you get a successful validation report. Unfortunately, bugs are still being found in the validator from time to time, so in some rare cases, valid sites do not validate, or errors are not caught. Therefore it is a good idea to review the list of known bugs on the validator Web site and check to see if any of them may be applicable to you. If you have configured your Web server to issue P3P headers, you need to make sure that your server is actually issuing those headers. The validator report will indicate whether or not the validator received any valid P3P headers from your Web site.

Related Reading

Web Privacy with P3P
By Lorrie Faith Cranor

Once you have validated your site, you should test it with at least one P3P user agent, and, if possible, with all P3P user agents that visitors to your site might be using. Right now I would advise Webmasters test their P3P implementations using IE6, Netscape 7, and the AT&T Privacy Bird. The first thing to test with all three of these P3P user agents is whether they can produce a human-readable summary of your site's P3P policy. You can get that summary with Privacy Bird by clicking on the bird and selecting Policy Summary from the About This Site menu. IE6 will produce a policy summary if you select Privacy Report from the View Menu. In Netscape 7 you will need to go to the View menu, select Page Info, go to the Privacy tab, and click on the Summary button.

Besides verifying that all three user agents can produce a policy summary, you should also read the summaries and make sure they accurately reflect your privacy policy. This is a good way to spot any errors you may have made when encoding your privacy policy in XML. While we have found some rare cases where valid P3P policies are not properly displayed, or not displayed at all by one or more P3P user agents, generally, if your policy does not display properly, it indicates there is something wrong with your policy. If you make changes to your policy, you may need to clear your browser's cache or the Privacy Bird's cache before you see an updated policy summary.

If you have implemented compact policies on your Web site, you should also use IE6 and Netscape 7 to see how your cookies are handled. You should be sure to test URLs that result in your cookies being set in a third-party context (if your cookies are ever used in such a context). Use the browsers' default (medium) settings to make sure your cookies will not be blocked for most users. If IE6 displays an eye with a do-not-enter sign in the lower right hand corner, then your cookies are being blocked or restricted. Click on the eye for more information. Likewise, Netscape will display a cookie icon in the lower right hand corner when cookies are being blocked, restricted, or flagged. When these icons appear, it does not necessarily mean that your cookies are being blocked, so do read the more detailed information to find out how the browser is handling each cookie.

Related Article:

Help! IE6 Is Blocking My Cookies -- Lorrie Cranor, author of Web Privacy with P3P offers an introduction to P3P and an overview of what you need to do to prevent IE6 from blocking your cookies.

IE6 and Netscape 7 browsers may block, restrict, or flag cookies when they do not have a compact policy (or there is a problem with the compact policy) or when the compact policy indicates an "unsatisfactory" privacy practice. (Users may configure them to block cookies under other conditions as well). Several tools will tell you whether or not your compact policy will be considered satisfactory by IE6, including the IBM P3P Policy Editor and the P3P Compact Policy Translator.

Common P3P Policy Problems

A frequent problem I see with Web site P3P policies is that they mention only data they collect explicitly from Web forms. Don't forget to mention Web log files too. Almost every site keeps Web log files. Unless you know for a fact that your site keeps no Web logs, make sure you mention them in your P3P policy. Several examples of how to do this are explained at the end of Chapter 9, "Data Schemas," in my book.

Some P3P policies do not disclose all of the data associated with cookies. It is not sufficient to describe only the data stored in a cookie; you must also describe the data linked to the cookie. So, for example, if the cookie contains a unique identifier that is used as a database key, all of the types of information in that database must also be described. You must also be aware of how this data will be used by all of the sites in your domain to which the cookie might be replayed.

Some policies disclose the contact purpose unnecessarily. The contact purpose need only be disclosed if the site may contact visitors for marketing. If the site contacts visitors only in response to their emails or as part of performing the service the visitor requested (unless the requested service is marketing), then the contact purpose is not necessary.

Webmasters should make sure that if their sites indicate that opt-in or opt-out choices are available, then they should disclose an opturi that actually explains how to opt-in or opt-out. I've seen some sites point to a statement that says that it is possible to opt-out, but does not provide instructions on how to do it. I've also seen sites that incorrectly write an email address or phone number in the opturi field instead of providing a URL. A mailto URL is also not a valid opturi, as it provides no information about opt-out options.

Common Policy Reference File Problems

One of the most common errors I have seen in policy reference files are sites that include <include>/</include> in their policy reference file when they want to apply a policy to their entire site. This statement will apply the policy only to the home page. The correct way to apply a policy to an entire site is with <include>/*</include>. I have also seen sites that use a "\" character instead of a "/" character. The "\" character is incorrect.

It is easy to get confused about the absolute URL to which relative URLs are relative. Relative URLs in the about attribute are evaluated relative to the policy reference file (which is often in the /w3c directory). Relative URLs in INCLUDE and EXCLUDE elements are evaluated relative to the root of the host to which they are applied. To avoid some of this confusion, you can always begin your relative URLs with a "/" character to indicate that they are relative to the root of the host to which they are applied. Don't forget to include the name of the policy in the about attribute. The policy name is in the name attribute of the POLICY element. Add a pound sign (#) to the end of the URL for the policy file and then add the policy name. Thus, if a policy named "policy" was found in a file at http://www.example.com/w3c/policyfile.xml, then the about attribute would have the value http://www.example.com/w3c/policyfile.xml#policy. Because URLs cannot contain spaces unless they are properly escaped, do not put a space in your policy name.

If you want to apply your policy to cookies on your site, don't forget your COOKIE- INCLUDE elements. P3P user agents will not apply any policy to your cookies unless you have COOKIE-INCLUDE elements.

Don't put your policies and policy reference files on parts of your Web site that are password-protected or require authentication. A P3P user agent will usually not be able to authenticate itself and thus will not be able to fetch these files automatically. If you have a password-protected site that you want to P3P-enable, it's best to put your P3P files outside the password-protected area.

If you have a secure server that is addressed with URLs like https://www.example.com, and you are using the well-known location, make sure that a request to https://www.example.com/w3c/p3p.xml will return your policy reference file. If the policy reference file is not accessible with an https request, P3P user agents won't be able to find it.

Common Compact Policy Problems

If you think you've done everything right but IE6 is blocking your cookies under its default setting, it's time to do some more testing. First, you need to make sure that your compact policies are actually being served in the same response in which your cookies are being set. Then you need to make sure your compact policy syntax is correct--make sure you check the validator bug list too--and that your compact policy is considered "satisfactory."

I've corresponded with a number of implementers who were pulling their hair out trying to figure out why their cookies were being blocked, only to discover that their cookies were not really being blocked. After P3P-enabling your site or changing your compact policy configuration, make sure you delete the relevant cookies and restart your browser before testing. Otherwise you may be observing the behavior of legacy cookies that were not properly P3P-enabled.

Where to Turn for Help

I hope this article has helped you learn how to troubleshoot your P3P implementation. However, if you need more information there are several places you might turn to for help. The W3C P3P Web site, the P3P Toolbox Web site, and the Web site for my book all contain a variety of online resources that may be helpful. My book is also an excellent resource for Webmasters. In addition to providing a detailed tutorial on P3P-enabling a Web site, it also contains a lot of background on privacy issues, writing privacy policies, and more. Finally, the W3C's www-p3p-policy@w3.org mailing list is a good place to read about how other people solved P3P implementation problems and to post your own questions. To subscribe, email with "subscribe" in the subject line. The mailing list archive is available at lists.w3.org/Archives/Public/www-p3p-policy/.

O'Reilly & Associates recently released (September 2002) Web Privacy with P3P.

Lorrie Faith Cranor is an Associate Research Professor in the School of Computer Science and in the Engineering and Public Policy Department at Carnegie Mellon University. She is director of the CMU Usable Privacy and Security Laboratory (CUPS). She came to CMU in December 2003 after seven years at AT&T Labs-Research.

Return to the Web Development DevCenter.

Copyright © 2009 O'Reilly Media, Inc.