Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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.
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/.
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:
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.
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:
There are several important items which you should consider before deploying P3P on your Web 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.
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:
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.
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.
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-GROUP>
<DATA ref="#dynamic.cookies">
<CATEGORIES><demographic/><online/><physical/></CATEGORIES>
</DATA>
</DATA-GROUP>
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-REFERENCES>
<POLICY-REF about="/P3P/Policy1.xml">
<COOKIE-INCLUDE>* * *</COOKIE-INCLUDE>
</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.
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.
This section gives specific instructions on what needs to be done to deploy P3P using each of the three methods described earlier:
Regardless of the method clients will use to locate the site’s policy reference file, there are several other tasks to complete:
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 1A 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.
GET /index.html HTTP/1.1 Host: catalog.example.com Accept: */* Accept-Language: de, en User-Agent: WonderBrowser/5.2 (RT-11)
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...
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.
GET /products/prod42-09.html HTTP/1.1 Host: catalog.example.com Accept: */* Accept-Language: en, ru User-Agent: WonderBrowser/5.2 (RT-11)
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.
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 1A 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. More information about server-side includes is available in the Apache Web server manual.
This guide should help you deploy P3P on your Web site. We hope it has been helpful and informative.
We would like to thank the following people for their assistance with this document:
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.
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.
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.
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.
LoadModule headers_module path/mod_headers.soIn addition, the configuration file should contain an AddModule directive to activate the header module:
AddModule mod_headers.cThis is required even if mod_headers is compiled into the server (i.e., even if it is not dynamically loaded by a LoadModule directive).
<Location / > </Location>
<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.
For more information on the Header directive, see the documentation for mod_headers.
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.
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.
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.
File index.html.meta P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml"
Done! You have now associated the page with its P3P privacy policy.
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.
This section covers Jigsaw version 2.1 and later. It covers all platforms supported by Jigsaw.
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:
Jigsaw provides other ways to add HTTP headers other than the above procedure. And, the server does not examine the contents of the header.
The configuration with JigAdmin does not cover the servlets; they must generate their own P3P headers.
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.
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.
This appendix covers common questions people have when deploying P3P.
Questions
Answers