P3P policies are encoded in XML. They may also be represented using the RDF data model ([RDF]); however, an RDF representation is not included in this specification. (Such a representation is planned to be made available as a W3C Note prior to submitting P3P as a Proposed Recommendation, together with a suitable RDF encoding of the policy reference file).
At CatalogExample, we care about your privacy. When you come to our site to look for an item, we will only use this information to improve our site and will not store it with information we could use to identify you.
CatalogExample, Inc. is a licensee of the PrivacySealExample Program. The PrivacySealExample Program ensures your privacy by holding Web site licensees to high privacy standards and confirming with independent auditors that these information practices are being followed.
Questions regarding this statement should be directed to:
CatalogExample 4000 Lincoln Ave. Birmingham, MI 48009 USA email: firstname.lastname@example.org Telephone 248-EXAMPLE (248-392-6753)
What We Collect and Why:
When you browse through our site we collect:
We purge every two weeks the browsing information that we collect.
Here is Example 3.1 in a more formal description, using the P3P element and attribute names [with the section of the spec that was used cited in brackets for easy reference]:
At CatalogExample, we care about your privacy. We will never share your credit card number or any other financial information with any third party. With your permission only, we will share information with carefully selected marketing partners that meet either the preferences that you've specifically provided or your past purchasing habits. The more we know about your likes and dislikes, the better we can tailor offerings to your needs.
CatalogExample is a licensee of the PrivacySealExample Program. The PrivacySealExample Program ensures your privacy by holding Web site licensees to high privacy standards and confirming with independent auditors that these information practices are being followed.
Questions regarding this statement should be directed to:
CatalogExample 4000 Lincoln Ave. Birmingham, MI 48009 USA email: email@example.com Telephone +1 248-EXAMPLE (+1 248-392-6753)
When you browse through our site we collect:
If you choose to purchase an item we will ask you for more information including:
Also on this page we will give you the option to choose if you would like to receive email, telephone calls or written service from CatalogExample or from our carefully selected marketing partners who maintain similar privacy practices. If you would like to receive these solicitations simply check the appropriate boxes. You can choose to stop participating at any time simply by changing your preferences.
Changing and Updating personal information
Consumers can change all of their personal account information by going to the preferences section of CatalogExample at http://catalog.example.com/preferences.html. You can change your address, telephone number, email address, password as well as your privacy settings.
We will keep the information about you and your purchases for as long as you remain our customer. If you do not place an order from us for one year we will remove your information from our databases.
The following pieces of [XML] capture the information as expressed in the above two examples. P3P policies are statements that are properly expressed as well-formed XML. The policy syntax will be explained in more detail in the sections that follow.
XML Encoding of Example 3.1:
XML Encoding of Example 3.2:
This section defines the syntax and semantics of P3P policies.
All policies MUST be encoded using [UTF-8]. P3P servers MUST encode their policies using this encoding. P3P user agents MUST be able to parse this syntax. User agents SHOULD NOT act upon or render policy data containing a syntax error. Furthermore, user agents MUST NOT act upon or render policy data containing a syntax error, unless the user has been informed in a meaningful way that there may be an error, or unless the user's preferences specify that errors may be ignored.
Policies have to be placed inside a POLICIES element.
The POLICIES element is used to gather several P3P policies together in a single file. This is provided as a performance optimization: many policies can be collected with a single request, improving network traffic and caching. Even, the POLICIES element can be placed in the well-known location, inside the META element: in this case, user agents need only fetch a single file, containing both the policy reference file and the policies.
The POLICIES element can optionally contain an EXPIRY element, indicating the expiration of the included policies, and an embedded data schema using the DATASCHEMA element (see Section 5).
Since policies are included in a POLICIES element, they MUST have a name attribute which is unique in the file. This allows policy references (in POLICY-REF elements) to link to that policy.
The file in http://www.example.com/Shop/policies.xml could have the following content:
The files in http://www.example.com/Shop/CDs/* could then be associated to the second policy ("policy2") using the following policy reference file in http://www.example.com/w3c/p3p.xml:
<META xmlns="http://www.w3.org/2001/09/P3Pv1"> <POLICY-REFERENCES> <POLICY-REF about="/Shop/policies#policy2"> <INCLUDE>/Shops/CDs/*</INCLUDE> </POLICY-REF> </POLICY-REFERENCES> </META>
The POLICY element contains a complete P3P policy. Each P3P policy MUST contain exactly one POLICY element. The policy element MUST contain an ENTITY element that identifies the legal entity making the representation of the privacy practices contained in the policy. In addition, the policy element MUST contain an ACCESS element, and optionally STATEMENT elements, a DISPUTES-GROUP element, a P3P data schema, and one or more extensions.
Includes one or more statements. Each statement includes a set of disclosures as applied to a set of data elements.
name (mandatory attribute)
name of the policy, used as a fragment identifier to be able to reference the policy.
discuri (mandatory attribute)
URI of the natural language privacy statement
URI of instructions that users can follow to request or decline to have their data used for a particular purpose (opt-in or opt-out). This attribute is mandatory for policies that contain a purpose with required attribute set to opt-in or opt-out.
Here, URI is defined as per RFC 2396 [URI].
The TEST element is used for testing purposes: the presence of TEST in a policy indicates that the policy is just an example, and as such, it MUST be ignored, and not be considered as a valid P3P policy.
The ENTITY element gives a precise description of the legal entity making the representation of the privacy practices.
Identifies the legal entity making the representation of the privacy practices contained in the policy.
Here, string is defined as a sequence of characters (with " and & escaped) among the values that are allowed by the business dataset. PCDATA is defined as in [XML].
The ACCESS element indicates whether the site provides access to various kinds of information.
The ability of the individual to view identified data and address questions or concerns to the service provider. Service providers MUST disclose one value for the access attribute. The method of access is not specified. Any disclosure (other than <all/>) is not meant to imply that access to all data is possible, but that some of the data may be accessible and that the user should communicate further with the service provider to determine what capabilities they have.
Note that service providers may also wish to provide capabilities to access information collected through means other than the Web at the discuri. However, the scope of P3P statements are limited to data collected through HTTP or other Web transport protocols. Also, if access is provided through the Web, use of strong authentication and security mechanisms for such access is recommended; however, security issues are outside the scope of this document.
The ACCESS element must contain one of the following elements:
Web site does not collect identified data.
All Identified Data: access is given to all identified data.
Identified Contact Information and Other Identified Data: access is given to identified online and physical contact information as well as to certain other identified data.
Identifiable Contact Information: access is given to identified online and physical contact information (e.g., users can access things such as a postal address).
Other Identified Data: access is given to certain other identified data (e.g., users can access things such as their online account charges).
None: no access to identified data is given.
A policy SHOULD contain a DISPUTES-GROUP element, which contains one or more DISPUTES elements. These elements describe dispute resolution procedures that may be followed for disputes about a service's privacy practices. Each DISPUTES element can optionally contain a LONG-DESCRIPTION element, an IMG element, and a REMEDIES element. Service providers with multiple dispute resolution procedures should use a separate DISPUTES element for each. Since different dispute procedures have separate remedy processes, each DISPUTES element would need a separate LONG-DESCRIPTION, IMG tag and REMEDIES element, if they are being used.
Describes dispute resolution procedures that may be followed for disputes about a service's privacy practices, or in case of protocol violation.
resolution-type (mandatory attribute)
Takes one of the following four values:
Customer Service [service]
Individual may complain to the Web site's customer service representative for resolution of disputes regarding the use of collected data. The description MUST include information about how to contact customer service.
Independent Organization [independent]
Individual may complain to an independent organization for resolution of disputes regarding the use of collected data. The description MUST include information about how to contact the third party organization.
Individual may file a legal complaint against the Web site.
Applicable Law [law]
Disputes arising in connection with the privacy statement will be resolved in accordance with the law referenced in the description.
service (mandatory attribute)
URI of the customer service Web page or independent organization, or URI for information about the relevant court or applicable law
URI or certificate that can be used for verification purposes. It is anticipated that seal providers will provide a mechanism for verifying a site's claim that they have a seal.
A short human readable description of the name of the appropriate legal forum, applicable law, or third party organization; or contact information for customer service if not already provided at the service URI. No more than 255 characters.
The DISPUTES element can contain a LONG-DESCRIPTION element, where a human readable description is present: this should contain the name of the appropriate legal forum, applicable law, or third party organization; or contact information for customer service if not already provided at the service URI.
This element contains a (possibly long) human readable description.
An image logo (for example, of the independent organization or relevant court)
src (mandatory attribute)
URI of the image logo
width in pixels of the image logo
height in pixels of the image logo
alt (mandatory attribute)
very short textual alternative for the image logo
Here, string is defined as a sequence of characters (with " and & escaped), and PCDATA is defined as in [XML].
Note that there can be multiple assurance services, specified via multiple occurrences of DISPUTES within the DISPUTES-GROUP element. These fields are expected to be used in a number of ways, including representing that one's privacy practices are self assured, audited by a third party, or under the jurisdiction of a regulatory authority.
Each DISPUTES element SHOULD contain a REMEDIES element that specifies the possible remedies in case a policy breach occurs.
Remedies in case a policy breach occurs.
The REMEDIES element must contain one or more of the following:
Remedies for breaches of the policy statement will be determined based on the law referenced in the human readable description.
Statements describe data practices that are applied to particular types of data.
The STATEMENT element is a container that groups together a PURPOSE element, a RECIPIENT element, a RETENTION element, a DATA-GROUP element, and optionally a CONSEQUENCE element and one or more extensions. All of the data referenced by the DATA-GROUP is handled according to the disclosures made in the other elements contained by the statement. Thus, sites may group elements that are handled the same way and create a statement for each group. Sites that would prefer to disclose separate purposes and other information for each kind of data they collect can do so by creating a separate statement for each data element.
data practices as applied to data elements.
To simplify practice declaration, service providers may aggregate any of the disclosures (purposes, recipients, and retention) within a statement over data elements. Service providers MUST make such aggregations as an additive operation. For instance, a site that distributes your age to ours (ourselves and our agents), but distributes your postal code to unrelated (unrelated third parties), MAY say they distribute your name and postal code to ours and unrelated. Such a statement appears to distribute more data than actually happens. It is up to the service provider to determine if their disclosure deserves specificity or brevity. Note that when aggregating disclosures across statements that include the NON-IDENTIFIABLE element, this element may be included in the aggregated statement only if it would otherwise appear in every statement if the statements were written separately.
Also, one must always disclose all options that apply. Consider a site with the sole purpose of collecting information for the purposes of contact (Contacting Visitors for Marketing of Services or Products). Even though this is considered to be for the current (Completion and Support of Current Activity) purpose, the site must state both contact and current purposes. Consider a site which distributes information to ours in order to redistribute it to public: the site must state both ours and public recipients.
Service providers often aggregate data they collect. Sometimes this aggregate data may be used for different purposes than the original data, shared more widely than the original data, or retained longer than the original data. For example many sites publish or disclose to their advertisers statistics such as number of visitors to their Web site, percentage of visitors who fit into various demographic groups, etc. When aggregate statistics are used or shared such that it would not be possible to derive data for individual people or households based on these statistics, no disclosures about these statistics are necessary in a P3P policy. However, services MUST disclose the fact that the original data is collected and declare any use that is made of the data before it is aggregated.
STATEMENT elements may optionally contain a CONSEQUENCE element that can be shown to a human user to provide further explanation about a site's practices.
Consequences that can be shown to a human user to explain why the suggested practice may be valuable in a particular instance even if the user would not normally allow the practice.
STATEMENT elements may optionally contain a NON-IDENTIFIABLE element, only when the requirements specified below are fulfilled.
This is an element that can only be present in the statement, if there is no data or no identifiable data collected. Data is seen as non-identifiable in the sense of the present specification, if there is no reasonable way for the entity or a third party to attach the collected data to the identity of a natural person.
If the <NON-IDENTIFIABLE/> element is present, a human-readable explanation of how this is achieved MUST be included at the discuri.
Each STATEMENT element MUST contain a PURPOSE element that contains one or more purposes of data collection or uses of data. Sites MUST classify their data practices into one or more of the purposes specified below.
Purposes for data processing relevant to the Web.
The PURPOSE element MUST contain one or more of the following:
Completion and Support of Activity For Which Data Was Provided: Information may be used by the service provider to complete the activity for which it was provided, whether a one-time activity such as returning the results from a Web search, forwarding an email message, or placing an order; or a recurring activity such as providing a subscription service, or allowing access to an online address book or electronic wallet.
Web Site and System Administration: Information may be used for the technical support of the Web site and its computer system. This would include processing computer account information, information used in the course of securing and maintaining the site, and verification of Web site activity by the site or its agents.
Research and Development: Information may be used to enhance, evaluate, or otherwise review the site, service, product, or market. This does not include personal information used to tailor or modify the content to the specific individual nor information used to evaluate, target, profile or contact the individual.
One-time Tailoring: Information may be used to tailor or modify content or design of the site where the information is used only for a single visit to the site and not used for any kind of future customization. For example, an online store that suggests other items a visitor may wish to purchase based on the items he has already placed in his shopping basket.
Pseudonymous Analysis: Information may be used to create or build a record of a particular individual or computer that is tied to a pseudonymous identifier, without tying identified data (such as name, address, phone number, or email address) to the record. This profile will be used to determine the habits, interests, or other characteristics of individuals for purpose of research, analysis and reporting, but it will not be used to attempt to identify specific individuals. For example, a marketer may wish to understand the interests of visitors to different portions of a Web site.
Pseudonymous Decision: Information may be used to create or build a record of a particular individual or computer that is tied to a pseudonymous identifier, without tying identified data (such as name, address, phone number, or email address) to the record. This profile will be used to determine the habits, interests, or other characteristics of individuals to make a decision that directly affects that individual, but it will not be used to attempt to identify specific individuals. For example, a marketer may tailor or modify content displayed to the browser based on pages viewed during previous visits.
Individual Analysis: Information may be used to determine the habits, interests, or other characteristics of individuals and combine it with identified data for the purpose of research, analysis and reporting. For example, an online Web site for a physical store may wish to analyze how online shoppers make offline purchases.
Individual Decision: Information may be used to determine the habits, interests, or other characteristics of individuals and combine it with identified data to make a decision that directly affects that individual. For example, an online store suggests items a visitor may wish to purchase based on items he has purchased during previous visits to the Web site.
Contacting Visitors for Marketing of Services or Products: Information may be used to contact the individual, through a communications channel other than voice telephone, for the promotion of a product or service. This includes notifying visitors about updates to the Web site. This does not include a direct reply to a question or comment or customer service for a single transaction?in those cases, <current/> would be used. In addition, this does not include marketing via customized Web content or banner advertisements embedded in sites the user is visiting?these cases would be covered by the <tailoring/>, <pseudo-analysis/> and <pseudo-decision/>, or <individual-analysis/> and <individual-decision/> purposes.
Historical Preservation: Information may be archived or stored for the purpose of preserving social history as governed by an existing law or policy. This law or policy MUST be referenced in the <DISPUTES> element and MUST include a specific definition of the type of qualified researcher who can access the information, where this information will be stored and specifically how this collection advances the preservation of history.
Contacting Visitors for Marketing of Services or Products Via Telephone: Information may be used to contact the individual via a voice telephone call for promotion of a product or service. This does not include a direct reply to a question or comment or customer service for a single transaction?in those cases, <current/> would be used.
<other-purpose> string </other-purpose>
Other Uses: Information may be used in other ways not captured by the above definitions. (A human readable explanation should be provided in these instances).
Each type of purpose (with the exception of current) can have the following optional attribute:
Whether the purpose is a required practice for the site. The attribute can take the following values:
always: The purpose is always required; users cannot opt-in or opt-out of this use of their data. This is the default when no required attribute is present.
opt-in: Data may be used for this purpose only when the user affirmatively requests this use?for example, when a user asks to be added to a mailing list. An affirmative request requires users to take some action specifically to make the request. For example, when users fill out a survey, checking an additional box to request to be added to a mailing list would be considered an affirmative request. However, submitting a survey form that contains a pre-checked mailing list request box would not be considered an affirmative request. In addition, for any purpose that users may affirmatively request, there must also be a way for them to change their minds later and decline?this MUST be specified at the opturi.
opt-out: Data may be used for this purpose unless the user requests that it not be used in this way. When this value is selected, the service MUST provide clear instructions to users on how to opt-out of this purpose at the opturi. Services SHOULD also provide these instructions or a pointer to these instructions at the point of data collection.
Service providers MUST use the above elements to explain the purpose of data collection. Service providers MUST disclose all that apply. If a service provider does not disclose that a data element will be used for a given purpose, that is a representation that data will not be used for that purpose. Service providers that disclose that they use data for "other" purposes MUST provide human readable explanations of those purposes.
Each STATEMENT element MUST contain a RECIPIENT element that contains one or more recipients of the collected data. Sites MUST classify their recipients into one or more of the six recipients specified.
The legal entity, or domain, beyond the service provider and its agents where data may be distributed.
The RECIPIENT element MUST contain one or more of the following:
Ourselves and/or our entities acting as our agents or entities for whom we are acting as an agent: An agent in this instance is defined as a third party that processes data only on behalf of the service provider for the completion of the stated purposes (e.g., the service provider and its printing bureau which prints address labels and does nothing further with the information).
Delivery services possibly following different practices: Legal entities performing delivery services that may use data for purposes other than completion of the stated purpose. This should also be used for delivery services whose data practices are unknown.
Legal entities following our practices: Legal entities who use the data on their own behalf under equable practices. (e.g., consider a service provider that grants the user access to collected personal information, and also provides it to a partner who uses it once but discards it. Since the recipient, who has otherwise similar practices, cannot grant the user access to information that it discarded, they are considered to have equable practices.)
Legal entities following different practices: Legal entities that are constrained by and accountable to the original service provider, but may use the data in a way not specified in the service provider's practices (e.g., the service provider collects data that is shared with a partner who may use it for other purposes. However, it is in the service provider's interest to ensure that the data is not used in a way that would be considered abusive to the users' and its own interests.).
Unrelated third parties: Legal entities whose data usage practices are not known by the original service provider.
Public fora: Public fora such as bulletin boards, public directories, or commercial CD-ROM directories.
Each of the above tags can optionally contain:
one or more recipient-description tags, containing a description of the recipient;
with the exception of <ours>, a required attribute: this attribute is defined exactly as the analogous attribute in the