The Platform for Privacy Preferences Project (P3P) was introduced to create a standard way for websites to express their practices when managing user-supplied data and to create a standard way for these expressed practices to be compared to a set of data management preferences set by each individual Web user. The P3P specification was created to define these standards.

The P3P specification defines the syntax and semantics that will be used to create P3P privacy policies. It defines the mechanisms that will associate those privacy policies with user-requested Web resources. It also addresses standards for user agents (browsers or other P3P applications) that will locate and interpret the privacy policies.

P3P policies consist of a series of statements created with a P3P vocabulary that provides a way for a website to encode its data-collection and data-use practices in a machine-readable, XML format.

When Web users access Web resources, P3P user agents look for references to the location of a relevant P3P policy. P3P user agents can be built into Web browsers, browser plug-ins, and proxy servers. They can be built into electronic wallets, automatic form-fillers, or other user tools. They can also be implemented as Java applets or JavaScript in user applications.

A site’s P3P policies present a machine-readable summary of how the site collects, handles, and uses personal data about its visitors. P3P-enabled Web browsers and other P3P applications will read and understand this summary information automatically, will compare it to each set of privacy preferences that have been set by each individual visitor to the site, and will inform each visitor when his/her preferences do not match the data management practices of the website s/he is visiting.

A site’s P3P policy will express the following information about its data management practices.

• Who is collecting data?
• What data is collected?
• For what purposes will data be used?
• Is there an ability to opt-in or opt-out of some data uses?
• Who are the data recipients (anyone beyond the data collector)?
• To what information does the data collector provide access?
• What is the data retention policy?
• How will disputes about the policy be resolved?
• Where is the human readable privacy policy?

P3P policies are not a substitute for human-readable privacy policies because P3P cannot represent an organization's data management practices in entirety. Rather, P3P policies should be viewed as important extensions to a website’s human-readable policy.

Although P3P provides a technical mechanism for helping inform website visitors about privacy policies before they release personal information, it does not provide a mechanism for ensuring that sites act according to their policies. P3P policies are not meant to be a policing device for how a website implements its data management practices. However, P3P policies may contain information for contacting representatives of the website if questions arise about discrepancies between stated privacy practices and the practices that the user observes.

Anything that has a Uniform Resource Indicator (URI) can have a P3P policy. In addition, cookies can implement P3P policies via separate compact policies that summarize the portion of the full P3P policy that applies only to cookies. This summary is sent in a simple, compact syntax. The compact policy is returned as an HTTP response header.

Compact policies provide hints to user agents (browsers or other P3P applications) to enable the user agent to make quick, synchronous decisions about applying policy. Compact policies are a performance optimization that is meant by the P3P specification to be optional for either user agents or servers. The Web server is meant by the P3P specification to be responsible for building a P3P compact policy to represent the cookies referenced in a full P3P policy. The data management practices specified in a P3P compact policy applies to data stored within all cookies set in the same HTTP response as the compact policy, all cookies set by scripts associated with that HTTP response, and also to data linked to the cookies.

However, even though compliance with the P3P specification would mean that compact policies would be optional and would mean that the Web server would be able to build a P3P compact policy from the full P3P policy, keep in mind that 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 a pre-existing compact policy when deciding how to handle a site's cookies.

Internet Explorer 6.0's P3P implementation is solely concerned with the issue of cookies. The implementation distinguishes between first-party cookies and third-party cookies. The term first-party cookie is used to refer to a cookie that is transmitted to your browser in the header of the base HTML page that a browser is viewing. The term third-party cookie is used to refer to cookies that are transmitted in the header of included images or frames that come from websites other than the website of the base page. In both cases, the browser can be configured to accept or reject cookies depending on whether or not a site has a P3P compact policy, and on how the policy says the site will handle personally identifiable information (PII).

Compact policies are not an alternative to full P3P policies. If a website uses compact policies, it must also supply full P3P policies. The compact policies only cover the site's cookies, and they omit important information that a user agent (browser or other P3P application) might need in order to interact with the website.

A website will need to have at least one full P3P policy to cover the whole site, and if the site generates cookies, it will need to have at least one compact P3P policy governing the data collected in the cookies. A P3P policy MUST cover all data generated or exchanged as part of a site's HTTP interactions with visitors. Currently, P3P policies do not cover resources retrieved by means other than HTTP.

A website may decide to have more than one P3P policy covering the whole site. It may want to have one P3P policy for those pages where data is shared with third parties, another P3P policy for the pages where data is only shared with third parties if the user opts-in to such sharing, and perhaps a third P3P policy for areas of the site where no data was collected from the user. In addition, it will need compact P3P policies to govern any cookies generated by the site.

A website will typically be composed of many entities. An "entity" is a single HTTP request or response. Generally, a single HTTP request will ask for a single URL that is returned as the "response entity". Therefore, a website may be composed of many URL’s and files called P3P Policy Reference Files that map full P3P policies onto URLs.

Also, keep in mind that P3P policies must declare data management practices at least at the point that data collection occurs. In the case of most HTML forms, the act of submitting the form actually collects the user's personal information. A site that decides to use multiple P3P policies would need to declare all of the information collected on the form and do so in the policy covering the URL to which the form is submitted. Another policy would be created for the URL from which the HTML form was loaded and would not have to declare the collected data.

Very careful consideration should be given to how many P3P policies to create for a site. Placing many different P3P policies on different “entities” on a single site may make rendering the site and informing the user of the relevant P3P policies difficult for a Web browser. Also, because of the chore of managing numerous P3P policy statements, it is in a site’s interest to use as few P3P policy statements as possible to cover the site. It is acceptable to publish a policy statement that overstates the data collection of the site. Thus it is allowed to have, for example, a single full P3P policy that covers all of the data collected anywhere on the site plus a single compact policy for all generated cookies. This may serve two purposes. It may decrease the time and trouble to manage P3P policy for the site and may cover data collection broadly enough to guarantee that all data collected on the site has been addressed by an adequate policy. However, these advantages need to be balanced against the risk of scaring away visitors if they think that data is being collected in parts of the site where it is not. Specificity will reduce that risk.

The four common elements of P3P are the P3P Policy Reference File (p3p.xml), the P3P Policy File (default name is policy1.xml), the human-readable natural language P3P Policy (one or more P3P Policies are located in each P3P Policy File), and the Compact Policy (for cookies). If the site generates cookies, the Policy Reference File should have a "COOKIE-INCLUDE" statement.

For a user agent (browser or other P3P application) to process the policy that applies to a given resource, it must first locate the Policy Reference File for that resource, fetch it, and parse it to locate the P3P Policy Files, fetch any required P3P Policy Files, and then parse the P3P Policy Files. The user agent can then automatically compare the stated policy against the privacy preferences that the user has set. In most cases, these preferences will be set in the user’s Web browser. If compact policies for cookies are involved, the user agent will fetch this information and compare it to the user’s preferences.

A policy referenced in a Policy Reference File can be applied only to URI’s on the DNS (Domain Name System) host that references it. URI’s may contain network port numbers. For the purposes of P3P, different ports on a single host must be considered to be separate "sites". A Policy Reference File defined for one site with one port will not cover another site with a different port even if they are on the same host. This also applies to SSL and non-SSL access. Since SSL and non-SSL access to the same site occurs through different ports, a Policy Reference File for SSL access will not cover the non-SSL access.

The location of the Policy Reference File can be indicated using one of four mechanisms listed below.

1. The Policy Reference File may be located in a predefined "well-known" location. However, it is only possible to use the well-known location for the organization that controls the entire website (i.e., the Web server). For example, someone who controls a personal page on a multi-user server cannot deploy P3P policy using the well-known location for their personal page because the location will be specific to the Web server and not to the individual page.
2. A document may indicate a Policy Reference File through an HTML link tag.
3. A document may indicate a Policy Reference File through an XHTML link tag.
4. The location can be defined through an HTTP header. This is also the only mechanism for sites to serve compact policies for cookies since the compact policies are sent as HTTP response headers. Thus, if a site is unable or unwilling to add HTTP response headers, compact policies cannot be used.

For a site owner who controls the entire website, s/he is strongly encouraged to use mechanism #1 by making the Policy Reference File available on the site at the path /w3c/p3p.xml relative to the DNS host name. Compact policies will still have to be added to the HTTP response headers.

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. In Perl and Java applications, the Policy Reference File and/or the compact policy can be added to the HTTP header programmatically.

Perl example:
$P3P_POLICY_REF = "onestart.iu.edu/my/w3c/p3p.xml";
$P3P_COMPACT_PRIVACY_POLICY = "CP=\"NON DSP COR CUR ADM OUR NOR UNI STA\"";
print "Content-type: text/html";
print "\nP3P: policyref=\"".$P3P_POLICY_REF . "\"," . $P3P_COMPACT_PRIVACY_POLICY;

Java example:
HttpServletResponse.setHeader("P3P", "policyref=\"onestart.iu.edu/my/w3c/p3p.xml\",CP=\"NON DSP COR CUR ADM OUR NOR UNI STA\"");

Inserting a link to the Policy Reference File is the choice to use when the site owner does not control the entire website, and is 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. It cannot be used to reference compact policies for cookies.

The above information is provided to give OneStart publisher’s general information about P3P policy and how it can be deployed. There is additional detailed information at many sites on the Web:

• A P3P overview can be found at URL http://www.w3.org/P3P/.
• Examples of Policy Reference Files and Policy File statements can be found under “Chapter 10. P3P-Enabled Web Site Examples” at http://p3pbook.com/examples.html.
• Detailed information regarding P3P syntax can be found at http://www.w3.org/TR/P3P/#XML-Name.
• Information about developer tools (policy generators, editors, and checkers) can be found at http://www.w3.org/P3P/implementations.
• Information about how P3P works with Microsoft Internet Explorer 6 can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpriv/html/ie6privacyfeature.asp.
• Additional P3P information can be found at http://www.p3ptoolbox.org/ and http://wdvl.internet.com/Internet/Security/P3P/.

Please contact the OneStart Project Team if you have any further questions about the information contained in this document or the Indiana University OneStart portal.