P3P 1.1 User Agent Guidelines

Abstract

This document specifies guidelines for P3P 1.1 user agents.

Status of this document

This is an editors' draft with no standing. We are proposing that this document be folded into the P3P 1.1 specification in the places as indicated by the section numbers here.

1.1.4 P3P User Agents

[change second paragraph to the following]

The P3P 1.1 Specification gives implementers a lot of flexibility to determine the design and functionality of P3P user agents. However, the specification does include some requirements and guidelines for user agent implementers. Most of these can be found in section 6 and Appendix 7.

6.0 User Agent Guidelines

This section specifies guidelines for P3P 1.1 user agents. Some of these guidelines serve to reinforce requirements that appear elsewhere in this specification, providing specific guidance for user agent implementers. Other guidelines introduce new requirements for full compliance with this specifcation or provide suggestions for implementers. All of these guidelines are designed to promote consistency among user agent implementations and to assist implementers in designing user agents that will be both usable and useful. By using consistent language to describe web site privacy practices, user agent implementers can help ensure that their implementations represent web site privacy practices accurately. In addition, consistent implementations serve to reduce the uncertainty web site operators have about how their policies will be displayed by P3P user agents.

6.1 Completeness of Human-Readable Translations

P3P user agents may display human-readable translations of P3P policies. Because of the large number of fields in a P3P policy, in some case, user agent implementers may wish to develop human-readable translations that do not include all P3P policy elements. The following guidelines are designed to reduce the chance that abridged translations may mislead users.

1. While the default view of a human-readable P3P translation MAY be abridged, user agents SHOULD include a mechanism that allows users to view a complete translation, including an enumeration of all data elements referenced in a P3P policy.
2. Translations that include information about P3P DATA elements MAY provide this information at differing levels of granularity; however, they SHOULD include information about all relevant data elements in the policy. For example, a user agent that displays only category information and not individual element names SHOULD include the categories that correspond to the elements referenced explicitly by name. Thus, a user agent that displays only category information would display some indication that online contact information was being collected if it encountered a site that said it collected the user.home-info.online.email data element.
3. Translations that include information about P3P PURPOSE elements SHOULD provide information to indicate whether any of these purposes are being performed on an opt-in or opt-out basis.
4. Translations that include information about P3P RECIPIENTS elements should provide information to indicate whether data is disclosed to any of these recipients on an opt-in or opt-out basis.
5. Translations SHOULD include relevant human-readable fields from a P3P policy. However, user agents MAY truncate lengthy human-readable fields or display such fields on a click-through basis. Typically, 500 characters is adequate for the human-readable P3P fields.

6.2 Plain Language Translations of P3P Vocabulary Elements

Section 3 includes normative definitions for all P3P vocabulary elements. However, many of these definitions are rather verbose and use language that is unsuitable for display to end users. Therefore, the P3P 1.1 Working Group has developed a set of "plain language" translations for most of the P3P vocabulary elements. These translations are designed to convey the essence of each element in relatively simple language, without conflicting with the normative definition. A "plain English" version is presented here, translations to other languages are available at ??? P3P user agents SHOULD display P3P policy information to users using the plain English wording shown here or an equivalent translation.

HERE IS A LINK TO OUR DRAFT -- once we have a consensus on it we will put a table here with the P3P element name, normative definition, and plain English translation

6.3 Storage of P3P Policies and Translations

P3P user agents SHOULD include mechanisms that allow users to store P3P policies and their corresponding translations easily to make them available for later viewing or printing.

6.4 Compact Policy Processing

P3P user agents SHOULD NOT rely on P3P compact policies that do not comply with the P3P 1.0 or P3P 1.1 specifications or are obviously erroneous. Such compact policies SHOULD be deemed invalid and the corresponding cookies should be treated as if they had no compact policies.] The following guidelines are designed to reduce the chance that a P3P user agent will accept an invalid compact policy.

1. Compact policies that do not comply with the syntax specified in section 4 of the P3P 1.0 Specificaiton or section ?? of the P3P 1.1 specification are invalid.
2. Compact policies for which there is no corresponding full P3P policy are invalid. (Note, in some cases user agents may not be able to verify that a corresponding full P3P policy exists until after storing and possibly even replaying a cookie. In that case, upon determining that no full P3P policy exists, the user agent should refrain from further replay of that cookie.)
3. Compact policies that include the IVA token that do not include at least one of the following tokens are invalid: PHY, ONL, FIN, PUR, GOV. (RATIONALE: This purpose requires "identified data". While it is possible to have other categories associated with an identified subject, the actual identification is impossible without a data element associated with one or more of the above categories.)
4. Compact policies that include the IVD token that do not include at least one of the following tokens are invalid: PHY, ONL, FIN, PUR, GOV. (RATIONAEL: This purpose requires "identified data". While it is possible to have other categories associated with an identified subject, the actual identification is impossible without a data element associated with one or more of the above categories.)
5. Compact policies that include the CON token that do not include at least one of the following tokens are invalid: PHY, ONL. (RATIONALE: Logic dictates that to contact an individual the initiator of the contact would possess a data element identifying the individual in a place where he or she would be contacted - either the online or offline worlds. This would presuppose elements contained by one of the above categories.)
6. Compact policies that include the TEL token that do not include the PHY token are invalid. (RATIONALE: Again logic dictates that if you are going to contact someone via telephone, you at least have a data element that contains phone numbers. These data elements should all be within the Physical category.)

6.5 Sanity Checking P3P Policies

Although the P3P 1.1. specification does not hold user agents responsible for verifying that web site P3P policies are accurate, it is a good idea for user agents to do some sanity checking to flag P3P policies that are obviously erroneous. Such policies should be deemed invalid. The following guidelines are designed to reduce the chance that a P3P user agent will accept an invalid policy. (See also section 2.4.4 Policy and Policy Reference File Processing by User Agents.)

1. A policy is invalid if it contains a statement that includes the individual-analysis element and does not include at least one data element from one of the following data categories: physical, online, financial, purchase, government. (RATIONALE: This purpose requires "identified data". While it is possible to have other categories associated with an identified subject, the actual identification is impossible without a data element associated with one or more of the above categories.)
2. A policy is invalid if it contains a statement that includes the individual-decision element and does not include at least one data element from one of the following data categories: physical, online, financial, purchase, government. (RATIONAEL: This purpose requires "identified data". While it is possible to have other categories associated with an identified subject, the actual identification is impossible without a data element associated with one or more of the above categories.)
3. A policy is invalid if it contains a statement that includes the contact element and does not include at least one data element from one of the following data categories: physical, online. (RATIONALE: Logic dictates that to contact an individual the initiator of the contact would possess a data element identifying the individual in a place where he or she would be contacted - either the online or offline worlds. This would presuppose elements contained by one of the above categories.)
4. A policy is invalid if it contains a statement that includes the telemarketing element and does not include at least one data element from onte physical category. (RATIONALE: Again logic dictates that if you are going to contact someone via telephone, you at least have a data element that contains phone numbers. These data elements should all be within the Physical category.)