The Platform for Privacy Preferences Project (P3P) enables Web sites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents. P3P user agents will allow users to be informed of site practices (in both machine- and human-readable formats) and to automate decision-making based on these practices when appropriate. Thus users need not read the privacy policies at every site they visit.
Although P3P provides a technical mechanism for ensuring that users can be informed about privacy policies before they release personal information, it does not provide a technical mechanism for making sure sites act according to their policies. Products implementing this specification MAY provide some assistance in that regard, but that is up to specific implementations and outside the scope of this specification. However, P3P is complementary to laws and self-regulatory programs that can provide enforcement mechanisms. In addition, P3P does not include mechanisms for transferring data or for securing personal data in transit or storage. P3P may be built into tools designed to facilitate data transfer. These tools should include appropriate security safeguards.
The P3P1.0 specification defines the syntax and semantics of P3P privacy policies, and the mechanisms for associating policies with Web resources. P3P policies consist of statements made using the P3P vocabulary for expressing privacy practices. P3P policies also reference elements of the P3P base data schema?a standard set of data elements that all P3P user agents should be aware of. The P3P specification includes a mechanism for defining new data elements and data sets, and a simple mechanism that allows for extensions to the P3P vocabulary.
P3P version 1.0 is a protocol designed to inform Web users of the data-collection practices of Web sites. It provides a way for a Web site to encode its data-collection and data-use practices in a machine-readable XML format known as a P3P policy. The P3P specification defines:
A standard schema for data a Web site may wish to collect, known as the "P3P base data schema"
A standard set of uses, recipients, data categories, and other privacy disclosures
A means of associating privacy policies with Web pages or sites, and cookies
A mechanism for transporting P3P policies over HTTP
The goal of P3P version 1.0 is twofold. First, it allows Web sites to present their data-collection practices in a standardized, machine-readable, easy-to-locate manner. Second, it enables Web users to understand what data will be collected by sites they visit, how that data will be used, and what data/uses they may "opt-out" of or "opt-in" to.
As an introduction to P3P, let us consider one common scenario that makes use of P3P. Claudia has decided to check out a store called CatalogExample, located at http://www.catalog.example.com/. Let us assume that CatalogExample has placed P3P policies on all their pages, and that Claudia is using a Web browser with P3P built in.
The checkout page of CatalogExample requires some additional information: Claudia's name, address, credit card number, and telephone number. Another P3P policy is available that describes the data that is collected here and states that her data will be used only for completing the current transaction, her order.
Claudia's browser examines this P3P policy. Imagine that Claudia has told her browser that she wants to be warned whenever a site asks for her telephone number. In this case, the browser will pop up a message saying that this Web site is asking for her telephone number, and explaining the contents of the P3P statement. Claudia can then decide if this is acceptable to her. If it is acceptable, she can continue with her order; otherwise she can cancel the transaction.
Alternatively, Claudia could have told her browser that she wanted to be warned only if a site is asking for her telephone number and was going to give it to third parties and/or use it for uses other than completing the current transaction. In that case, she would have received no prompts from her browser at all, and she could proceed with completing her order.
Note that this scenario describes one hypothetical implementation of P3P. Other types of user interfaces are also possible.
P3P policies represent the practices of the site. Intermediaries such as telecommunication providers, Internet service providers, proxies, and others may be privy to the exchange of data between a site and a user, but their practices may not be governed by the site's policies.
Web sites can implement P3P1.0 on their servers by translating their human-readable privacy policies into P3P syntax and then publishing the resulting files along with a policy reference file that indicates the parts of the site to which the policy applies. Automated tools can assist site operators in performing this translation. P3P1.0 can be implemented on existing HTTP/1.1-compliant Web servers without requiring additional or upgraded software. Servers may publish their policy reference files at a well-known location, or they may reference their P3P policy reference files in HTML content using a link tag. Alternatively, compatible servers may be configured to insert a P3P extension header into all HTTP responses that indicates the location of a site's P3P policy reference file.
Web sites have some flexibility in how they use P3P: they can opt for one P3P policy for their entire site or they can designate different policies for different parts of their sites. A P3P policy MUST cover all data generated or exchanged as part of a site's HTTP interactions with visitors. In addition, some sites may wish to write policies that cover all data an entity collects, regardless of how the data is collected.
Significant sections were removed from earlier drafts of the P3P1.0 specification in order to facilitate rapid implementation and deployment of a P3P first step. A future version of the P3P specification might incorporate those features after P3P1.0 is deployed. Such specification would likely include improvements based on feedback from implementation and deployment experience as well as four major components that were part of the original P3P vision but not included in P3P1.0:
a mechanism to allow sites to offer a choice of P3P policies to visitors
a mechanism to allow visitors (through their user agents) to explicitly agree to a P3P policy
mechanisms to allow for non-repudiation of agreements between visitors and Web sites
a mechanism to allow user agents to transfer user data to services
This document, along with its normative references, includes all the specification necessary for the implementation of interoperable P3P applications.
The [ABNF] notation used in this specification is specified in RFC2234 and summarized in Appendix 6. However, note that in the case of XML syntax, such ABNF syntax is only a grammar representative of the XML syntax (for example, all the syntactic flexibilities of XML are also implicitly included; e.g., whitespace rules, quoting using either single quote (') or double quote ("), character escaping, comments, case sensitivity, order of attributes). All the XML syntax defined in this specification MUST conform to the XML Schema for P3P (see Appendix 4), which is the normative definition. For non-XML syntax (like, for example, in HTTP headers), the ABNF notation is the normative one.
In the sections that follow a number of XML elements are introduced. Each element is given in angle brackets ("<element>"), followed by a list of valid attributes. All listed attributes are optional, except when tagged as mandatory. Note that many XML elements are shown in the BNF with separate beginning and ending tags to allow optional elements inside them. If no elements are included, then, following standard XML rules, a self-closing element may be used instead.
The following key words are used throughout the document and have to be read as interoperability requirements. This specification uses words as defined in RFC2119 [KEY] for defining the significance of each particular requirement. These words are:
MUST or MUST NOT
This word or the adjective "required" means that the item is an absolute requirement of the specification.
SHOULD or SHOULD NOT
This word or the adjective "recommended" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
This word or the adjective "optional" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.
Strings consist of a sequence of zero or more characters, where a character is defined as in the XML Recommendation [XML]. A single character in P3P thus corresponds to a single Unicode abstract character with a single corresponding Unicode scalar value (see [UNICODE]).
An individual data entity, such as last name or telephone number. For interoperability, P3P1.0 specifies a base set of data elements.
A significant attribute of a data element or data set that may be used by a trust engine to determine what type of element is under discussion, such as physical contact information. P3P1.0 specifies a set of data categories.
A known grouping of data elements, such as "user.home-info.postal". The P3P1.0 base data schema specifies a number of data sets.
A collection of data elements and sets defined using the P3P1.0 DATASCHEMA element. P3P1.0 defines a standard data schema called the P3P base data schema.
A hierarchical description of a set of data elements. A data set can be described according to its data structure. P3P1.0 defines a set of basic data structures that are used to describe the data sets in the P3P base data schema.
A practice that is very similar to another in that the purpose and recipients are the same or more constrained than the original, and the other disclosures are not substantially different. For example, two sites with otherwise similar practices that follow different?but similar?sets of industry guidelines.
Data that reasonably can be used by the data collector to identify an individual.
A collection of one or more privacy statements together with information asserting the identity, URI, assurances, and dispute resolution procedures of the service covered by the policy.
The set of disclosures regarding data usage, including purpose, recipients, and other disclosures.
A rule, or set of rules, that determines what action(s) a user agent will take. A preference might be expressed as a formally defined computable statement (e.g., the [APPEL] preference exchange language).
The reason(s) for data collection and use.
A mechanism for storing user information under the control of the user agent.
Part of a Web site where the service provider performs only minimal data collection, and any data that is collected is used only in ways that would not reasonably identify an individual.
A program that issues policies and (possibly) data requests. By this definition, a service may be a server (site), a local application, a piece of locally active code, such as an ActiveX control or Java applet, or even another user agent.
Service Provider (Data Controller, Legal Entity)
The person or legal entity which offers information, products or services from a Web site, collects information, and is responsible for the representations made in a practice statement.
A P3P statement is a set of privacy practice disclosures relevant to a collection of data elements.
A Uniform Resource Identifier used to locate Web resources. For definitive information on URI syntax and semantics, see [URI]. URIs that appear within XML or HTML have to be treated as specified in [CHARMODEL], section Character Encoding in URI References. This does not apply to URIs appearing in HTTP header fields; the URIs there should always be fully escaped.
An individual (or group of individuals acting as a single entity) on whose behalf a service is accessed and for which personal data exists.
A program whose purpose is to mediate interactions with services on behalf of the user under the user's preferences. A user may have more than one user agent, and agents need not reside on the user's desktop, but any agent must be controlled by and act on behalf of only the user. The trust relationship between a user and his or her agent may be governed by constraints outside of P3P. For instance, an agent may be trusted as a part of the user's operating system or Web client, or as a part of the terms and conditions of an ISP or privacy proxy.