W3C

The Platform for Privacy Preferences 1.0 Deployment Guide

W3C Note 11 February 2002

This Version:
http://www.w3.org/TR/2002/NOTE-p3pdeployment-20020211
Latest Version:
http://www.w3.org/TR/p3pdeployment
Previous Version:
http://www.w3.org/TR/2001/NOTE-p3pdeployment-20011130
Author/Editor:
Martin Presler-Marshall, IBM (mpresler@us.ibm.com)
Contributors:
See Acknowledgments

Copyright Đ2001, 2002 W3CŪ (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Abstract

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. What Does a Policy Cover?
      1. How Policy Reference Files Work
      2. Pages vs. "Entities"
      3. Use of Forms
    2. How Many Policies For The Site?
    3. Locating The Policy Reference File
    4. Compact Policies
      1. Description and Advantages of Using Compact Policies
      2. Restrictions of Compact Policies
    5. Cookie Policies
      1. Describing Cookies in P3P Policies
      2. Assigning P3P Policies to Specific Cookies
    6. 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: iPlanet Web Server
    Appendix A.5: Jigsaw - The W3C's Web Server
    Appendix B: Frequently Asked Questions
    Appendix C: Change History

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 publish statements of their privacy practices in a 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.

This guide will not cover how to create the P3P policy statements. Several P3P policy editors and generators are available; look at the P3P implementations page for more information.

2.0 Planning

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

2.1 What Does a Policy Cover?

A P3P policy file contains a description of data collection, use, and sharing practices. It does not, however, declare what that policy applices to. P3P uses a seperate file, called a policy reference file, to list the P3P policies in use at a site (or portion of a site), and what portions of the site and what cookies are covered by each policy.

2.1.1 How Policy Reference Files Work

P3P policy reference files list the P3P policies which a site is currently using, and map out what parts of the site each one applies to. This mapping is done by giving a list of one or more URL patterns that each policy applies to. Each pattern is a local URL, and is allowed to contain wildcards. Thus a policy reference file might say that policy policy-1 applies to just /index.html, or to /content*, which means "all URLs on this host that begin with /content". Policy reference files use the <INCLUDE> element to indicate what URLs are covered by a specific policy.

Policy reference files can also list URLs which explicitly are not covered by a given policy; this is done with the <EXCLUDE> element. For example, it's possible to say that policy-1 applies to the entire site except for /cgi-bin; to do this, the following policy reference file might be used:

Example 1:

<META xmlns="http://www.w3.org/2000/12/P3Pv1">
   <POLICY-REFERENCES>
      <EXPIRY max-age="172800">
      <POLICY-REF about="/P3P/Policy1.xml">
      <INCLUDE>/*</INCLUDE>
      <EXCLUDE>/cgi-bin*</EXCLUDE>
      </POLICY-REF>
   </POLICY-REFERENCES>
</META>

Note that a single policy reference file need not cover an entire host. In some cases, a single hostname contains multiple Web sites controlled by different individuals or organizations. In that case, each portion of the site would likely have its own policy reference file. However, if a single organization owns the entire host, then it is a good idea to use a single policy reference file to cover the entire site whenever possible. Refer to section 2.3, Locating the Policy Reference File, for information on how clients find a site's policy reference file.

2.1.2 Pages vs. "Entities"

P3P policy reference files map policies onto URLs. The P3P specification also uses the term "entity" for describing what a policy applies to. This term comes from the HTTP 1.1 specification; an "entity" is a single HTTP request or response - the HTTP headers plus the content body. Generally, a single HTTP request will ask for a single URL, which is returned as the "response entity".

Web site visitors, however, are looking at pages, not "HTTP response entities". A page will typically be composed of many entities. Some examples follow:

As a practical note, placing many different P3P policies on different entities on a single page may make rendering the page and informing the user of the relevant policies difficult for a Web browser. Services should attempt to craft their policy reference files such that a single policy reference file covers any given page; this will speed up the user's browsing experience.

2.1.3 Use of Forms

When developing a site's policy reference file, one important principle to keep in mind is that P3P policies declare practices at the point that data collection occurs. This is particularly important in the case of HTML forms. Presenting a site visitor with a form asking them for their name and address does not collect that personal information from the visitor; it is the act of submitting the form which collects the personal information.

Thus, a site which wishes to use multiple policies could place one policy on the URL where the form is loaded from, and a seperate one on the URL where the form is submitted to. The policy for the URL that the form is submitted to must declare all of the information collected on the form; the policy for the URL that the form was loaded from need not declare that information. Practically, this makes it much easier to declare the appropriate policy: a site may have forms scattered in many places, but the server-side applications tend to be deployed under just a few URL trees.

2.2 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 very rare site which needs more than 10 P3P statements.

2.3 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.4 Compact Policies

2.4.1 Description and Advantages of Using 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 compact policy is returned as an HTTP response header. This means that the client will have the compact policy available to it when it considers any cookies sent by the site.

The use of compact policies is optional for Web sites; however, their use is strongly encouraged. Due to their location and simple syntax, compact policies can be quickly processed by clients, allowing them to make decisions on processing the cookies in that response. In addition, the Microsoft Internet Explorer 6.0 client does not implement the COOKIE-INCLUDE mechanism described in the most recent version of the P3P specification. As a result, Internet Explorer 6.0 will only consider the compact policy when deciding how to handle a site's cookies.

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

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 5 for an example of a P3P header which includes a compact policy.

2.4.2 Restrictions of Compact Policies

While compact policies are encouraged for sites which can use them, there are some significant restrictions on the use of compact policies which a site operator should be aware of before deciding to use them:

  1. 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.
  2. The HTML element META with the http-equiv attribute is sometimes used to simulate the effect of adding HTTP headers to HTML content. Some servers will scan HTML content, looking for these tags, and generate the corresponding HTTP response headers, and this will work well with P3P client software.
    However, for servers which are not scanning the HTML in this manner, the http-equiv mechanism should not be used to send a P3P compact policy header, as this information may not be available to a client until after it has processed the cookies in the response.
  3. A single compact policy covers all of the cookies in the response it comes with, and applies to those cookies until the cookies expire. This means that the site is bound to uphold the policy on those cookies for their entire lifetime; this can be a difficult burden for a site if it uses cookies with a long lifetime.
    If a site using compact policies needs to change the policy associated with a cookie, then the site needs to reset the cookie (with a new Set-Cookie header from the Web site), and send a new compact policy with that Set-Cookie header. This will cause clients to evaluate the new policy and make a decision on how to handle the cookie under its new policy.
  4. Compact policies have less granularity than do full P3P policies. If the full P3P policy contains multiple statements, then all of the data categories, uses, and recipients across all of the statements are merged when the compact policy is built. This loss of granularity can make a site's data use practices appear more privacy-invasive than they actually are. When writing the site's P3P policy, you should carefully examine the contents of the compact policy, and make sure that your are comfortable with the way it represents your site's practices before using the compact policy.

2.5 Cookie Policies

2.5.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 2:

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-GROUP>
    <DATA ref="#dynamic.cookies">
        <CATEGORIES><demographic/><online/><physical/></CATEGORIES>
    </DATA>
</DATA-GROUP>
2.5.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:

Example 3:

<META xmlns="http://www.w3.org/2000/12/P3Pv1">
<POLICY-REFERENCES>
    <POLICY-REF about="/P3P/Policy1.xml">
        <COOKIE-INCLUDE
            name="*"
            value="*"
            domain="*"
            path="*"/>
    </POLICY-REF>
</POLICY-REFERENCES>
</META>

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

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 5

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", 
    CP="NON DSP COR CURa ADMa DEVa CUSa TAIa OUR SAMa IND"
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:

<html>
<head>
<link rel="P3Pv1"
    href="http://catalog.example.com/P3P/PolicyReferences.xml">
...

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. Information about server-side includes is available from a number of sources, including the documentation for mod_include 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. The IBM HTTP Server distribution, for example, has mod_headers 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
  3. The configuration file also needs an AddModule directive to activate the header module: 
    AddModule mod_headers.c
    The AddModule directive is required even if mod_headers is compiled into the server (i.e., even if it is not dynamically loaded by a LoadModule directive).
  4. 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.
  5. 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 / >
</Location>
  6. 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\""
</Location>

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

A.1.4 Other Notes

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

If you need to apply different compact policies to different parts of the site, Apache supports this. Create a seperate set of Header directives for each compact policy. Then use the information at http://httpd.apache.org/docs/sections.html ("How Directory, Location, and Files Sections Work") to apply those directives to the appropriate parts of the site.

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

This section covers Microsoft Internet Information Server (IIS) on a Microsoft Windows 2000 Server platform.

A.3.1 Basics

The P3P header can be added through the IIS snap-in from the Computer Management console (MMC) on a Microsoft Windows 2000 server. This section assumes that you have already published your site's policy reference file and P3P policy files. It also assumes that you have decided how you will arrange the P3P headers 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 separate P3P headers are required. For more information on compact policies, see Compact Policies in this document.

For this example, one P3P header is used for the entire site.

A.3.2 Possible Difficulties

None known.

A.3.3 How to do it
  1. Start the IIS snap-in. To access the IIS snap-in from the Start menu, click Programs, Administrative Tools, and then Internet Information Services. The Internet Information Services snap-in appears.
  2. Navigate to the Web site to which you want to apply the privacy policy.
  3. Select the Web site and right-click to open the context menu. Select the Properties menu item. The IIS snap-in appears.
  4. Select the HTTP Headers property page.
  5. Select Add. The Add/Edit Custom HTTP Header dialog box appears.
  6. In the Custom Header Name text box, type in P3P. In the Custom Header Value dialog box, type in the contents of the P3P header.

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

A.4 iPlanet Web Server

This section covers the iPlanet Web Server (iWS) version 4.1 and 6.0.

A.4.1 Basics

iWS does not provide a way to configure the Web server to send custom response headers. Instead, this must be done by building and installing a server plugin which will add the response headers.

iPlanet has provided a document in their knoledge base which documents how to do this. It is available at http://knowledgebase.iplanet.com/ikb/kb/articles/7747.html, and it documents the steps required. See the example under "Method 2" in the article for specific instructions.

A.4.2 Possible Difficulties

This requires compiling and installing a NSAPI plugin. In order to do this, you will need access to a C compiler for the platform your server runs on.

A.4.3 How to do it

See the article above for specific instructions

A.5 Jigsaw - The W3C's Web Server

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

A.5.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.5.2 Possible Difficulties

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

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

Questions

  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?

Answers

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

Appendix C: Change History

The initial version of this guide was published May 10, 2001.

Changes from the November 30, 2001 version:

Changes from the July 24, 2001 version:

Changes from the May 10, 2001 version: