-
The Web provides di erent ways to communicate and perform activities that
vary from simple to sophisticated: using forums on websites, online shopping,
orchestrating Web Services. All of them involve processing data about the user,
be it technical (e.g., the version of the user's browser or the IP address) or
personal information (name, address, gender, credit card number, etc.). In order
to give the user control over their data on the Web, P3P, the Platform for
Privacy Preferences, [
5
] was o cially recommended by the World Wide Web
Consortium in 2002. P3P is a language and a protocol allowing websites to
describe data practices: what data is collected, what for, how long it will be
stored and what parts of the data are exposed to other parties. These policies
are declarative and non-executable, which leads to the topic of presented work:
How to make Web-based systems comply with declared policies? How to make
systems policy-aware?
2.1
Work
Previous Attempts at P3P Enforcement
Agrawal et al. [
6
] proposed translating a P3P policy into a set of restrictions in
relational database management system (RDBMS) on the level of columns, rows
or cells, provided that a user query would contain information about purpose
and recipient. This approach requires the support from database producers, since
it proposes new language constructs and implementation design for ne-grained
access control.
Ashley [
7
] suggested implementation of an external policy framework that has
integration points (Privacy Monitors) between the Privacy Server that contains
policies and the application environment. This approach uses Reference Monitors
(see below).
IBM developed Tivoli Privacy Manager [
1
] and related technologies: the
Declarative Policy Monitoring [
8
] and Reference Monitor [
12
], but the Privacy
Manager was withdrawn from marketing in 2009 [
2
] and corresponding
technologies have been retired.
In the work of Hayati and Abadi [
10
] the authors develop a language-based
approach for modeling and verifying aspects of privacy policies. They use the
programming language Jif [
4
], an extension of Java with information- ow types,
to show how to prevent leaks of the data from the system and how to implement
P3P notions of purposes and retentions. However, this work does not cover all
aspects of the P3P language, e.g., base/custom data schemes.
2.2
P3P as an Intermediate Representation
Karjoth et al. [
13
] proposed the Platform for Enterprise Privacy Practices
(EP3P), which uses P3P to present a coarser-grained privacy policy to the
customer, while for internal enforcement a new language is suggested.
In the work of Salim et al. [
17
], P3P policies are used as an intermediate
level between the extended Digital Rights Management model and the user,
because P3P preferences are more abstract than a license and it's easier for data
owners to specify the purposes for which data is to be collected. In the end, P3P
preferences are transformed into MPEG REL (Moving Picture Expert Group
Rights Expression Language) licenses that can be enforced by the framework.
2.3
General Solutions to Policy Enforcement
He and Anton [
11
] propose a framework to bridge the gap between high-level
privacy requirements and low-level access control policies by modeling privacy
requirements in the role engineering process. The framework provides a basis for
enforcing privacy requirements with RBAC (role-based access control) model.
The work does not address any high-level privacy requirements language in
particular, though, uses P3P elements (e.g., purpose) as an example of standard
privacy policy entities.
Mont et al. [
15
] introduce a notion of \sticky policy" in order to prevent
leaking of personal information. The proposed privacy model involves Tracing
Authorities as a main point to log and audit the disclosures of con dential data
as well as to notify the owner of the data. Such a model requires a request to the
Tracing Authority each time when a service wants to transfer the data outside.
Ringelstein and Staab [
16
] introduce a notion of \sticky logging" in order to
collect di erent kinds of data usage (create, copy, read, update, transfer, delete)
in distributed environments. This allows to reconstruct the execution afterwards,
which might be useful, if the customer requests the report about data usage.
This work does not directly address any kind of compliance of a reconstructed
execution with existing privacy policies of a system.
3
Proposed Solution
The relation between the system and the policy can be twofold.
One case is that a P3P policy is created for the existing system by analyzing
the behaviour of the system and translating it into the P3P language. This means
that a P3P policy can be seen as a by-product of the system and ideally could
be generated from the system.
The second case is that a P3P policy exists before the system. This means
that a P3P policy can be seen as a speci cation of the system or as additional
constraints at the modelling phase of the system.
While these scenarios are polar, we hope to bridge them in practical
experiments (for more details see Section 4). In the end, we aim to develop
language support for describing policies as part of the programming e ort: that is,
a policy-aware programming language supporting idioms for expressing
policyrelated constraints. We see this language as a simpli ed, idealized language or
calculus, similar to other language design e orts that use Featherweight or
Classic Java.There may be the following language constructs for privacy awareness:
annotations of the data model with the privacy-related categories; annotations
of persistence actions with duration or access information; annotations of service
calls so that sharing of data is classi ed.
4
Research Method
We started our research with an empirical study of P3P policies in the wild [
14
].
We believe that an empirical study of the language at hand is an important
stage of working with the language. While one can start from the speci cation
of the language and try to devise a solution top-down, it can be the case that
some combinations of language elements/constructs are seldom or never used,
inadequate in practice, or even contradictory [
18, 14
].
For example, we've found out, that even with low P3P usage { for the seed
of 1,450,660 URLs, we were able to download only 4,158 XML les with P3P
policies1{ the coverage of the base data schema proposed in P3P speci cation is
76%. In other words, the language is used to its full extent and there can be no
short-cuts in our e ort.
Now that we know the shape of P3P policies, we can start with a realistic
and interesting case study to guide the development of a prototype system. This
is our plan of attack:
{ First, we consider a typical lightweight architecture for a Web-based
system: persistence layer, domain-speci c logic, presentation layer and,
optionally, Web Services. At this point we have decided to dedicate ourselves to
Java Pet Store [
3
], a sample Web application, designed to run on the Java
Enterprise Edition 5 platform. While this application has all technical
aspects highlighted above, it also suggests non-trivial information ow issues
(see Fig. 4). We intend to put some developing e orts into the system in
order to make it complete w.r.t. those issues.
1 Please, note, that this low usage is partially because our approach used one seed of
URLs (Google Directory). Cranor et al. [
9
] found that P3P had been deployed on
10% of the sites returned in the top-20 results of typical searches, and on 21% of the
sites returned in the top-20 results of e-commerce searches.
buyer's payment
through paypal
mark item in the catalog
as reserved
buy an item
pet store receives
payment email
[payment accepted]
send email to seller
with meeting point
send email to buyer
with meeting point
meet all parties
at meeting point
seller hands out the
item to buyer
pet stthoeremhoannedys out
marked the item in the
catalog as sold
(a) The scenario
Does PayPal get the buyer's contact information?
Does PayPal get the seller's contact information?
Does the seller get the buyer's contact information?
Does the buyer get the seller's contact information?
Is the contact information deleted upon purchase
completion?
(b) Interesting questions about information ow
<STATEMENT>
<PURPOSE><current/></PURPOSE>
<RECIPIENT><ours/></RECIPIENT>
<RETENTION><indefinitely/></RETENTION>
<DATA-GROUP>
<DATA ref="#user.name"/>
<DATA ref="#user.home-info.online.email"/>
<DATA ref="#user.home-info.postal"/>
</DATA-GROUP>
</STATEMENT>
(c) A P3P policy (excerpt) for the seller