Alexander Gabel
email: ale.gabel@ostfalia.de2i.schiering@ostfalia.de

Ina Schiering

Sandra Verena Müller

Funda Ertas

mHealth Applications for Goal Management Training -Privacy Engineering in Neuropsychological Studies

Keywords: mHealth, privacy, data minimization, pseudonymity, transparency, privacy protection goals, privacy design strategies, goal management training, executive dysfunctions

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Based on recent technological innovations as the Internet of Things (IoT) and smart devices, the potential of digitalization is also utilized in healthcare. Especially the widespread use of smartphones and broadband internet access fosters the trend of mobile applications in healthcare which has the potential to overcome structural barriers, allow for scalability and address the need for interdisciplinary research [START_REF] Becker | mHealth 2.0: Experiences, possibilities, and perspectives[END_REF]. These so called mHealth solutions allow "real-time monitoring and detection of changes in health status" [START_REF] Kumar | Mobile health: Revolutionizing healthcare through transdisciplinary research[END_REF].

On the other hand 44 percent of data breaches happen in healthcare alone [START_REF]Bitglass: The 2014 bitglass healthcare breach report[END_REF][START_REF] Vrhovec | Challenges of mobile device use in healthcare[END_REF]. In an evaluation of mHealth solutions and corresponding studies McKay et al. [START_REF] Mckay | Evaluating mobile phone applications for health behaviour change: A systematic review[END_REF] point out the "lack of information in any of these studies about readability, privacy or security". The privacy risks of connected health devices and the importance of approaches as privacy by design are stated by Allaert et al. [START_REF] Allaert | The tidal waves of connected health devices with healthcare applications: consequences on privacy and care management in european healthcare systems[END_REF]. But in the literature about mHealth solutions privacy is often reduced to informed consent in combination with an ethical approval [START_REF] Vogel | mHealth and application technology supporting clinical trials: Todays limitations and future perspective of smartRCTs[END_REF]).

Although there exist a broad range of reviews and assessments of mHealth solutions stating deficits especially in the area of privacy and information security, in mHealth solutions which are used in clinical studies, privacy and information security are not in the focus of the consideration. Hence this paper presents a case study about privacy engineering in the context of the mHealth solution presented in Section 2. In this context both privacy and data protection as differentiated by the Charter of Fundamental Rights of the European Union [START_REF]Charter of fundamental rights of the european union[END_REF] in Article 7 and 8 are considered [START_REF] Kokott | The distinction between privacy and data protection in the jurisprudence of the CJEU and the ECtHR[END_REF].

The aim of this paper is to realize privacy by design by privacy engineering methodologies in the context of an mHealth project and the accompanying studies. The feasibility of a structured privacy by design approach [START_REF] Hansen | The standard data protection model -a concept for inspection and consultation on the basis of unified protection goals[END_REF], [START_REF] Hoepman | Privacy design strategies[END_REF] for an mHealth solution and accompanying study is evaluated.

In this context an mHealth solution to realize the so-called goal management training (GMT) is considered. GMT is a neuropsychological training used for cognitive rehabilitation of executive dysfunction after a brain injury e.g after a stroke or an accident [START_REF] Levine | Rehabilitation of executive functioning: An experimental-clinical validation of goal management training[END_REF]. The realization of GMT as mHealth solution has the potential to integrate rehabilitation measurements in the daily life of the patients instead of using it solely during therapy sessions as in the traditional approach. To cope with the accompanied privacy risks a privacy by design approach is applied. Privacy risks are identified based on the model of the seven types of privacy by Finn et al. [START_REF] Finn | Seven types of privacy[END_REF] to cope with the variety of privacy aspects in the context of mHealth applications where devices are equipped with a huge variety of sensors as e.g. cameras and GPS localisation. Privacy requirements are modelled based on the concept of privacy protection goals [START_REF] Hansen | The standard data protection model -a concept for inspection and consultation on the basis of unified protection goals[END_REF], [START_REF] Hansen | Protection goals for privacy engineering[END_REF]. These requirements are then detailed in in the architecture and data flow oriented context of privacy design strategies [START_REF] Hoepman | Privacy design strategies[END_REF] where measurements are sketched if possible based on privacy patterns.

Background

Executive Dysfunctions and Goal Management Training

Executive dysfunctions are deficits of brain-damaged patients concerning "the selection and execution of cognitive plans, their updating and monitoring, the inhibition of irrelevant responses and problems with goal-directed behaviour usually result in disorganized behaviour, impulsivity and problems in goal management and self-regulation" [15, p. 17]. To address these disabilities an important therapy is the so-called goal management training (GMT) [START_REF] Levine | Rehabilitation of executive functioning: An experimental-clinical validation of goal management training[END_REF]. The main idea is to divide goals into subgoals and use the resulting list of subgoals to train multistep workflows. These trainings are typically realized based on standard tasks as e.g. proof reading or meal preparation with a pen and pencil approach during therapy sessions. The main steps of GMT are summarized in Fig. 1. Typical study populations in the area of executive dysfunctions consist of 30 to 60 participants with acquired brain injuries, executive dysfunction which are at least 18 years old.

Recent studies which investigate variants of GMT [START_REF] Bertens | Doin' it right: Assessment and errorless learning of executive skills after brain injury[END_REF], [START_REF] Emmanouel | Look at the frontal side of life: Anterior brain pathology and everyday executive function: Assessment approaches and treatment[END_REF] showed that the use of real-life scenarios based on individual tasks relevant to patients foster the motivation of patients. In the traditional paper and pencil approach the use and adaptation of individual tasks is time-consuming. Instead of checking the correctness of the steps after the "Do It" phase in Fig. 1 which could potentially lead to "learning errors", it is recommended to train the workflows based on a documentation e.g. realised by task cards. This approach is called errorless learning.

An mHealth Solution for Goal Management Training

An mHealth solution has the potential to simplify GMT with individual tasks in combination with errorless learning based on a workflow editor and the use of mobile devices for workflow execution. The roles in this scenario, the central process and screenshots of the GMT applications are summarized in Fig. 2.

The central roles are the neuropsychologist as therapist and the patient. The therapist develops and adjusts workflows based on individual tasks in cooperation with the patient using a workflow editor based on a specific customization of The patient can provide direct feedback to the therapist about workflow usage and the impact.

At the moment the therapist only gains information about the time between two therapy sessions which is typically a week by the personal report of the patient. The GMT mHealth solution offers the opportunity to gain insight into this blind spot by collecting outcome measurements on the smart device. Examples are the number of cancelled workflows or workflows which are "clicked through" which means that a certain amount of tasks is clicked within seconds. Both measurements could give hints to problems in daily life to follow goals. On the other hand it is also possible that the patient was very confident about certain workflows and therefore skipped through the information for assurance. Combined with the personal conversation about the results during the therapy session the therapist gains more insight in the progress of the patient. Patients get training concerning GMT in general and the used GMT solution.

Hence behavioural data concerning the workflow execution as a basis for the therapy session is collected whereas typical mHealth solutions collect sensor data as e.g. blood sugar level, heart rate or movement data. Since the user group of people with executive dysfunctions is very diverse with respect to the level of disability, education and technical competence, usability and user acceptance of the solution and of the concepts to ensure privacy and security is very important.

The GMT mHealth solution was developed in cooperation with therapists. Before the practical use in therapy the effectiveness and user acceptance of the solution has to be evaluated. Therefore a pilot study and afterwards an intervention study are planned before the use in therapy. In this context the role of the study team needs to be introduced. To gain first feedback from therapists and patients concerning the proposed GMT solution, a pilot study is planned based on a functional prototype. This prototype does not collect any data and also no outcome measurements. The focus is to get feedback from therapists and patients to improve the solution based on interviews and questionnaires. Afterwards an intervention study is planned to investigate the effectiveness of the approach and to validate the planned outcome measurements. To allow for comparability, which is necessary for the study, the study team needs access to the workflows and a uniform set of outcome measurements connected to a pseudonym of a patient encompassing information about aborted workflows and workflows which are clicked through..

For the use in therapy the patient can choose the level of data collection. Levels which are useful for patients and also the granularity of choice will be investigated in the context of the intervention study. Ideas for such levels are no data collection, collection of the same amount of data as in the intervention study, collect only data about some workflows or collect only statistical data aggregated about all workflows.

Privacy and Legal Regulations in the European Union

Prior the review of mHealth solutions from the literature and privacy modelling of the case study which is the basis of the considerations of this paper, we summarise requirements for privacy based on legal regulations in the European Union. Since the mHealth solution used as a case study in this paper is not classified as a medical device, specific legal regulations for medical devices are not considered.

The basis for the consideration about privacy and data protection in the European Union is the Charter of Fundamental Rights of the European Union [START_REF]Charter of fundamental rights of the european union[END_REF], which considers privacy and data protection in Article 7 and 8. The aspect of privacy is in the focus of Article 7 "Respect for private and family life" stating that "everyone has the right to respect for his or her private and family life, home and communications". Article 8 on "Protection of personal data" has the focus on data protection where in Article 8(1) it says "Everyone has the right to the protection of personal data concerning him or her" and in Article 8 [START_REF] Bakken | Data obfuscation: Anonymity and desensitization of usable data sets[END_REF] this is detailed as "Such data must be processed fairly for specified purposes and on the basis of the consent of the person concerned or some other legitimate basis laid down by law. Everyone has the right of access to data which has been collected concerning him or her, and the right to have it rectified.".

Concerning data protection in the European Union compliance with the General Data Protection Regulation (GDPR) [START_REF] Regulation | 679 of the european parliament and of the council of 27 april 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing directive 95/46/EC (general data protection regulation)[END_REF] is considered which applies from 25 May 2018. The central basis for data protection are summarised in the principles of data protection in Article 5 of GDPR as lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity, confidentiality and accountability.

For the lawfulness of the processing of personal data for an mHealth application and the corresponding intervention study, informed consent of the patients described in Article 6(1) and Article 9(2)(a) concerning health data is needed.

Section 3 details the rights of the data subject concerning rectification and erasure. According to Article 20 there is in addition the right to data portability, and Article 25 demands the realisation of data protection by design and by default. Concerning the security of processing in Article 32 beside the standard technical and organisational measurements the concept of pseudonymisation is mentioned which is an important concept in the context of the planned study. In Article 33, 34 regulations concerning data breaches are stated and Article 35 addresses the importance of a data protection impact assessment.

Privacy and Information Security in mHealth -an overview

Based on the consideration of the legal requirements in the European Union, literature about mHealth is reviewed concerning the investigated aspects of privacy and information security. In the following an overview of scientific literature is considered including the description of mHealth solutions, studies and reviews.

In studies about mHealth solutions typically privacy aspects are only mentioned without further detail. In Volkova et al. [START_REF] Volkova | smart"RCTs: Development of a smartphone app for fully automated nutritionlabeling intervention trials[END_REF] where a Food Label Trial app is investigated in a fully automated trial, it is only mentioned concerning privacy that "Ethical and security requirements have also been considered during the app development". Other studies as e.g. [START_REF] Jenkins | Administering cognitive tests through touch screen tablet devices: Potential issues[END_REF] focus solely on usability and do not even mention information security and privacy issues. Studies as [START_REF] Gamito | Executive functioning in alcoholics following an mHealth cognitive stimulation program: Randomized controlled trial[END_REF], [START_REF] Zmily | Study of the usability of spaced retrieval exercise using mobile devices for alzheimers disease rehabilitation[END_REF], [START_REF] Pfaeffli | A mHealth cardiac rehabilitation exercise intervention: findings from content development studies[END_REF] concentrate on the medical impact and mention at most the existence of an ethics approval. Vogel et al. [START_REF] Vogel | mHealth and application technology supporting clinical trials: Todays limitations and future perspective of smartRCTs[END_REF] confirm this perception by stating that for legal compliance mainly informed consent and an ethical approval is needed, wheras Allaert et al. [START_REF] Allaert | The tidal waves of connected health devices with healthcare applications: consequences on privacy and care management in european healthcare systems[END_REF] point out the importance of privacy by design for mHealth.

A recent trend in mHealth are app ecosystems as e.g. Apple ResearchKit6 and Google Study Kit7 . Based on ResearchKit already studies as the mPower study concerning Parkinson disease [START_REF] Bot | The mPower study, parkinson disease mobile data collected using ResearchKit[END_REF] are performed where in addition the pseudonymised data is stored on Synapse 8 , a general-purpose data and analysis sharing service. Mandl et al. [START_REF] Mandl | Driving innovation in health systems through an apps-based information economy[END_REF] analyse the potential for innovation by standardised app platforms. There the need for regulation and certification especially concerning "accuracy, utility, safety, privacy, and security" is stated. A further analysis of such app ecosystems would be important, but is beyond the scope of this paper.

Although in mHealth studies often privacy is not in the focus of the consideration, Peng et al. [START_REF] Peng | A qualitative study of user perceptions of mobile health apps[END_REF] mention in the context of a user study potential privacy issues of users concerning tracking behaviour and sharing of personal information. Prasad et al. [START_REF] Prasad | Understanding sharing preferences and behavior for mHealth devices[END_REF] investigate user attitudes towards sharing of information and privacy. Evaluations of health apps [START_REF] Huckvale | Unaddressed privacy risks in accredited health and wellness apps: a cross-sectional systematic assessment[END_REF] reveal several deficits concerning privacy and information security. Other evaluations [START_REF] Sunyaev | Availability and quality of mobile health app privacy policies[END_REF] point out the lack respectively poor quality of privacy policies of mHealth apps, and furthermore the lack of regulatory guidelines and supervision [START_REF] Kao | Consumer mobile health apps: Current state, barriers, and future directions[END_REF], [START_REF] Tirman | The current state of mHealth applications and the need for improved regulatory guidelines to protect the privacy of patient health information[END_REF], [START_REF] Ranchordas | MHealth for alzheimer's disease: Regulation, consent, and privacy concerns[END_REF], [START_REF] Mckay | Evaluating mobile phone applications for health behaviour change: A systematic review[END_REF].

Methodologies for Privacy Engineering

A central requirement of the GDPR [START_REF] Regulation | 679 of the european parliament and of the council of 27 april 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing directive 95/46/EC (general data protection regulation)[END_REF] is to implement the principles of data protection by design and by default. Data protection by design respectively privacy by design was first introduced by Langheinrich [START_REF] Langheinrich | Privacy by design-principles of privacy-aware ubiquitous systems[END_REF] in the context of ubiquitous systems, where the intention was to develop guidelines for designing privacy-aware systems based on EU legislation and OECD guidelines. He proposes to investigate the seven areas notice, choice and consent, anonymity and pseudonymity, proximity and locality, adequate security, access and recourse.

In a more general approach Cavoukian [START_REF] Cavoukian | Privacy by design: The 7 foundational principles. Implementation and mapping of fair information practices[END_REF], [START_REF] Cavoukian | Privacy by design: essential for organizational accountability and strong business practices[END_REF] introduced seven principles of privacy by design as a holistic model for privacy integrated in the culture of organisations. The principles proposed there are proactive not reactive, preventative not reactive, privacy as the default, privacy embedded into design, full functionality positive sum, not zero-sum, end-to-end lifecycle protection, visibility and transparency, respect for user privacy.

To realise the central ideas of privacy by design in a concrete mHealth project, we focus on methodologies in the context of privacy engineering. mHealth solutions encompass potentially various smart devices in combination with specialised apps connected to web applications and storing information in backendrespectively cloud services. Hence to start as a methodology for evaluating potential privacy risks of such a complex set of technologies, the model of seven types of privacy [START_REF] Finn | Seven types of privacy[END_REF] is used, which differentiates the several types of privacy risks, as shown in Table 1.

Privacy requirements are modelled based on the description of privacy risks using the model of privacy protection goals [START_REF] Hansen | Protection goals for privacy engineering[END_REF][START_REF] Hansen | The standard data protection model -a concept for inspection and consultation on the basis of unified protection goals[END_REF]. As an extension of the security protection goals confidentiality, integrity and availability the privacy specific protection goals transparency, unlinkability and intervenability are introduced (Fig. 3). To realize the requirements modelled based on these protection goals in a system architecture, privacy design strategies [START_REF] Hoepman | Privacy design strategies[END_REF], [START_REF] Colesky | A critical analysis of privacy design strategies[END_REF] can be utilized in the system design process encompassing minimize, hide, separate, abstract, inform, control, enforce, demonstrate (Fig. 4). 1. Seven types of privacy, as proposed by Finn et al. [START_REF] Finn | Seven types of privacy[END_REF] This system design can be further detailed using privacy patterns. Privacy patterns are reusable solutions to recurring privacy problems [START_REF] Siljee | Privacy transparency patterns[END_REF]. These patterns often encompass security related aspects and they are proposed for different phases of the design process, such as requirements engineering, architecture, design and implementation or quality assurance [START_REF] Lenhard | A literature study on privacy patterns research[END_REF][START_REF] Hafiz | Growing a pattern language (for security)[END_REF][START_REF] Hafiz | A pattern language for developing privacy enhancing technologies[END_REF] Examples include [START_REF] Lenhard | A literature study on privacy patterns research[END_REF] patterns in privacy requirements engineering [START_REF] Kalloniatis | Addressing privacy requirements in system design: the PriS method[END_REF], architectural patterns such as the Data Abstraction or the Privacy Proxy pattern [START_REF] Bier | Common privacy patterns in video surveillance and smart energy[END_REF], as well as patterns for implementation and design such as privacy transparency patterns (Personal Data Table, Privacy Policy Icons) [START_REF] Siljee | Privacy transparency patterns[END_REF] or patterns regarding the protection goal hide (Cover Traffic, Anonymity Set, Layered Encryption) [START_REF] Hafiz | A pattern language for developing privacy enhancing technologies[END_REF]. Furthermore privacy dark patterns are proposed, trying to "deceive and mislead" users for malicious purposes [START_REF] Bösch | Tales from the dark side: Privacy dark strategies and privacy dark patterns[END_REF].

Privacy Engineering in the Context of an mHealth Solution

Privacy Risk Identification

The privacy engineering methodologies presented in Section 5 are applied to the GMT mHealth solution. The central basis for the consideration of privacy risks is the level of data collected for the intervention study described in Subsection 2.2. For the use in therapy after the study the level of data collection can be controlled by the patients. There the patients can also choose not to collect any data. To consider the privacy risks especially in the context of smart devices, the model of seven types of privacy is applied (Table 2). The central risk of the considered mHealth solution for GMT itself is the risk of behaviour tracking by outcome measurements as explained in Subsection 2.2.

In combination with names and descriptions of workflows which are associated with the outcome measurements, it is potentially possible to track behaviour and actions of patients. This is a typical risk of mHealth solutions in neuropsychology, because approaches for behavioural therapy are promising choices for digitalization. Since typical other mHealth solutions focus more on data collection with the help of sensors, the consideration differs in this point. Most of the other privacy risks identified here are associated with the use of smart devices in general. E.g. a personal smart phone of the patient where a broad range of apps is installed. In general it is difficult to control, limit and verify the behaviour of third-party apps on a patients device. An example of risks induced by those apps are the use of advertisement SDKs, which leak private data from the phone, such as call logs or location information, to track the users [START_REF] Bauer | Igexin advertising network put user privacy at risk[END_REF]. Furthermore in 2016 the browser plugin Web Of Trust (WOT) tracked users and sold their personally-identifiable information [START_REF]heise online: Abgegriffene Browserdaten: WOT-Anbieter will Datenschutz-Vorwürfe prüfen[END_REF][START_REF]Daten zu Surfverhalten von Millionen Deutschen als "kostenlose Probe[END_REF]. Since it is difficult to address these risks by technology, an important element of security and privacy measurements is user risk awareness and training which can be integrated in the general GMT training mentioned in Section 2.2.

Based on first feedback by therapists and job coaches there are possible extensions where workflows can also be triggered via location or additional markers such as QR codes. Also in some application areas for workflows it would be important to document the success of the whole workflow or certain steps by images respectively reporting of additional data. These risks are only mentioned here. Since these extensions will not be investigated further in the context of the GMT invention study which is in the center of the consideration here, these risks will not be considered further in this paper.

Modelling with Privacy Protection Goals and Privacy Design Strategies

In the privacy engineering process we model privacy requirements via the use of privacy protection goals (Fig. 3). The risk modelling is based on the risk areas identified with the model of seven types of privacy in Subsection 6.1. To address the modelled privacy protection goals in the system design process, we use privacy design strategies (Fig. 4). The privacy design strategies are considered in the context of the privacy protection goals with a focus on the privacy goals unlinkability, tranparency and intervenability. There the connection between privacy protection goals and privacy design strategies as proposed in Fig. 4 is used to structure the consideration. Based on the description of these strategies, possible measurements are discussed. If possible privacy patterns are proposed.

Confidentiality

Unlinkability: In the context of this use case it is important for therapists respectively the study team to be able to get feedback in terms of outcome measurements linked to a specific patient. The aim to collect personally identifiable data in the context of the GMT mHealth solution, i.e. workflows and associated outcome measurements, is that therapists and the study team get insights in the progress of the therapy of a single patient. Aggregated data about several patients does not make sense to evaluate the progress of a single patient. Because of the number of participants in the intervention study, which is typically between 30 and 60 in the field of GMT [START_REF] Bertens | Doin' it right: Assessment and errorless learning of executive skills after brain injury[END_REF], and data which is collected continuously over a time-frame of several months, full anonymisation would not be not achievable because of the risk of re-identification. Since all measurements need to be connected to patients, full unlinkability is not possible. Therapists need to know the patient, in the context of the intervention study pseudonyms are sufficient.

The four, data-oriented privacy design strategies foster the unlinkability of personally identifiable data to a patient: MINIMIZE: The collection and processing of personally identifiable data should be minimized as much as possible. Hence the modelling of outcome measurements must be restricted to necessary measurements and patients must be trained adequately. Outside of the intervention study patients can choose to store data only on the device of the user (pattern: Personal Data Store [START_REF] Colesky | Privacy patterns[END_REF]). HIDE: Strong pseudonymisation techniques should be applied in the context of the study. An option to share workflows between patients and therapists using the server, which is currently implemented, is to share a private link realised by QR codes. This is also known as the Private Link Pattern [START_REF] Colesky | Privacy patterns[END_REF]. The intended encryption measurements are considered for the goal confidentiality. SEPARATE: In the context of the intervention study it is intended to use a distributed pseudonym table, which is stored on the therapists sides. A similar approach, the so-called Pseudoynm Broker Pattern, which also avoids the use of a central pseudonym table by separation, was proposed by Hillen [START_REF] Hillen | The pseudonym broker privacy pattern in medical data collection[END_REF]. ABSTRACT: In addition to data minimization also the collected data should be abstracted as much as possible by data obfuscation [START_REF] Bakken | Data obfuscation: Anonymity and desensitization of usable data sets[END_REF] respectively statistical disclosure control [START_REF] Hundepool | Handbook on statistical disclosure control[END_REF]. Examples of these techniques are the choice of restricted granularity for time and location information, e.g. instead of storing a timestamp for every "click" of the user to detect clicked through workflows, only a specific feature, i.e. several tasks were clicked within a few seconds, is considered.

Transparency: Transparency is important since the user needs to be informed about the processing of personal data and the rights of the data subject concerning opt-out of the study, deletion, rectification and portability of data to foster trust in the mHealth solution and to comply with legal regulations (Section 3).

INFORM: An important pattern to realize transparency is a Privacy Dashboard [START_REF] Siljee | Privacy transparency patterns[END_REF] [START_REF] Colesky | Privacy patterns[END_REF], which is a central place for privacy information in an application and allows the user in addition also to intervene, i.e. to modify, delete and stop processing of personal data, opt-out of the study. In addition the user needs to be informed about potential data breaches. DEMONSTRATE: Measures as data protection impact assessments, privacy seals respectively certifications are important additional transparency measurements will be potentially considered.

Intervenability: Intervenability in connection with transparency is important to ensure the rights of the data subject. CONTROL: To control processing of personal data and access to it a Privacy Dashboard is intended to be used. During the intervention study opt-out of the study is possible, which could be also stated to the therapist respectively the study team. When used in therapy, also the level of collection of personal data can be adjusted via this planned dashboard. ENFORCE: Access to personally identifiable data needs to be restricted. Workflows are transfered with the help of the Private Link pattern. Access to outcome measurements should only be possible for the responsible therapist and during the intervention study also for part of the study team. This can be realized by role-based access control.

Confidentiality Beside the restriction of access by role-based access control and the use of pseudonyms, information security measurements as encryption are important to ensure confidentiality of the information. HIDE: To strengthen the role-based access control attribute-based encryption is planned to use. In general, this type of encryption needs an authority, which issues keys, certifying certain attributes to each user. In ciphertext-policy attributebased encryption [START_REF] Bethencourt | Ciphertext-policy attribute-based encryption[END_REF], a monotonic tree-access structure can be specified, such that a user has to satisfy a boolean formula of attributes to be able to decrypt a certain ciphertext. This concept could be combined with authenticated encryption to furthermore ensure authenticity and integrity. In addition the secrets involved in encryption and decryption should be kept on the client side (pattern: Encryption with User-Managed Keys [START_REF] Colesky | Privacy patterns[END_REF]).

Availability Standard measurements concerning availability of the server are applied, as e.g. backups, etc. As a work around if the server is unavailable, workflows and outcome measurements can also be exchanged via file transfer. The availability of the mobile device which belongs to the patient is not considered.

Integrity Integrity of communication and data is ensured via TLS, using a profile which also provices MACs. Workflow integrity is ensured by authenticated encryption (cf. confidentiality). Integrity does not have an obvious representative in the design strategies, however one may argue that at least the data controller needs to be aware of data inconsistency to address the problem and inform the user. Hence this can be seen as connected to the process oriented strategies INFORM, CONTROL.

Discussion and Final Remarks

Privacy engineering methodologies proved to give helpful guidelines for the development of mHealth solutions in neuropsychology and the preparation of the accompanying intervention study. Therefore the chosen structured privacy by design approach was very helpful. The general approach as specified in Section 5 can be transferred to mHealth and eHealth projects in general, but as the risk modelling (Subsection 6.1) showed, the risks in these areas differ.

Identifying privacy patterns which are applicable in a certain situation is still an intricate task: Pattern catalogues10 and pattern languages [START_REF] Hafiz | A pattern language for developing privacy enhancing technologies[END_REF] are an important first step, but still whole catalogues have to be checked to find the most appropriate pattern. There is a considerable variety concerning levels of abstraction of privacy patterns. Some patterns merely represent a general idea as the Pseudonymous Identity Pattern [START_REF] Bier | Common privacy patterns in video surveillance and smart energy[END_REF] whereas others focus on very special situations as e.g. the Pseudonym Broker Pattern [START_REF] Hillen | The pseudonym broker privacy pattern in medical data collection[END_REF].

In future work the focus will be the investigation and development of privacy patterns in areas which are important for the mHealth environment investigated here. These areas encompass data minimization including data obfuscation, pseudonymization techniques, key management and key exchange.

Based on these design considerations presented here a detailed system design needs to be developed and the usability of the mHealth solution needs to be investigated in depth encompassing measurements for privacy and security. Beside the mere technical design processes and additional organisational measurements to address the rights of the data subjects, also information and training for patients, therapists and the study team needs to be implemented.

Fig. 1 .

 1 Fig. 1. Main steps of Goal Management Training[START_REF] Levine | Rehabilitation of executive functioning: An experimental-clinical validation of goal management training[END_REF]

Fig. 2 .

 2 Fig. 2. Roles, process and screenshots of GMT mHealth solution

Fig. 3 .

 3 Fig. 3. Privacy Protection Goals in an mHealth scenario

Fig. 4 .

 4 Fig. 4. Privacy Design Strategies

  The more general area of eHealth encompasses beside mHealth applications e.g. information systems as Electronic Patient Records which are difficult to compare.

	a a Privacy type Risk in mHealth scenario a a a a a a a a a a a a a a a	GMT risk by measure-outcome	General risk of smart devices 1	Potential risk of extensions 2
		ments
	Privacy of person
	Privacy of behaviour and action
	Privacy of communication
	Privacy of data and image
	Privacy of thought and feelings
	Privacy of location and space
	Privacy of association

1

e.g. risks from third-party apps user tracking 2 location-based workflows, progress documentation (e.g. photos)

Table 2 .

 2 Types of privacy -privacy risk modelling

https://developers.google.com/blockly/

http://researchkit.org/

https://studykit.google.com

https://www.synapse.org/

https://privacypatterns.org/

Acknowledgment This work was supported by the Ministry for Science and Culture of Lower Saxony as part of SecuRIn (VWZN3224).


Jose M Del Alamo

Yod-Samuel Martín

Julio C Caiza

Towards Organizing the Growing Knowledge on Privacy Engineering

Keywords: Privacy, Data Protection, Software Engineering

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The European Union (EU) General Data Protection Regulation (GDPR) [START_REF]679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data[END_REF], in force since 2016 and mandatory in May 2018, sets an array of binding data protection principles, individuals' rights, and legal obligations to ensure the protection of personal data of EU citizens. But the legal approach is not enough if it does not come along with technical measures to protect privacy and personal data in practice. As it is often said, "[software] code is law": the technological support regulates what we do by favoring, imposing or precluding specific actions, as much as the legal framework does so by allowing, enforcing or banning them. Indeed, the notion that privacy and data protection must be proactively considered since the onset of a project and during the design and development of information systems is captured by the principles of Privacy by Design (PbD) [START_REF] Cavoukian | Privacy by design: The 7 foundational principles. implementation and mapping of fair information practices[END_REF]. This approach was openly embraced by Data Protection Authorities in Europe [3] and worldwide [START_REF]Data Protection and Privacy Commissioners: Resolution on Privacy by Design, 32nd International Conference of Data Protection and Privacy Commissioners[END_REF], and afterwards it has explicitly become legally required by GDPR (rec. 78 and art. [START_REF] Martin | A Metamodel for Privacy Engineering Methods[END_REF].

While there seems to be consensus on the benefits of the privacy and data protection by design approach its realization in engineering processes remains limited due to the divergent approaches taken so far from different disciplines. First, privacy is a multidimensional [START_REF] Ohara | The Seven Veils of Privacy[END_REF], plural [START_REF] Solove | A taxonomy of privacy[END_REF] and essentially contested concept [START_REF] Mulligan | Privacy is an essentially contested concept: a multidimensional analytic for mapping privacy[END_REF], which can thus be subject to multiple reference frameworks e.g. [START_REF] Nissenbaum | Privacy in context: Technology, policy, and the integrity of social life[END_REF] [START_REF]Information technologies -Security techniques -Privacy framework[END_REF]. If engineers find difficulties to deal with abstracts principles coming from regulations, having several different privacy conceptualizations just worsens the problem. From the purely technological arena, solutions have long been researched and elaborated to create Privacy-Enhancing Technologies (PETs) that foster data protection and respond to privacy concerns [START_REF] Heurix | A taxonomy for privacy enhancing technologies[END_REF]. However, PETs remain unknown for most engineers, due to the uncoupling between these technologies and the practice of systematic engineering and development, which makes engineers unaware or unknowledgeable of the proper applicability of such solutions. On top of that, software and systems engineering practices are also varied regarding e.g. the type of information system targeted and the development process followed, and thus preclude having a one-size-fits-all engineering approach for privacy.

In this context, Privacy Engineering is the nascent field of research and practice that aims to address these challenges by reconciling the different approaches and deliver methods to systematically identify and address privacy and data protection concerns throughout the software development process.

This paper describes our proposal for the organization and progress of this emerging field. In particular, we introduce a methodological framework to describe the concepts and elements that underlie the various contributions subsumed under the Privacy Engineering field, following a common model and an agreed vocabulary. We further detail one of such elements that exemplify the knowledge available in practice i.e. privacy design patterns.

From Privacy by Design to Privacy Engineering

For PbD to be viable, engineers must be effectively involved in the loop, as they are ultimately responsible for conceiving, elaborating, constructing and maintaining the systems, services, and software products. Indeed, Data Protection Authorities around the world have also recognized developers and engineers overall as key stakeholders to achieve effective data protection [START_REF]Data Protection and Privacy Commissioners: Warsaw declaration on the "appification[END_REF]. However, despite the interest sparked by PbD in the regulatory arena, it has not yet gained widespread, active adoption in the engineering practice [START_REF] Hadar | Privacy by designers: software developers' privacy mindset[END_REF]. This responds to a mismatch between the legal and the technological mindsets [START_REF] Birnhack | Privacy mindset, technological mindset[END_REF]. Indeed, regulations tend to provide abstract guidance and provisions which are independent of specific technological contexts and can remain applicable as these evolve. However, technical requirements need be more concrete and anticipate the specific scenarios that may unfold. Unfortunately, this mismatch has caused privacy and data protection to be neglected or simply overlooked by most relevant works on data engineering. As a conse-quence, from the engineers' mindset [START_REF] Hadar | Privacy by designers: software developers' privacy mindset[END_REF], privacy and data protection are usually considered just from the perspective of data security, if any; and they tend to rely for compliance on privacy policies rather than on the technical designs and architecture, which they chose instead depending on requirements and constraints other than privacy and data protection.

Furthermore, academic research has consistently shown [START_REF] Balebako | Improving app privacy: Nudging app developers to protect user privacy[END_REF][15] that developers and engineers (who usually are not privacy-savvy at all), find privacy and data protection alien to their work and, most importantly, seldom use privacy management tools, as they find these are more oriented to the legal arena rather than to the engineering activities. Same research has encountered that they will be more akin to take decisions that protect privacy and data protection when the process is embedded within their usual development workflow and tools.

Nonetheless, privacy and data protection regulatory innovations do have an impact on the engineering process. As a matter of example, the right to be forgotten or the right to data portability, besides entitling individuals to request data controllers to honor those rights, entail that the products need to implement any functionalities needed to support the user requests. This has a real impact throughout the development cycle of the product, as it implies, introducing the operational requirements to enforce those rights, modelling the categories of personal data affected, determining the functions and behavior of the system upon the users' requests, and implementing and validating those behaviors. Other regulatory innovations affect directly the process, such as accountability or data protection impact assessment.

We have identified the greatest impact in the following software and systems engineering disciplines:

• Risk management, which supports the execution of privacy and data protection impact assessments from the engineering perspective to identify, assess, evaluate and mitigate risks for the data subjects that may arise from processing activities dealing with their personal data. • Requirements engineering, which supports the operationalization of high-level privacy and data protection goals (e.g. privacy principles, data subjects' rights, obligations of controllers and processors) into design requirements (privacy controls), and their overall systematic specification, management, analysis, traceability, validation and verification. • Modelling, which supports engineers to analyse the systems under development from the perspective of privacy and data protection, and the appropriate choice of solutions (e.g. architecture, privacy patterns, PETs). • Assurance, which supports the demonstration of compliance with the regulation and the observance of the principle of accountability through systematic capture of evidences, their association to requirements and artefacts, traceability to the regulation, and argumentation of compliance derived from those evidences.

The privacy engineering community have proposed dozens of novel contributions fitting in some of these engineering disciplines [16][17]. Even engineering methodologies have been developed [START_REF] Notario | PRIPARE: integrating privacy best practices into a privacy engineering methodology[END_REF][19] [20][21] which define activities that deal with privacy aspects at different stages of the development process. Yet each proposal targets specific aspects of the privacy problem, using different techniques, and following diverse methodologies to suit its own situation. This makes difficult to grasp the adequacy and assess the benefits of any such solution.

To overcome this problem, there is a need to deliver a comprehensive privacy engineering metamodel able to encompass and organize all the components available in the privacy engineering realm, including the different privacy conceptualizations as well as engineering methodologies and their elements. It can be thought of as a labelled rack, to each of whose compartments the contributions on privacy engineering can be anchored. This metamodel will further facilitate:

• The description of the different types of concepts and elements involved in existing privacy engineering methods, following a common model and agreed, shared vocabulary. • The comparison, assessment, interoperability and integration of the distinct elements, both within and outside of the context of the method where they were originally defined, thanks to enrich descriptions of method elements that include welldefined connection hooks. • The communication among privacy engineers, and with the other roles involved in the development process.

Method Engineering is the discipline dealing with these issues as it focuses on "the design, construction and evaluation of methods, techniques and support tools" [START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF]. Different conceptual frameworks have been historically developed for method engineering. All share a set of concepts that allow defining methodologies in compatible terms: processes, activities and tasks that can be executed, people carrying them out, products resulting from their application, and guidelines or constraints that tell how all those should be related in practice. The Software Engineering Metamodel for Development Methodologies (SEMDM), standardized as ISO/IEC 24744 [23], has perhaps been able to best capture all these concepts in its entirety, covering processes, producers (including people) and products, as well as given resources that are applied in a methodology as is (rather than instantiated or enacted). Thus, we build on SEMDM to elaborate our privacy engineering metamodel.

A Privacy Engineering Metamodel

Research has shown that, oftentimes, systems development activities concentrate on delivering the required functionalities at the expense of dismissing other, non-functional requirements (NFRs) [START_REF] Franch | Bridging the gap among academics and practitioners in Non-Functional Requirements management: Some reflections and proposals for the future[END_REF] -such as those dealing with privacy properties. This phenomenon has been observed even in the presence of sizeable academic corpuses that deal with those requirements. Moreover, when NFRs are only considered as an afterthought, if any, to remediate blatant infringements, the correct application of Privacy by Design is eventually hindered. Nonetheless, method engineering has been proposed by same research as an approach to make existing knowledge attractive for practitioners, whose systematic application is cost-effective, whose benefits can be appraised, whose application can be customized, and which can leverage the help of computer-aided software and systems engineering tools. Thus, we propose the systematic application of method engineering to privacy engineering methods so as to facilitate their adoption by engineers. Method engineering allows arranging the different concepts that usually underlie privacy engineering methodologies into a controlled vocabulary of methodological elements and a normalized set of connection points and relationships to organize those. All in all, even though different privacy engineering methodologies exist, all of them can be modelled in terms of the above mentioned SEMDM metamodel. For instance, a given privacy engineering methodology may define:

─ Tasks, which specify what must be done when enacting the methodology, e.g. mapping the types of personal data processed by the system, designing the appropriate architecture, etc. Each methodology will define its own set of tasks. ─ Techniques, which describe procedures that tell how the tasks are to be completed; e.g. analyze a database model, apply a formal architecture analysis method, etc. Depending on the methodology, such techniques can be mandatory, recommended, optional or discouraged. ─ Processes that group related tasks into larger units of work, within a common area of expertise, e.g. privacy impact assessment, application of PETs, etc. ─ Phases of the software and systems application lifecycle where the tasks are applied e.g. inception, analysis, maintenance, operation, etc. ─ Work Products that are consumed as inputs by the tasks and/or produced as their result. Different types of work products include Models (e.g. a dataflow diagram, a misuse case, etc.), Documents (a requirements specification, a risk assessment document), Software products, or even Hardware products. ─ Roles that perform or take part in some of those tasks, e.g. a Data Protection Officer, a systems analyst, a software architect, an external auditor, etc.

It shall be noted that, in any case, a privacy engineering methodology need not be allencompassing (specifying all the tasks, techniques, etc.). They may also require inputs (e.g. a system's architecture) that depend on the results of external tasks, refer engineers to external resources, leave unspecified techniques for some tasks, or even focus only on specific processes or phases. A detailed example of how a particular privacy engineering methodology (LINDDUN) can be described in terms of the SEMDM metamodel may be found at [START_REF] Martin | A Metamodel for Privacy Engineering Methods[END_REF].

Even though the SEMDM metamodel may cater for a large variety of methodologies, non-functional requirements may entail the addition of new elements into the metamodel. In our case, and in order to deal with privacy NFRs, we have extended SEMDM with a set of Resources that are usually encountered in privacy engineering methods. In SEMDM, a Resource is a methodology element to be used 'as is' at the project level, without requiring any instantiation. In particular, and in order to take privacy into account when designing systems, engineers can be provided with four kinds of Resources, each of them dealing with privacy from different, complementary perspectives (Table 1). A Privacy Conceptual Model (PCM) deals with privacy from an ontological perspective. Any privacy engineering method is framed by and grounded on a particular, underlying theory of privacy (even if different, competing theories currently exist). That theory describes the essential concepts of privacy in terms of principles, harms, goals, etcetera; as well as it defines the subject and the object of privacy itself. Often (but not always) the concept of privacy is partitioned into a list of unitary concepts. For instance, ISO29100 privacy framework [START_REF]Information technologies -Security techniques -Privacy framework[END_REF] provides a list of fundamental, privacy principles, besides defining personal information, actors involved and their interactions, etc. Or, LINDDUN [START_REF]LINDDUN homepage[END_REF] methodology defines nine privacy properties in opposition to seven threat categories.

A Privacy Normative Framework (PNF) deals with privacy from a deontological perspective. Many privacy engineering methods claim to abide by some binding regulations (established by e.g. laws, quasi-and co-regulations, binding policies, etc.) or non-binding recommended best practices. These prescribe both constraints that refer to the application of the method itself (e.g. impose the existence of specific method elements, or that they be applied according to a precise temporal order), and requirements that refer to the products created when the method is enacted. For example, the EU GDPR requires (in certain cases, and among others) that:

• a Data Protection Officer (DPO) is nominated who performs specific tasks (e.g. monitoring compliance, training, etc.); • an impact assessment process is carried out before processing any personal information; • technical measures are implemented so as to ensure confidentiality, integrity, availability and resilience of processing systems and services.

Note that GDPR defines as well a set of principles for personal data processing which are not part of the PNF, but rather of a PCM, even if defined within the same document.

A Privacy Engineering Code (PEC) deals with privacy from a situational perspective. There exist many codes of conduct and codes of practice which provide different sets of guidelines that document how normative requirements can be better applied on specific contexts or situations, thus refining or clarifying the application of the corresponding PNF. The compliance with such codes can be usually subject to audits.

A Privacy Knowledge Base (PKB) deals with privacy from an epistemological perspective. The community of practice and research of privacy engineering has developed an amount of generally recognized knowledge, whose value and usefulness are collectively endorsed for their application by privacy engineering practitioners. This knowledge is sometimes compiled into repositories, modelled according to a homogeneous template, and arranged into a structure that facilitates their systematic application. Such PKBs have been defined which gather e.g. privacy design strategies [START_REF] Hoepman | Privacy Design Strategies[END_REF], privacy threats [START_REF]LINDDUN homepage[END_REF], and privacy design patterns [START_REF]PrivacyPatterns homepage[END_REF].

Indeed, the PKBs of privacy design patterns particularly illustrate the usefulness of having systematic, reusable knowledge at hand, as advocated by method engineering proponents. A privacy design pattern (privacy pattern for short) provides a commonly applied, well-proven design solution to common privacy problems in particular contexts. Further, privacy pattern repositories gather patterns endorsed by the community and provide navigation mechanisms that allow engineers to easily choose the most appropriate design solution(s) to apply whenever they need to cope with privacy issues in a specific context. Next section elaborates in detail into privacy patterns and their repositories.

Privacy Design Patterns

Patterns researchers have defined a path to improve their applicability in system's development: patterns collections can evolve from being mere patterns catalogs, through patterns systems, until achieving a pattern language level [START_REF] Buschmann | Pattern-Oriented Software Architecture: A System of Patterns[END_REF]. Each provides more operationalization benefits than the previous one. A pattern catalog maintains together and classifies a set of design patterns. A pattern system goes further and presents a set of patterns with a uniform structure, some relationships between them, and as sufficient base to build the foundations of an information system. Finally, a pattern language should eventually support the complete construction of an information system, but in a very specific domain.

The state of the art already includes different contributions on privacy design patterns. Some authors have identified single patterns [START_REF] Romanosky | Privacy Patterns for Online Interactions[END_REF] [START_REF] Fernandez | Two Patterns for HIPAA Regulations[END_REF]; other have proposed catalogs of privacy patterns classified by different approaches [START_REF]PrivacyPatterns homepage[END_REF]; and there has been even a pattern language proposal revolving around anonymity [START_REF] Hafiz | A Pattern Language for Developing Privacy Enhancing Technologies[END_REF].

The existing privacy pattern catalogs have remained isolated and approached from different perspectives for classification and implementation. For instance, Colesky et al. classify patterns according to strategies and tactics [START_REF] Colesky | A Critical Analysis of Privacy Design Strategies[END_REF], while Drozd uses ISO 29100 privacy principles [START_REF] Drozd | Privacy pattern catalogue: A tool for integrating privacy principles of ISO/IEC 29100 into the software development process[END_REF]. In an attempt to generate a uniform knowledge base for privacy engineering practice, some authors have joined efforts to set up a common repository of privacy patterns, which could be used as a toolbox to help system designers.

The efforts of this community have concentrated in gathering the privacy patterns together, describing them according to an agreed template, and using a common categorization schema for their classification [START_REF]PrivacyPatterns homepage[END_REF].

As part of this community, we have evolved a part of this catalogue into a system of patterns. To this end we have (1) proposed a taxonomy of types of relationships to describe the patterns connections [START_REF] Caiza | Organizing Design Patterns for Privacy: A Taxonomy of Types of Relationships[END_REF], (2) dug into the available patterns to identify these connections, and (3) built a patterns system out of the individual patterns [START_REF] Colesky | A System of Privacy Patterns for User Control[END_REF]. Table 2 enumerates and describes a sample of patterns focused on the selective disclosure of personal data. Fig. 2 further shows the relationships identified.

Pattern name Pattern description

Buddy List Use a short list of close and trusted contacts for the user and allow the expansion of the list. Enable/Disable Functions Allow the users to define which functions (and provided data) they require inside an application.

Decoupling Content and Location

Allow the users to configure the privacy level of location to be disclosed associated to a content depending on the context.

Discouraging Blanket Strategies

Give the users a range of possibilities to select the privacy level associated to a content to be shared.

Negotiation of Privacy Policy

Allow the users opt-in and opt-out in the privacy configuration since the beginning of the service use.

Reasonable Level of Control

Give the users a selective control on the information they provide and to whom. Explore push and pull mechanisms for achieving this goal.

Selective Access Control

Allow the users to specify (granularly) the audience for the content during and after sharing.

Support Selective Disclosure

Instead of the massive collection of personal data, even before the use of a service, allow the users to configure the privacy level they feel comfortable with before, during and after sharing content.

Conclusion

Regulation asks engineers to stick to Privacy by Design principles and apply data protection solutions throughout their projects. However, to accomplish that, engineers demand methodological elements that are closer to their mindset, and allow them to systematically introduce such solutions within the workflow and environment they are accustomed to. This paper has introduced a conceptual model to organize the growing number of methodological elements already available for privacy engineering, and has further elaborated on privacy pattern systems as means to gather systematic, reusable knowledge.

Our next steps point towards introducing some of these privacy engineering methodological elements into existent mainstream software engineering methods and tools, so as to ease their adoption by engineers even when they are not savvy in the privacy field. This is aligned with the recommendations issued by the EU Agency for Network and Information Security (ENISA) [START_REF] Danezis | Privacy and Data Protection by Design-from policy to engineering[END_REF]: "Providers of software development tools and the research community need to offer tools that enable the intuitive implementation of privacy properties.".

Fig. 1 .

 1 Fig. 1. Privacy patterns for the selective disclosure of personal information.

Table 1 .

 1 Types of resources provided by privacy engineering methodologies.

	Resource	Privacy	Privacy	Privacy	Privacy
		Conceptual	Normative	Engineering	Knowledge Base
		Model (PCM)	Framework	Code (PEC)	(PKB)
			(PNF)
	Perspective Ontological	Deontological	Situational	Epistemological
	Source	Theory of	Binding	Codes of	Community of
		privacy	regulations, non-	conduct, codes	practice,
			binding best	of practice	repositories
			practices
	Purpose	Describes	Prescribes	Refines,	Compiles,
				clarifies,	arranges, endorses
				documents
	Contents	Essential	Method	Guidelines	Applicable
		concepts	constraints and		knowledge models
			product
			requirements

Table 2 .

 2 Patterns supporting the selective disclosure of personal information.

Acknowledgements

This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 731711 and from the Spanish Government's Agencia Estatal de Investigación under grant agreement No EUIN2017-87180.


Aderonke Busayo Sakpere

Anne V D M Kayem

On Anonymizing Streaming Crime Data: A Solution Approach for Resource Constrained Environments

A typical resource constrained environment is restrained in terms of availability of resources such as skilled personnel, equipments, power and Internet connectivity. Designing privacy-based service-oriented architectures therefore requires re-adapting existing solutions to cope with the constraints of the environment. In this paper, we consider the case of mobile crime-reporting systems that have emerged as an effective and efficient data collection method in developing countries. Analyzing the data, can be helpful in addressing crime but, law enforcement agencies in resource-constrained contexts typically do not have the expertise required to handle these tasks. A possible cost-effective strategy is thus to outsource the data analytics operations to third-party service providers. However, the sensitivity of the data makes privacy an important consideration. In this paper we propose a two-pronged approach to addressing the issue of privacy in outsourcing crime data in resource constrained contexts. We build on this in the second step to propose a streaming data anonymization algorithm to analyse reported data based on occurrence rate rather than at a preset time on a static repository. Results from our prototype implementation and usability tests indicate that having a usable and covet crime-reporting application encourages users to declare crime occurrences and anonymizing streaming data contributes to faster crime resolution times.

Introduction

While organizations generate data that can contribute to improving performance daily, many of these organizations do not have the in-house expertise required to analyse the data. The lack of expertise is prominent in resource constrained environments manifested in rural/remote developing world regions, for instance, where constraints on resources such as access to computational power, reliable electricity, and the Internet pose a further challenge. A cost-effective solution is to outsource the data to a professional third-party data analytics service provider.

A study [START_REF] Isafiade | Citisafe: Adaptive spatial pattern knowledge using fp-growth algorithm for crime situation recognition[END_REF] carried out in technologically resource-constrained environments has revealed that collected crime data are usually not studied or analysed to support crime resolution. A possible reason for this is the lack of the necessary in-house expertise, both in terms of human capital and computational processing power [START_REF] Jensen | Toward an mPolicing solution for Namibia: leveraging emerging mobile platforms and crime mapping[END_REF][START_REF] Sakpere | A Usable and Secure Crime Reporting System for Technology Resource Constrained Contexts[END_REF][START_REF] Burke | Enabling anonymous crime reporting on mobile phones in the developing world[END_REF]. This deprives policy makers in these regions of the benefits that could have been derived through data analytics. A possible solution to this is to involve a third-party data analytics service provider [START_REF] Isafiade | Citisafe: Adaptive spatial pattern knowledge using fp-growth algorithm for crime situation recognition[END_REF][START_REF] Qiu | Protecting business intelligence and customer privacy while outsourcing data mining tasks[END_REF]. However, because of the sensitive nature of crime data it makes sense to ensure that the outsourced data are protected from all unauthorized access including that of an honest-butcurious data mining service provider. Therefore, this paper focuses on developing a test bed framework to preserve privacy during real-time information sharing using the crime domain as an application scenario. However, it is important to stress that the ideas and approaches considered in this study are applicable to other areas or domains as well.

Related Work

A naive approach to preserve privacy or anonymity in data is to exclude explicit identifiers such as name and/or identification number. However linking attacks aimed at data deanonymisation, can be provoked successfully by combining non-explicit identifiers (such as date of birth, address and sex) with external or publicly available data [START_REF] Zakerzadeh | Delay-sensitive approaches for anonymizing numerical streaming data[END_REF][START_REF] Wang | Privacy protection on sliding window of data streams[END_REF][START_REF] Li | Anonymizing streaming data for privacy protection[END_REF]. To illustrate how a linking attack can be provoked, let us consider Figure 1, which shows two compartments (or storage) that contains data. The upper compartment contains a portion of a publicly available table in which name is an explicit identifier attribute and the lower compartment shows a portion of a data stream that has been sanitized to exclude explicit identifiers (name) in order to disguise the identities of the individuals associated with the data. However, when a joining operation is performed on both compartments using attributes common to both compartments, the supposedly anonymized individual is re-identified successfully as Ade who lives at 10 Pope Street and also revealing her sensitive information that she has been a victim of rape.

According to Sweeney [START_REF] Sweeney | k-anonymity: A model for protecting privacy[END_REF][START_REF] Sweeney | Achieving k-anonymity privacy protection using generalization and suppression[END_REF] 87% of the population in the United States were uniquely identified by the combination of non-explicit identifiers such as gender, zip code and date of birth from the 1990 census dataset using linking attack. Therefore, Sweeney et al. came up with a better approach named kanonymity to anonymize data in a manner that linking attack is minimized.

K-anonymity ensures privacy is preserved by hiding each individual in a cluster which contains at least k individuals such that an adversary finds it difficult to get additional individual information, but rather information about a group of k individuals [START_REF] Sweeney | k-anonymity: A model for protecting privacy[END_REF][START_REF] Sweeney | Computational Disclosure Control: A Primer on Data Privacy Protection[END_REF]. To understand how k-anonymity works, let us assume an attacker tries to identify a friend in a k-anonymized table, but the only information he has is her birth date and gender. K-anonymity ensures that the adversary finds it difficult to identify the individual by guaranteeing that at least k people have the same date of birth and gender. Thus minimizing the rate of linking attack to at least 1/k. K-anonymity algorithms can generally be grouped into two categories, namely hierarchy-based generalization and hierarchy-free gener-Fig. 1: Illustration of Linking Attack alization [START_REF] Zakerzadeh | Delay-sensitive approaches for anonymizing numerical streaming data[END_REF]. In the hierarchy-based generalization, data anonymization requires a generalization tree as an input to aid in the anonymization process while in the hierarchy-free generalization, generalization tree is not required as an input rather the algorithm makes use of clustering concepts and some heuristics.

The evolution of k-anonymity has led to the birth of newer privacy models to address its inherent limitation. Some of the popular and newer privacy models that extend k-anonymity are -diversity and t-closeness [START_REF] Machanavajjhala | l-diversity: Privacy beyond k-anonymity[END_REF][START_REF] Li | t-closeness: Privacy beyond kanonymity and l-diversity[END_REF]. The main essence of -diversity is to address homogeneity attack to which k-anonymity is vulnerable and it does this by requiring that each cluster in a k-anonymized table has at least distinct sensitive values [START_REF] Machanavajjhala | l-diversity: Privacy beyond k-anonymity[END_REF]. T-closeness further complements -diversity by ensuring that distribution of sensitive values in a cluster is similar to that of the entire anonymized table [START_REF] Li | t-closeness: Privacy beyond kanonymity and l-diversity[END_REF].

An equally fast-growing data preservation technique is differential privacy. Differential privacy achieves anonymization by altering the data (i.e. unanonymized data) with the addition of mathematical noise [START_REF] Dwork | Differential privacy[END_REF]. In other words, differential privacy preserves privacy through the difference between the data supplied and the noise added to it. Interestingly, recent research [START_REF] Soria-Comas | Differential privacy via t-closeness in data publishing[END_REF] [START_REF] Domingo-Ferrer | From t-closeness to differential privacy and vice versa in data anonymization[END_REF] has shown that the use of t-closeness with k-anonymity can yield similar privacy result as those of differential privacy. In this research we focus on k-anonymity and its complementary techniques because of the simplicity [START_REF] Machanavajjhala | l-diversity: Privacy beyond k-anonymity[END_REF], effectiveness [START_REF] Sweeney | Achieving k-anonymity privacy protection using generalization and suppression[END_REF] and high utility [START_REF] Soria-Comas | Differential privacy via t-closeness in data publishing[END_REF] offered, especially when compared to an evolving counterpart such as differential privacy. In addition, recent research [START_REF] Soria-Comas | Differential privacy via t-closeness in data publishing[END_REF] [33] has shown that differential privacy is achieved as long as a dataset is anonymized using k-anonymity and t-closeness. Therefore this paper focuses on the use of k-anonymity, -diversity and t-closeness to achieve anonymization.

The adaptation of k-anonymity & its complementaries to data stream (realtime data) has led current research to integrate the concept of a buffering (or sliding window) mechanism and delay constraint into data stream anonymization [START_REF] Zakerzadeh | Delay-sensitive approaches for anonymizing numerical streaming data[END_REF][START_REF] Wang | Privacy protection on sliding window of data streams[END_REF][START_REF] Li | Anonymizing streaming data for privacy protection[END_REF][START_REF] Guo | Fast clustering-based anonymization approaches with time constraints for data streams[END_REF][START_REF] Cao | Castle: Continuously anonymizing data streams[END_REF][START_REF] Zhang | KIDS: K-anonymization data stream base on sliding window[END_REF]. The buffer is designed to hold a portion of the data stream at every instant of time, after which an anonymization algorithm can be applied to data in the buffer. Delay constraints is required to put a check on each tuple so that it does not stay in the buffer beyond a pre-defined deadline. Inspite of this, many of the existing algorithms adapted for anonymization of data streams face the following challenges:

-First, buffering according to delay constraints, can result in certain records being held in the buffer for long periods [START_REF] Zakerzadeh | Delay-sensitive approaches for anonymizing numerical streaming data[END_REF][START_REF] Mohammadian | Fast: fast anonymization of big data streams[END_REF][START_REF] Sakpere | Adaptive buffer resizing for efficient anonymization of streaming data with minimal information loss[END_REF]. When such records are timesensitive or need to be processed in real time, occurrence of delay usually results in high levels of information loss. Since a key requirement of a good anonymization scheme is high data utility, high levels of information loss due to expired tuples or dropped (or suppressed/unanonymizable) records are undesirable. -Second, building on the first problem, we note that many of the existing data stream anonymization schemes based on k-anonymity and its derivatives do not take distribution of future data streams into consideration during anonymization [START_REF] Guo | Fast clustering-based anonymization approaches with time constraints for data streams[END_REF]. An implication of this is that a record that is likely to offer better anonymization at a lower rate of information loss in a future sliding window or data stream can be anonymized with such a future sliding window rather than the current sliding window or data stream. Therefore, there is a need to have a model that can predict the best sliding window or stream with which a record should be anonymized.

Therefore, the focus in this paper is to present a data-stream anonymization framework that addresses the aforementioned challenges inherent in existing framework. More detailed literature review can be found in [START_REF] Sakpere | A state of the art review of data stream anonymisation schemes[END_REF].

Data Stream Anonymization Framework

Figure 2 presents an overview of our Data Stream Anonymization Framework using the crime domain as an application scenario. Users make crime reports electronically and the reports are anonymized in real time at the anonymization layer. The results from the anonymization layer are transferred to third party for data mining process at the application layer.

Users Layer: Crime Reporting Layer

As noted in previous sections, this research considers the crime domain as an application scenario for achieving data stream anonymization. However, the ideas in this research extend to any other domain that requires real-time anonymization of sensitive data. Thus, to enable us to create an application that allow people to report crime in a secured and covert way, we converted the existing paper-based crime reporting system of a University Campus Setting in South Africa into a digitized Crime Reporting System. We chose to use mobile device Fig. 2: System Overview as platform for crime reporting because the use of mobile devices provides a good security platform for crime report [START_REF] Lasley | When crime reporting goes high-tech: An experimental test of computerized citizen response to crime[END_REF] [START_REF] Lewis | IBM computer usability satisfaction questionnaires: psychometric evaluation and instructions for use[END_REF].

In order to ensure that our mobile crime reporting system is acceptable and usable in real-life we applied an iterative user-centered design methodology. To this effect we interviewed different key stakeholders within law enforcement agencies and crime victims. We had different iterations in our design until we came up with a final prototype acceptable to all stakeholders. Figure 3 presents the screenshots of our final prototype. More details about the research on the development and deployment of the crime reporting application,CryHelp, can be found in [START_REF] Sakpere | A Usable and Secure Crime Reporting System for Technology Resource Constrained Contexts[END_REF].

Anonymization Layer: Data Stream Anonymization

In our proposed crime reporting application scenario, data arrives in form of streams and contains information that is analyzed for statistical or data mining predictions. These data are temporarily stored in a buffer in order for anonymization to take place. A buffer is used to hold portions of the continuous data stream based on delay constraints that specify the duration for which tuples can remain in the buffer just before anonymization takes place. As illustrated in Figure 4, the buffer optimizer uses time-based sliding window and Poisson probability to monitor the data in the buffer, ensuring that tuples are anonymised before the expiry time threshold is reached while Figure 5 illustrates the data anonymizer which uses k-anonymity, -diversity and t-closeness for data privacy preservation. We opted for Poisson distribution because it is concerned with the number Fig. 3: Screenshot of our Crime Reporting Application of success that occurs within a given unit of measure. This property of the Poisson distribution makes viewing the arrival rate of the reported crime data as a series of events occurring within a fixed time interval at an average rate that is independent of occurrence of the time of the last event [START_REF] Li | Poisson process with fuzzy rates[END_REF]. Only one parameter needs to be known, the rate at which the events occur which in our case is the rate at which crime reporting occurs.

Buffer Optimizer

Time-Based Sliding Window Poisson Probability

Adaptive Buffer Re-Sizing Scheme

As illustrated in Figure 6, a "sliding window (buffer)", sw i , is a subset of the data stream, DS, where DS = {sw 1 , sw 2 , sw 3 ,..., sw m } implies that the data stream consists of m sliding windows. The sliding windows obey a total ordering such that for i < j, sw i precedes sw j . Each sliding window, sw i only exists for a specific period of time T and consists of a finite and varying number of records, n, so that sw i = R 0 , ..., R n-1 . Our adaptive buffer sizing scheme as illustrated in figure 7 is categorized into 6 phases and detailed explanation about how each of these phases work is in our earlier publication [START_REF] Sakpere | Adaptive Buffer Resizing for Efficient Anonymization of Streaming Data with Minimal Information Loss[END_REF]. We summarize these details as follows. First we begin by setting the size of the buffer to some initial threshold value. Given the time-sensitivity of the data, we set the size of the sliding window, sw i , to a value, T . T is a time value that is bounded by a lower bound value, t l , and an upper bound value, t u . The anonymization algorithm is applied to the data that was collected in the sliding window sw i during the period T . So, essentially sw i = T . All records that are not anonymizable from the data collected in sw i are either included in a subsequent sliding window, say sw i+1 or incorporated into already anonymized clusters of data that are similar in content wise.

Data Anonymizer k-anonymity l-diversity t-closeness

In order to determine whether or not an unanonymizable record can be included in a subsequent sliding window, say sw i+1 , we compute its expiry time T E and compare its values to the bounds for acceptable sliding window sizes [t l , t u ]. We compute T E as follows: where T E is the time to expiry of a record , T S is the time for which the record was stored in sw i , and T A is the time required to anonymize the data in sw i .

T E = sw i -T S -T A ...(
Starting with the unanonymizable record, R i , that has the lowest T E and whose value falls within the acceptable bound, [t l , t u ], we check for other unanonymizable records, n, that belong to the same data anonymization group as R i . We then proceed to find the rate of arrival, λ, of data in that anonymization group. We compute the arrival rate of records required to anonymize R i within time T E as follows:

λ = n sw 1 × T E ...( 2
)
The expected arrival rate, λ, is used to determine the probability of arrival of at least the number of records needed to guarantee that delaying anonymizing the unanonymizable record, R i , to the next sliding window sw i+1 will not adversely increase information loss. We next determine the minimum number of records, m, required to guarantee anonymization of R i in the next sliding window, sw i+1 . When the decision is to include the R i into the next sliding window sw i+1 , we need to then compute the optimal size for sw i+1 in order to minimize information loss from record expiry. We achieve this by finding the probability that m records will actually arrive in the data stream within time, T E , in order to anonymize the unanonymizable record, R i . We use equation 3 to compute the probability of having i = 0...m records arrive in the stream within

T E f (sw i+1 , λ) = Pr (i = 0 .... n) = λ i e -λ i! ...( 3
)
where λ is the expected arrival rate, e is the base of the natural logarithm (i.e. e = 2.71828) and i is the number of records under observation.

Therefore the probability of having greater that m or more records arrive in the stream within time

T E is 1 - m-1 i=0 pr ...( 4
)
where pr is the probability outcome of equation 3. If the result of equation 4 is greater than a preset probability threshold, δ, we set the size of the subsequent sliding window, sw i+1 , to the expiry time of the unanonymizable record under consideration. We then mark the unanonymizable record for inclusion in the subsequent sliding window along with other unanonymizable records that have their T E within bounds for acceptable sliding window sizes [t l , t u ]. In the event that the probability of all unanonymizable records is less than the preset probability threshold, we set the subsequent sliding window size to a random number within the time bound, [t l , t u ]. More detailed explanation of the adaptive buffer scheme can be found in our previous work [START_REF] Sakpere | Adaptive Buffer Resizing for Efficient Anonymization of Streaming Data with Minimal Information Loss[END_REF].

Experiments and Results

This section presents the implementation and results of the crime-reporting Application, CryApp, and the adaptive buffering scheme algorithm.

CryHelp Application Evaluation

In order to evaluate the usability of our mobile crime reporting application, CryHelp, we developed a questionnaire. The questionnaire was based on IBM CSUQ [START_REF] Lewis | IBM computer usability satisfaction questionnaires: psychometric evaluation and instructions for use[END_REF]. The advantage of the IBM CSUQ [START_REF] Lewis | IBM computer usability satisfaction questionnaires: psychometric evaluation and instructions for use[END_REF] is that it allows questionnaires to be divided into scores and specific categories. These categories are: System Overall, System Usefulness, Information Quality and Interface Quality. These categories allow evaluation of each individual component of the system to gauge which aspects perform well or poorly on average. These results directly address the issue of whether a mobile device can be used to effectively and securely send a crime report.

Figure 8 shows the result of each component of the system. From the figure, it can be seen that overall the system was well received with an overall system score of 77.06%, this suggests the users found the system very usable with a standard deviation of 0.05 for contributing scores System Use, Information Quality and Interface Quality. It is not surprising to find that the interface quality (78.33%), though marginally, is the most appreciated aspect of the system as the design process was centered on the users. These results bode very well for the feasibility of a mobile solution for crime reporting.

Experiments on Anonymization

Our feasibility study and experiment conducted on the prototype crime data collection application, CryHelp [START_REF] Sakpere | A Usable and Secure Crime Reporting System for Technology Resource Constrained Contexts[END_REF], informed the generation of more datasets for the second phase of experiment. The generation of more crime data was done using a random generator software1 and pseudo-random algorithm based on a Gaussian distribution to populate the crime data-stream based on ground-truth provided by the users, UCT Campus Protection Service and the South African Police Service. Our data are in two sets, which contain 1000 and 10 000 records respectively, the first set contains 1000 records while the second set contains 10000 records, this is a reasonable bound for daily average crime report rates in South Africa [START_REF] Sakpere | A Usable and Secure Crime Reporting System for Technology Resource Constrained Contexts[END_REF].

Therefore, this section discusses the gains obtained using Poisson probability distribution to predict the time a sliding window should exist, while ensuring that records do not expire, the number of unanonymizable (or suppressed) records is minimal and privacy is maintained using k-anonymity, -diversity and t-closeness. The gains obtained are explained in the following sub-sections:

Recovered Unanonymizable Tuples: During anonymization there is usually a trade-off between the rate of IL, suppression and generalization. Usually if an equivalence class (cluster) is unable to satisfy the privacy requirement, such a class is either merged with another class or all its records are suppressed. A higher suppression rate implies that vital information is likely to be concealed from the recipient of the anonymized table, while merging of classes implies an increase in IL, which has the drawback of offering lower data utility. In order to curb this, Poisson probability distribution predicts the chances of such unanonymizable (suppressed) records undergoing anonymization in the next sliding window in a manner that preserves privacy and maximizes data utility with the goal of minimizing delay or expiration of records.

Figures 9 and10 show the rate at which unanonymizable records were anonymized again, going by the predictions of Poisson probability distribution. It is evident from the figure that many unanonymizable records were recovered and allowed to go for anonymization again. It was also observed that the probability threshold influenced the number of unanonymizable records recovered. This leads to the conclusion that the higher the probability threshold, the lower the probability of unanonymizable records being given a chance for anonymization re-consideration in subsequent sliding window(s). The implication of this is that more records are likely not to be given the chance of another round of anonymization if higher threshold values are used. Another observation is that if a higher threshold value is used, then there are fewer changes or movements in records between sliding windows. Fig. 9: Poisson Probability Threshold Versus Recovered Tuples for Dataset 1 Privacy Value/Level versus Recovered Unanonymizable Tuples: "Privacy level" simply means the degree of anonymity offered, while unanonymizable tuples are those tuples that belong to an equivalence class whose size is less than k. For the purpose of sliding windows that start with a small number of tuples, the minimum privacy level threshold was set as k =2 and the maximum at k = 15; the -diversity value, , was varied between values 3 and 5 and finally the t-closeness value, t, was alternated between values 0.1 and 0.15 for the two datasets.

As illustrated in Figures 11 and12, it was observed that as the privacy value/level increases, the possible number of unanonymizable records that can be recovered using Poisson probability prediction is reduced. The main reason for this is that as the privacy level or degree increases, it is expected that the rate or possibility of achieving anonymization will become increasingly challenging. This definitely also influences the expectation of higher chances of anonymization rate for unanonymizable records. To understand the reason for the decline in the rate of recovered unanonymizable records better, let us assume the k privacy level is set to three and an equivalence class, EC i , has two records; this implies that we are looking for at least one more record to make EC i satisfy k-anonymity. In essence, using Poisson probability, the adaptive buffer resizing model attempts to predict the chance of at least one record in EC i arrive within time, t, in the next sliding window. If k is set to four, this will mean the chance of at least two records arriving in the next sliding window. An implication of this is that the chances of having at least two records is more difficult or demanding compared to the chances of just one record. Thus, this explains why the model has a drop in recovered unanonymizable records as privacy level increases. Therefore, the conclusion is that the rate at which unanonymizable records in a current sliding window can be anonymized in a subsequent window is mainly dependent on the privacy value. As a baseline case, for evaluating our proposed adaptive buffering scheme we implemented the proactive-FAANST and passive-FAANST. These algorithms are a good comparison benchmark because they are the current state-of-the-art streaming data anonymization and reduce IL with minimum delay and expired tuples [START_REF] Zakerzadeh | Delay-sensitive approaches for anonymizing numerical streaming data[END_REF]. The proactive-FAANST decides if an unanonymizable record will expire if included in the next sliding window, while passive-FAANST searches for unanonymizable records that have expired. A major drawback of these two variants is that there is no way of deciding whether or not such unanonymizable records would be anonymizable during the next sliding window. This is necessary to avoid repeatedly cycling a tuple that has a low chance of anonymization in subsequent sliding window(s). Moreover, these algorithms do not consider the fact that the flow or speed of a data stream could change. These weaknesses of proactive-FAANST and passive-FAANST are what we attempt to address by using Poisson probability distribution to predict if such tuples would be anonymizable in subsequent sliding window(s) by taking into consideration the arrival rate of records, success rate of anonymization per sliding window, time a tuple can exist and rate of suppressed records.

Expired Tuples and Information Loss in Delay:

A tuple expires when it remains in the system for longer than a pre-specified threshold called delay [START_REF] Zakerzadeh | Delay-sensitive approaches for anonymizing numerical streaming data[END_REF][START_REF] Mohammadian | Fast: fast anonymization of big data streams[END_REF]. In order to decide whether a tuple has exceeded its time-delay constraint, additional attributes such as arrival time, expected waiting time and entry time were included. As a heuristic, the choice of delay values, t l = 2000 ms and t u = 5000 ms, is guided by values of delay that are used in published experimentation results [START_REF] Zakerzadeh | Delay-sensitive approaches for anonymizing numerical streaming data[END_REF].

In general, our approach shows that there are fewer expired tuples when compared to passive-FAANST and proactive-FAANST solutions. This is because before our Poisson prediction transfers suppressed records to another sliding window, it checks for the possibility of their anonymization. In other solutions, there is no mechanism in place to check the likelihood of the anonymizability of a suppressed record before allowing it to go to the next sliding window/round. As a result, such tuples are sent to the next sliding window and have high a tendency to expire eventually. Our solution also shows that the lower a kvalue, the higher the number of expired tuples. This is because the outcome of Poisson prediction is lower for higher k-values. As a result, there are fewer changes of sliding windows as the k-value increases and this means there is a lower possibility of expired tuples.

One of the main goals of our solution is to reduce IL in delay (i.e. to lower the number of expired tuples). Figure 13 depicts that our solution is successful in achieving its main goal, and the IL (delay) in our solution is lower than in passive and proactive solutions. In order to determine the total number of records that expired, a simple count function was used to retrieve all records that had remain in the buffer longer than the upper limit threshold, t u . To determine the average expired records, we sum up the expired records in all the experiments and divide the result by the total number of experiments. Data Utility and Information Loss in Record: An important factor that is considered in anonymization is the degree of usability of anonymized data for data analysis or data mining tasks [START_REF] Li | On the tradeoff between privacy and utility in data publishing[END_REF]. Therefore, we compared the degree of IL in records of our solution with that of Passive-FAANST and proactive-FAANST. Our result, as illustrated in Figure 14, shows that at the minimal level of privacy enforcement, the information loss of our solution is par with the other two schemes, while at the maximal level our solution has better data utility.

Conclusions

We started this paper on the note that resource constrained environments lack data analytic expertise that can analyze and mine crime data in real-time. This anonymization process is important in order to provide intervention that can carry out this analysis in timely fashion. We adopted k-anonymity, -diversity and t-closeness as our anonymization scheme due to their simplicity, efficiency and applicability in real-life. However current literature on integration of these techniques to data stream has issues in terms of performance and privacy. The performance issue deals with information loss in terms of delay and running cost.

To address the challenge of ensuring that delay is optimal during anonymization process, we adaptively resized the buffer to handle intermittent flows of crime reporting traffic optimally by using Poisson Distribution. Results from our prototype implementation demonstrate that in addition to ensuring privacy of the data, our proposed scheme outperforms other with an information loss rate of 1.95% in comparison to 12.7% on varying the privacy level of crime report data records.

Fig. 4 :

 4 Fig. 4: Details of Anonymization Layer: Buffer Optimizer

Fig. 5 :Fig. 6 :

 56 Fig. 5: Details of Anonymization Layer: Data Anonymizer

Fig. 8 :

 8 Fig. 8: The chart of the questionnaire score breakdown, with standard deviation 0.05

Fig. 10 :

 10 Fig. 10: Poisson Probability Threshold Versus Recovered Tuples for Dataset 2

Fig. 11 :Fig. 12 :

 1112 Fig. 11: Relationship Between Privacy Level and Recovered Tuples for Dataset1

Fig. 13 :

 13 Fig. 13: Privacy Level Versus Expired Tuples for Poisson Solution, Passive-FAANST and Proactive-FAANST

Fig. 14 :

 14 Fig. 14: Privacy Level Versus Information Loss for Poisson Solution, Passive-FAANST and Proactive-FAANST

  [START_REF] Isafiade | Citisafe: Adaptive spatial pattern knowledge using fp-growth algorithm for crime situation recognition[END_REF]

	Phase 1	Phase 2	Phase 3	Phase 4
	Determine Initial Buffer Size	Reduce Information Loss	Prepare for Next Sliding Window	Estimate Arrival Rate for Next Window
	Anonymize Data Stream	Phase 6	Phase 5
		Launch Next Window	Compute optimal sizes for Next Window
	Fig. 7: Phases of Adaptive Buffer Re-sizing Scheme

http://www.mockaroo.com