The Platform for Privacy Preferences 1.0 Deployment Guide

W3C Note 10 May 2001

This Version:
Latest Public Version:
Previous Version:
Martin Presler-Marshall, IBM (mpresler@us.ibm.com)
See Acknowledgments


This is a guide to help site operators deploy the Platform for Privacy Preferences (P3P) on their site. It provides information on the tasks required, and gives guidance on how to best complete them.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This Note is made available for Web site owners and administrators wishing to implement P3P on their Web site. It is not intended to be a normative specification. Instead, it captures the authors' thoughts on the process for deploying P3P1.0 on a Web site. This note has been produced by several members of the Platform for Privacy Preferences project (P3P), and reflects the opinions of some members of that working group.

The authors welcome comments on this document, but they do not guarantee a reply or any further action. Please send comments to www-p3p-public-comments@w3.org; public archives are available. Comments may also be directed to the editor at the address given above. This document may be updated or added to based on implementation experience, but no commitment is made by the W3C, or any of its members, regarding future updates.

This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. A list of current W3C technical reports and publications, including Working Drafts and Notes, can be found at http://www.w3.org/TR/.

Table of Contents

  1. Introduction
    1. Purpose
    2. What's Involved?
  2. Planning
    1. How Many Policies For The Site?
    2. Locating The Policy Reference File
    3. Compact Policies
    4. Cookie Policies
      1. Describing Cookies in P3P Policies
      2. Assigning P3P Policies to Specific Cookies
    5. How Will the Site Handle Policy Updates?
  3. Deployment
    1. Using HTTP Headers
    2. Pointing To A Policy Reference File With A Link Tag
  4. Conclusion
  5. Acknowledgments
  6. Appendices
    Appendix A: Instructions For Specific Servers
    Appendix A.1: Apache and derivatives
    Appendix A.2: CERN HTTPD and derivatives
    Appendix A.3: Microsoft Internet Information Server
    Appendix A.4: Jigsaw - The W3C's Web Server
    Appendix B: Frequently Asked Questions

1.0 Introduction

The Platform for Privacy Preferences (P3P) provides a way for Web sites to publish their privacy policies in a machine-readable syntax. This guide explains how to deploy P3P on a Web site, and issues that Webmasters and content owners should consider when deploying P3P.

This guide is intended for Web site administrators and owners. You can use it whether you operate your own Web server (or many of them), or are responsible for some pages on a server someone else operates. You should have some familiarity with publishing content (HTML files, images, etc.) to a Web server, but do not need to be an expert at configuring and operating Web servers. You also don't need to be a P3P expert.

This guide will discuss how to go about deploying P3P. It will discuss:

The following topics will not be covered in this guide:

1.1 Purpose

A Web site will deploy P3P in order to make its privacy practices more transparent to the site's visitors. P3P defines a way for sites to make machine-readable format. A visitor's Web browser can then download those machine-readable privacy statements, and compare the contents of those statements to the user’s preferences. This way, the user’s browser can automatically notify the user when they visit a site whose practices match the user’s preferences - or warn the user if the practices and preferences don't match.

1.2 What's Involved?

P3P is designed to be deployed on existing Web server software without any software changes or upgrades. It is also designed to be deployed without requiring any new server-side programs (such as CGI programs or servlets). Deploying P3P on a Web site requires:

  1. Creating one or more policy statements which describes the data the site collects and how it will be used. These are XML documents, typically less than 10K bytes in size. The policy statements must be published on the Web site.
  2. Creating a policy reference file, which gives the URL for the site’s policy statements, and indicates what portions of the site - and the site's cookies - are covered by which statements. This is an XML document, and is typically a few kilobytes in size. The policy reference file then must be published on the Web site.
  3. The site’s human-readable privacy policy must be published. P3P policies contain a link pointing to a human-readable version of the privacy policy, so the human-readable policy must be published at the same time that the machine-readable XML version is published.
  4. Telling browsers how to locate the policy reference file. There are several mechanisms available to do this. The policy reference file can be published in a predefined location on the site, the server can send an HTTP response header giving the location of the reference file, or the site’s HTML content can be modified to contain links to the reference file.

2.0 Planning

There are several important items which you should consider before deploying P3P on your Web site:

2.1 How Many Policies For The Site?

When deploying P3P, the Web site developer can choose how many policy statements to use to cover the site. This consideration may seem strange for someone used to text-based privacy policies, but there is an important distinction for P3P privacy statements.

A P3P privacy statement is specific about the data or types of data being collected by the site. Thus the statement will list specific elements of data which the site collects, such as “User’s name”, or else specific types of data which the site collects, such as “User’s physical contact information”.

This is important, as Web sites generally collect different amounts of data in different parts of the site. For example, a web site may collect no information about the visitor’s name and address at the site homepage, but may need detailed contact information to complete an order.

It is acceptable, in the P3P protocol, to publish a statement which overstates the data collection of the site. Thus it’s allowed to have a single policy which covers all of the data collected anywhere on the site. However, it is in the site’s interest to have highly specific P3P statements. In the example above, the site doesn’t need to claim - and probably doesn’t want to claim - that it needs the visitor’s name and address just to access the homepage when that information is really only needed to submit an order. This could well scare away visitors who are simply browsing.

It’s also in the site’s interest to use as few P3P statements as possible to cover the site. After all, it takes some amount of time to create a P3P statement, and managing 100 P3P statements on a single site is probably unrealistic even for the most heroic Webmaster or Webmistress. Thus a site needs to strike a balance between specificity and number of policies. While there is no right answer for every site, most sites can be covered by five or fewer P3P statements, and it is a rare site which needs more than 10 P3P statements.

2.2 Locating The Policy Reference File

Part of deploying P3P on a Web site is deciding how browsers will find the site’s policy reference file. The policy reference file lists the P3P policies used by the site, and tells clients which policies apply to which parts of the site. P3P defines three different ways for clients to locate this policy reference file:

  1. Place the a policy reference file in the “well-known location” (at the location /w3c/p3p.xml on the site)
  2. Add an extra HTTP header to each response from the Web site giving the location of the policy reference file
  3. Place a link to the policy reference file in each HTML page on the site

The preferred deployment choice is to place the policy reference file in the well-known location. This is the simplest for the site administrator, as no server configuration changes are required. It is also simple for clients, as P3P client software knows to look in the well-known location for a policy reference file before accessing the site. However, it’s only possible to use the well-known location for the organization which controls the entire Web site. For example, someone who controls a personal page on a multiuser server cannot deploy P3P using the well-known location for their personal page, as they cannot place files in that directory.

Giving the location of the policy reference file in an HTTP header is a second choice. In some cases, a site owner may be able to add HTTP headers to their content even if they are not able to place files in the well-known location directory. This method has advantages over editing HTML, as it will give quicker turnaround time for clients, and can be used for non-HTML content.

Inserting a link to the policy reference file is the choice to use when the site owner does not control the entire Website, and it not able to add HTTP headers to the response. It can be used on any site where it’s possible to publish HTML, but has the lowest performance of all three deployment methods. If the link tags must be inserted by manually editing the HTML, this method is also tedious and error-prone.

2.3 Compact Policies

In addition to the full XML privacy statements defined by P3P, P3P also defines a compact policy format. The compact policy summarizies the portion of the P3P policy which applies to the cookies in a response. The summary is sent in a simple, compact syntax. The use of compact policies is optional for Web sites; however, their use is strongly encouraged.

A Web site may choose to use compact P3P policies, as they are a performance optimization. The compact policy is returned as an HTTP response header, which is also where any cookies sent by the site are found. This allows the client to quickly process the compact policy and decide how to treat the received cookies.

Compact policies are not an alternative to full P3P statements. If a site uses compact policies, it must also supply full P3P statements. The compact policies only cover the site's cookies, and they omit important information which a client might need in order to interact with the site.

There is only one mechanism for sites to serve compact policies; they are sent as HTTP response headers. Thus, if a site is unable or unwilling to add HTTP response headers, compact policies cannot be used.

If you have used a tool to create your P3P policy, it should also generate the corresponding compact policy. The text of the compact policy is sent in a P3P: header, as CP="text of compact policy". See Example 1 for an example of a P3P header which includes a compact policy.

2.4 Cookie Policies

2.4.1 Describing Cookies in P3P Policies

If a site (or a portion of a site) uses cookies, then its P3P needs to disclose that cookies are used and explain how they are used. Use of cookies is disclosed by putting the P3P data element dynamic.cookies into a statement in the policy.

Since cookies can be used to collect or link to many different types of data, a P3P policy must disclose the data categories associated with the cookies when they are included in a P3P policy. All data collected by the cookie, or linked to by the cookie, should be included in the data categories associated with the cookie policy.

Example: Consider the case of a cookie which stores an key to look up a user in a company's customer information database. In that database, information about the user's name, mailing address, and e-mail address are kept. The cookie would be disclosed as follows in the P3P policy:

    <DATA ref="#dynamic.cookies">
2.4.2 Assigning P3P Policies to Specific Cookies

Typically, a site will cover all the cookies being sent by the site with a single policy; this is done by putting one <COOKIE-INCLUDE> element in the policy reference file:

<META xmlns="http://www.w3.org/2000/12/P3Pv1">
    <POLICY-REF about="/P3P/Policy1.xml">

This is the most straightforward way to cover the cookies generated by a site with a P3P policy. However, a site may wish to assign policies to individual cookies sent by a Web site. A site should consider doing this if:

The disadvantage to doing this is that you must write more policies - one for each cookie that will get its own policy. In addition, the site's policy reference file must specify the cookies by name, and this information must be kept synchronized with the actual cookie names.

If your site wishes to do this, then write seperate P3P policies for each cookie, and then list the cookies seperately (by cookie name, cookie domain, or cookie path) in the site's policy reference file. Then deploy the policy reference file and the P3P policies as normal.

2.5 How Will the Site Handle Policy Updates?

It is desirable for servers to inform user agents how long they can use the claims made in a policy reference file. By enabling clients to cache the contents of a policy reference file, it reduces the time required to process the privacy policy associated with a Web page. This also reduces load on the network. In addition, clients that don't have a valid policy reference file for a URI will need to use restrictive "safe zone" practices for their requests. If clients have policy reference files which they know are still valid, then they can make more informed decisions on how to proceed.

The lifetime of a policy reference file tells user agents how long they can rely on the claims made in the reference file. For example, if a policy reference file has a lifetime of 3 days, then a user agent need not reload that file for 3 days, and can assume that the references made in that reference file are good for 3 days. All of the policy references made in a single policy reference file will receive the same lifetime. The only way to specify different lifetimes for P3P policies is to use separate policy reference files for each policy.

When picking a lifetime for policies and policy reference files, sites need to pick a lifetime which balances two competing concerns. One concern is that the lifetime ought to be long enough to allow user agents to receive significant benefits from caching. The other concern is that the site would like to be able to change their policy without waiting for an extremely long lifetime to expire. It is expected that lifetimes in the range of 1-7 days would be a reasonable balance between these two competing desires. P3P also imposes a lower limit on policy reference file lifetime; the lifetime cannot be less than 1 day.

The lifetime of a policy reference file is given with the <EXPIRY> element in the policy reference file. When generating the policy reference file, put the lifetime you desire in this element of the policy reference file. Likewise, the lifetime of a policy is given by the <EXPIRY> element in the policy; this should be inserted in the policy when it's created.

Note that when a Web site changes its P3P policy, the old policy applies to data collected when it was in effect. It is the responsibility of the site to keep records of past P3P policies and policy reference files along with the dates when they were in effect, and to apply these policies appropriately. If a site wishes to apply a new P3P policy to previously collected data, it must provide appropriate notice and opportunities for users to accept the new policy that are consistent with applicable laws, industry guidelines, or other privacy-related agreements the site has made.

3.0 Deployment

This section gives specific instructions on what needs to be done to deploy P3P using each of the three methods described earlier:

  1. Placing the policy reference file in the well-known location. This is done by simply publishing the policy reference file on the server.
  2. Using HTTP headers to allow clients to locate the policy reference file.
  3. Placing <link> tags within HTML to give the location of the policy reference file.

Regardless of the method clients will use to locate the site’s policy reference file, there are several other tasks to complete:

  1. Place the policy reference file in the location selected. This will either be in the well-known location, if using that deployment method, or the location given by the P3P header, or the location given in the HTML <link> tag which points to the policy reference file.
  2. Place the P3P policy files in the correct directories so that they are accessible by clients at the URLs listed in the policy reference file. The "correct directories" are the locations given in the policy reference file.
  3. Place the site’s human-readable privacy policy in the correct location. The correct location is the location specified in the P3P policy files).
  4. If compact policies are being used, add the HTTP response header containing the compact policy. See the Using HTTP Headers section for additional information.

3.1 Using HTTP Headers

A Web site may need to add HTTP headers in its responses to either give the location of the policy reference file, or to send compact P3P policies. The name of the header to be sent in the response is defined by P3P; it is P3P.The HTTP header follows the format of several other HTTP headers in being one or more key-value pairs. The value is always a quoted string. The following keys are used in P3P:

If the site needs to use both keys in a single response, then they are seperated by a comma.

Example 1

A client is requesting the homepage for catalog.example.com, and the site returns a P3P header which gives the location of the site’s policy reference file.

  1. Client makes a GET request.
    GET /index.html HTTP/1.1 
    Host: catalog.example.com 
    Accept: */* 
    Accept-Language: de, en 
    User-Agent: WonderBrowser/5.2 (RT-11)
  2. Server returns content and the P3P header pointing to the policy of the page.
    HTTP/1.1 200 OK 
    P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml" 
    Content-Type: text/html 
    Content-Length: 7413 
    Server: CC-Galaxy/1.3.18
    ...content follows...
Example 2

A client is requesting a page on the catalog.example.com site, and the site is returning a compacy P3P policy and the location of the site’s policy reference file in a single P3P header.

  1. Client makes a GET request:
    GET /products/prod42-09.html HTTP/1.1
    Host: catalog.example.com 
    Accept: */* Accept-Language: en, ru 
    User-Agent: WonderBrowser/5.2 (RT-11)
  2. Server returns content and the P3P header.
    HTTP/1.1 200 OK
    P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml", 
    Content-Type: text/html
    Content-Length: 8104
    Server: CC-Galaxy/1.3.18
    ...content follows...

The appendix contains information on how to add HTTP response-headers for some popular Web servers.

3.2 Pointing To A Policy Reference File With A Link Tag

Sites can have their HTML content link to the policy reference file with an HTML <link> tag. The <link> tag looks like the following:

<link rel="P3Pv1" href="some-URL"> 

The actual URL where the site’s policy reference file is located is given in place of some-URL.

Example 1

A client is requesting the homepage for catalog.example.com; the site returns the following in the HTML page which makes up their homepage:

<link rel="P3Pv1"

Note that editing every HTML page on a site can be very tedious and error-prone for sites which contain more than just a few HTML pages. One way to insert the link tags more easily is to use server-side includes. This is a feature supported by many Web servers, which allows the Web server to insert text, or the contents of another file, within a page when it is being served by the server. More information about server-side includes is available in the Apache Web server manual.

4.0 Conclusion

This guide should help you deploy P3P on your Web site. We hope it has been helpful and informative.

5.0 Acknowledgments

We would like to thank the following people for their assistance with this document:

Appendix A: Instructions For Specific Servers

When deploying P3P, your site may need to send additional HTTP response headers. While HTTP headers all have a standard format, and the headers used by P3P are defined as part of the P3P specification, the technique for adding HTTP headers to a server’s response varies from server to server.

This section describes how to add HTTP headers to the response for some popular Web servers. The choice of Web servers here is not meant to imply that P3P can only be used with these servers; we expect that P3P should be able to be deployed with any Web server.

A.1 Apache and derivatives

This section covers the Apache Web Server 1.2.x and 1.3.x, as well as servers derived from those versions of Apache. This mechanism will work on all platforms supported by Apache. It will not work on earlier releases (1.1.x, for example), as the headers module was not introduced until Apache 1.2.

A.1.1 Basics

The Apache Web server includes a module called mod_headers which is used to add extra headers to HTTP responses. The configuration directive which is used to add these headers makes use of the normal Apache scoping rules, so headers can be added to an individual file, a set of files matching a regular expression, a set of directories matching a regular expression, or an entire Web site.

The headers module is used to add any arbitrary headers to an HTTP response. Thus the Apache Web server does not need to "understand" the P3P headers.

A.1.2 Possible Difficulties

The headers module (mod_headers) is an "Extension" module. This means that the source distribution from Apache does not have this module included by default. If you have compiled your own server, you may need to rebuild it to include mod_headers. If you are using a binary distribution of Apache, then you should check that distribution's documentation to see if mod_headers is built in.

If you need to rebuild Apache to include the headers module, read the "compiling Apache" instructions from the Apache Web site, and make sure that you update the configuration before compiling to include mod_headers.

A.1.3 How to do it
  1. Publish the site's policy reference file and privacy policies. Before you put the P3P headers on the content, you should first publish the P3P privacy policies. Copy the policy files to the appropriate part of your server's content tree.
  2. Verify that the headers module is being loaded and enabled. If mod_headers is compiled as a dynamic shared object (certain binary distributions do this on UNIX platforms, for example), then httpd.conf should contain a LoadModule directive:
    LoadModule headers_module path/mod_headers.so
    In addition, the configuration file should contain an AddModule directive to activate the header module:
    AddModule mod_headers.c
    This is required even if mod_headers is compiled into the server (i.e., even if it is not dynamically loaded by a LoadModule directive).
  3. Decide how the headers will be arranged on the site. If the same compact policy is used on the entire site, then it is usually possible to send the same P3P header for the entire site. On the other hand, if different parts of the site require different compact policies, then seperate P3P headers will be required. For this example, we'll assume that we're using one P3P header on the entire site.
  4. Create the appropriate scope sections in the server configuration file (httpd.conf). This is explained in "How Directory, Location, and Files sections work". For our example, it will look like this:
    <Location / >
  5. Add the P3P header. To do this, place a Header directive within the section(s) created in the previous step. For our example, the result will look as follows:
    <Location / >
    Header append P3P "policyref=\"http://catalog.example.com/P3P/PolicyReferences.xml\""

Done! You have now associated the page with its P3P privacy policy.

For more information on the Header directive, see the documentation for mod_headers.

A.2 CERN HTTPD and derivatives

This section covers CERN httpd version 3.0 and derivatives. "Derivatives" include Lotus Domino Go Webserver (LDGW) version 4.6, and the IBM Internet Connection Server (IBM ICS) version 4.2, and possibly other servers. Note that the metafile mechanism described in this chapter does not function properly in IBM ICS version 1.0.

A.2.1 Basics

CERN httpd has a concept called "metafiles" for associating meta-information (additional HTTP headers) with Web content. Each content file - HTML, image, sound file, or whatever - may have one metafile associated with it. CERN httpd has no support for a single metafile covering multiple documents, an entire directory, or a directory tree. Note that metafiles are optional, since Web sites never need to add extra headers to their content. If a Web site does not contain any metafiles, then the content served by that site will just have the standard headers created by the Web server. Metafiles may contain any HTTP headers. The server does not examine the contents of a metafile to perform any kind of validation. Thus the Web server does not need to "understand" the P3P headers.

A.2.2 Possible Difficulties

Since each metafile only covers a single document, this can be a very tedious way to link to the site's policy reference file. If you're using a CERN derivative which supports server-side includes (SSI), then you may wish to consider that method for publishing your privacy policy.

Metafiles cannot be used for CGI programs; they must generate their own P3P headers.

A.2.3 How to do it
  1. Publish the site's policy reference file and privacy policies. Before you put the P3P headers on the content, you should first publish the P3P privacy policies. Copy the policy files to the appropriate part of your server's content tree.
  2. Create a metafile. A metafile simply contains header information that will be copied verbatim into the response, in the header section (before the actual document content). This means that you should just enter the headers exactly as they will be seen by the browser, as in the following example:
    File index.html.meta 
    P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml" 
  3. Configure the server to use metafiles. CERN httpd and derivatives use a master configuration file called httpd.conf. On UNIX platforms, this is located in the /etc directory. Windows versions typically place this file in other directories, such as the Windows directory (\WINNT on the boot drive). CERN httpd will look for and use metafiles by default, but IBM ICS and LDGW have them disabled by default.To instruct those servers to make use of metafiles, place the following directive anywhere in the server configuration file: UseMetafiles ON
  4. Put the metafile on the server. Metafiles are associated with content by location and filename. The metafiles for a content directory are located in a special subdirectory named .web. Metafiles have the name of their parent (content) file, with the suffix .meta added. So, consider the case of serving /index.html from the filesystem directory /home/httpd/content/index.html. To associate a metafile with that file, create the directory /home/httpd/content/.web. Then place the metafile in that directory, using the name index.html.meta. As stated above, a seperate metafile is required for each content file that you want to put the P3P headers on.

Done! You have now associated the page with its P3P privacy policy.

A.3 Microsoft Internet Information Server

The P3P header can be added to an HTTP response from IIS using Active Server Pages (ASP) or through the computer management console on Microsoft Windows 2000 server. Additional details and step-by-step instructions will be forthcoming in a future version on this guide.

A.4 Jigsaw - The W3C's Web Server

This section covers Jigsaw version 2.1 and later. It covers all platforms supported by Jigsaw.

A.4.1 Basics

Jigsaw has an administration/configuration tool with a GUI, called JigAdmin, which allows the administrator to add any HTTP headers to any web resources (files, directories, and CGI scripts).

With JigAdmin, you can put an HTTP header to a resource in the following procedure:

  1. Double-click the mouse on the target resource in the "Docs space" pane, then the resource editor will be launched.
  2. Select an appropriate frame in the Frames pane. "Appropriate frame" will be HTTPFrame for normal files and directories, and CGIFrame for CGI scripts.
  3. Select Add frame to selected resourece/frame menu item to launch the Add Frame dialog.
  4. Select org.w3c.jigsaw.filters.HeaderFilter in the Class name field in the Add Frame dialog and push OK button.
  5. Now you see the HeaderFilter item in the Frames pane in the resource editor.
  6. Select HeaderFilter item, then you see the header-name and header-value fields in the Attribute pane.
  7. Type the header name and value in the fields. For example, if you put P3P in the header-name field and policyref="http://catalog.example/P3P/ref.xml" in the header-value field, the HTTP header P3P: policyref="http://catalog.example/P3P/ref.xml" will be added to the response of the target resource.
  8. When you want to put more than one HTTP header, you have to repeat steps 3-7.

Jigsaw provides other ways to add HTTP headers other than the above procedure. And, the server does not examine the contents of the header.

A.4.2 Possible Difficulties

The configuration with JigAdmin does not cover the servlets; they must generate their own P3P headers.

A.4.3 How to do it
  1. Publish the P3P Privacy Policies and Policy Reference Files.

    Before you put the P3P headers on the content, you should first publish the P3P privacy policies and Policy reference files. Copy the policy files to the appropriate part of your server's content tree.

  2. Configure using JigAdmin

    Configure using JigAdmin to add the required HTTP headers to the target resource (files, directories, and CGI scripts).

Done! You have now associated the page with its P3P privacy policy.

For more information on the Header directive, see the documentation for Jigsaw.

Appendix B: Frequently Asked Questions

This appendix covers common questions people have when deploying P3P.


  1. My policy editor says I have to give the data categories and purposes for the cookies my Web site uses. How do I do this?


  1. See section 2.4.1, Describing Cookies in P3P Policies.