In recent years, privacy-compliant software development has become an important topic, especially with the emergence of the EU General Data Protection Regulation (GDPR). Existing practices of software development challenge privacy compliance by increasingly promoting reuse, adaptation and integration of existing software artifacts from organizational or opensource repositories. Methods and approaches have been introduced to accelerate and improve development through reuse on the one hand and to mitigate threats related to data privacy on the other hand. However, the operationalization of this body of knowledge for developing systems that intensively reuse software artifacts is understudied. Moreover, ontologies, taxonomies and frameworks developed to conceptualize, organize and model privacy requirements focus on forward engineering activities (software design and development), and are less oriented for application in existing software projects and artifacts that are considered for reuse and integration. The aim of this research is to create a framework aimed to investigate, explore and guide privacy-compliant software reuse, especially in open-source environments. To this end, we will follow a design science approach whose main artifact will be a privacy compliance assessment method. The method will be developed in three steps: (1) systematically reviewing and analyzing the state-of-the-art in privacy-compliant software reuse; (2) empirically studying open-source repositories (in particular, GitHub) for privacy discussions, including ontologybased machine learning method for privacy discussions identification; and (3) developing and evaluating a privacy assessment method, for supporting reuse decisions, utilizing the existing models and frameworks.
Privacy is a fundamental human right. In the digital world, we are dependent on trustworthy
functioning of information and communication technologies on one hand and experience a growing
power of imbalance between data processing entities and the individuals whose data is at stake on the
other hand [1]. To protect the individuals’ right for privacy, several regulations and standards have been
established, with the General Data Protection Regulation (GDPR) [2] being the most studied one.
The evolution of information technologies and the growing concern for privacy and data protection yielded the development of Privacy Enhancing Technologies (PETs), for assessing and mitigating privacy risks. PETs protect the individual's privacy using technical means, such as encryption, anonymous communication protocols, attribute-based access and private database querying [4].
To utilize the full benefit for privacy and data protection, PETs need to be introduced into the initial stages of system development, i.e., design, rather than added in late development stages [1], [5]. The Privacy-by-Design (PbD)2 approach has been developed [6] with the aim to ensure data protection of individuals by integrating privacy considerations from the outset of the development of products, services, business practices, and infrastructures. PbD can be supported through eight privacy design strategies [7]: minimize, hide, separate, aggregate, inform, control, enforce and demonstrate.
While the PbD approach is already incorporated into the industry standards and practices and the importance of PETs is recognized, those techniques and approaches focus mainly on forward engineering activities, and privacy compliance of existing artifacts is less studied. 1.2.
Even before the GDPR came into force, it has been imperative for organizations to consider privacy compliance at the initial stages of the software development [8]. However, software reuse raises additional challenges to privacy compliance. While the existing privacy compliance approaches mainly reside in the forward engineering activities, i.e., designing and building privacy compliant software components [9], assessing compliance of existing artifacts and integrating them in an existing system in a privacy compliant manner are still challenging. These require reverse engineering of privacy requirements and analysis of applied privacy strategies and PETs. The effort required to adapt privacycompliant software reuse methods to different (and evolving) privacy regulations should be further investigated. In addition, objectively measuring the level of privacy compliance may assist in improving reuse decisions in general and selecting the most appropriate artifacts for reuse in particular. 1.3.
Over the years, several ontologies and taxonomies have been proposed to conceptualize, organize and model privacy requirements. Two of the recent examples are the ontology by Gharib et al. [10] and the taxonomy by Sangaroonsilp et al. [11]. Conducting a systematic literature review, Gharib et al. identified 55 concepts and relations, grouped into four main categories: organizational concepts (including agentive, intentional and informational entities, as well as entities’ interactions), risk, treatment, and privacy [requirement] concepts. Sangaroonsilp et al. developed a taxonomy that provides a comprehensive set of privacy requirements based on four well-established personal data protection regulations and privacy frameworks, including GDPR, ISO/IEC 29100, Thailand Personal Data Protection Act (PDPA) and Asia-Pacific Economic Cooperation (APEC). The taxonomy includes seven categories (User Participation, Notice, User Desirability, Data Processing, Breach, Complaint/Request and Security), their sub-categories and the specific privacy requirements that may belong to multiple categories and sub-categories.
In addition, to facilitate and realize the Data Protection by Design approach, a few projects have been initiated by individuals and by the EU to create frameworks for privacy compliance. One example is the privacy threat analysis framework LINDDUN [12], which stands for Linkability, Identifiability, Non-repudiation, Deniability, Disclosure of information, Unawareness and Non-compliance – privacy threat types that negate common widely accepted privacy properties. Additionally, PDP4E project suggested methods and tools for GDPR compliance through privacy and data protection engineering by implementing those methods into ongoing systematic engineering practices, and DEFeND project (Data Governance for Supporting GDPR) delivered a platform for assisting organizations achieve compliance with legal and privacy requirements, focusing on the GDPR implementation [13]. However, those frameworks concentrate on incorporating compliance from the beginning of the software development lifecycle. Facilitating privacy compliance while performing software reuse remains insufficient. 2 Sometimes referred to as “Data Protection by Design”.
Privacy has gained an increasing interest in the last two decades and a variety of regulations, strategies and technologies have been proposed to address its different aspects. While performing forward engineering activities in software development in a manner compliant to privacy regulations has already been explored by different studies but achieving privacy compliant software reuse is still understudied. This calls for developing a method that aims to assess and evaluate privacy level of the components and to integrate them into the system in a compliant way.
In addition, while modeling by taxonomies, ontologies and frameworks has been underway, those mostly target privacy requirements and concentrate on forward engineering activities, and do not handle assessing privacy levels of existing software artifacts to support reuse.
The rest of this paper is organized as follows. Section 2 presents the research objectives and the research questions. Section 3 presents the related work. Section 4 describes the research methodology and the expected contributions, while Section 5 details the progress achieved so far.
Our main working hypothesis is that software reuse challenges privacy compliance in general and PbD in particular. Two major gaps identified in literature serve as the motivation for our research.
The first gap regards analyzing, mining, monitoring and tracing privacy requirements. Despite the large corpus of privacy regulations and compliance methods, developers face challenges to operationalize them [14]. This is significantly noticeable when the development includes reuse of opensource artifacts. Our first objective is to analyze and mine existing artifacts for privacy characteristics through analyzing their meta-data and discussions.
The second gap regards adaptation and integration of artifacts in complex projects that comprise of dependent software artifacts [15]. Complex projects may comprise of artifacts originating from different sources (i.e., proprietary software, third-party software, open-source repositories), and having different levels of privacy. Our second objective is to analyze, simulate and devise the “aggregate” level of privacy of the entire system and check whether it satisfies the overall privacy requirements, thus performing privacy compliance assessment of the artifacts and the integrated software. 2.2.
To fulfil the above objectives, we consider the following research questions (RQ): 1. RQ1. What is the current state-of-the-art in privacy-compliant software reuse? • RQ1.1 What are the regulations considered in privacy-compliant software reuse? • RQ1.2 What are the business and technological domains in which privacy-compliant software reuse is researched? • RQ1.3 What are the utilized reuse approaches and how do they relate to the reuse landscape? • RQ1.4 What are the privacy strategies implemented in the context of privacy-compliant software reuse? • RQ1.5 How is privacy-compliant software reuse evaluated? • RQ1.6 What are the main open challenges for performing privacy-compliant software reuse? 2. RQ2. How are privacy issues discussed and dealt with in open-source environments? • RQ2.1 How can privacy issues be identified in open-source environments? • RQ2.2 To what extent can the identification be improved based on privacy ontologies? • RQ2.3 To what extent do automatically analyzed sentiments of privacy-related issues correlate with privacy compliance of those projects? • RQ2.4 What are the unique privacy-related characteristics for software projects with a high reuse potential? 3. RQ3. How can the privacy compliance of a software artifact be assessed to facilitate and support reuse? • RQ3.1 How can the privacy compliance of existing software artifacts be assessed? • RQ3.2 What is the aggregate privacy compliance level when integrating software artifacts?
This section briefly reviews the literature relevant for answering our research questions.
State-of-the-art in privacy compliant software development (RQ1): A few SLR works were performed in the last decade on security aspects in software development. Among them, the works in [16]–[18] discuss security in cyber-physical systems, electronic health records and software development lifecycle in general. Differently from these works, our study concentrates on software reuse which requires assessment and integration of already existing artifacts, evaluating their level of privacy compliance and preserving the level of privacy when being adapted and integrated.
Several systematic reviews on software requirements reuse [19], and on non-functional requirements [20], [21] that inherently include privacy requirements were also performed. However, these works do not concentrate on privacy compliance aspects.
The systematic mapping study in [22] deals with privacy-by-design approaches in software engineering. This work maps the goals of privacy-by-design to software engineering activities. We further aim to analyze the challenges of privacy compliance in software reuse scenarios.
Discussions on privacy aspects in open-source environments (RQ2): Discussions in open-source environments have been researched for different purposes, such as understanding the social potential of those environments, devising on popularity of the different projects and analyzing their maintenance level and required contributions [23]. In the context of privacy and security, the issues usually provide an important source of information on the project. The work in [24] identified several end-user humancentric issues discussed on GitHub: Inclusiveness, Privacy & Security, Compatibility, Location & Language, Preference, Satisfaction, Emotional Aspects, and Accessibility. Some works further analyzed the sentiments of comments and discussions in social networks. The work in [25], for example, found that applying emotion mining to developer issue reports can be useful to identify and monitor the mood of the development team, and thus predict and resolve potential threats to the team well-being, as well as discover factors that enhance team productivity. The work in [26] created a domain-specific tool for sentiment analysis of the issues documented in software development, improving the accuracy of the analysis by enriching the classifier with domain-specific lexicon. The work in [27] reports on a positive correlation between favorable sentiments and improved practices in the context of software engineering and development. We intend to advance this body of research by analyzing the relations of the analyzed sentiments to privacy compliance, and to explore whether meta-data of OSS projects (in particular, issues) can predict privacy compliance.
One of the challenges in performing empirical research on privacy issues in OSS is a lack of previously annotated datasets on the subject, impeding the precision and correctness of privacy issues identification and categorization. An approach to overcome this challenge is utilizing ontology. The researchers in [28] conducted experiments on text classification with various classifiers, both prior to and subsequent to utilizing a disease ontology. Notably, this integration led to enhancement in the outcomes. Moreover, the adoption of a domain-specific ontology has demonstrated improvement in the accuracy of text classification in situations where a sufficiently large and well-labeled training corpus is not at hand [29]. Our research seeks to extrapolate these approaches to the realm of privacy, employing Gharib et al.’s ontology [10].
Privacy compliance assessment (RQ3): Privacy is a multi-faceted concept [30]–[32] that may refer to social, physical, informational and psychological domains. The methods for assessing privacy levels that are described in literature focus mostly on security aspects [33], [34], such as the Common Vulnerability Scoring System (CVSS)3, an open scoring system of security vulnerabilities and threats. Previous works analyze privacy and security breaches for a specific domain (smart homes) [35], or a specific type of applications (contact tracing) [36]. However, checking an overall privacy compliance 3 https://www.first.org/cvss/ of software is challenging. Few works focus on the analysis of the software code itself for implementation of privacy requirements [37], [38]. According to [39], a traditional static code analysisbased vulnerability discovery is insufficient for compliance checking of regulatory requirements. A model for automated privacy compliance checking of applications in the cloud is introduced in [40]. Despite the above studies, to the best of our knowledge, there is no end-to-end approach for assessing and measuring privacy compliance level of software artifacts, and we aim to advance this line of research by creating a privacy compliance assessment method.
This activity aims to address RQ1 by systematically reviewing and analyzing the existing
state-ofthe-art privacy-compliant software development, focusing on reuse scenarios. It follows the guidelines
for conducting SLRs by Kitchenham [41], complemented by the guidelines on snowball sampling by
Wohlin [42] and the guidelines fo
The SLR search query includes the following concepts with a logical condition of AND between them: • Concept 1 (the examined aspect): privacy OR “data protection” • Concept 2 (the examined process): reuse OR reusing OR reusab* OR cloning OR clone OR config* • Concept 3 (the examined object): software OR product OR system • Concept 4 (the examined phase): requirement* OR analys* OR analis* OR analyz* OR analiz*
OR domain* OR model* OR design*.
After retrieving the potential papers to be included in the SLR, inclusion and exclusion are applied. The inclusion criteria are: (1) the paper should introduce a technique/method/tool for privacy-compliant software reuse and (2) it should be published in a peer-reviewed journal, conference or workshop. The exclusion criteria are: (1) the paper should not be too short (3 pages or less), (2) the paper is not a variant of another paper in the corpus, (3) the paper is written in English, (4) the paper is not a primary study, (5) the paper is not directly related to software reuse or data privacy, and (5) the full text of the paper is not accessible. We resulted with a corpus of 61 papers which was analyzed to address questions RQ1.x (see Section 5.1 for more details). 4.2.
To address RQ2, we apply an empirical approach on a sample of open-source projects, with the purpose of identifying privacy aspects in highly reusable projects as compared to those with a lesser reuse potential. Those aspects may appear in different fields (e.g., issues, comments, commits and pull requests). We aim to explore whether machine learning methods can automatically identify privacyrelated issues, and whether this method can be enhanced utilizing existing knowledge representations. We assume that, if the automatically computed outcomes can be mapped to human-generated knowledge base, then large datasets of issues can be automatically analyzed and decisions, e.g., regarding using or reusing the related projects, can be made automatically or semi-automatically, based on privacy requirements, as reflected in issue discussions.
As for devising the reuse potential of the projects, some meta-data available in open-source repositories refer to popularity of projects or users, e.g., the numbers of active forks, stars and followers [44], [45]. The authors of [46] have already demonstrated a relation between popularity of a project to its quality and reuse potential. We plan to analyze the popularity characteristics of a sample of OSS projects, to differentiate between potentially highly reusable and “regular” software projects, and to explore the relations between the privacy characteristics of those two kinds of projects.
While initial results have already been achieved and submitted to a conference (see Section 5.2), we intend to extend the datasets and the explored elements beyond issues. In addition, we intend to devise whether the sentiment of the privacy discussions (positive/neutral/negative) and the subjective privacy compliance level of the project are correlated. We plan to conduct sentiment analysis of the identified privacy issues, and independently, to conduct a survey with OSS project owners or privacy experts to annotate the projects in our dataset to [privacy-]compliant and non-compliant. To this end, we plan to base our survey on the privacy design strategies presented in [7]. The results of those two steps will be compared for correlations using statistical techniques. 4.3.
This activity will follow the design science approach [47] and will be based on the results of the SLR (addressing RQ1) and the empirical exploration (addressing RQ2). We will develop techniques for privacy compliance assessments of software artifacts and for presenting those assessments in supporting reuse decisions.
An initial input for the privacy compliance assessment method will be the comparison of the privacy requirements for the regulation compliance of the software artifact and the privacy strategies [7] and/or PETs [48] already implemented in the artifact. Since the discovery of the already implemented privacy strategies and PETs requires detailed technical documentation of the software project and is not always available, our method will incorporate the existing documentation together with the community discussions on and sentiment analysis of the software artifact.
This part of the research has not begun and there are still a few challenges to overcome: The first challenge refers to the definition of the privacy compliance level of software artifacts. Whilst this level may be either qualitative or quantitative in one or more dimensions, we plan on creating a multi-dimensional qualitative scoring method. The method will include, as a first step, a scoring scale for applying PETs; as a second step mining of relevant privacy strategies will be performed for the specific software artifact, based on the known privacy requirements; next, extraction of already applied PETs will be performed based on the project documentation and meta-data; and finally, the score for the software artifact privacy compliance level will be devised, based on the previous steps and additional data such as sentiment analysis.
An additional challenge is the level at which the privacy compliance level will be calculated – e.g., a project, a component or a function. Currently, our plans refer to whole projects, since most of the data on which we base our analysis is managed on the project level. However, as the privacy compliance level of the different parts of a project may differ, we will have to check the impact of such a score on lower levels of granularity (e.g., components and functions). In addition, many of the reuse scenarios deal with reuse on lower levels of granularity by integrating third-party components, libraries and/or functions into existing projects to resolve existing issues and to create additional functionality. The challenge is to assess the impact of those integrations on the overall privacy compliance level of the software project.
Finally, the suggested method has to be evaluated for usability and generality, and the access to evaluation objects may be challenging [49]. One of the main ways of evaluating method usability and usefulness is with experts. To overcome this challenge, we plan to conduct expert evaluation of the method itself, or its outcomes, with professionals and/or advanced students.
The contributions of the work are valuable both for research and practice.
From a research point of view, the research artifacts will enrich the knowledge base with: A1. A systematic review (RQ1) that will examine the current state-of-the-art and present the results of a comparative analysis of privacy-compliant software reuse methods. Special attention will be given to the reuse approaches and privacy strategies of these methods. The SLR will also identify the contemporary challenges for performing privacy-compliant software reuse and future directions.
A2. An ontology-guided machine-learning method (RQ2) for identifying and classifying privacyrelated discussions in the form of issues and additional meta-data items in open-source repositories. The method will also devise the potential privacy compliance of projects based on the sentiment of the privacy discussions in the OSS and opinions of experts involved in the projects, for projects with different reuse potential.
A3. A method for assessing the privacy compliance level of software projects (RQ3) that will support the reuse lifecycle and improve privacy compliance of those projects by making sure the additional software artifacts integrated into the projects do not decrease the current compliance level.
From a practical point of view, we plan on supporting privacy-compliant software reuse by applying the method in A3 on third-party and open-source artifacts and assessing their privacy compliance level to select the most appropriate artifacts for reuse. This will increase the level of privacy compliance in complex software systems that make extensive reuse of software artifacts.
We so far concentrated on the two first research questions, forming the basis for RQ3. Below is a summary of the achievements. 5.1.
This part was completed, and its outcomes were sent as a paper to the IST (Information & Software Technology) journal. It is currently under minor revision. We found that the reviewed 61 studies vary in terms of business domains (e.g., healthcare, smart objects and finance) and technological domains (e.g., IoT, mobile, cloud and microservices). Most of the studies do not refer to a specific regulation and if so – to GDPR. Their common purpose is to support benign reuse, most notably through patterns, components & libraries and model-driven engineering, but malicious reuse is also researched to a lesser extent. A strong emphasis is put on integrating privacy strategies whose goal is building trust and transparency (in particular, inform and demonstrate), while other strategies are studied to a limited extent in software reuse context. Evaluation is commonly performed through analytical, observational and experimental approaches.
We further found that the assessment and operationalization of privacy compliance practices for existing software artifacts is still challenging. The challenges encompass improving trustworthiness of reused artifacts, ensuring privacy compliance in distributed architectures, bridging the gap between legal regulations and software requirements, enhancing privacy analysis and vulnerability detection, supporting late application of privacy strategies, and developing objective assessments for privacycompliant software reuse. 5.2.
So far, we studied to what extent machine learning outcomes can be mapped to privacy-related knowledge representations for identifying and categorizing privacy-related issues in open-source environments. We explored a dataset of 2,556 issues from open-source projects. 1,374 of them (about 54%) are issue reports from Jira associated with two large-scale, popular and well-maintained software projects, Chrome and Moodle, used in [11] and annotated as privacy-related. The other 1,182 are issues from six diverse projects in GitHub annotated by [24] as non-privacy related.
First, we preprocessed the dataset by means of text cleaning, removing irrelevant parts (e.g., html tags, numbers, punctuation marks and stop words) and performing tokenization and lemmatization [50]. We extracted words from URLs that appear in the issues and left them for the analyses, assuming that some may be meaningful and relevant for classification. Then, we used YAKE! keyword extractor [51] for extracting potential key-terms from the preprocessed text. We applied Reduced Error Pruning (REP) tree [52] and Support Vector Machine (SVM) [53] classifiers. We chose these classifiers because they differ in their underlying principles, learning approach, and decision-making processes. The metrics of the two classifiers were compared to validate that the results are similar in terms of correctly classified items, precision, recall and F-measure, indicating that similar patterns or relationships in the data have been learned. As indicated by the relatively high values of F-measure for both classifiers (86.6% for REP tree and 87.1% for SVM), we can conclude that the classifiers have the potential for distinguishing between privacy and non-privacy issues. Due to the simple, intuitive and visual format of REP tree outcomes, we used them to identify key-terms for classification of the issues into one of two classes – privacy and non-privacy related. Lastly, we succeeded in manually mapping the identified key terms to the main concepts of the ontology in [10]. The root term, privacy, appeared in only 20% of privacyrelated issues, so the relatively high accuracy of the classifier cannot be attributed only to this term. The terms user, datum and setting can be considered organizational; tool policy and tool data privacy relate to policies or guidelines for data privacy handling; and incognito window, incognito mode and [third] party cookie – to privacy-related risks.
I am grateful to my advisor Professor Iris Reinhartz-Berger for supervising my research, for countless inspirational discussions and for being available for me almost around the clock. I really appreciate this enormous dedication. [30] [31] [33] P. Mell, K. Scarfone, and S. Romanosky, “Common vulnerability scoring system,” IEEE Secur.
Priv., vol. 4, no. 6, pp. 85–89, 2006, doi: 10.1109/MSP.2006.145.
[34] P. Mell, “The generation of software security scoring systems leveraging
Cybersecurity Priv., vol. 1, pp. 597–614, 2021.
[37] S. Zimmeck et al., “Automated analysis of privacy requirements for mobile a
Softw. Technol., vol. 51, no. 1, pp. 7–15, 2009, doi: 10.1016/j.infsof.2008.09.009.
[42] C. Wohlin, “Guidelines for snowballing in systematic literature studies and a replication in
software engineering,” ACM Int. Conf. Proceeding Ser., 2014, doi: 10.1145/2601248.2601268.
[43] M. J. Page et al., “The P