Computer Security – ESORICS 2002. pp 104 -125. Springer Lecture Notes in Computer Science 2502.

Gollman,
Karjoth, Waidner (Eds.)
A fully compliant research implementation of the P3P standard for privacy protection:
experiences and recommendations

Giles Hogben, Tom Jackson, Marc Wilikens1

Institute for the Security and Protection of the Citizen,
Joint Research Centre of the EC2

Abstract
This paper describes the experience gained from the development of a fully
compliant implementation of the P3P standard. P3P is an XML based standard issued
by W3C which aims to make privacy policies of web sites machine readable and
transparent for the user and thereby to clarify and speed up transactions of personal
data on the internet.
We look at some of the most important issues that have arisen from the development
of this implementation, including problems with the privacy preference standard,
APPEL, before concentrating in our final section on some issues related to assurance
for end users. In that section we look at P3P usage scenarios to show that the current
P3P standard has weaknesses in certain areas. The paper then considers possible
extensions to the W3C's P3P specification which could provide greater assurance to
end users, facilitate dispute resolution and ease Internet data flow. In particular, we
present an overview of the possible ways for increasing assurance of a privacy
policy's validity. In this regard, we describe the use of XML signatures and of hash
storage by a third party, as an alternate solution to the assurance .

Keywords: privacy enhancing technologies, P3P, XML Digital Signatures, secure

electronic commerce, transaction management, security verification

1 Introduction
1.1 Online privacy concerns
There have been several optimistic projections of rapid growth in e-commerce however the
business-to-consumer (B2C) sector has failed to realise its expected growth potential. Surveys
show that lack of information about data practices, and lack of trust in third party management of
personal data is one of the most significant obstacles to the growth of e-commerce on the Internet.
A survey performed by Consumers International [Scribbens, 2001], reveals that a third of
investigated web sites made no mention of their privacy practices and the quality of actual
practices where they existed was not assessed. A Harris poll [NCL2000] showed that when asked
specifically about their online privacy concerns, respondents said they were most worried about
web sites providing their personal information to others without their knowledge (64 percent) and
web sites collecting information about them without their knowledge (59 percent).
Due to large consumer backlash over concerns relating to abuse of privacy rights in on-line
commerce there has been a trend for commercial web sites to include a text based privacy policy,
typically linked from the site home page, which sets out the data processing practices of the
organisation. However this has done little to allay fears.
The P3P standard has been proposed and developed by the World Wide Web Consortium (W3C)
in response to the growing technological need to manage the privacy concerns of consumers
engaging in on-line commerce. This paper will describe the experience gained in the development
of a P3P implementation that is fully compliant with the standard, will identify some of the
outstanding problems and outline recommendations for addressing them. It should be stressed
1
Contact: Marc.Wilikens@jrc.it
2
The views expressed in this paper are the author’s own, and may not be taken in any way as representative
of those of the European Commission.
that P3P offers only one (albeit important) technical solution in a wider spectrum of privacy
enhancing technologies that can be applied in managing on-line privacy issues. In particular it
provides a framework, which allows users to assess the terms and conditions of a web sites’
Privacy Policy via unambiguous machine readable statements which explicitly declare a
corporation’s data handling practices for personal data. These statements are processed
automatically, but visibly, before any personal data is sent to a remote web site.

After a brief introduction to P3P, we describe the JRC P3P demonstration implementation in
section 2. Section 3 reviews some of the findings deriving form the implementation. Section 4
describes how some important questions of end user trust remain inadequately addressed by the
current P3P specification. For example, the privacy statement of a web site might state that they
will not contravene certain privacy principles (such as disclosure to third parties) but currently
P3P does not contribute to the process of making this an agreement that can be enforced. We
claim that the P3P process has the potential to deliver far more in terms of a legally binding
statement.
1.2 Platform for Privacy Preferences - Brief Introduction
The W3C specification document gives the following description of P3P:
"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." [W3C2001]

The aims of P3P can be summarised as follows:

• To increase trust in data transactions on the Internet by providing unambiguous statements of
Data Protection policies.
• To facilitate the flow of data by making such statements machine readable.
• To facilitate privacy dispute resolution by providing statements which can be discussed
unambiguously.

A schematic overview of the process flow (figure 1) shows the main functions and flows of P3P:

1. A web service/site (e.g. e-commerce shop) defines its Privacy Policy that is subsequently
translated into a P3P XML version, possibly using an off the shelf tool. This typically
specifies issues such as how long data will be retained, whether it will be disclosed to
unrelated third parties and how users can access the information stored about them.
2. The Internet user defines his/her Privacy preferences (i.e. ways in which his personal data
should be handled if he is to give it over to another party) that is subsequently translated
into a P3P XML version possibly using a graphical tool such as the ruleset editor
prototype developed by the JRC3. This will typically specify a set of characteristics to
look for in P3P policies along with what to do if the user agent finds them. The
characteristics that the rules look for can be any of those possible within P3P such as user
access rights, data retention, etc.
3. After the Internet user starts a web session with a web server, the P3P User agent fetches
the P3P XML privacy policy.
4. The P3P User agent evaluates the privacy policy against the user privacy preference set.

3
See JRC P3P resource center http://p3p.jrc.it

2
 5. Depending on evaluation result, personal information is released to the web site’s data
store and the client may be given information on the evaluation results.

Figure 1. Schematic overview of the P3P Process Model

Although a global standards initiative, the importance of P3P to the EU business sector cannot be
underestimated. If the standard is widely adopted (Microsoft now have a partial release within
Internet Explorer 6.0 which can only enhance its chances of global deployment) it is likely that
European businesses will also conform. A broad survey conducted in the US by the Internet
Education Foundation found that about one-third of the top 100 web sites have adopted the P3P
standard for defining their privacy policy or plan to do so.

2 Description of the P3P reference implementation

2.1 Objectives
The Joint Research Centre of the EC, has been working on a complete implementation of the
Platform for Privacy Preferences standard4. This implementation is the first fully compliant
implementation of the standard available in the world, and has been adopted by the W3C5 as a
reference model to demonstrate the maturity of the standard. A demonstration site and evaluation
environment has been developed for our P3P implementation which provides a broad range of
assessment and familiarisation functions:
1. EU Privacy Compliance Platform: The level of the standard's compliance with European
legislation on Personal Data Protection has been a major question mark thus far. The P3P
standard defines privacy requirements in terms of ‘preferences’. However, many have argued
that the EU legislation makes personal data protection a legal requisite, not an issue for
negotiation between a business and a consumer. The implementation will allow these
questions to be explored in greater detail, and will allow the EC and the member state Data
Protection Agencies to evaluate the impact and validity of P3P in the EU context.

4
See the JRC P3P resource center at http://p3p.jrc.it
5
See the W3C web site: http://www.w3c.org/p3p

3
2. Educational Platform: The P3P demonstrator provides the EU with a commercially
independent implementation of the standard within an interactive tutorial environment. This
allows interested parties within the EU to familiarise themselves with the standard and its
likely implementation framework.
3. Research Platform: The implementation will permit assessment of technological challenges
from the perspective of P3P integration into trusted on-line systems which deploy emerging
security management technologies (for example, digital signatures and smart cards) and other
Privacy Enhancing Technologies (PETs) (for example, cookie crushers and anonymiser
technologies). For instance in Berthol outlines [Berthol, 2000], possibilities for designing
identity management systems using P3P.
2.2 Architecture
The implementation is written in Java 1.2 with a proxy architecture which ensures compatibility
with all browsers. The architecture is very modular, thus allowing free experimentation with the
different components. It consists of the following components (see figure 2):

Server/ Business
Web Sites Data
Store

5. Policy
Discovery
Module

2. Ruleset 1. APPEL 4. Proxy

Creation Matching Module
GUI Module

3. Syntax
Validation
Module

Client
Browser i
Figure 2. Architecture components of the JRC P3P implementation

1. APPEL preference matching component: The intelligent agent which performs matches
between the web site P3P privacy policy and the user’s XML (APPEL) privacy preferences.
For this it uses the protocol defined in the W3C's APPEL specification [APPEL2001].
APPEL allows a user to express his/her privacy preferences in a set of XML rules (called a
ruleset), which can then be used by their user agent to make automated or semi-automated
decisions regarding the acceptability of machine-readable privacy policies from P3P enabled
Web sites.
2. Preference creation component: A Graphical User Interface allowing users to translate their
privacy preferences into XML format.
3. Syntax validation component: Performs numerous syntax checks on the Privacy Policy and
the privacy preference ruleset.

4
4. Proxy component: Mediates between client and server, filtering content according to P3P.
Also handles the different users accessing the machine simultaneously so that content is sent
back only to the user who requested it.
5. Policy discovery component. Looks for policy reference files (files specifying which policies
apply to which resources) and decides which P3P policy applies to which resource.

The set up also contains a mock-up of a typical P3P enabled commercial Web site to demonstrate
a realistic process and end user interactions.

3 Main findings deriving from the P3P implementation

3.1 User interface and performance issues
Perhaps the most interesting part of the development effort was in trying to build an interface
through which users can easily set up their privacy preferences. P3P can express almost any
aspect of human readable privacy policies in an unambiguous machine readable XML format.
Building on this, APPEL is able to create rules which will match any
aspect of P3P's granular structure. Therefore in setting up an interface for creating APPEL rules,
we were forced to present a very large number of possibilities to the user in order to allow them
to match any aspect of a P3P policy.

3.1.1 User interface issues with APPEL.

A survey of existing implementations shows that commercial implementations have
not implemented full versions of APPEL. One of the possible reasons for this is that the
possibility space provided by APPEL is too large for any application to be able to offer a simple
and easy to use interface for creating privacy rules. For example it is possible to state for any one
of over 100 data types whether their collection is optional or not. To give the ordinary user the
ability to control the optionality of every one of the data types would present him with an
impossibly complex array of choices. However for people using APPEL in a more professional
capacity such as European Data commissioners, the ability to control such choices is vital.

Any user interface therefore needs to be firmly divided between the expert and the general user.
After creating our Rule creation GUI, we were reasonably confident of being able to create an
interface that would be useful to informed experts. We also found that it was possible to create an
interface for general users based on selecting from a set of predefined rules (e.g. "block all
cookies which link to personal information"). The main obstacle we needed to overcome was
making sure that the complexity of complete rule creation was not presented to ordinary users,
whilst still allowing it as a possibility for advanced users. Figure 3 shows the two sections of the
GUI, one based on choosing between a simple selection of predefined rules, the other offering
complete control over all aspects of the privacy rule. You can see that the second, more complex
GUI is designed to allow control over all aspects of privacy rules, while the first gives a quick
and easy choice aimed at the ordinary user. We are hoping to refine these interfaces over time to
make them simpler and more intuitive.

5
Figure 3: Simple and Advanced rule creation interfaces.

3.1.2 Complexity of algorithm.

Another possible reason for the lack of full implementations of APPEL is that in order to provide
a completely general matching algorithm, capable of dealing with any possible privacy preference
within the semantic space provided by P3P, a complex sub-tree matching algorithm is required.
This is costly to implement in terms of development time and difficult to make efficient.

At first sight, the APPEL algorithm appears to be very heavy because it is a highly recursive. This
may have put off many implementers. However, because P3P policies never reach more than 5
generations in depth and generally only extend to 4, the recursivity does not produce excessive
load. We found that with a full policy validation in our Java implementation, the APPEL
evaluation process on a standard PC can take of the order of 1 second for a real world ruleset and
policy. However timing tests revealed that this was more due to inefficiencies in document
parsing than in excessive load created by the algorithm. The actual matching process only takes
typically 20 milliseconds. We would suggest therefore that implementers should not be put off
using APPEL because of its apparent complexity. Already some implementers have been
successfully using our example module which can be used as a stand alone component, so it may
be that in time this reluctance will be overcome.

3.1.3 Performance in P3P user agents

The fact that most commercial implementations and most notably Microsoft's IE 6 have chosen to
implement a cut down version of P3P, and in general policies are processed after resources have
been loaded, highlights performance problems faced by implementers of P3P. A typical page load
with a P3P user agent installed can involve 6 extra http calls for policy reference files, policies for
embedded resources etc. This is very costly in terms of speed.

W3C's proposed solution to this has been the P3P compact policy. This is an abbreviated version
of the P3P policy contained in the http header, which allows a much quicker evaluation time.
However these only apply to cookies and are therefore by no means a complete solution. At
present, this is largely an unsolved problem, but it is also a major component of our ongoing
research.

One solution is to capitalize on the fact that many companies are tending to use standardized
(“catch-all”) privacy policies for reasons of legal security and to save work in creating policies.

6
Looking for example at the Yahoo.com policy; The policy which covers the majority of pages
within their domain states that information collected may be used for opt out telemarketing. But
on most pages within Yahoo, no personal information is actually collected. This reflects the fact
that it is easier for companies to create a "lowest common denominator" policy which will cover
anything that might possibly happen on their site, than to create policies tailored to individual
pages.

If this trend develops, what may happen is that companies will use standardized privacy policies
kept by third parties at well known URI's, which may be well known to a user agent, in the same
way as data documents can use standard XML schemas. This would allow a major performance
enhancement because clients could then store a list of URI's of standard policies and simply
match against their URI's rather than having to fetch a policy and do complex sub-tree matching.
This is effectively a way of reducing the size of the matching space, which drastically reduces
loading. Other possible avenues for performance enhancement might include the extension of
compact policies to cover all resources, and the use of binary xml.
3.2 APPEL specification issues
There are a number of reasons why we believe APPEL is currently inadequate from a logical
inference point of view and for handling complex HTML pages with embedded resources.

3.2.1 Ambiguity of logic inference system

At present it is possible to write 2 semantically equivalent P3P policies, one of which will be
blocked by a given rule and the other which will not. This is clearly unacceptable.

Take for example, following rule which looks for any information which is not the user's email
or web site address and blocks resources which ask for it.
<appel:RULE behavior="block">
<p3p:POLICY>
<p3p:STATEMENT>
<p3p:DATA-GROUP connective="non-and">
<p3p:DATA ref=" #user.home-info.online.uri"/>
< p3p:DATA ref=" #user.home-info.online.email"/>
</p3p:DATA-GROUP>
</p3p:STATEMENT>
</p3p:POLICY>
</appel:RULE>

This RULE will cause a block behavior for the following web site policy (only relevant parts
quoted)
<POLICY>
<STATEMENT>
<DATA-GROUP>
<DATA ref="#business.contact-info"/>
<DATA ref="#Dynamic.HTTP.UserAgent"/>
</DATA-GROUP>
</STATEMENT>
</POLICY>

but not for this one

<POLICY>
<STATEMENT>
<DATA-GROUP>
<DATA ref="#business.contact-info"/>
</DATA-GROUP>
</STATEMENT>
<STATEMENT>
<DATA-GROUP>
<DATA ref="#Dynamic.HTTP.UserAgent"/>
</DATA-GROUP>
</STATEMENT>
</POLICY> 7
Note the presence of the "non-and" connective in the rule, which means - "only if not all sub-
elements are present in the sub-elements of the matched element in the policy. This is true for the
first policy snippet but not the second, which is clearly unacceptable. As we suggest below, we
believe the solution to such problems with APPEL lies in moving to an RDF based
implementation.

3.2.2 Expressive inadequacy of logical connectives

The problem of ambiguity outlined above is just one example of the inadequacy of the logical
system contained within APPEL.
One of our lines of research will shortly be in bi-lateral negotiation systems. This will require a
much more sophisticated capability in terms of logic and inference. For instance we would like to
be able to express the following: if the privacy policy says it will retain my information
"indefinitely", try changing this to "for the stated purpose only" and send the policy back to see if
the server's logic engine will agree to this in exchange for the same services.

At present, APPEL contains only the ability to match arbitrary sub-trees and is not well suited for
such inferences.

Move to an RDF based rule system.

Any rule system which is able to match the full range of possibilities specified by P3P is by
definition going to be as complex as P3P. We do not therefore believe that trying to simplify
APPEL is the answer.

Instead, rather than putting much more effort in to complete what is now a very immature
specification, it is better to make use of a standard which already has much more development
time behind it. The solution is to move APPEL into an RDF [RDF1999] based system. We cite
the following reasons for this:

• P3P has already been translated into an RDF schema and the consensus of the working group
is that the next version of P3P should be expressed entirely in RDF.
• RDF is ideally suited to intelligent rule matching algorithms as it is able to express very rich
semantic structure.
• RDF is well suited to expressing natural language statements such as "this site will retain
your information indefinitely" and to using such statements in intelligent inference engines
such as rule matchers.
• The RDF community is already rich with Rule matching systems such as ruleML
[ruleML2000] which have been assessed by a very wide community. RDF is therefore the
perfect candidate for such a system.
• RDF has been designed from the bottom up for exactly this kind of purpose.

The details of this development are beyond the scope of this paper.

3.3 P3P and EU data protection legal compliance issues

One of the most pressing questions for P3P in the context of the on-line business sector is the
degree to which the P3P standard is able to support or comply with the European data protection
legislation. There are three important issues in this regard:

1. Is P3P able to provide support for e-commerce providers who wish to implement personal
data handling practices in an EU compliant way?

8
2. Can P3P permit end users to express their privacy preferences as a statement of their rights
under EU legislation?
3. How will P3P operate in transborder environments where the privacy legislation may change
to reflect member state individual interpretations of the EU directives or across global borders
outside of the jurisdiction of the EU directives?

The issue of EU compliance for e-commerce providers is complex. The EU Directives set out
principles of transparency for data collection, which include concepts such as purpose
specification, collection minimization and purpose limitation. The EU directives do not make
any specific reference to the role of Privacy Policies, which of course is the focus of the P3P
standard. Clearly, Privacy Policies can contribute to the task of informing users of the data
processing practices of a web site, and of defining the purposes of data collection and subsequent
usage. To this extent, by automating the exchange of privacy policies, P3P can support a web site
in specifying its practices to be EU compliant. However, there are some key pragmatic issues
that are not yet clear in regard to P3P’s compliance. The directives state that information as to
purpose of data collection and usage should be declared at the point at which data is collected, so
that end users are explicitly informed at the moment of data submission. P3P does not, by
default, operate in this mode. There is no explicit statement, rather it is implicit in the agreement
reached by the APPEL parser during the exchange of the privacy policy and a user’s ruleset. As
such privacy policies do not go far enough in meeting the requirements of the EU directives,
unless they are expressed and exhibited explicitly at the points of data collection. There is nothing
in principle to stop P3P doing this, but it is not the currently envisaged model for its deployment.

The second issue is the expression of a user’s preferences in a way that reflects their rights
granted under EU data protection legislation. In this respect , P3P can play a useful role, and in
the course of our implementation activities we have in fact produced a Ruleset that reflects all of
the principles of the EU directives. The APPEL language used to create the Rulesets is
sufficiently flexible and expressive to facilitate this. Although it would be beyond the capabilities
of most consumer users to define such a Ruleset, there is nothing to prevent them downloading a
default EU Ruleset from a local agency, such as the member state Data Protection Agencies. Our
EU ruleset was produced and edited using the APPEL Rulset editor tool developed within the
project. With the EU Ruleset configured for the P3P proxy server, we visited a large number of
the websites that are currently advertised as P3P compliant. We observed that almost every site
failed to comply with the preferences expressed in the Ruleset. Whilst this may initially be seen
as a very negative result, it does have some positive implications. What it shows is that by virtue
of its unambiguous transparency, P3P will bring such issues much more out into the open. In
order to compete in an internet environment where P3P is used, companies will be forced to state
unambiguously what their practices are , and end-users, whether consumers or Data Protection
Auditors will be able to see almost instantly those whose privacy policies are not conforming to
the EU Data Protection Legislation.

The third issue of cross global border browsing is not so much a technology issue but more of a
policy issue. If users wish to express their privacy preference in terms of the EU directives it is to
be expected that they will not find sites that are compliant outside of the EU. End users need to
be aware of this fact, and should be clearly educated that their privacy rights may vary
significantly if they wish to browse or participate in e-commerce outside of the EU. P3P can
have a role to play here by rapidly identifying sites which do not meet EU regulations, as
described above. However, it may be that end users will also need some mechanisms within their
browsing environment to dynamically configure their privacy preferences to allow them to
browse on web sites outside of EU borders using a different Ruleset. The P3P standard does not
currently specify this, but it is an issue that relates more to the definition of P3P browser
integration, than with the standard itself.

9
4 Current limitations and outlook concerning end user assurance
With the increasing prominence of the P3P standard, the number of standardised machine
readable privacy policies is increasing and, in fact, may well become a standardised practice
when the P3P version 1.0 specification reaches stability. However, there are still a number of
outstanding problems related to enforcement of the privacy policies and in particular related to
assuring the integrity and non-repudiation of these policies.
4.1 P3P Examples of Risk Scenarios
In order to clarify the problem space, we now provide the following three scenarios to describe
how the P3P process might be abused, to the detriment of both end users and commercial
organisations:

Scenario 1. I receive a large amount of unsolicited email from various sources unknown to me,
despite the fact that I only ever give my email address away to sites whose P3P policies promise
only to use my email address to carry out the stated purpose of the transaction. I seek to take
legal action using the P3P policy which was available on one of the offending sites at the time I
made the transaction, as evidence. The corporation I am suing denies that it published this policy
at the time I sent my details. I have no way of proving what Privacy Policy was published at the
time and as a consequence my legal action is not successful.

This example highlights up two specific repudiation issues in regard to the deployment of P3P:
1. If a user cannot prove that a company published a specific privacy statement, then a privacy
policy is of limited benefit to him/her in pursuing a legal action;
2. (An issue we do not have space to address here) If a user cannot prove the source of a loss of
privacy then any number of assurances are of limited benefit to him/her.

Scenario 2. I am a corporation and hacker X replaces my P3P policy with a policy stating that I
will not give away email addresses to third parties. I do not notice this for 3 months and in the
meantime give away 10,000 email addresses which were taken on the basis of a policy stating
that I would not give away email addresses to third party. I am sued by 100 of them, and as a
result go out of business.

This example shows that assuring the integrity of polices may not only be useful to end users but
also to commercial organisations.

Scenario 3. A possible extension to P3P is to include bi-lateral negotiation which allows the end
user to trade losses of privacy (and changes to the P3P policy) for services or goods. This is also
mentioned in the current W3C APPEL P3P privacy preference language specification [W3C
APPEL] as a possible route for extending the protocol. One possible specification of this type of
extension is treated in detail by R.H.Thibadeau [Thib2000]. One scenario which arises from this
inclusion of bi-lateral negotiation is the following:

Private individual x’s computer negotiates with server Entity y, according to the proposed P3P
negotiation protocol. Private individual x agrees to give away his email address if and only if
server y assures him that it will not be given to third parties. Later Private individual x discovers
that Server Entity y has in fact given his information away to a third party. Server Entity y claims
that he did not make such an agreement and an unresolvable dispute follows.

This example shows that policies which need to be assured may not always be fixed documents,
but may be produced dynamically as part of a bilateral negotiation process, hence requiring more
care in the consideration of loading on servers.

10
4.2 Extensions to the P3P Specification to deal with assurance issues.
In the following sections we discuss extensions to the P3P standard which could provide it with
more enforcement rigour, and consequently provide greater assurance.

It should be noted however, that any modifications to the P3P standard need to take into account
the constraints imposed by the computing environment of end-users. This often includes a low
bandwidth network environment and low-to-mid range PC platforms, particularly in the European
context. They also need to be accommodate the fact that although end-users are keen to protect
their privacy, they are also unwilling to accept computational overheads that might interrupt the
flow of their browsing experience.

4.2.1. Non-repudiatable Privacy Policies via P3P

One of the principle problems we have found in the standard is that if a company’s practices in
the processing of personal data contravene its stated privacy policy, there is currently little
technical framework to prove that a company made the statements which may have existed on its
web privacy statement at a given time. In other words, it is very easy for a company to repudiate
its policy.
At present, P3P does increase the level of trust felt by consumers by providing more transparent
and unambiguous information, it does not however provide any assurance as to the authenticity
and integrity of this information.
XML signatures offer a coherent solution to the problem of making a policy at a given URI non-
repudiatable. The problem of how to make a privacy policy non-repudiatable is ideally suited to
the application of digital signatures. XML signatures are an obvious candidate solution for this
task.

XML signatures, provide the opportunity to introduce assertions such as "X assures the content of
this document" into the semantics of signed material. Also since P3P is entirely expressed in
XML, it is pragmatic to use the XML version of asymmetric digital signatures to provide this
assurance. The following section defines in detail how this might be achieved.

We examine and build upon the proposals of Reagle [Reagle2000] for the inclusion of XML
digitally signed [XMLDigSig] policies within the P3P standard. As Reagle has already set out
most of the mechanisms for achieving this, we make only three minor additions to the technical
specification. Our main aim is to look at possible technical problems with the use of the XML
signature extension, and to provide pragmatic solutions.

XML Digitally Signed Policies.

P3P enabled servers could have the possibility of providing an XML digital signature as part of
their policy, or as a separate document referenced within the policy. This is easily accomplished
provided that the correct syntax is incorporated into the P3P specification, as shown by Reagle.
We provide an example, see Annexe 1, adapted from Reagle, which we have extended in the
following ways:

a) By using a PKI based X.509 certificate bag in order to assure interoperability in certificate
and PKI schemes. This is now included, as well as a timestamping.

b) By including a signature bound to the Policy Reference File, which details which resources
the policy applies to. Any signature that does not assure this information loses much of its
legal significance.

11
4.2.2. Computational Overhead in Processing Signed Policies.
The P3P process involves the exchange and processing of privacy preference files written in
XML. Consequently, any increase in the complexity of the policies, such as the proposed
addition of digital signatures, implies an increase in the computational overhead (processor
loading) for processing the data. The processor loading may occur at both the server and client.

In terms of the server, the additional processing can be considered as negligible. There is no
dynamic load on the server from the encryption processes involved in producing the signature.
This is because the Privacy Policy statement is usually static (that is, a site’s privacy policy does
not change regularly) hence the digital signing process only needs to be carried out once, either
when a new policy is created or edited. Once digitally signed, the policy signature can be stored
and accessed on a web site with no further processor load than is the case with a standard XML
privacy policy.

In the case of the client there is a more significant computational overhead, as the burden lies
with the client to verify the policy files that are received from a remote server. Whilst assessing
test cases, we have observed that signing and verification operations for a client, using a typical
and representative desktop PC, are of the order of 100ms. In isolated cases, this additional
processor load is acceptable, as it will have minimal impact on a user’s on-line browsing
experience.

However, there are certain scenarios, which could theoretically lead to the processor leading
becoming a significant issue for both the server and the client. For example:

• If the client had to handle multiple policies, assigned to different resources within a web
site, then it could make the browsing process unacceptably slow. For example a page
might require the client to verify signatures from several different sources to handle the
embedded resources within the page.
• Conversely, for servers with high traffic loads, if there is an additional http request to a
signature resource with every http resource requested, then the additional load becomes
significant.
• In the case of bi-lateral negotiated policies, some form of intermediary filtering is an
essential component in the process. In this case, P3P policies could be dynamically
altered to suit the user's preferences. In extreme scenarios, this could lead to a different
policy being sent for every resource accessed. The resultant load on the server caused by
requiring it to generate a new signature for every resource accessed (by every client)
would be a processing bottleneck.

Fortunately, there is a pragmatic way in which the above issues can be constrained, to limit the
number of times such operations would have to be carried out (both on the server, and the client),
using the APPEL [APPEL2001] P3P preference matching protocol (as developed by W3C to
process privacy preferences). It is therefore useful to look at how more selective retrieval of
signed policies might be achieved using APPEL.

Figures 4 and 5 provide a diagrammatic overview of the APPEL matching process. Figure 5
describes our proposed extension to the process.

12
 2.Limit
2. User Agent
Parses out 6. Parse and
1. User Validate Policy 1. Appel Resource
Location of 3.Request Returned to
Requests Evaluator
Policy User
Page
4.Block
‘No Policy’ Parse or
Error Validation
Error

Figure 4: APPEL CURRENT VERSION BASIC PROCESS FLOW

2.Limit
2. User Agent
Parses out 6. Parse and
1. User Validate Policy 1. Appel Resource
Location of 3.Request Returned to
Requests Evaluator
Policy User
Page
4.Block
‘No Policy’ Parse or
Error Validation
Error 6. Signature
Exists

7.Block

Figure 5: APPEL PROPOSED EXTENSION PROCESS FLOW.

In the basic version (Figure 4), a P3P policy is retrieved and matched against an XML preference set
according to the APPEL protocol. Once this matching process has been carried out, there are only 3
basic outcomes:
• (4.) page block
• (3.) page request
• (2.) page request with http header limitation.

Each of which can be optionally authorized by a user prompt. For example the following is an
expression of such a rule in XML.

<appel:RULE prompt="yes" promptmsg="This resource does not specifiy any access rights to
submitted data, do you wish to proceed" behavior="block">
<p3p:POLICY appel:connective="non-or">
< p3p:ACCESS/>
</ p3p:POLICY>
</appel:RULE>

which in plaintext means:

13
“if the policy doesn’t specify the user can access his data once it has been sent to the entity, then block
the HTTP request, but get the user's consent first.”

Reducing Signed Policy Processor Loading in P3P

Although it is not currently included, it would be very easy to extend this syntax to solve the problem
of loading and redundancy in an automated privacy environment. In the extended version (Figure 5), an
extra but OPTIONAL decision step has been added (6.) which may lead either to a page block (7.) in
the case of an invalid or non-existent signature, or to the continuation to the standard behaviors (8,9,10).
This again may be automated or may involve input from the user in the form of a prompt (for example -
"this page does not have a valid signed policy - do you wish to proceed").

We suggest that with the addition of a signaturerequired attribute to the rule element, preference
matching rules could be built like this:

<appel:RULE prompt="no" behavior="request" signaturerequired="yes">

<p3p:POLICY appel:connective="and">
< p3p:ACCESS/>
</ p3p:POLICY>
</appel:RULE>

Such a rule would then state in plaintext:

"If the agent finds a statement regarding how I will access my data after it has been sent to the entity,
require that there exists a valid XML signature for the policy, retrieve it and store it."

This change has the effect of reducing processor loading and network traffic. It also makes it easier to
retrieve signatures when needed because the user stores only those signatures deemed necessary.

Signing of Policy Reference Files

The P3P process has 2 main components on the server; an XML policy and an XML policy reference
file which binds policies to resources. The policy reference file, like the policy has a validity timestamp.
The P3P statement about a resource is therefore a combination of the policy and the reference file
which binds the policy to the resource at a given time.

Reagle’s P3P extension does not include any binding signature for the P3P policy reference file. This is
an oversight, because the omission of this signature binding the policy with the resource it applies to
negates the non-reputability of the policy file itself.

The importance of the policy reference file cannot be ignored. We have shown, however, in the
example signature (Annexe 1) the necessary XML extensions to permit a digital signature to be bound
to the policy reference file.

4.2.3. Hash Storage: An Alternate Approach.

Due to the fact that the infrastructure for digital signature is still some way from maturity, it could be
argued that the use of XML signatures to ensure non-repudiation of privacy policies in P3P is an overly
complex solution. Legal precedents already exist for far less rigorous evidence such as printed web
pages, server logs and unsigned electronic records being used as evidence in court. Hashing is a simpler
alternative to digital signatures for P3P. The following is an outline of a method, based on hashing,
which could be used to provide a less watertight form of evidence for privacy agreements.

1. P3PAssure.org is a trusted third party which holds a copy of a hash of privacy critical resources,
policies and PRF files, sent to it voluntarily or otherwise, by any number of businesses.

14
2. BeMadToTrustUs.org is a business venture which takes credit card details and publishes them on a
web site accessible to all public search engines.

Whenever BeMadToTrustUs.org creates a new privacy policy, a new Privacy critical resource or a new
policy reference file, it sends a copy to P3Passure.org, which stores a hash of them in a database along
with a validity timestamp. If a user wishes to gain assurance of the validity of a policy against a
resource, they must note that the Policy refers to P3Passure.org as the Assurer, he/she decides to trust
P3Passure.org and stores the policy.

At a later date BeMadtoTrustUs.org publishes the user’s credit card details on the Internet despite
assurance in their P3P policy that they would not. They also deny in court that their P3P policy said any
such thing. In order to provide evidence in the legal action, the user must simply provide a copy of the
hashes whose authenticity is guaranteed by P3Passure along with the policy which produced them.

This non-repudiation system requires the following:

1. XML Canonicalization of P3P policies and Policy Reference Files (using, for example the
C14N algorithm [C14N]) .
2. Non-ambiguity of URI strings.
3. PKI like assurance infrastructure for assuring organizations. We suggest that this requirement
would probably make this solution impractical.

It should be noted that the storage of the hashes by the party himself or by a non-trusted third party
would not be permitted - since it as easy to produce a hash of a faked document as it is to produce one
of a real document.

5 Conclusion
The issuing of the P3P standard has been a great boost to the protection of privacy on the Internet. A
full implementation of the P3P standard and a neutral platform for its evaluation allows the privacy
community to assess P3P. So far, we have identified a number of challenges on the road to this standard
becoming fully mature:
• Creation of an easy to use interface for creating privacy preference sets which will be useful to both
the ordinary user and the expert user.
• Creation of a new language for the storage of privacy preferences which solves the problems
inherent in the current APPEL specification, namely inadequate logical expressivity and ambiguity.
• Solution of performance problems presented by an implementation which is faithful to the standard.
• Continuous evaluation of the use of P3P for enhancing compliance of privacy practices with EU
privacy regulation and other regulatory initiatives.
• Data flow and consumer confidence on the Internet is severely hampered by privacy related factors
which can easily be addressed. The lack of trust in privacy policies, and the lack of established
mechanisms for legal recourse based on the policies, are issues which can be addressed by
extensions to the P3P standard. One practical extension, which has been discussed in detail, is the
application of XML digital signatures. The lack of a clear legal route for the ordinary citizen in the
face of privacy violations, may be solved by using XML digital signatures within the framework of
P3P in combination with mechanisms for automatic selection of which resources might require such
evidence. Although 3rd party hash storage would probably be sufficient within the current legal
framework, we suggest that the establishment of the required hash storage infrastructure is
impractical.

6 References
[NCL2000] Harris Poll carried out for National Consumer League of America October 2000 - see
http://www.nclnet.org/pressessentials.htm

15
[RDF1999] RDF Specification. Resource Description Framework (RDF) Model and Syntax
Specification http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/

[W3C2001] The Platform for Privacy Preferences 1.0 (P3P1.0) Specification

W3C Working Draft 28 September 2001, http://www.w3.org/TR/2001/WD-P3P-20010928

[GVU2001] WWW Survey 2001, Graphics,Visualization, & Usability Center,

http://www.cc.gatech.edu/gvu/wwwinit/survey.html

[APPEL2001] A P3P Preference Exchange Language 1.0 (APPEL1.0), W3C Working Draft 26
February 2001, http://www.w3.org/TR/2001/WD-P3P-preferences-20010226

[Reagle2001] Joseph Reagle, A P3P Assurance Signature Profile, W3C Note 2,

February 2001, http://www.w3.org/TR/xmldsig-p3p-profile/

[Thib2001] Thibadeau, Robert. 2001 “Privacy Science” see

http://yuan.ecom.cmu.edu/psp/privacy2001.ppt. Paper presented at the European Commission
Workshop on Privacy and Identity in the Information Society: Emerging technological challenges,
October 4-5, Brussels, Belgium. See also http://yuan.ecom.cmu.edu/psp/ .

[W3C2002] The Platform for Privacy Preferences 1.0 Deployment Guide

http://www.w3.org/TR/p3pdeployment

[Scribbins 2001] Scribbins, K., “Should I Buy? Shopping online 2001: An international
comparative study of electronic commerce”, Consumers International,
http://www.consumersinternational.org/CI_Should_I_buy.pdf , ISBN 1902391365, 2001.

[Berthol 2000] Berthol, O and Marit Köhntopp, M. “Identity Management Based On P3P”,
presented at the Workshop on Design Issues in Anonymity and Unobservability. Available from
http://www.w3.org/P3P/

[ruleML 2000] International XML rule language initiative, home page http://www.dfki.uni-
kl.de/ruleml/

[XMLDigSig] XML Digital Signatures - W3C Recommendation

http://www.w3.org/TR/xmldsig-core/

[C14N] Exclusive Canonical XML - W3C Candidate Recommendation http://www.w3.org/TR/xml-

c14n

16
Annexe 1: Sample XML signature of P3P policy

<Signature Id="Signature1" xmlns="http://www.w3.org/2000/09/xmldsig#">

<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000907"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference URI="http://www.example.org/p3p.xml">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000907"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
<Reference URI="#Assurance1" Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>1342=-0KKAASIC!=123Adxdf</DigestValue>
</Reference>
<!-- Reference over signature policy to comply with EU directive -->
<Reference URI="http://www.example.org/signaturePolicy.xml">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>1234x3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
<!-- Reference over Time Stamp to comply with EU directive -->
<Reference URI="#TimeStamp1" Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>

<!-- Reference over Policy Reference file-->

<Reference URI="#PolicyReference" Type="http://www.w3.org/2000/09/xmldsig#SignatureProperty">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
<KeyInfo>
<X509Data>
<X509IssuerSerial>
<X509IssuerName>CN=Smith John, OU=TRL, O=IBM, L=Example, ST=Ex-ample,
C=</X509IssuerName>
<X509SerialNumber>
12345678
</X509SerialNumber>
</X509IssuerSerial>
<X509SKI>
31d97bd7
</X509SKI>

</X509Data>
<X509Data><!-- single pointer to certificate-B -->
<X509SubjectName>Subject of Certificate B</X509SubjectName>
</X509Data>
<X509Data> <!-- certificate chain -->
<X509Certificate>MIICXTCCA..</X509Certificate>
<X509Certificate>MIICPzCCA...</X509Certificate>
<X509Certificate>MIICSTCCA...</X509Certificate>
</X509Data>
</KeyInfo>
<Object>
<SignatureProperties>
<SignatureProperty Id="Assurance1" Target="#Signature1" xmlns="http://www.w3.org/2000/09/xmldsig#">
<Assures Policy="http://www.example.org/p3p.xml" xmlns="http://www.w3.org/2001/02/xmldsig-p3p-profile"/>
</SignatureProperty>
<SignatureProperty Id="TimeStamp1" Target="#MySecondSignature"> <timestamp xmlns="http://www.ietf.org/rfcXXXX.txt">
date>19990908</date> <time>14:34:34:34</time> </timestamp> </SignatureProperty>
</SignatureProperties>
</Object>
</Signature>

17
 Annexe 2: APPEL Ruleset for an example user privacy preference consistent with EU data
protection directive

<?xml version="1.0" encoding="UTF-8"?>

<appel:RULESET xmlns:appel="http://www.w3.org/2001/02/appelv1" xmlns:p3p="http://www.w3.org/2000/12/p3pv1">
<appel:RULE behavior="block" description="Any marketing must be opt-in with prompt|Data-Type|Any" prompt="yes" promptmsg="Your
privacy agent has detected a site which will use your data for marketing if you agree to it - do you want to go to this page">
<p3p:POLICY>
<p3p:STATEMENT>
<p3p:PURPOSE appel:connective="or">
<p3p:telemarketing required="opt-in"/>
<p3p:contact required="opt-in"/>
</p3p:PURPOSE>
</p3p:STATEMENT>
</p3p:POLICY>
</appel:RULE>
<appel:RULE behavior="block" description="No compulsary marketing" prompt="no">
<p3p:POLICY>
<p3p:STATEMENT>
<p3p:PURPOSE appel:connective="or">
<p3p:telemarketing required="always"/>
<p3p:contact required="always"/>
</p3p:PURPOSE></p3p:STATEMENT></p3p:POLICY></appel:RULE>
<appel:RULE behavior="block" description="Blocked because site will use your information for marketing purposes on an opt-out basis."
prompt="no">
<p3p:POLICY>
<p3p:STATEMENT>
<p3p:PURPOSE appel:connective="or">
<p3p:telemarketing required="opt-out"/>
<p3p:contact required="opt-out"/>
</p3p:PURPOSE></p3p:STATEMENT></p3p:POLICY></appel:RULE>
<appel:RULE behavior="block" description="Blocked because you cannot access all your data after submitting it" prompt="no">
<p3p:POLICY>
<p3p:ACCESS appel:connective="non-and">
<p3p:all/><p3p:nonident/>
</p3p:ACCESS>
</p3p:POLICY>
</appel:RULE>
<appel:RULE behavior="block" description="Site will retain information collected by this resource beyond what is necessary to carry out the
stated purpose" prompt="no">
<p3p:POLICY>
<p3p:STATEMENT>
<p3p:RETENTION appel:connective="non-and">
<p3p:stated-purpose/>
</p3p:RETENTION></p3p:STATEMENT></p3p:POLICY></appel:RULE>
<appel:RULE behavior="block" description="Require identity and physical address of controller" prompt="no">
<p3p:POLICY appel:connective="non-or">
<p3p:ENTITY>
<p3p:DATA-GROUP>
<p3p:DATA ref="#business.contact-info.postal.street"/>
<p3p:DATA ref="#business.contact-info.postal.city"/>
<p3p:DATA ref="#business.contact-info.postal.stateprov"/>
<p3p:DATA ref="#business.contact-info.postal.postalcode"/>
<p3p:DATA ref="#business.contact-info.postal.country"/>
</p3p:DATA-GROUP>
</p3p:ENTITY>
</p3p:POLICY>
</appel:RULE>
<appel:RULE behavior="request" description="Passed all rules and final check on disclosure to countries outside EU which don't follow the
same practices and if they do, Access rights must be stated." prompt="no">
<p3p:POLICY>
<p3p:STATEMENT>
<p3p:RECIPIENT appel:connective="or-exact">
<p3p:ours/>
<p3p:delivery/>
<p3p:same/>
</p3p:RECIPIENT>
</p3p:STATEMENT>
</p3p:POLICY>
</appel:RULE>
<appel:RULE behavior="block" description="Default Rule fired"><appel:OTHERWISE/></appel:RULE></appel:RULESET>

18
Annexe 3: Example of a Web site privacy policy complying with the principles of the EU data
protection directive
<?xml version="1.0"?>
<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
<EXPIRY max-age="604800"/>

<POLICY
discuri="http://p3p.jrc.it/modelsite/htmlpolicies/officialpolicy.html"
opturi="http://p3pproxy.jrc.it:1080"
name="mainpolicy">
<!-- Description of the entity making this policy statement. -->
<ENTITY>
<DATA-GROUP>
<DATA ref="#business.name">Joint Research Center</DATA>
<DATA ref="#business.contact-info.postal.street">Cybersecurity
TP 361
Via Enrico Fermi 1</DATA>
<DATA ref="#business.contact-info.postal.city">Ispra</DATA>
<DATA ref="#business.contact-info.postal.stateprov">Lombardia</DATA>
<DATA ref="#business.contact-info.postal.postalcode">21020</DATA>
<DATA ref="#business.contact-info.postal.country">Italy</DATA>
<DATA ref="#business.contact-info.postal.organization">Giles Hogben</DATA>
<DATA ref="#business.contact-info.online.email">giles.hogben@jrc.it</DATA>
<DATA ref="#business.contact-info.online.uri">http://p3p.jrc.it</DATA>
</DATA-GROUP>
</ENTITY>
<!-- Disclosure -->
<ACCESS><all/></ACCESS>
<!-- No dispute information -->
<!-- Statement for group "General clickstream data" -->
<STATEMENT>
<!-- No consequence specified -->
<!-- Data in this statement is marked as being non-identifiable -->
<NON-IDENTIFIABLE/>
<!-- Use (purpose) -->
<PURPOSE><current/></PURPOSE>
<!-- Recipients -->
<RECIPIENT><ours/></RECIPIENT>
<!-- Retention -->
<RETENTION><stated-purpose/></RETENTION>
<!-- Base dataschema elements. -->
<DATA-GROUP>
<DATA ref="#dynamic.clickstream"/>
<DATA ref="#dynamic.http"/>
</DATA-GROUP>
</STATEMENT>
<!-- End of policy -->
</POLICY>
</POLICIES>

19