Roger Clarke's Web-Site

© Xamax Consultancy Pty Ltd,  1995-2024
Photo of Roger Clarke

Roger Clarke's 'P3P Overview'

Platform for Privacy Preferences: An Overview

Roger Clarke

Principal, Xamax Consultancy Pty Ltd, Canberra

Visiting Fellow, Department of Computer Science, Australian National University

Version of 20 May 1998, with additional references to 29 October 1999

© Xamax Consultancy Pty Ltd, 1998

Available under an AEShareNet Free for Education licence

These notes were originally prepared to accompany a panel presentation at WWW7 in Brisbane in April 1998. They were re-published in Privacy Law & Policy Reporter 5, 2 (July 1998) at 35-39

This is the first of a family of three papers. The other two are A Critique (1998) and a Re-visit (2001)

This document is at






The P3P Architecture and Process

Technical Mechanisms

Further Reading



Privacy is a very important public concern. My pages include an introduction to the topic; together with a vast array of relevant information.

Internet privacy is of particular, and rapidly increasing, concern. My pages include a substantial review. Quite a lot of people are actively doing something about Internet privacy. Their actions range from assaults on privacy-invaders, through responsible net-activist activities, privacy-sensitive architectures and services, and privacy-enhancing technology development, to actions in legislatures.

This document provides background to one particular initiative, the Platform for Privacy Preferences (P3P) protocol developed by the World Wide Web Consortium (W3C).

This overview document is complemented by a critique of P3P (which assumes that you've already read the document that is currently in front of you).

W3C is a foundation charged with maintenance and enhancement of the web. Despite being funded almost exclusively by IT providers, W3C retains a remarkably close affinity with the mainstream of the Internet-public. It seeks to enable web-based electronic commerce, without in the process undermining the web-based electronic community ethos. For the last couple of years, I've been cautiously optimistic about that aspiration being able to be sustained, and I continue to be positive about it.


In 1996-97, the World Wide Web Consortium (W3C) recognised the importance of establishing a framework within which trust can be achieved between web services providers and consumers. It launched an initiative entitled Platform for Privacy Preferences (P3P).

A Public Working Draft of the syntax specification was published on 19 May 1998.

Major providers, including Engage Technologies, Firefly, Microsoft, Netscape, Open Sesame and Microsystems Software have announced plans to implement the P3P protocol within their products.

This document provides an (unofficial) overview of P3P. It is based on the information provided by W3C P3P, in particular the FAQ, a presentation, and the architecture, grammar, and harmonisation drafts. These will be revised and consolidated in the coming months.


The P3P protocol is intended to support negotiations in a wide variety of contexts, including the following:

P3P explicitly recognises the need to support multiple personae per web-user. Personae allow the web-user to create different views of themselves by changing the data given to a service. A persona may be based upon the service's purpose (e.g. business, gaming, home, etc.), credentials (e.g. level of associated trust), consequences and practices (e.g. personalization, shipping, mailing list), or any user defined rationale (e.g. time of day, phase of moon, etc). Hence a web-user might decline to enter a web-site under their 'normal' persona, which might have a substantial amount of personal data associated with it; but might switch personae to a pseudonymous, or data-poor persona, and enter the site while making little about themselves available to it.

P3P is intended to support interactions involving basic HTTP. It is as yet precisely how it will be applied to interactions involving enhancements to basic HTTP, such as cookies, Javascript, Java and ActiveX.


The purpose of the P3P specification is to enable:

In effect, it is to provide means whereby an individual can have sufficient information that he or she can make an informed decision on whether to permit further use of the data, or decline further use of the data. Moreover, that decision is to be able to be delegated to a software agent acting on behalf of the individual.

If the individual denies access to data, or denies the service-provider authority to use the data, the web-site operator might provide a degraded service, or might provide no service at all. In either case, this may be by choice (e.g. because the web-site operator places a high value on collecting such data, or wishes to discourage the denial of data), or by necessity (e.g. because it is not feasible to provide the service in the absence of the data, such as the delivery address for physical goods, or a means of ensuring receipt of payment).

P3P is also intended to make a major contribution (but not to provide a complete solution) to the following, more abstract objectives:

The P3P Architecture and Process

The elements of a P3P-enabled web-context are as follows:

A simplified description of the basic process is as follows:

The effect of the scheme is to achieve what W3C refers to as 'informed consent through user choice'.

P3P assumes that some external mechanism exists to provide assurance that the practice will be conformed with. This assurance may come from the web-site or an independent assuring party. Ideally, the assuring party would digitally sign proposals, and would be financially liable for breach.

Technical Mechanisms

The manner of implementation in web-browsers and web-servers, including user-interface aspects, is not specified in the P3P protocol, because this is an appropriate domain for competitive marketplace behaviour.

To enable the uttering of privacy statements, and the exchange of data under user control, the P3P protocol is built over the emergent W3C standards for:

It is intended that P3P support future digital certificate and digital signature capabilities as they become available. P3P is being designed to be able to be incorporated into browsers, and servers, and proxy servers that sit between a client and server.

The P3P Grammar is a set of rules that defines the structure of P3P clauses used to make a valid P3P statement. The following example structures clauses (in the parentheses) to make a simple privacy practice statement:

	for (these URIs)
	the following (practices) apply
	to this (set of data)

The Appendices provide the following further information:

Further Reading

The primary document that defines P3P is:

This author has published a companion to the descriptive document that you currently have in front of you:

Other critiques include:

The P3P Syntax Specification was based on other documents, specifically the

as well as the:

Lorrie Faith Cranor (one of the primary architects of P3P) offers a valuable page of source-materials.

Related materials include:

The P3P specification was for some time under challenge by a company called Intermind, which claimed that P3P infringed its patents, and therefore its application would require a licence and royalty payments. In October 1999, W3C published a legal opinion that declared conclusively that P3P did not infringe the patent. See also a Wired Magazine report and prior references.

Appendix 1
General Form and Pseudocode Form of the P3P Grammatical Model


Accessed on 9 April 1998

The general form of a proposal is:

       using schema
       (for some experience space)
       (you will enter an agreement with this entity)
       They will offer:
       (this access)
       (and this qualifier)
       (Accepting will give you this consequence)
       (for more information, contact)

Statements are composed of the following mandatory clauses:

Statements might also include the following optional clauses:

These clauses are further specified below.

The proposed protocols and negotiation working group will also determine any additional syntax that might be needed for combining statements into proposals.

The general form of a statement is:

       (for some experience space)
       (you will enter an agreement with this entity)
       who will apply this (practice to (qualified data set)+ 
          (with qualifier)* 
          (with access)
       (Accepting will give you this consequence)
       (for more information, contact)

The general form of a qualified data set is:

       named set of data
       falling into this (category)+
       using data schema
       Apply the access permission restriction
       (and this qualifier) 


In an HTML-like pseudocode, this might look something like:

<ablock id="proposal">
        <namespace href="" as="P3"/>
        <ablock id="statement1">
                <ablock id="data1"><P3::practice>3</P3::practice>
                        <P3::named_data>"contact information"</P3::named_data>
                <ablock id="data2"><P3::practice>3</P3::practice>
                        <P3::named_data>"computer information"</P3::named_data>
<ablock href="#proposal1" id="signature">
        <namespace href="" as="pkcs7">

Appendix 2
P3P Data Categories

From Categories

Accessed on 9 April 1998

0 Physical Contact Information

1 Online Contact Information

2 Unique Identifiers

3 Financial Account Identifiers

4 Computer Information

5 Navigation and Click-stream Data

6 Transaction Data

7 Demographic and Socio-economic Data

8 Preference Data

9 Content

Appendix 3
P3P Purposes

From Defined

Accessed on 9 April 1998

0 Completion and Support of Current Activity

1 Web Site and System Administration

2 Customization of Site to Individuals

3 Research and Development

4 Contacting Visitors for Marketing of Services or Products

5 Other Uses

Appendix 4
P3P Purpose Qualifiers

From Qualifiers

Accessed on 9 April 1998

Identifiable Use

Is data used in a way that is personally identifiable -- including linking it with identifiable information about you from other sources? Examples: (full_name), but also other data, such as (zip_code, salary, birth_date), and even IP number.

       0 No 
       1 Yes 

Recipients (Domain of Use)

This defines an organizational area, or domain, beyond the service provider and its agents where data may be distributed.

0 Only ourselves and our agents

1 Organizations following our practices

2 Organizations following different practices

3 Unrelated third parties or public fora

Appendix 5
General Disclosures

From Disclosures

Accessed on 9 April 1998

Access to Identifiable Information

The ability of the individual to view identifiable information and address questions or concerns to the service provider.

0 Identifiable Data is Not Used

1 Identifiable Contact Information

2 Other Identifiable Information

3 None

Assurance (accountability)

Does the site have an assuring party that attests that the service will abide by its proposal, follows guidelines in the processing of data, or other relevant assertions. Assurance may come from the service provider or an independent assuring party.

 0 	No    there is no disclosure with respect to assurance.
 1 	Yes   there is an assurance mechanism, see our disclosure. 

0 Change_Agreement

1 Retention

xamaxsmall.gif missing
The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.

From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 65 million in early 2021.

Sponsored by the Gallery, Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer
Xamax Consultancy Pty Ltd
ACN: 002 360 456
78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916

Created: 16 April 1998 - Last Amended: 29 October 1999; addition of FfE licence 5 March 2004 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at
Mail to Webmaster   -    © Xamax Consultancy Pty Ltd, 1995-2022   -    Privacy Policy