1 Introduction

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.

1.1 The P3P1.0 Specification

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.

1.1.1 Goals and Capabilities of P3P1.0

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

  • An XML format for expressing a privacy policy

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

1.1.2 Example of P3P in Use

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.

Claudia types the address for CatalogExample into her Web browser. Her browser is able to automatically fetch the P3P policy for that page. The policy states that the only data the site collects on its home page is the data found in standard HTTP access logs. Now Claudia's Web browser checks this policy against the preferences Claudia has given it. Is this policy acceptable to her, or should she be notified? Let's assume that Claudia has told her browser that this is acceptable. In this case, the home page is displayed normally, with no pop-up messages appearing. Perhaps her browser displays a small icon somewhere along the edge of its window to tell her that a privacy policy was given by the site, and that it matched her preferences.

Next, Claudia clicks on a link to the site's online catalog. The catalog section of the site has some more complex software behind it. This software uses cookies to implement a "shopping cart" feature. Since more information is being gathered in this section of the Web site, the Web server provides a separate P3P policy to cover this section of the site. Again, let's assume that this policy matches Claudia's preferences, so she gets no pop-up messages. Claudia continues and selects a few items she wishes to purchase. Then she proceeds to the checkout page.

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.

1.1.3 P3P Policies

P3P policies use an XML encoding of the P3P vocabulary to provide contact information for the legal entity making the representation of privacy practices in a policy, enumerate the types of data or data elements collected, and explain how the data will be used. In addition, policies identify the data recipients, and make a variety of other disclosures including information about dispute resolution, and the address of a site's human-readable privacy policy. P3P policies must cover all relevant data elements and practices (but note that legal issues regarding law enforcement demands for information are not addressed by this specification; it is possible that a site that otherwise abides by its policy of not redistributing data to others may be required to do so by force of law). P3P declarations are positive, meaning that sites state what they do, rather than what they do not do. The P3P vocabulary is designed to be descriptive of a site's practices rather than simply an indicator of compliance with a particular law or code of conduct. However, user agents may be developed that can test whether a site's practices are compliant with a law or code.

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.

1.1.4 P3P User Agents

P3P1.0 user agents can be built into Web browsers, browser plug-ins, or proxy servers. They can also be implemented as Java applets or JavaScript; or built into electronic wallets, automatic form-fillers, or other user data management tools. P3P user agents look for references to a P3P policy at a well-known location, in P3P headers in HTTP responses, and in P3P link tags embedded in HTML content. These references indicate the location of a relevant P3P policy. User agents can fetch the policy from the indicated location, parse it, and display symbols, play sounds, or generate user prompts that reflect a site's P3P privacy practices. They can also compare P3P policies with privacy preferences set by the user and take appropriate actions. P3P can perform a sort of "gate keeper" function for data transfer mechanisms such as electronic wallets and automatic form fillers. A P3P user agent integrated into one of these mechanisms would retrieve P3P policies, compare them with users' preferences, and authorize the release of data only if a) the policy is consistent with the user's preferences and b) the requested data transfer is consistent with the policy. If one of these conditions is not met, the user might be informed of the discrepancy and given an opportunity to authorize the data release themselves .

1.1.5 Implementing P3P1.0 on Servers

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.

1.1.6 Future Versions of P3P

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

1.2 About This Specification

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.

MAY

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.

1.3 Terminology

Character

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

Data Element

An individual data entity, such as last name or telephone number. For interoperability, P3P1.0 specifies a base set of data elements.

Data Category

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.

Data Set

A known grouping of data elements, such as "user.home- info .postal" . The P3P1.0 base data schema specifies a number of data sets.

Data Schema

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 .

Data Structure

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.

Equable Practice

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.

Identified Data

Data that reasonably can be used by the data collector to identify an individual.

Policy

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.

Practice

The set of disclosures regarding data usage, including purpose, recipients, and other disclosures.

Preference

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

Purpose

The reason(s) for data collection and use.

Repository

A mechanism for storing user information under the control of the user agent.

Safe Zone

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.

Service

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.

Statement

A P3P statement is a set of privacy practice disclosures relevant to a collection of data elements.

URI

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.

User

An individual (or group of individuals acting as a single entity) on whose behalf a service is accessed and for which personal data exists.

User Agent

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.



Mobile Location Servies(c) The Definitive Guide
Software Project Management in Practice
ISBN: 0201737213
EAN: 2147483647
Year: 2005
Pages: 150
Authors: Pankaj Jalote

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net