Ioannis Agrafiotis
email: ioannis.agrafiotis@cs.ox.ac.uk

Sadie Creese
email: sadie.creese@cs.ox.ac.uk

Michael Goldsmith
email: michael.goldsmith@cs.ox.ac.uk

Developing a Strategy for Automated Privacy Testing Suites

This paper describes a strategy to develop automated privacy testing suites to assess the correctness of consent and revocation (C&R) controls offered to users by an EnCoRe system 1 . This strategy is based on a formal language in order to provide rigorous and unambiguous consent and revocation specifications, and comprises of two novel procedures that facilitate the process of eliciting testing requirements for privacy properties and creating automated privacy-testing suites. We demonstrate the effectiveness of the strategy by describing our application of the method to a realistic case study, although space limitations preclude a complete presentation.

Introduction

The ubiquity of information systems in everyday life has increased the need of individuals to disclose personal information via the Internet, in order to acquire the benefits of today's society. Constantly evolving technologies have on one hand increased the efficiency of the services offered by enterprises, organisations and government institutions, but on the other hand have facilitated them to collect, store, process and share a huge amount of personal data. Concerns about individual privacy are growing mainly because the individuals have little or no knowledge and practical control over how their data is handled by "data controllers". (In this paper we use the term "data controllers" to describe all the parties that handle and process personal data and "data subjects" to describe the individual whose personal data is handled.) The increasing number of incidents where personal data has been lost, used for different purposes, or shared without authority [START_REF] Agrafiotis | Reaching for informed revocation: Shutting off the tap on personal data[END_REF], render the use of privacy-enhancing technologies essential for every Internet user.

Although there is no inherent definition to the term privacy [START_REF] Whitley | Information privacy consent and the 'control' of personal data[END_REF], the right to privacy has been established in many democratic societies. The difficulties in defining privacy, arise from its complex, multidimensional and context-depended notion. Privacy means different things for different people, and diverse meanings and interpretations derive from peoples' experiences and culture. The volatile notion of privacy, the adaptation of new Internet applications such as Web 2.0 and the tendency of the data controllers to use the benefits of the cloud computing, makes the need carefully to study, develop and enforce effective privacy controls for data subjects more urgent than ever.

This paper is inspired by the work undertaken for the needs of the EnCoRe project [5]. We adopt Westin's [START_REF] Westin | Privacy and freedom[END_REF] view of privacy as "the claim of individuals, groups or institutions to determine for themselves when, how and to what extend information about them is communicated to others". Based on this view, in the EnCoRe project we are working to offer the data subject C&R controls through which an individual could manage the flow of their personal data. The overall vision of the project is to "make giving consent as reliable and easy as turning on a tap and revoking that consent as reliable and easy as turning it off again" [5]. To achieve our aim we are addressing challenges at a social, legal, regulatory and technical level.

In this paper we describe a novel strategy for creating test suites to gather evidence of the correctness of the consent and revocation (C&R) controls offered by an EnCoRe system; EnCoRe delivers a range of technology and procedural controls designed to provide data subjects with C&R lifecycle management over their personal data. The strategy combines two procedures: Procedure 1 uses a novel formal language to elicit and document unambiguous requirements, see [START_REF] Agrafiotis | Applying formal methods to detect and resolve ambiguities in privacy requirements[END_REF] for discussion of the application of this language; Procedure 2 uses such formal descriptions of requirements to generate a test suite. We have used the novel formal language to formalise requirements for the EnCoRe system in two different case studies. Translating the method into machine-readable language will allow the creation of automated test suites for the EnCoRe system. We demonstrate here our novel strategy by application to an aspect of one of the EnCoRe case studies.

Our intention is to create a testing strategy that could be applied to any system required to handle the life-cycle of consent and revocation controls imposed on data. In this paper the tests are generated for the EnCoRe system.

Testing in the EnCoRe System

Our aim is to perform automated tests to ensure correctness of the EnCoRe implementation, by reference to a set of requirements derived from the project scenarios. The strategy will generate tests to assess functional requirements, specifically by focusing on ensuring that the C&R related functions behave as expected. Ultimately enabling us to gain confidence in the integrity of the EnCoRe system. Proving correctness for the EnCoRe system is "elusive" [START_REF] Fernandez | An experiment in automatic generation of test suites for protocols with verification technology* 1[END_REF] and in this strategy we focus only on privacy requirements. We do not address non-functional requirements here. 2The challenges raised in creating privacy test suites for the EnCoRe system are two-fold. They derive from the important role that the data subject has in control-ling how their personal data is handled by the system, and from the privacy issues that need to be addressed to ensure that the data will be handled in accordance with the data subject wishes expressed in the form of C&R controls.

We use a formal language to describe test requirements rather than natural language in order to provide clear and unambiguous results. This clarity is guaranteed by the existence of a mathematical semantics.

In the literature there are limited references to testing privacy properties. To our knowledge the most comprehensive privacy-testing methodology is that proposed by the Prime Project [START_REF] Casassa Mont | Privacy and identity management in europe.overview of existing assurance methods in the area of privacy and it security[END_REF], which champions the development of common criteria and privacy-protection profiles. They propose core privacy properties, well-defined within the academic community, such as: anonymity, unlinkability, unobservability, undetectability, and pseudo-anonymity. However, the assessment of these attributes is still unsuccessful. To our knowledge there are no test suites designed to assess the effectiveness of consent and revocation controls for the handling of personal data, thus we consider our test strategy to be novel.

Testing Strategy

The strategy comprises of two novel procedures. The first one aims in eliciting testing requirements based on a formal language, while the second processes the results of the first procedure to generate a list of tests in a machine-readable format suitable for automation within a test harness. We believe that functional testing goes hand-in-hand with the requirements formalisation [START_REF] Agrafiotis | Applying formal methods to detect and resolve ambiguities in privacy requirements[END_REF]. The requirements have been identified and expressed using a Hoare logic, namely the C&R logic described in that paper. The C&R Hoare logic enables us to express all the states of a system capable of handling consent and revocation controls. Actions are given in the form of triples that describe a transition from one state to another.

The testing strategy model comprises of initial states, transitions and final states. The states are identifiable, finite in number and expressed with the Hoare Logic.

According to a testing report of the British Computer Society (BCS) [START_REF]Standard for software component testing[END_REF], a strategy for testing a state transition system should specify:

-The starting state -The input to that state -The expected output -The expected final state With the C&R Hoare logic we are able to describe with clarity all the aforementioned attributes for a successful testing strategy. The desirable initial state is captured by the pre-condition of the triple, the input that triggers the transition is defined by the action and the expected final state is described in the post-condition. Outputs from the final state, are captured with the form of obligations.

In order to clarify how the requirements are expressed, we explain the notation used. Each action corresponds to a requirement of the following form: {pre-condition(rights/permissions)} action(a, b, δ)

{post-condition(rights/permissions/obligations)}

The pre-condition comprises of rights and permissions. Every right consists of a sequence of three letters. The first letter denotes the actor that pertains the specific right, the second letter describes the nature of the right (right to process data or right to share data) and the third letter denotes the data that the right applies to. The permissions are expressed in variables that constrain specific rights.

The action describes a transition from one state of the system to another and denotes the actors that participate in this transition. The first actor is the initiator of the action and the second is the actor influenced by this transition.

The post-condition, in analogy to the pre-condition, comprises of rights and permissions. In addition, it could contain obligations, which are two-folded. They are actions that need to be triggered in the future, under certain conditions or actions that should be cascaded to third parties in order for the post-condition to be completed. In the latter case, a third actor is also influenced by the transition from one state to another.

The state of the system comprises of:

-Actors, -Rights, predicates of the logic that are either true or false -A number of Consent and Revocation variables, that define the dimensions in which restrictions can be imposed on data use -The actual values of these C&R variables Each action can be triggered when the pre-condition is met and when completed could either 1. alter rights on one actor alter rights on more than one if there exists an obligation in the postcondition 2. update data 3. change variables 4. set notification rules 5. send notifications

Procedure 1: Eliciting test requirements

With the procedure illustrated below, we elicit the requirements for the testing suites. Based on the formalisation of the system's requirements, we analyse every requirement and derive the factors and the results that will define the test suites on the next procedure. More specifically, we identify the actors of the system and those that participate in the specific formalisation, we clarify the rights that are

Procedure 2: Producing test suites

The factors and results identified from the previous procedure, are used as variables that influence the creation of the test suites. In order to produce test suites we need to consider the following:

1. Verify that the pre-condition of the action is true 2. Verify that only the identified actor has been influenced from the action and not the other actors of the system 3. The rights have been altered appropriately when actions belong to the a, b and d class, data changed when actions belong to the c class and variables changed when actions belong to the e class 4. No more/less rights have been added/reduced to/from the actors 5. The values of the variables that constrain the rights are respected by actors 6. Notification was sent/ not sent to the appropriate actor after the action was completed

The test suites are designed to exercise "valid transitions" between states. Since we have formalised the final state of the system, based on Hoare rules and axioms we could test only the actions that are allowed to be triggered from that state. However, test cases may also be designed to test that "unspecified transitions" cannot be triggered [START_REF]Standard for software component testing[END_REF]. This distinction allows our testing strategy to be simple by only testing the valid transitions or more thorough by verifying that transitions prohibited by the Hoare rules, are also denied by the implementation of the system.

The test suites generated for each action of the Hoare logic provide a black box of tests, meaning that every time a specific action is triggered and the transition from one state to another is completed, the tests required to validate the correctness of such a transition will remain the same.

There are though limitations to our model. For testing sequential actions 1,2,3 leading from state A of the system to state D, the system should generate tests for each action separately, testing the transition from state A to B, from B to C and from C to D.

Concurrency of actions is another limitation. When two or more actions are triggered simultaneously, or an action is triggered before the system has reacted on a previous transition, the testing suites generated by our model should be complemented with further tests to provide efficient assessment.

Applying the Testing Strategy to a Real Case Study

The case study selected for the validation of the models and the logic is the Enhanced Employee Data Scenario [START_REF] Agrafiotis | Applying formal methods to detect and resolve ambiguities in privacy requirements[END_REF]. Our choice was informed by the fact that the management of employee data in organisations is a well-understood problem, and employees' privacy offers interesting issues in terms of managing consent and revocation controls in a context where different business, legal and personal requirements need to be taken into account. The case study describes a number of use case scenarios and elicits from these a list of requirements. We explore how we can automate the process for creating test suites to ensure the correctness of the invoking consent and revocation controls.

We have generated tests for all the different use cases of the scenario but for the purpose of this paper we will apply our strategy and develop the testing requirements for two use cases only. In the first use case, Mary (our data subject) has just been hired by a company X. In the second use case, Mary resigns from company X. These use cases provide complex situations and conflicting actions, since in the first use case Mary is consenting to the use and share of her data, whereas in the second Mary requests her data to be deleted.

Testing verifies that the interactions of the system under examination, in this particular case EnCoRe system, with the environment through "points of control and observation" [START_REF] Fernandez | An experiment in automatic generation of test suites for protocols with verification technology* 1[END_REF] conform with specifications. The specifications of the EnCoRe system, for this particular case study, have been identified and formalised in [START_REF] Agrafiotis | Applying formal methods to detect and resolve ambiguities in privacy requirements[END_REF]. We need to capture the environment of the system and according to Armando et al [START_REF] Armando | Model-checking driven security testing of web-based applications[END_REF], in order to describe the testing environment we need to define the System Under Test (SUT). The actors that use the specific EnCoRe system are defined as SUT and all the other actors are simulated by the tester. In our case study, the SUT is HR department of the X company, which is represented by the actor h in the system model. The actors Mary, Mary's boss and third parties are all simulated by the tester and comprise the environment of the system.

Mary is hired by company X

Before she starts in her new position she reports to Human Resources (HR) where she fills out various forms, including necessary health information. She signs a form agreeing to the terms and conditions which are stored by HR.

{mOδ} grant † (m, h, δ, Φ) {hLδ ∧ hP δ ∧ hS * δ}
where Φ = destination:Π ∧ ¬π ∧ purpose:p ∧ time duration:t ∧ times processed:t * and Π ⊆ {Mary's boss} , π ⊆ {third parties}and p ⊆ {internal purposes}, t ⊆ {One year -five years} and t * ⊆ {One time -100 times}

The semantics of the formalisation are: m= Mary, h= HR department, δ= health information. Π is a variable that allows the HR department to share data only with Mary's boss, π restrains the HR department from sharing Mary's data with third parties while p defines the purpose for which the data should be processed. Furthermore, there are variables describing the duration of consent, t denotes the years that data should be stored for, and t * the number of times the HR department may process the data.

All the actions performed in the system are defined by the system administrator and in this specific case study, the HR department. Thus, the options from which Mary can choose from are pre-defined by the HR department. Furthermore, all the actions may invoke changes in the rights of the actors. In the above formalisation, before the action Mary was the owner of the data. After the action, there is a transition to a state where the HR department possess the right to process Mary's data (hP δ), the right to store Mary's data (hLδ) and the right to share Mary's data(hSδ), all of which are restrained by conditions described in Φ.

Fig. 2. Transition from the initial state to the final by the grant action

By applying the first procedure, we identify the actors of the system, the rights that each actor has, the variables that restrict the rights and which rights should be altered. In essence, we elicit requirements that allows us to define the initial state, the triggering action and the final state of the system.

The actors of the system are four, namely:

1. Mary 2. HR department 3. Mary's boss 4. Third party From these actors, those implicated into the action are Mary and the HR department. The latter actor is influenced by this action. The action is part of the "grant" class and there are no obligations created. With this action the rights that are influenced are three, namely:

1. Right to collect 2. Right to process

Right to share

The data pertaining to the action is Mary's health data and the variables defined are five, namely:

1. Destination (Mary's boss) and NOT (Third parties) 2. Purpose (internal use) 3. Time of consent (Up to five years) 4. Times data processed (up to 100 times) These results are presented in the table below: We then apply Procedure 2 to the results of Procedure 1, recorded in Table 1, and produce the test requirements described in Table 2 below.

We need to verify that only the HR department has obtained the appropriate rights and that Mary's choices are enforced. Thus, we create tests to verify whether the HR department has obtained the right to collect, process and share Mary's data and if her choices (variables) are enforced. Further testing is required to examine if the HR department has obtained more rights than those mentioned and if any other actor of the system was influenced. The last tests aim at verifying that transitions prohibited in the Hoare logic are not allowed by the implementation.

Our aim is that the tests, captured in this procedure, will be produced automaticaly. There is an ongoing work to develope an algorith that, based on the logic, will create tests whenever an action occurs in the system. Furthermore, the algorith will be configured and will produce different levels of testing according to how thorough the company would like the testing procedure to be. Each row effectively describes a single test of the system: a test harness must first establish a correct system state (satisfying the pre-condition), attempt the access specified, and then observe whether the resulting system state meets the postcondition. If it does, the test is considered to be passed; if not, a failure is registered.

Of course, given all the unconstrained factors that contribute to the system state, there is no guarantee that this result is completely determined; the same test might give the opposite result in other circumstances. The role of testing within EnCoRe, however, is to contribute to evidence-gathering about the correctness of the implementation, not to be the sole arbiter, and tests passed will contribute to confidence. The testing suites are executed twice in every transition. Firstly, we test if the triggering of the action from the initial state was valid. The expected result for the tests is described in the third column of the Table 2 above. The second set of tests aim to verify that the transition has resulted in reaching the desirable final state and the result for each test is defined in the fourth column of the Table 2.

Mary Leaves the Company

Mary decides to leave the company. She wishes to revoke her consent regarding the use of her data and requires all data to be deleted.

{mOδ ∧ hLδ ∧ hP δ ∧ hSδ ∧ hRδΦ} delete(m, h, δ) {¬hLδ ∧ ¬hP δ ∧ ¬hSδ}
When the transition is completed, in the final state of the system the only actor with rights should be Mary.

The semantics of the formalisation are: m= Mary, h= HR department, δ= health information. hRδΦ is a right denoting that the HR department respect the choices (Φvariables) that Mary gave in the past and restrict the process and sharing of her data. From these actors, those implicated into the action are Mary and the HR department.The latter actor is influenced by this action. The action is part of the "revoke" class, meaning that the rights are subtracted and there are no obligations created. With this action the rights that are subtracted from the HR department are three, namely:

1. Right to collect 2. Right to process 3. Right to share

The data pertaining to the action is Mary's health data and the variables that were defined by Mary in previous transitions are five, namely:

1. Destination (Mary's boss) and NOT (Third parties) 2. Purpose (internal use) 3. Time of consent (Up to five years) 4. Times data processed (up to 100 times) These results are presented in the table below: We then apply Procedure 2 to the results of Procedure 1, recorded in Table 3, and produce the test requirements described in Table 4 below.

We need to verify that the appropriate rights were revoked by the HR department and that Mary's data is deleted. Thus, we create tests to verify whether the HR department still possesses the right to collect, process and share Mary's data. Further testing is required to examine if the HR department has any other rights and if any other actor of the system was influenced. The test suites designed for this formalisation and presented in Table 4 are the same with the previous use case, but the results of the tests are different. The testing is successful because the actions described transitions from state A to state B and backwards. Since the transitions were only between these two states of the system, the tests should remain the same, since the pre-condition for the one transition was the post-condition of the other and vice versa.

Conclusion and future work

With the development of Internet applications such as Web 2.0 or cloud computing, new challenges arise for protecting individuals' privacy. Research is conducted in diverse disciplines examining the legal, regulative and technical aspects of privacy, but little has been achieved so far regarding the development of a methodology for testing privacy properties.

In this paper, we proposed a strategy comprised by two novel models, that develops automated testing suites for effectively validating the correctness of consent and revocation controls. We applied the strategy on a real case scenario to prove its practicality, at least as far as individual actions are concerned.

For future work, we intend to consider the effects of concurrency and how our test strategy should evolve to probe them. We will also validate our method on another case study in order to create a detailed assessment of the applicability of the approach.

Fig. 1 .

 1 Fig. 1. The state of the system

Fig. 3 .

 3 Fig. 3. Transition from the initial state to the final by the delete action

Table 1 .

 1 Results from the application of the first procedure

	Actor	Rights on data Rights to change by the action
	Mary	owner of the data	none
	HR department	none	store, process, share
	Mary's boss	none	none
	Third parties	none	none

Table 2 .

 2 Test cases generated by the application of the second model

	Actor	Test	Pre-condition Post condition
	Third party	Attempt to access Mary's data	No Access	No Access
		as other users
	Mary's boss	Attempt to access Mary's data	No Access	No Access
		held within the HR department
	HR department Attempt to process Mary's data	No Access	Access Granted
		for 99th time
	HR department Attempt to process Mary's data	No Access	No Access
		for 101th time
	HR department Attempt to process Mary's data	No Access	No Access
		after five years
	HR department Attempt to share Mary's data	No Access	Access Granted
		with Mary's boss
	HR department	Attempt to notify Mary	No Access	No access
	HR department Attempt to release Mary's data	No Access	No Access
		to third parties

Table 3 .

 3 Results from the application of the first procedure

	Actor	Rights on data Rights to change by the action
	Mary	owner of the data	owner of the data
	HR department store, process, share	none
	Mary's boss	none	none
	Third parties	none	none

Table 4 .

 4 Test cases generated by the application of the second model

	Actor	Test	Pre-condition Post condition
	Third party	Attempt to access Mary's data	No Access	No Access
		as other users
	Mary's boss	Attempt to access Mary's data	No Access	No Access
		held within the HR department
	HR department Attempt to process Mary's data	Access Granted No Access
		for 99th time
	HR department Attempt to process Mary's data	No Access	No Access
		for 101th time
	HR department Attempt to process Mary's data	No Access	No Access
		after five years
	HR department Attempt to share Mary's data	Access Granted No Access
		with Mary's boss
	HR department	Attempt to notify Mary	No Access	No access
	HR department Attempt to release Mary's data	No Access	No Access
		to third parties

The EnCoRe project[5] is an interdisciplinary research project, a collaboration between UK industry and academia, partially funded by the UK Technology Strategy Board (TP/12/NS/P0501A), the UK Engineering and Physical Sciences Research Council and the UK Economic and Social Research Council (EP/G002541/1).

The neglected non-functional requirements have two different sources. They derive from the assessment of the security properties, which is not relevant to privacy properties and from the complexity of privacy features, such as aggregation or anonymity, which created ambiguities in our attempt to formalise the requirements for the first EnCoRe case study[START_REF] Agrafiotis | Applying formal methods to detect and resolve ambiguities in privacy requirements[END_REF].


Ina Schiering
email: i.schiering@ostfalia.de2j.kretschmer@ostfalia.de

Jan Kretschmer

The Infrastructure Level of Cloud Computing as a Basis for Privacy and Security of Software Services

Keywords: cloud computing, privacy, security, IT service management, auditing

An important basis for cloud computing are public IaaS cloud services as offered e.g. by Amazon, Rackspace, VmWare. Since IaaS cloud services are often used as a flexible infrastructure for SaaS cloud services, it is important to investigate IaaS cloud services as a basis to realise regulatory requirements in cloud computing, e.g the European Data Protection Directive and the E-Privacy Directive. In this context a prototype of an IaaS cloud service is presented which serves as a basis for software services (e.g. SaaS services) compliant with these European Directive. This is achieved by a combination of organisational, and technical measures accompanied by auditing and monitoring.

Introduction

Cloud computing is an important trend towards standardisation and industrialisation of IT services. It is a further development of paradigms as virtualisation and utility computing as stated by Armbrust et al. [START_REF] Armbrust | Above the Clouds: A Berkeley View of Cloud Computing[END_REF] and offers flexible, scalable IT services with a usage based price model. In this paper the service model Infrastructure as a Service (IaaS) is investigated. See the National Institute of Standards and Technology (NIST) [START_REF] Mell | The NIST Definition of Cloud Computing[END_REF] for a definition of cloud computing. The focus of the IaaS cloud service investigated here is the provisioning of virtual resource sets as indicated by Lenk et al. [START_REF] Lenk | What's inside the Cloud? An architectural map of the Cloud landscape[END_REF](e.g. Amazon EC2, Eucalyptus. Open-Stack, etc.). This service is investigated in the form of a public cloud service, i.e. the cloud service is supposed to be provided by an external cloud provider for the general public.

The characteristics of cloud computing, especially the usage based price model and the flexible deployment model of public cloud services have great advantages, especially for small and medium sized enterprises. They avoid investment in hardware, data centres and need less trained IT specialists compared to a traditional IT infrastructure which is built and operated in-house. In particular they profit from the scalability of the service. Despite the economic advantages there are a lot of obstacles concerning the use of public cloud services in the area of security, privacy, availability and legal compliance as indicated by Jansen [START_REF] Jansen | Cloud Hooks: Security and Privacy Issues in Cloud Computing[END_REF], Chow et. al. [START_REF] Chow | Controlling data in the cloud: outsourcing computation without outsourcing control[END_REF] and the cloud computing risk assessment provided by the ENISA [START_REF]Cloud computing risk assessment[END_REF].

In this paper we focus on privacy requirements in public cloud services. Because of the complexity and broad range of cloud services it is important to start at the bottom of the cloud stack in the sense of Lenk et al. [START_REF] Lenk | What's inside the Cloud? An architectural map of the Cloud landscape[END_REF] with IaaS virtual resource sets. The organisation that provides the cloud service is the cloud provider. Cloud services are used by cloud users. It is an interesting approach to realise SaaS (Software as a Service) cloud services but also other IT systems based on IaaS and PaaS (Platform as a Service) cloud services, see e.g. the Amazon case studies [START_REF] Amazon | Case Studies[END_REF], since the flexibility, scalability and the usage-based price model fit well to the requirements of these services.

This paper describes a prototype of an IaaS cloud based on the open source cloud stack Eucalyptus [START_REF] Eucalyptus | [END_REF], see Nurmi et. al. for an overview of the architecture [START_REF] Nurmi | Eucalyptus: A technical Report on an Elastic Utility Computing Architecture Linking your Programs to Useful Systems[END_REF]. There privacy requirements based on the Data Protection Directive 95/46/EC [10] and the E-Privacy Directive 2002/58/EC [11] are investigated. The aim of this IaaS cloud service is to be a basis for IT systems in general or SaaS cloud services in particular where personal data is processed. There the IaaS service should serve as a basis for the IT system resp. SaaS service to be compliant with the Data Protection Directive and if applicable to the E-Privacy Directive. Examples for IT systems are Mail-and Calendar Servers, SAP Systems, examples for SaaS cloud services are Dropbox, Gmail, social communities, enterprise content management.

The approach investigated here is focussed on the IT operation of the cloud provider and uses a combination of automated procedures to avoid access to data where possible, encryption, accompanied by operational processes and auditing. Since concepts where encrypted data is processed like homomorphic encryption (see Gentry [START_REF] Gentry | Fully homomorphic encryption using ideal lattices[END_REF]) are not feasible yet, it is important to review alternatives. In the following, the adversary model and the legal requirements on the European level are summarised. Afterwards, the prototype as a basis for the considerations are presented. Then it is discussed how the requirements concerning privacy on the legal level could be achieved and what risks are still present.

Adversary Model

What are the implications when the data processing of an IT system or a SaaS service is transferred from a data centre of the service provider or a dedicated outsourcing company to an IaaS cloud provider? In general it is unclear where the data is operated. Since the cloud provider can itself use e.g. for peak load resources of other providers the data might be transferred to a third party. When data is operated by a cloud provider there is the risk of unauthorised access by personnel of cloud providers. Hence the personnel of the IaaS provider is an adversary to be analysed. This adversary is characterised by access to the physical hardware and administrative access to the operating system level of the systems, the software managing the cloud and the network layer. See the section about the prototype for details concerning the cloud technology stack. Furthermore the data is not processed on dedicated resources, but resources are shared with other customers of the cloud service. The cloud provider has to ensure the separation between the data and services of different customers (multi-tenancy). Hence the second type of adversary are other cloud users. Instead of accessing data over a local network when it is processed in a local data centre, the data is accessed over the internet which leads to risks concerning network security and access control to services and data. The third type of adversary is therefore a person with internet access. A risk which is always present in IT systems is the risk inside the organisation of the user of the IT system or the SaaS service. There personell data could be processed for other purposes without consent of the data subject or also unauthorized access to data can happen if roles and responsibilities are not properly managed. Hence the fourth type of adversary is the personnel of the user of the IT system resp. SaaS service.

Concerning these four types of adversaries the focus in this paper is to investigate measures concerning the personnel of the cloud provider as an adversary. There we focus on the IT operation of the IaaS cloud. The risks inside the organisation of the users of an application are always present when IT systems are used and are therefore not specific for a cloud service. Also the issues with adversaries with internet access focus more on network security than on cloud computing. The adversary other cloud users is interesting in SaaS cloud environments. There especially in SaaS services very often the data of different cloud users is integrated in a common database. Hence multi-tenancy is realised in the application via identity management and access control. In this environment the role of other cloud users is interesting to evaluate. In an IaaS environment the risk reduces mainly to software bugs in the virtualisation layer resp. the cloud layer, where standard software is used. Hence for IaaS services the most interesting adversaries are the personnel of the IaaS provider which is investigated in this paper.

Technical Requirements derived from the Regulatory Framework

The regulatory framework concerning the processing of personal data in the European Union consists of the Data Protection Directive 95/46/EC [10] and e.g. concerning web services and services addressing mobile phones often additionally the E-Privacy Directive 2002/58/EC [11].

In the Data Protection Directive the basic roles which are used are the data controller and the data processor. In a general cloud computing environment, it is an intricate task to differentiate these roles. See Leenes [START_REF] Leenes | Who Controls the Cloud?[END_REF] for a thorough discussion of this issue. The data controller is characterised in Article 2 (d) as the party that "determines the purposes and means of processing of personal data" and the data processor processes "personal data on behalf of the controller".

In the scenario of an IaaS cloud which is used to built SaaS cloud services or general IT systems for processing of personal data the provider of the IT system resp. SaaS service could be a data controller e.g. in the case of services directly addressing users. Otherwise the provider of the service could also be a processor in the case that the service provided is a B2B (business to business) service, where the user of that service is e.g. a company that processes personal data, e.g. names, addresses and bank accounts of customers. There could be even more complex scenarios with respect to the roles of data controller and data processor. But in all cases the provider of the IaaS cloud is the data processor that processes personal data on behalf of another party.

In the following the Data Protection Directive and the E-Privacy Directive are investigated. Technical requirements for IaaS cloud services as data processors in the scenario described above are extracted and explained.

Requirements derived from the Data Protection Directive

The processing of personal data is in this paper restricted to personal data that does not belong to the special categories of data stated in the Data Protection Directive in Article 8 "personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership and the processing of data concerning health or sex life". Unless the fact that people disclose these data voluntarily in social networks and Internet forums, there is a higher risk associated with the processing of e.g. the health records in a hospital compared to the processing of customer addresses and payment details as needed e.g. for a web shop. For the processing of these categories of data it would be advisable to use an internal system or at least a community cloud to reduce the risk. The measures described in this paper have the intention to reduce the risk concerning the processing of standard personal data as described above with "a level of security appropriate to the risks represented by the processing and the nature of the data to be protected" as it is described in the Data Protection Directive Article 17, 1.

In Section I "principles relating to data quality" Article 6 (b), (d) demands from a technical perspective that data is only processed for legitimate purposes and that data can be rectified and erased. Similar requirements result from Article 12 (a), (b) "right of access", where the data subject has the right that the data controller communicates "an intelligible form of the data undergoing processing" and the right of "rectification, erasure and blocking of data". Even if in Article 12 only the data controller is addressed, the data controller would need to demand appropriate requirements from the data processor in form of a contract, even if the data processor is not addressed in the Directive. The obligation for such a contract is mentioned in Article 17, 3. These requirements are mainly to be fulfilled on the database and application layer since data is stored in the form of databases and hence these requirements can only be realised there. The only requirement that needs to be realised on the IaaS layer is (1) deletion of all data when virtual instances are no longer needed.

The next group of requirements are addressing confidentiality and security of processing. In Article 16 concerning the confidentiality of processing the data controller and data processor are directly addressed "any person acting under the authority of the controller or of the processor, including the processor himself, who has access to personal data must not process them except on instructions from the controller". Hence (2) access to personal data has to be restricted and processing of data must be controlled by every party involved in data processing and therefore also by the IaaS provider. Concerning the security of processing in Article 17, 1 the data controller is obliged to "implement appropriate technical and organizational measures to protect personal data against accidental or unlawful destruction or accidental loss, alteration, unauthorized disclosure or access ... and against all other unlawful forms of processing". Article 17, 2 states that "the controller must, when processing is carried out on his behalf, choose a processor providing sufficient guarantees in respect of the technical security measures and organizational measures governing the processing to be carried out, and must ensure compliance with those measures". These requirements must according to Article 17, 3 be "governed by a contract". The IaaS Provider has to ensure (3) personal data has to be protected against accidental or unlawful destruction or accidental loss, alteration, unauthorized disclosure or access and (4) compliance according to the technical and organisational measures has to be ensured.

The last technical requirement that can be derived from the Data Protection Directive is based on Chapter IV "transfer of personal data to third countries". Hence the IaaS cloud provider must allow (5) restrictions concerning the location of processing. This has to be combined with a check concerning the legislation of the country where the provider resides. An example for this issue is the Patriot Act as mentioned e.g. in the data use limits of Microsoft Online Service [START_REF]Microsoft Online Services, Data use limits[END_REF].

Requirements derived from the E-Privacy Directive

The E-Privacy Directive addresses providers of public communication services. Similar to the Data Protection Directive in Article 4, 1 "the provider of a publicly available electronic communications service must take appropriate technical and organisational measures to safeguard security of its services" which is amended in Article 4, 1(a) (according to the amendment 2009/136/EC) such that the measures "shall ensure that personal data can be accessed only by authorised personnel for legally authorised purposes" and "protect personal data stored or transmitted against accidental or unlawful destruction, accidental loss or alteration, and unauthorised or unlawful storage, processing, access or disclosure". There also the "implementation of a security policy with respect to the processing of personal data" is demanded. If the service provider employs an IaaS cloud service the requirements (2), ( 3) and ( 5) from the section about the Data Protection Directive should be fulfilled to build a communication service which is compliant. From the implementation of the security policy further requirements concerning the IaaS cloud provider may arise which could not be described on this general level.

Additionally, in Article 4 there are regulations concerning data breaches where there exists in the amendment 2009/136/EC Article 4.3 the possibility instead of informing the users about data breaches apply technological measures that "shall render the data unintelligible to any person who is not authorised to access it". There in the realisation of the communication service appropriate encryption has to be employed. This has to be done at the application and database layer. Also encryption at the file system level is done inside the operating system in the virtual instance and is not in the responsibility of the IaaS provider. The provisions of Article 5, 1 "prohibit listening, tapping, storage or other kinds of interception of communications and the related traffic data by persons other than the users, without the consent of the users allowed" and of Article 6 concerning traffic data need to be realised already at the application level. There concerning the deletion of traffic data it would be advisable that the IaaS provider fulfils requirement (1) deletion of all data when virtual instances are no longer needed. Also Article 8 and 9 address technical requirements concerning the communication service, but all these requirements need to be realised by the applications of the communication service. The cloud provider is responsible for the technology stack from the hardware up to the cloud layer which is in the case of this prototype Eucalyptus. The cloud user is responsible for the operating system of the virtual image and for the application. In the context of the European Data Protection directive it is important to be able to impose restrictions concerning the locations where data is processed. There Eucalyptus offers the concept of a cloud which consists of several clusters representing different locations. Clusters are a concept similar to Amazons availability zones. Each cluster is controlled by a cluster controller (CC)

and manages a group of assigned node controllers (NC), where virtual instances for cloud users are generated. The whole cloud infrastructure is controlled by the cloud controller (CLC). The IaaS technology stack consists of the hardware, the operating system, the network, the virtualisation and the cloud layer. The cluster and cloud controller communicate with the virtual instances over a virtual private network. Via another virtual network connection also the public network connection to the virtual instance is realised. Therefore the virtual instances are already adequately separated from other instances apart from bugs in Xen or VDE. Hence the role of other cloud users as adversaries would be interesting with a focus on security issues of the technology stack. The access to the virtual instances is controlled via a public-key infrastructure. Only the cloud user and the cluster controller for internal purposes can access the virtual instance over the cloud infrastructure. But with root access to the operating system of the node controllers the administrators of the cloud provider can also get access to the virtual instances.

Santos et al. [START_REF] Santos | Towards trusted cloud computing[END_REF] investigated how virtual machines can be protected against the administrators of the cloud provider under the assumption that the administrator has root access to the system. They propose an approach using TPM technology (Trusted Platform Module). In contrast to this approach which makes assumptions about the hardware platform of the cloud service, it is investigated here how this can be accomplished via automated procedures and operational processes accompanied with an approach for monitoring and auditing.

Technical and Organisational Measures Addressing the Requirements Identified

In the section about legal requirements there were 5 requirements derived concerning an IaaS cloud service as data processor:

(1) Deletion of all data when virtual instances are no longer needed (2) Access to personal data has to be restricted and processing of data must be controlled (3) Personal data has to be protected against accidental or unlawful destruction or accidental loss, alteration, unauthorized disclosure or access (4) Compliance according to the technical and organisational measures has to be ensured (5) Restrictions concerning the location of procession Requirement ( 5) is already fulfilled by the prototype. The other requirements are addressed by the following approach: The operation of a cloud is a highly industrialised form of IT operation. Therefore most operational tasks should be accomplished in the form of automated procedures. The tasks where this is not possible must be organised with the help of processes. Hence administrative access to the system in general is only needed in very restricted situations. The normal operation of the cloud should need no administrator interaction. The focus of the work of administrators is to develop, test and maintain automated procedures. These automated procedures are transferred to the production in form of a change or the deployment of a new release.

All tasks must be controlled via monitoring to allow for regular audits. The Federal Office for Information Security in Germany (BSI) recommends to use an IT service management framework as ITIL or CoBIT in their recommendations for cloud computing providers [START_REF]Security recommendations for cloud computing providers[END_REF] as a basis for ISO 27000 resp. IT-Grundschutz. Hence we assume that the IT operation of the cloud service is implemented according to the IT Infrastructure Library (ITIL) which is a best practice framework for IT service management. See [START_REF]ITIL IT Service Management-Glossary of Terms and Definitions[END_REF] concerning notions of IT service management according to ITIL. We claim that through the following technical measurements, where this is not possible organisational measurements accompanied by auditing an IaaS cloud provider fulfils the above named requirements. That means that associated risks are reduced in an adequate manner. In the following operational tasks of the cloud provider are investigated. Since for cloud computing it is important to profit of the economy of scale it is assumed that a group of administrators of the cloud provider will be responsible for the IT operation of the cloud service. These are in the following named administrators.

Because there are several administrators it can be assumed that a segregation of duties is possible. What are the operational tasks to deliver virtual instances in form of a cloud service to cloud users? A short overview is given here. The detailed analysis follows afterwards. To build up the infrastructure administrators need to add and remove systems. For updates and patches it is necessary to change systems. Beside that it is needed to realise standard administrative tasks as monitoring of the whole technology stack, backup the node controllers. If needed, it must be possible to restore a system from the backup. In the case of an incident1 troubleshooting has to be done. For the tasks add system and change system, images resp. packages have to be provided.

Add, Remove Systems

As an example for a system a node controller is used. What are the necessary steps to add a system (here a node controller is used) to the cloud infrastructure? -A change is initiated with technical details as MAC address, the role of the system, i.e. node controller or cluster controller, etc.. The technical details can be extracted from the change for automated procedures described in the next steps and for auditing purposes. -The new system is placed in the data centre. Because of the segregation of duties between the administrators it is assumed that an administrator that has access to the data centre do not has any other administrative access to the systems. -The system is installed. This can be realised as an automated procedure.

The MAC address is added to the DHCP configuration and the system is added to the configuration of the boot server. The system boots the designated image. The integrity of the image can be verified by the use of checksums. -Add the system to the cloud configuration. This can be also realised with an automated procedure.

All steps in the above workflow beside the initial placement of the system in the data centre can be automated. Since the result of each step can be checked by comparing configuration files or by using commands for monitoring and can be documented in log files, the whole workflow can be checked against the initial change in an automated auditing process. In the following we describe how images which are needed also here can be realised in this model.

Provide Image An important step to build up the cloud infrastructure are operating systems images. An image is a collection of software packages accompanied by configuration changes. They are needed in the task add system for node controllers and cluster controllers. beside that the cloud provider has to provide operating system images for the creation of virtual images by cloud users. Also a special image is needed to delete all data of a virtual instance after the cloud user has finished to use it according to Article 12 (b) of the Data Protection Directive. To provide an image the following steps need to be performed:

-Plan image Select packages and plan configuration changes, document the image. This step can only be checked by the four-eyes principle and should be documented in the form of a change.

-Build image This can be realised by an automated procedure based on the documentation. The images is built from packages which are provided from a central repository. The checksums of the packages can be used for verification. -Test the image with respect to the documentation An install of the image is provided and the result is tested against the initial documentation with the help of tools to analyse the system. -Create checksum (automated procedure) -Deploy image on boot server (automated procedure) -Regularly check the integrity of the image by verifying the checksum (automated procedure)

For the tasks which cannot be automated, the risk can be reduced by using the four-eyes principle and by relying on the segregation of duties, i.e. that the person that plans an image does not perform the checks. These elements can be assured via rigorous application of change management. It now has to be explained how the basic building blocks for images, the packages, could be realised in this model.

Provide Package Packages are the basic building blocks of operating system images. Most packages used to build up images are standard software packages as e.g. MySQL, package consisting of system utilities, etc. But a package can also consist of individual software as e.g. a collection of scripts. Similar to the creation of images, the package is planned. But afterwards the software needs to be implemented which is a manual process where the risk can only be reduced by rigorous software engineering methodologies. An important approach there is model driven development (see France and Rumpe [START_REF] France | Model-driven Development of Complex Software: A Research Roadmap[END_REF] for an overview) where the aim is to generate code from a model, e.g. in UML or SysML. This approach is often used for embedded systems. Then as before a checksum is created and the package is deployed to the repository. The integrity of the package can be verified by an automated procedure on a regular basis.

Change Systems

In contrast to standard IT operation a system is in this industrialised form of cloud computing only changed in form of an update. This can be a minor update where only some updated packages have to be integrated and a reboot is not needed or in the form of a major update where the whole image is changed.

Hence the case of a major update is already described in the task add, remove system where also a new image is installed.

Monitoring, Backup, Restore

The standard tasks monitoring, backup and restore are usually realised in an automated way. For backups of systems access restrictions have to be realised and restore processes need to be confirmed by a change since a restore should normally not occur in a cloud service providing virtual instances. There the measures for availability should be focussed.

Troubleshooting

This is beside software development the task where manual intervention is needed. But manual intervention can be accompanied by the four-eyes principle and logging of all administrative actions. Based on these logs the operation can be reviewed afterwards. With these procedural measures it is possible to reduce the risk.

Auditing

The documentation of the processes and the log files of IT operations are a basis for auditing. In the prototype process mining according to van der Aalst [START_REF] Van Der Aalst | Process Discovery: Capturing the Invisible[END_REF] is used for auditing. This is an approach where log files and other data can be after the transformation to the XML file format XES used as a basis for auditing purposes. These measures can be complemented with an audit of the cloud service focusing on privacy, e.g. a Privacy Impact Assessment of the Information Commissioners Office in the UK [START_REF]Privacy Impact Assessment Handbook[END_REF] or the European Privacy Seal [23]. In [START_REF] Tancock | A Privacy Impact Assessment Tool for Cloud Computing[END_REF] a tool based approach is proposed for PIAs in a cloud computing environment.

A different approach proposed by Neisse et.al [START_REF] Neisse | Implementing Trust in Cloud Infrastructures[END_REF] is to use a cloud certification system based also on TPM that detects unintended or malicious modifications of the cloud infrastructure It guarantees to service providers at runtime the detection of unintended or malicious modifications of cloud infrastructure configurations.

Remaining Risks

Several administrative tasks as provide OS images, implementation of automated procedures and also update systems are based on software which is implemented resp. selected and configured by the cloud provider. Change management and release management processes can only reduce the risk that someone tries to manipulate code or that software has vulnerabilities.

But because of the standardised cloud architecture software resp. hardware bugs and errors in configurations have greater impact (e.g. the Amazon EC2 and Amazon RDS Service Disruption in the US East Region [START_REF] Amazon | Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region[END_REF]). To reduce the impacts it is possible to use cloud services that employ different technologies or an intercloud where this is realised. But there the problem is that most cloud providers do not disclose their technology since it is their intellectual property.

Another risk is that in the case of troubleshooting no access restrictions can be applied. The risk is reduced by logging actions and the four-eyes principle, but it is not possible to avoid it in general.

In this paper the focus is on administrative roles. Hence attacks as e.g. Distributed Denial of Service attacks (DDoS) need to be addressed by additional measures. Another risk that needs to be accounted for is governmental access to data. E.g. companies from the U.S. are giving government entities access to user data based on legal requirements based on the Patriot Act, even if it is stored in Europe. This is documented for example in the data use limits of Microsoft Online Service [START_REF]Microsoft Online Services, Data use limits[END_REF].

Related Work

There are already various approaches addressing security and privacy by proposing a trusted technology stack or the use of TPM (Trusted Platform Module) technology. The measurements for the administrative level could be combined with these approaches. Concerning the focus of security of IaaS cloud services Santos et al. [START_REF] Santos | Towards trusted cloud computing[END_REF] investigated how virtual machines can be protected against the administrators of the cloud provider under the assumption that the administrator has root access to the system. Here TPM is used. On the other hand, the cloud provider needs assurance about the integrity of the virtual machines and can provide this also as a service to cloud users. Christodorescu et. al. [START_REF] Christodorescu | Cloud security is not (just) virtualization security: a short paper[END_REF] propose for this aim an approach of secure introspection of virtual instances by cloud providers. Another approach which addresses security and privacy in cloud computing is from Doelitzscher et al. [START_REF] Doelitzscher | Designing Cloud Services Adhering to Government Privacy Laws[END_REF]. There a six-layer security model for cloud computing consisting of risk analysis, security guidelines, QoS monitoring, data encryption, logging, encrypted communication is proposed.

These approaches focus mainly on technical measures, which result in adaptation resp. development of new cloud management software. In the prototype presented here, we concentrate on existing technologies and use a combination of organisational, procedural and technical measures accompanied with an approach for auditing these measures to realise privacy requirements.

With a focus on SaaS cloud services Pearson et al. [START_REF] Pearson | Taking account of privacy when designing cloud computing services[END_REF] investigated as example services sales data analysis, mining multiple databases, customized end user services and proposed a privacy manager software on the client as a central component. In [START_REF] Pearson | Accountability as a Way Forward for Privacy Protection in the Cloud[END_REF] they used also a combination of a procedural and a technical approach to assure accountability for large organisations in a general cloud computing scenario. In the prototype investigated here additionally processes of IT service management and the possibilities to restrict access to the production environment by automation and further control by audits on the basis of log files are discussed.

Conclusion

In this paper a prototype for an IaaS cloud service based on a standard cloud stack is investigated with a focus on technical and operational measurements. Measures as the segregation of duties, automation of administrative tasks, IT service management processes, the employment of cryptography and auditing are applied. These considerations concerning system operation are a basis for compliance with the Data Protection Directive 95/46/EC, resp. the E-Privacy Directive integrated in a more general concept based on ISO 27000 resp. IT-Grundschutz. Future work will be based on this prototype and extend the investigation to PaaS and SaaS cloud services. Another interesting direction for research is the composition of cloud services out of services of different cloud providers and the investigation of processes for data processing of cloud users incorporating cloud services.

4 Prototype

 4 The prototype described in this paper is an IaaS cloud service based on the open source cloud stack Eucalyptus[START_REF] Eucalyptus | [END_REF]. Eucalyptus is a mature cloud computing stack which is widely used and e.g. integrated in the Ubuntu Linux distribution. Eucalyptus uses Xen [15] as a virtualisation layer and VDE (Virtual distributed Ethernet)[16] for the realisation of virtual network connections.

  (T) Technical measurements (T1) Automated procedures (T2) Restrict privileged access to the system where possible (O) Organisational measurements (O1) IT service management (especially change management is important) (O2) Four-eyes principle (O3) Segregation of duties (O4) Software engineering methodologies (e.g. model driven development) (A) Auditing (A1) Logging (A2) Cryptographic measures (e.g. checksums) (A3) Monitoring, automated auditing

An unplanned interruption to an IT service or a reduction in the quality of an IT service.[START_REF]ITIL IT Service Management-Glossary of Terms and Definitions[END_REF]


FCIPS, I.S.P., ITCP Professor, Thomas P Keenan
email: keenan@ucalgary.ca

Are They Making Our Privates Public? -Emerging Risks of Governmental Open Data Initiatives

Governments around the world are opening their data vaults to public (and corporate) access and scrutiny. Notable examples including New York City's NYC Datamine, Philadelphia's OpenData Philly, Europe's Open Data Challenge, and Canada's Open Data Framework, which now spans several cities including Toronto, Vancouver, Edmonton, and Ottawa. Anyone can read government plans, budgets, contractor lists, and in many cases, documents relating to individual citizens. The intention behind these data transparency projects is laudable, but it behooves those interested in privacy to take a careful look at just what information our governments are sharing with the world. There have already been "Open Data Hackathons" which have discovered interesting and unforeseen vulnerabilities, often by combining multiple data sources. There are also commercial ventures using government released data in combination with other sources in ways that were never anticipated, such as genealogical research. We are breaking new ground here and we need to generate new principles to protect privacy in the face of data that is going from "public" to "super-public".

Introduction

"The road to hell is paved with good intentions" is a proverb whose origins are lost in history but that becomes more timely every day. Governments around the world are leaping breathlessly onto the "Open Data" bandwagon, driven by a desire to improve citizen services, a fear that officials will be accused of hoarding data, and just plain economics, since enabling third party Open Data applications often costs the government almost nothing. There is also a certain cachet to being "open" with your data --perhaps because of the warm feelings people have for open source software, the Creative Commons license, etc. In addition, the Wikileaks disclosures of government data have convinced many in government that their confidential data will get out anyway. It looks far less suspicious and sinister if they release it voluntarily and systematically.

What follows are examples of major governmental Open Data initiatives and a demonstration of how each illustrates a type of privacy-related problem.

New York's NYC Datamine -Fat Fingers at the Data Office

As the financial capital of the United States, as well as a media center and home to numerous high tech companies, it is predictable that New York City would take a lead in opening government-collected data to the public. And so it did, with a highly touted and freely available collection of 103 municipal data sets and a promise to add even more. The NYC Datamine project was unveiled on October 6, 2009, only to be greeted with an immediate privacy scandal.

According to Nancy Scola, writing on TechPresident.com, "Discussion on the public Sunlight Labs Google Group revealed that one XLS table listing the city's more than 1,100 women's organizations contained not only the personal email address of the group's contact with the New York City Commission on Women's Issues (CWI), but what he or she was using as the Secret Question and Secret Answer." [1] This relatively minor privacy breach was actually fortuitous because it forced the city to examine all its newly released files to ensure that they did not contain other personally identifiable information.

While this oversight could be dismissed as a "teething problem," it illustrates that even in a major jurisdiction, well aware of privacy issues, mistakes can and will occur. The clear lesson is to carefully review everything that is being released, thoroughly remove personal data, and act swiftly if a mistake is made.

Philadelphia's Open Data Philly -Too Much Sharing

One of principles of North American democracy is that contributors to political campaigns (who often receive a generous tax deduction for their contribution) should be identified. This seems justified, as the public has a right to know who is financing campaigns to ensure that politicians are not being "bought" by generous donors. Some jurisdictions only report contributions over a certain monetary value. The City of Philadelphia, PA, USA has chosen to report all contributions. and make the results "freely viewable and printable, but not available for download" on a website, www.opendataphilly.org.

There, we learn that a certain person contributed $3.00 US to the Communication Workers of America (a trade union). We are also given that person's precise home address as reported on the campaign contribution receipt. In fact, checking some of these addresses against the best known U.S. home address directory database (www.anywho.com, operated by Intellius, Inc. and promoted by AT&T) shows that the information in the contributor database is frequently more complete than what is available in the directory. In many cases a person's address in the contribution database is not even shown in the directory database, perhaps because that person asked to be unlisted for privacy reasons. In an era of home invasions and identity theft, this is a very common choice.

On the other hand, people are highly likely to provide a complete and accurate address for a campaign donation receipt, since it is an official document and they are expecting to file it with their income tax return to claim a tax deduction.

The most reasonable justification for including contributor addresses in the public dataset would appear to be to disambiguate donors who share the same first and last names. There might also be some value for doing a geographic analysis of donation patterns. Despite the claim that this dataset was not downloadable, it was actually easy to download parts of it, such as everyone with a particular surname. Checking the three most common American surnames, Smith, Johnson and Williams, produced only a few apparent duplicates where having the address information may have been helpful. The experiment performed is described below.

Method: The donor files for 2010 were downloaded from OpenDataPhilly as .CSV files, imported into Microsoft Excel and sorted by the contributor name field. "Potential Duplicates" were defined as additional names that were shown identically as a name in the database, but with a different address. Of course it is possible that a person moved or gave a home address on one donation form and an office address for another donation. So the "duplicate" might really be the same person. Therefore, this is a conservative estimate of how much benefit might possibly accrue from having the addresses.

Results: The results were as follows: Union. This makes sense because these donors are apparently receiving their receipts in care of that business at its office address.

The fact that over 15% of the respondents in these three name groups gave the 1719 Spring Garden Street address further illustrates the futility of trying to disambiguate people with identical names based on their addresses. For example, there are two runs of contributions at that address from a "Michael Smith". Are they from the same person? There is no way to tell from this database. So the inclusion of home address in this database actually compromises privacy without adding any real functionality. It was probably just easier for those in charge of making the data public to leave the address in rather than taking it out.

Should we be concerned by the inclusion of address information in this database? There is certainly an issue of informed consent and purpose of use for the data. It is highly doubtful that people realized when they filled out their donation receipts that their addresses would be permanently posted on the Internet for all to see. In fact, this database contains information back to 2005, long before the OpenDataPhilly project even existed. So it is fair to say that, in many cases, citizens have unwittingly disclosed information through their city government that they did not willingly provide to other sources such as the telephone directory company.

As for whether or not home address is protected as Personally Identifiable Information (PII), the law and practice varies widely by jurisdiction. However, the US National Institute of Standards and Technology, in its Special Publication 800-122 explicitly defines "address information such as street address" as being PII.

[2]

Canada's Open Data Framework -Are Elephants Feasible?

There is certainly an argument that people who are paid with public money should be willing to have that information placed in the public domain. This would include those who received consulting contracts from a municipal government. Yet, overly aggressive journalists or snoopy citizens could easily make unfair use of some of the data.

A number of Canadian cities have jointed the Open Data Framework with a commitment to making as much civic data as possible freely available to the public. Looking into the consultant expenses of the City of Toronto, one might well ask why a Mr. John Lehnhardt was paid $3,275 for an "Elephant Feasibility Study." We already know that elephants are feasible. Fortunately, this line item is tagged with the label "Toronto Zoo," so we can imagine that it is probably quite valid and justified. Then again, in tough times, Toronto citizens might well ask why Victor Ford & Associates charged their city government $7,500 for a "Mountain Bike Skills Park Site Assessment." In these cases, providing more data might have been desirable, e.g. some justification of the expenses so that they are not mis-interpreted when disclosed in database form.

It should be acknowledged that the designers of Toronto's Open Data initiatives have made some attempts to protect the privacy of the general public. For example, their database on calls to the city's complaint and service request line (reached by dialing 311) is anonymized to show, in general, only a partial (three out of six characters) postal code, e.g. M4V. That narrows the address to a part of the city, but it might be many city blocks. However, there are numerous cases where this field instead contains a precise intersection such as WOLFE AVE & DANFORTH RD, SCARBOROUGH. With enough cases like this, and other databases such as Google Maps and Google Streetview, it is certainly possible that the calls could be traced back to an individual property and hence to the owner.

While these cases would probably only be of interest to a bored journalist or a vindictive neighbor, the principle is clear. Data being placed in the public domain can be used for inappropriate purposes. As more and more data sets are released, the chances go up that someone will find something interesting to analyze and possibly track it back to an individual person.

Edmonton's election results -Did My Wife Vote for Me?

Election results are high on the list of data that clearly belongs in the public domain. Wellmeaning Open Data fans even build "real time dashboards" to display election results more graphically to a waiting public. Still, there are privacy issues here, such as reporting very low vote counts.

The City of Edmonton, Alberta, Canada made the results of its 2010 municipal election available on the Internet.

[3] From this dataset, we can learn that a mayoral candidate named Robert Ligertwood received 0 votes in the city wide hospital voting. So what? Suppose his wife was hospitalized at the time of the hospital poll and confirms that she voted in it and says she voted for Mr. Ligertwood. Now there is either a vote counting problem (rather unlikely given the auditing procedures for Canadian elections) or a marital honesty problem. In any case, one should not be able to deduce how an individual voted on a secret ballot from publicly released information.

While this seems like (and is) a contrived example, it is indicative of a general problem in data release whereby the reporting of small numbers can be used to make fairly accurate inferences about individuals.

Statistics Canada is the Government of Canada's data collection arm and has legal authority to compel individuals and businesses to provide data, e.g. on census forms. They also have an obligation to protect individual and business privacy. They dealt with the "low number problem" long ago by reporting "not significant" when cells in a database fall below a certain threshold.

The US Government publication cited above [2] also contains guidelines for effectively anonymizing data reports, which include introducing noise and replacing data in a group with the average value. All of these could be applied for the low-scoring candidates in an election.

Europe's Open Data Challenge -Bring on the Lawyers

The Open Knowledge Foundation sponsored the Open Data Challenge, held from April to June 2011 which by all accounts was a huge success. Offering total prize money of 20,000 € brought an impressive 430 entries from citizens of 24 EU member states. The winner, Znasichdani.sk, created by the Slovakian NGO Fair-Play Alliance, allows anyone to enter a name and obtain the value of Slovakian government contracts issued to companies in which that person plays a role. Entering "Vladimír Poór" (a Slovak entrepreneur, and one of the names suggested by the site) pulls up his association with contracts ranging back to 2005 and with a total value of 52 828 130,05 € . The data is obtained by cross-referencing existing governmental databases.

This application clearly touched a nerve, since one of the companies listed in it successfully sued to have certain data removed. According to news reports, "statutory representative, Jarmila Povazanova, of the Strabag construction company demanded in court that the total value of all public contracts of companies Povazanova represents be removed from the site. The Bratislava II district court ordered the NGO to remove that information." [START_REF] Zijlstra | A court has ordered Slovak NGO Fair-Play Alliance to take down data from their award winning Open Data application[END_REF] On one level, this demonstrates the value of the database. If a company bothered to sue to have the data removed, it may be assumed that it "had something to hide". Ironically, the media attention from this lawsuit has served to turn the spotlight on the companies involved and their perhaps too cozy relationship with the Slovak government.

There is also an interesting technical issue here since the Znasichdani.sk application is only a conduit to official governmental databases. Since the offending data was not held within the scope of that application, there is certainly something strange about a court order to delete some data when in fact the data was hosted on the government's own databases! 2 Should the Rich Have Less Privacy?

The fact that legal action was even taken in the Strabag case demonstrates the often contentious nature of government-held data. Most people agree that those who receive public money should be subjected to scrutiny. Yet, this principle certainly does not apply at all socioeconomic levels.

Consider the EBT/Food Stamp subsidy program in the USA, which is intended to help those who cannot afford to buy basic food products.

There is a strong feeling that this program is abused by many recipients. As one online commentator put it, "I saw people come through my line who would buy all kinds of expensive junk food. Name brand foods. Chips, donuts, fruit snacks, microwave popcorn, all kinds of stuff like that. Then they'd pull out their little EBT card, and I would stand there and think 'Wait... is our government really helping you?'" [5] The same writer notes that some people use food stamps for their groceries, then pay cash for beer and cigarettes, demonstrating that they had money that could have been spent on food.

Technologically, we could easily track and even post the purchase history of food stamp recipients, who are, after all, consuming public funds. Yet as a society we have chosen not to do that. The outrage about EBT spending expressed in the blog posting quoted above remains just a personal rant, not a systematic disclosure. This raises a provocative question about whether or not government database releases are effectively discriminating against certain sectors of society.

A competition, sponsored by the Ethics & Excellence in Journalism Foundation and the John S. and James L. Knight Foundation was held in April 2011 at the WeMedia NYC conference.

Companies competed for two $25,000 prizes based on their innovative technology ideas.

One winner was a proposed website called Stable Renters: Public Scoring for Apartments and Landlords (www.stablerenters.com). Among other things, it will allow tenants to identify who really owns their apartment building, as well as searching for health and building code violations. [6] The example shown on their website illustrates a building in Brooklyn, NY with "191 open violations since 2000" and provides the real names of the owner (as opposed to a holding corporation) and manager. It also assigns a grade (in this case "F") to the property to warn prospective renters. In accepting the prize, site founder Benjamin Sacks said he wanted to "level the playing field" between landlords and renters, since the former already have access to tools, such as credit reports and even confidential blacklists, to evaluate prospective tenants.

Landlords are people, with privacy rights like anyone else. Just as some doctors object to physician rating systems like www.ratemymd.ca and many professors bristle at anonymous student comments on www.ratemyprofessors.com, landlords might well feel that people are posting untrue and unfair comments about them and their properties on the Stable Renters site. With no easy way to have this information corrected, they might well feel like victims. The problem escalates to a higher level when this information is combined with other sources, such as those that might reveal the home address of a landlord.

Of course it is not only the rich whose personal details can be exposed through the release of government data, and it is not all about money. Lives may be endangered. Although it was not planned, the July 2010 Wikileaks-driven release of US military files relating to the war in Afghanistan was reported to disclose the true identities of Afghani translators and informants who cooperated with the US Forces, possible endangering their lives. There was also a situation after the 2006 Katrina hurricane in the US in which data on 16,000 aid recipients was improperly posted on a web site, reportedly endangering some, such as those who were being protected from abusive spouses.

[7]

Indirect Risks of Releasing Government Data

There is every reason to believe that private companies will use government data to their advantage, both in overt ways (like re-selling it) and for their own internal purposes such as looking up past government contracts or development plans to improve their own commercial fortunes. Indeed, corporate use is part of the reason the data is being released. The New York City MTA (which runs the busses and subways) even makes a virtue of this, with ads in subway cars bragging that "our apps are whiz kid certified.

" [8]

What they really mean is that they have allowed independent contractors to create smartphone apps using the MTA's data. Of course they also saved the cost and annoyance of having their own IT department develop them, and they can disavow responsibility if your bus doesn't show up at the time shown on your smartphone.

Bus schedules and arrival times don't compromise personal privacy (except perhaps of errant bus drivers) but genealogy sites most certainly do. Consider the wildly popular genealogy website ancestry.com, which has local versions like ancestry.ca in Canada, ancestry.co.uk in the UK, etc. According to their December 2010 report "more than 6 billion records have been added to the site in the past 14 years. Ancestry users have created more than 20 million family trees containing over 2 billion profiles." [9] The vast majority of the company's data comes from government sources, and, in that same report, they note they have recently added US military cadet applications and U.S. penitentiary records.

Clearly, the vast majority of these birth, death, marriage, immigration, travel and military service records were not created with the intention of being part of a for-profit company's genealogical database. The persons mentioned in them were never asked for permission for these records to be released. They have simply been made available to this company.

Aside from the great convenience of the ancestry.com user interface, privacy compromise in genealogical records is also facilitated by the existence of a common data format for their exchange, GEDCOM, developed for the (Mormon) Church of Jesus Christ of Latter Day Saints which has a huge interest in genealogy.

Are breaches of personal privacy occurring on genealogy sites? Almost certainly. According to a posting by a certified genealogist on rootsweb (hosted by Ancestry.com) "In just one file that I downloaded . . . I found more than 200 names of persons born within the last 70 years." She quotes another report that "I was shocked and dismayed to find that someone had copied my entire GEDCOM and put it up on their Web site. While I have no objection to anyone using my dead ancestors, this person had included the living as well . . ." [START_REF] Gormley | Oxymoron: Privacy and the Internet[END_REF] This author goes on to plead for voluntary restraint in the posting of information relating to living persons:

"We should exercise good manners and respect the privacy of our families --those generous relatives who have shared information with us or who shared with a cousin of a cousin. Additionally, there is another and growing problem --identity theft. Why make it easy for cyberthieves to steal your or a loved one's identity?" [START_REF] Gormley | Oxymoron: Privacy and the Internet[END_REF] In terms of potential commercial misuse of genealogical data, the most commonly cited example is insurance companies who might infer, for example, if all your known relatives died at a young age you might be a poor risk for life insurance. More subtle interactions can also put privacy at risk through informed speculation about genetically-linked medical conditions.

According to a US National Institutes of Health publication, [START_REF]The Value of Genetic and Genomic Technologies[END_REF] a set of gene mutations referred to as Lynch syndrome is linked to colorectal cancer. Identifying it by genetic testing can be helpful in selecting the best treatement. However, individuals who carry this mutation are also susceptible to other cancers. "An insurance company or potential employer who learns that a person carries the mutations that can cause Lynch syndrome now knows that the person is susceptible not only to colon cancer but also to other cancers as well," comments attorney Andrew Spiegel, chief executive officer of the Colon Cancer Alliance. [START_REF]The Value of Genetic and Genomic Technologies[END_REF] Things get even creepier when DNA data is added into the genealogy database, and that is certainly becoming feasible. A 2007 report claimed that ancestry.com was in the process of adding DNA data to its site:

"Ancestry.com intends to launch a DNA testing program to their site by the end of the summer, all for $200 and decrease in personal privacy for your entire family gene pool. Ancestry.com has 24,000 genealogical databases, meaning that your cheek-swab test would be available to anyone with access to their site. Sorenson Genomics is partnering with Ancestry.com on this project." [12] Their DNA testing price has now dropped to $149 USD. Another genetic genealogy site, www.dnaancestryproject.com is also quite sweeping in its scope.

Those who contribute DNA to databases like these, even with the best of intentions, are compromising the privacy (and possibly the insurability, employment prospects, etc.) of themselves and even their family members. As the author at lossofprivacy.com points out, there are very large privacy and confidentiality issues here. "What happens when an insurance company gets a hold of these results and then denies your claims, or even insurance, because you have a possible genetic, pre-existing condition? You might not even have your DNA on file with Ancestry.com, but your sister, brother, mother, father, cousin, etc., might and their results could still tell a lot about you even though you've taken the precaution to not have your DNA in their database." [12] London-based watchdog Privacy International filed a lawsuit against Ancestry.com relating to their use of DNA data, stating that it believes "that the practice substantially violates UK Data Protection law" as well as the European Union Data Protection Directive." [START_REF]PI files complaint about online DNA genealogical testing firm[END_REF] 4 The Implications of De-anonymnization Techniques US legal scholar Paul Ohm notes that, contrary to common belief, computer scientists "have demonstrated they can often 'reidentify' or 'deanonymize' individuals hidden in anonymized data with astonishing ease" [14] and argues that anonymity is much less effective at protecting privacy than is commonly believed. "This mistake pervades nearly every information privacy law, regulation, and debate, yet regulators and legal scholars have paid it scant attention," he writes. Ohm goes on to provide technical and legal suggestions for dealing with the growing ability to deanonymize databases.

There are numerous well known examples of supposedly anonymous data being "deanonymized" by sophisticated analysis. Notable among these are successful attacks on the anonymity of the Tor Network using traffic analysis techniques [START_REF] Abbot | Browser Based Attacks on Tor[END_REF] and the Netflix Prize which offered $1M US for the best algorithm to predict user ratings of movies. Researchers [START_REF] Narayanan | Robust De-Anonymization of Large Sparse Datasets[END_REF] found a way to identify certain individual users in the anonymized dataset released by Netflix, an online video rental company. This resulted in a lawsuit which was settled out of court and the cancellation of plans for a second contest. [START_REF] Albanescius | Netflix Prize Scrapped Over Privacy Concerns[END_REF] Further evidence that the risks of de-anonymization are more than theoretical and definitely apply to governmental data releases come from a recently released paper [START_REF] O'hara | Avoiding the Jigsaw Effect: Experiences with Ministry of Justice Reoffending Data[END_REF] that reports the results of turning three groups of students loose on supposedly anonymized re-offender data from the UK Ministry of Justice (MoJ.) O'Hara and colleagues found that at least one case of supposedly anonymized data was identifiable in conjunction with information on a local news website. This resulted in the data being sent back to the MoJ for further data redactions.

It is also worth noting that as progress is made in this type of analysis, previously released databases that were considered safe from attack may become vulnerable. This prompted one observer to caution that we should "beware of time travelling robots from the future."

A Carpenter is Only as Good as His Tools

Releasing public data sets would be a non-event if there were no tools to retrieve, organize, download and analyze them. Many Open Data projects are incorporating intuitive, easy to use interfaces with their data. Freely available databases such as SQL Lite also play a role here.

A clever tool called ScraperWiki collects Ruby, Python and PHP scripts that people have written for various purposes, thus providing convenient information retrieval across many databases. Available scrapers currently include everything from the zodiac signs of Nobel Prize Winners to the staff directory of employees of the Digital Enterprise Research Institute in Galway, Ireland. This information is all generally available in other forms -the role of the Scraper is to present it in a convenient format and its website www.scraperwiki.com alerts users to what is available, inspiring creativity in data searching.

Open Data competitions and contests as well as "Open Data Hackathons," (physical or virtual meetings where people develop tools and uses for public data) have entered the culture in a big way. David Eaves, advisor to the Mayor of Vancouver, Canada has said that "Open Data competitions are the innovation labs of open data, they are important not only because they foster new applications, but because they can expand our horizons and begin to reveal the depths of our imagination, and the potential of the open data opportunity" [START_REF] Opendatachallenge | [END_REF] Of course there are White Hat and Black Hat Hackathons, and we need to be very concerned about malicious uses of public data that might emerge from the latter.

In his writings, Eaves makes an important point which was raised when a version of the present paper was first presented at the IFIP Summer School on Privacy and Identity, held in Trento, Italy, Sept 5-9, 2011, and also in other venues. Eaves cautions us not to abandon worthwhile Open Data projects simply because the data released might possibly be used in a way that is harmful, illegal or embarassing to someone. In a blog posting [START_REF] Eaves | [END_REF] he likens Open Data initiatives to the building of public roads, which of course can be mis-used by speeders and criminals.

"The opportunity," Eaves writes, "of both roads and data, are significant enough that we build them and share them despite the fact that a small number of people may not use them appropriately. Should we be concerned about those who will misuse them? Absolutely. But do we allow a small amount of misuse to stop us from building roads or sharing data? No. We mitigate the concern." [START_REF] Eaves | [END_REF] Section 7 of the present paper presents some suggestions for such mitigation, as well as references to those who are tackling the privacy risks of Open Data.

The Rise of "Super-Public" Data

A great deal of data about individuals has been "public" for a long time. Documents filed in court cases, such as divorce proceedings, can often be accessed, though it might require a trip to the dusty basement of a small town courthouse. With the rise of the Internet and digital document preparation, all that has changed. As Fertik and Thompson write, "if it happened in the past ten years, it might be online. If it happened in the past five years, it's probably online.

And if it happened in the past two years, it's almost certainly online." They add that "anything that is said online may be available forever, no matter how hard anyone tries to delete it" [START_REF] Fertik | Wild West 2.0: How To Protect and Restore Your Online Reputation on the Untamed Social Frontier[END_REF] Private data aggregation companies such as Alpharetta, GA, (US) based ChoicePoint Systems Inc. have collected data on individuals for many years, going far beyond what credit bureaus keep in their files. They reportedly sent employees to hand copy court records such as divorce proceedings to build up their files, which they resold to prospective employers and others for a substantial fee. ChoicePoint was involved in numerous privacy breach and identity theft scandals and in 2006 was ordered to "pay $10 million in civil penalties and $5 million in consumer redress to settle Federal Trade Commission charges that its security and recordhandling procedures violated consumers' privacy rights and (U.S.) federal laws." [22] The company was purchased in 2008 and is now part of LexisNexis. There is every reason to believe that firms in the data business will freely avail themselves of any data made public by governments and use it as they see fit.

The ease of access to public data, largely driven by open government (and to some extent parallel programs in the private sector,) is qualitatively changing the very nature of public data. What used to be "public" in the sense that you could access it with a great deal of effort such as flying to another city, is now available with a few clicks of a mouse. It seems fair to call this data "super-public" since it is a far cry from what used to be thought of as public data.

Conclusions and Recommendations

Open Data initiatives are very much in the spirit of governmental transparency, open source sharing, and the mantra that "data wants to be free." They are extremely valuable and important, and it is certainly not the intent of this paper to hinder their development.

However, governments do need to think more carefully about the privacy implications of Open Data. They must develop ongoing and effective safeguards to deal with the creativity of the crowd, which may sometimes invade personal privacy. In the long run, this will benefit the Open Government and Transparency movements, since it will build public confidence in these projects and minimize the negative effects of data breaches, which are probably inevitable.

As a minimum, those implementing Open Data projects should: -Scan files carefully for direct PII that may be included; -Consider ways in which PII may be revealed indirectly;

-Act promptly to remove or redact databases that are shown to reveal PII, and retain clear legal rights to do so; -Anticipate the cross-correlation of government data with other databases, public and private; -Provide a convenient mechanism for users to express privacy concerns and ensure proper follow up; -Sponsor hackathons before the data is released to try to foresee unanticipated uses; -Negotiate strong privacy protection on data provided to the private sector;

There are also important roles for NGOs, privacy commissioners and the general public in monitoring the release and use of governmental information, and objecting promptly and loudly when Open Data projects appear to violate commonly understood privacy standards.

A good set of suggestions and list of resources on Open Data Policy can be found at the Civic Commons Wiki [23] but there is much more to be done. There will need to be a thoughtful, evolving balance between data openness and personal privacy and this task will be ongoing as new technologies like facial recognition arrive on the scene.

Acknowledgements

The many helpful comments provided by the Program Committee, reviewers, and participants in the IFIP Summer School on Privacy and Identity, held in Trento, Italy, Sept 5-9, 2011 were very useful in developing this paper. Travel support from the conference and the University of Calgary is also gratefully acknowledged. \