Software Project Management in Practice

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).

Section 3.1 begins with an example of an English language privacy policy and a corresponding P3P policy. P3P policies include general assertions that apply to the entire policy as well as specific assertions ”called statements ” that apply only to the handling of particular types of data referred to by data references . Section 3.2 describes the POLICY element and policy-level assertions. Section 3.3 describes statements and data references.

3.1 Example Policies

3.1.1 English Language Policies

The following are two examples of English-language privacy policy to be encoded as a P3P policy. Both policies are for one example company, CatalogExample, which has different policies for those browsing their site and those actually purchasing products. Example 3.1. is provided in both English and as a more formal description using P3P element and attribute names .

3.1.2 XML Encoding of Policies

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.

3.2 Policies

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.

3.2.1 The 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.

3.2.2 The POLICY Element

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.

<POLICY>

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

• opturi

  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 .

3.2.3 The TEST Element

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.

3.2.4 The ENTITY Element

The ENTITY element gives a precise description of the legal entity making the representation of the privacy practices.

<ENTITY>

Identifies the legal entity making the representation of the privacy practices contained in the policy.

The ENTITY element contains a description of the legal entity consisting of DATA elements referencing (all or some of) the fields of the business dataset: it MUST contain both the legal entity's name as well as contact information such as postal address, telephone number, email address, or other information that individuals may use to contact the entity about their privacy policy. Note that some laws and codes of conduct require entities to include a postal address or other specific information in their contact information.

3.2.5 The ACCESS Element

The ACCESS element indicates whether the site provides access to various kinds of information.

<ACCESS>

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:

• <nonident/>

  Web site does not collect identified data.

• <all/>

  All Identified Data: access is given to all identified data.

• <contact-and-other/>

  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.

• <ident-contact/>

  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-ident/>

  Other Identified Data: access is given to certain other identified data (e.g., users can access things such as their online account charges).

• <none/>

  None: no access to identified data is given.

3.2.6 The DISPUTES Element

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.

<DISPUTES>

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:

  1. 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.

  2. 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.

  3. Court [court]

     Individual may file a legal complaint against the Web site.

  4. 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

• verification

  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.

• short-description

  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.

<LONG-DESCRIPTION>

This element contains a (possibly long) human readable description.

<IMG>

An image logo (for example, of the independent organization or relevant court)

• src ( mandatory attribute )

  URI of the image logo

• width

  width in pixels of the image logo

• height

  height in pixels of the image logo

• alt ( mandatory attribute )

  very short textual alternative for the image logo

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.

3.2.7 The REMEDIES Element

Each DISPUTES element SHOULD contain a REMEDIES element that specifies the possible remedies in case a policy breach occurs.

<REMEDIES>

Remedies in case a policy breach occurs.

The REMEDIES element must contain one or more of the following:

• <correct/>

  Errors or wrongful actions arising in connection with the privacy policy will be remedied by the service.

• <money/>

  If the service provider violates its privacy policy it will pay the individual an amount specified in the human readable privacy policy or the amount of damages.

• <law/>

  Remedies for breaches of the policy statement will be determined based on the law referenced in the human readable description.

3.3 Statements

Statements describe data practices that are applied to particular types of data.

3.3.1 The STATEMENT Element

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.

<STATEMENT>

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.

3.3.2 The CONSEQUENCE Element

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.

<CONSEQUENCE>

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.

3.3.3 The NON-IDENTIFIABLE Element

STATEMENT elements may optionally contain a NON-IDENTIFIABLE element, only when the requirements specified below are fulfilled.

<NON-IDENTIFIABLE/>

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.

3.3.4 The PURPOSE Element

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.

<PURPOSE>

Purposes for data processing relevant to the Web.

The PURPOSE element MUST contain one or more of the following:

• <current/>

  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.

• <admin/>

  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.

• <develop/>

  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.

• <tailoring/>

  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 .

• <pseudo-analysis/>

  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.

• <pseudo-decision/>

  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/>

  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/>

  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.

• <contact/>

  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/>

  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.

• <telemarketing/>

  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:

  required

  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.

3.3.5 The RECIPIENT Element

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.

<RECIPIENT>

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:

• <ours>

  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>

  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.

• <same>

  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.)

• <other-recipient>

  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>

  Unrelated third parties: Legal entities whose data usage practices are not known by the original service provider.

• <public>

  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 PURPOSE tag, indicating whether opt-in/opt-out of sharing is available (and, its default value is always ).

Service providers MUST disclose all the recipients that apply . P3P makes no distinctions about how that data is released to the recipient; it simply requires that if data is released, then that sharing must be disclosed in the P3P policy. Examples of disclosing data which MUST be covered by a P3P statement include:

• Transmitting customer data as part of an order-fulfillment or billing process

• Leasing or selling mailing lists

• Placing personal information in URIs when redirecting requests to a third party

• Placing personal information in URIs which link to a third party

Note that in some cases the above set of recipients may not completely describe all the recipients of data. For example, the issue of transaction facilitators, such as shipping or payment processors, who are necessary for the completion and support of the activity but may follow different practices was problematic . Currently, only delivery services can be explicitly represented in a policy. Other such transaction facilitators should be represented in whichever category most accurately reflects their practices with respect to the original service provider.

A special element for delivery services is included, but not one for payment processors (such as banks or credit card companies) for the following reasons: Financial institutions will typically have separate agreements with their customers regarding the use of their financial data, while delivery recipients typically do not have an opportunity to review a delivery service's privacy policy.

Note that the <delivery/> element SHOULD NOT be used for delivery services that agree to use data only on behalf of the service provider for completion of the delivery.

3.3.6 The RETENTION Element

Each STATEMENT element MUST contain a RETENTION element that indicates the kind of retention policy that applies to the data referenced in that statement.

<RETENTION>

The type of retention policy in effect.

The RETENTION element MUST contain one of the following:

• <no-retention/>

  Information is not retained for more than a brief period of time necessary to make use of it during the course of a single online interaction. Information MUST be destroyed following this interaction and MUST NOT be logged, archived, or otherwise stored. This type of retention policy would apply, for example, to services that keep no Web server logs, set cookies only for use during a single session, or collect information to perform a search but do not keep logs of searches performed.

• <stated-purpose/>

  For the stated purpose: Information is retained to meet the stated purpose. This requires information to be discarded at the earliest time possible. Sites MUST have a retention policy that establishes a destruction time table. The retention policy MUST be included in or linked from the site's human-readable privacy policy.

• <legal-requirement/>

  As required by law or liability under applicable law: Information is retained to meet a stated purpose, but the retention period is longer because of a legal requirement or liability. For example, a law may allow consumers to dispute transactions for a certain time period; therefore a business may for liability reasons decide to maintain records of transactions, or a law may affirmatively require a certain business to maintain records for auditing or other soundness purposes. Sites MUST have a retention policy that establishes a destruction time table. The retention policy MUST be included in or linked from the site's human-readable privacy policy.

• <business-practices/>

  Determined by service provider's business practice: Information is retained under a service provider's stated business practices. Sites MUST have a retention policy that establishes a destruction time table. The retention policy MUST be included in or linked from the site's human-readable privacy policy.

• <indefinitely/>

  Indefinitely: Information is retained for an indeterminate period of time. The absence of a retention policy would be reflected under this option. Where the recipient is a public fora, this is the appropriate retention policy.

3.3.7 The DATA-GROUP and DATA Elements

Each STATEMENT element MUST contain at least one DATA-GROUP element that contains one or more DATA elements. DATA elements are used to describe the type of data that a site collects.

<DATA-GROUP>

Describes the data to be transferred or inferred.

• base

  base URI ([URI]) for URI references present in ref attributes. When this attribute is omitted, the default value is the URI of the P3P base data schema (http://www.w3.org/TR/P3P/base). When the attribute appears as an empty string (""), the base is the local document.

<DATA>

Describes the data to be transferred or inferred.

• ref ( mandatory attribute )

  URI reference ([URI]), where the fragment identifier part denotes the name of a data element/set , and the URI part denotes the corresponding data schema . In case the URI part is not present, if the DATA element is contained within a DATA-GROUP element, then the default base URI is assumed to be the URI of the base attribute. In the other cases, as usual, the default base URI is a same-document reference ([URI]).

  Remember that names of data elements and sets are case-sensitive (so, for example, user.gender is different from USER.GENDER or User.Gender ).

• optional

  Indicates whether or not the site requires visitors to submit this data element; "no" indicates that the data element is required, while "yes" indicates that the data element is not required. The default is "no." The optional attribute is used only in policies (not in data schema definitions).

  Note that user agents should be cautious about using the optional attribute in automated decision-making. If the optional attribute is associated with a data element directly controlled by the user agent (such as the HTTP Referer header or cookies), the user agent should make sure that this data is not transmitted to Web sites at which a data element is optional if the site's policy would not match a user's preferences if the data element was required. Likewise, for data elements that users typically type into forms, user agents should alert users when a site's practices about optional data do not match their preferences.

DATA elements can contain the actual data (as already seen in the case of the ENTITY element), and can contain related category information.

For example, to reference the user's home address city, all the elements of the data set user.business-info and (optionally) all the elements of the data set user.home-info.telecom , the service would send the following references inside a P3P policy:

<DATA-GROUP> <DATA ref="#user.home-info.city"/> <DATA ref="#user.home-info.telecom" optional="yes"/> <DATA ref="#user.business-info"/> </DATA-GROUP>

When the actual value of the data is known, it can be expressed inside the DATA element. For example, as seen in the example policies:

<ENTITY> <DATA-GROUP> <DATA ref="#business.name">CatalogExample</DATA> <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave. </DATA> ...

3.4 Categories and the CATEGORIES Element

Categories are elements inside data elements that provide hints to users and user agents as to the intended uses of the data. Categories are vital to making P3P user agents easier to implement and use. Note that categories are not data elements : they just allow users to express more generalized preferences and rules over the exchange of their data.

The following elements are used to denote data categories:

• <physical/>

  Physical Contact Information: Information that allows an individual to be contacted or located in the physical world ”such as telephone number or address.

• <online/>

  Online Contact Information: Information that allows an individual to be contacted or located on the Internet ”such as email. Often, this information is independent of the specific computer used to access the network. (See the category "Computer Information")

• <uniqueid/>

  Unique Identifiers: Non-financial identifiers, excluding government-issued identifiers, issued for purposes of consistently identifying or recognizing the individual. These include identifiers issued by a Web site or service.

• <purchase/>

  Purchase Information: Information actively generated by the purchase of a product or service, including information about the method of payment.

• <financial/>

  Financial Information: Information about an individual's finances including account status and activity information such as account balance, payment or overdraft history, and information about an individual's purchase or use of financial instruments including credit or debit card information. Information about a discrete purchase by an individual, as described in "Purchase Information," alone does not come under the definition of "Financial Information."

• <computer/>

  Computer Information: Information about the computer system that the individual is using to access the network ”such as the IP number, domain name, browser type or operating system.

• <navigation/>

  Navigation and Click-stream Data: Data passively generated by browsing the Web site ”such as which pages are visited, and how long users stay on each page.

• <interactive/>

  Interactive Data: Data actively generated from or reflecting explicit interactions with a service provider through its site ”such as queries to a search engine, or logs of account activity.

• <demographic/>

  Demographic and Socioeconomic Data: Data about an individual's characteristics ”such as gender, age, and income.

• <content/>

  Content: The words and expressions contained in the body of a communication ”such as the text of email, bulletin board postings, or chat room communications.

• <state/>

  State Management Mechanisms: Mechanisms for maintaining a stateful session with a user or automatically recognizing users who have visited a particular site or accessed particular content previously ”such as HTTP cookies.

• <political/>

  Political Information: Membership in or affiliation with groups such as religious organizations, trade unions, professional associations, political parties, etc.

• <health/>

  Health Information: Information about an individual's physical or mental health, sexual orientation, use or inquiry into health care services or products, and purchase of health care services or products.

• <preference/>

  Preference Data: Data about an individual's likes and dislikes ”such as favorite color or musical tastes.

• <location/>

  Location Data: Information that can be used to identify an individual's current physical location and track them as their location changes ”such as GPS position data.

• <government/>

  Government-issued Identifiers: Identifiers issued by a government for purposes of consistently identifying the individual.

• <other-category> string </other-category>

  Other: Other types of data not captured by the above definitions. (A human readable explanation should be provided in these instances, between the <other-category> and the </other-category> tags.)

The Computer, Navigation, Interactive and Content categories can be distinguished as follows . The Computer category includes information about the user's computer including IP address and software configuration. Navigation data describes actual user behavior related to browsing. When an IP address is stored in a log file with information related to browsing activity, both the Computer category and the Navigation category should be used. Interactive Data is data actively solicited to provide some useful service at a site beyond browsing. Content is information exchanged on a site for the purposes of communication.

The Other category should be used only when data is requested that does not fit into any other category.

P3P uses categories to give users and user agents additional hints as to what type of information is requested from a service. While most data in the base data schema is in a known category (or a set of known categories), some data elements can be in a number of different categories, depending on the situation. The former are called fixed-category data elements (or "fixed data elements" for short), the latter variable-category data elements ("variable data elements"). Both types of elements are described in Section 5.7.

3.5 Extension Mechanism: The EXTENSION Element

P3P provides a flexible and powerful mechanism to extend its syntax and semantics using one element: EXTENSION . This element is used to indicate portions of the policy which belong to an extension. The meaning of the data within the EXTENSION element is defined by the extension itself.

<EXTENSION>

Describes an extension to the syntax.

• optional

  This attribute determines if the extension is mandatory or optional . A mandatory extension is indicated by giving the optional attribute a value of no . A mandatory extension to the P3P syntax means that applications that do not understand this extension cannot understand the meaning of the whole policy (or data schema). An optional extension, indicated by giving the optional attribute a value of yes , means that applications that do not understand this extension can safely ignore the contents of the EXTENSION element, and proceed to process the whole policy (or data schema) as usual. The optional attribute is not required; its default value is yes .

For example, if www.catalog.example.com would like to add to P3P a feature to indicate that a certain set of data elements were only to be collected from users living in the United States, Canada, or Mexico, it could add a mandatory extension like this:

<DATA-GROUP> ... <EXTENSION optional="no"> <COLLECTION-GEOGRAPHY type="include" xmlns= "http://www.catalog.example.com/P3P/region"> <USA/><Canada/><Mexico/> </COLLECTION-GEOGRAPHY> </EXTENSION> </DATA-GROUP>

On the other hand, if www.catalog.example.com would like to add an extension stating what country the server is in, an optional extension might be more appropriate, such as the following:

<POLICY> <EXTENSION optional="yes"> <ORIGIN xmlns="http://www.catalog.example.com/P3P/ origin" country="USA"/> </EXTENSION> ... </POLICY>

The xmlns attribute is significant since it specifies the namespace for interpreting the names of elements and attributes used in the extension. Note that, as specified in [XML-Name], the namespace URI is just intended to be a unique identifier for the XML entities used by the extension. Nevertheless, service providers MAY provide a page with a description of the extension at the corresponding URI.

3.6 Import and Export of User Preferences

User agents MUST document a method by which preferences can be imported and processed , and SHOULD document a method by which preferences can be exported.