# SoK: Demystifying Privacy Enhancing Technologies Through the Lens of
Software Developers

Maisha Boteju  The University of AucklandAucklandNew Zealand
<EMAIL_ADDRESS>,  Thilina Ranbaduge  Data61, CSIROCanberraAustralia
<EMAIL_ADDRESS>,  Dinusha Vatsalan  Macquarie
UniversitySydneyAustralia<EMAIL_ADDRESS>and  Nalin Asanka
Gamagedara Arachchilage  The University of AucklandAucklandNew Zealand
<EMAIL_ADDRESS>
(2018)

###### Abstract.

In the absence of data protection measures, software applications lead to
privacy breaches, posing threats to end-users and software organisations.
Privacy Enhancing Technologies (PETs) are technical measures that protect
personal data, thus minimising such privacy breaches. However, for software
applications to deliver data protection using PETs, software developers should
actively and correctly incorporate PETs into the software they develop.
Therefore, to uncover ways to encourage and support developers to embed PETs
into software, this Systematic Literature Review (SLR) analyses 39 empirical
studies on developers’ privacy practices. It reports the usage of six PETs in
software application scenarios. Then, it discusses challenges developers face
when integrating PETs into software, ranging from intrinsic challenges, such
as the unawareness of PETs, to extrinsic challenges, such as the increased
development cost. Next, the SLR presents the existing solutions to address
these challenges, along with the limitations of the solutions. Further, it
outlines future research avenues to better understand PETs from a developer
perspective and minimise the challenges developers face when incorporating
PETs into software.

Privacy Enhancing Technologies, data protection, developers, secure
computation

††copyright: acmcopyright††journalyear: 2023††doi: XXXXXXX.XXXXXXX††journal:
CSUR††journalvolume: 37††journalnumber: 4††article: 111††publicationmonth:
8††ccs: Security and privacy Human and societal aspects of security and
privacy††ccs: Software and its engineering Software development process
management††ccs: Software and its engineering Designing software††ccs: General
and reference Surveys and overviews

##  1\. Introduction

Software applications pose a significant threat to the privacy of their end-
users (Ekambaranathan et al., 2021; Barbala et al., 2023; Greene and Shilton,
2018). They routinely and excessively collect personal data, such as
personally identifiable information (e.g., names, locations) and sensitive
data (e.g., healthcare data), in exchange for their services (Hargitai et al.,
2018; Sanderson et al., 2023). For instance, in 2018, the New York Times found
that some software track the location of 200 million mobile users in the
United States, collecting accurate location data over 14,000 times daily
(Valentino-devries et al., 2018). Therefore, if software applications do not
provide means to protect these personal data, end-users could lose them to
unknown parties who might sometimes be malicious, causing end-users financial
losses, reputation damage and emotional distress (Senarath and Arachchilage,
2018a; Senarath et al., 2019). For example, the Ashley Madison website, a
platform facilitating extramarital affairs, fell victim to a hacking incident
that exposed the names, contact details, locations and financial transactions
of 30 million of its users (Mansfield-Devine, 2015). As a result, the
reputation of some celebrities and government officials was damaged, more
divorce cases were triggered, and some users even committed suicide
(Mansfield-Devine, 2015). This incident exemplifies how the absence of data
protection within software applications can profoundly affect its end-users.

Therefore, developing software applications with adequate data protection
measures is essential to protect end-users from such harmful consequences.
With scrutinised privacy regulations (e.g., GDPR (European Commission, 2016))
in place and increased public awareness about privacy, software organisations
are pressured to safeguard end-user data more than ever (Barbala et al., 2023;
Alomar and Egelman, 2022; Berk et al., 2023; Senarath and Arachchilage, 2021).
To meet this demand, integrating Privacy Enhancing Technologies (PETs) into
software emerges as a crucial strategy to achieve data protection (Raisaro et
al., 2019; Archer et al., 2022). PETs are a collection of technical solutions
which allow software applications to extract insights from personal data while
upholding data protection principles such as minimising the use of personal
data, i.e., data minimisation (Agrawal et al., 2021). For instance, federated
learning is a PET that allows training a machine learning model using
decentralised data (data splitting), ensuring those data are kept private at
their original locations (Zhang et al., 2021; Sanderson et al., 2023). PETs
achieve data protection through different approaches, including transforming
data to de-identify individuals, hiding or shielding data, and splitting or
controlling access to data (Office, 2023). Using these approaches, PETs can
achieve data protection by design and default in software, proactively
preserving the privacy of the data owners (Garrido et al., 2022; Office,
2023).

However, software developers rarely consider using PETs to ensure data
protection in software (Senarath and Arachchilage, 2018a). They usually
provide privacy policies and settings or limit data collection (Alomar and
Egelman, 2022; Hadar et al., 2018). However, these techniques do not guarantee
that personal data are protected once the data are disclosed to software.
Moreover, developers struggle to make decisions when embedding PETs into
software (Senarath and Arachchilage, 2018b). They are unsure how to select
suitable PETs for their applications or when and how to use them (Senarath and
Arachchilage, 2018a; Sarathy et al., 2023; Agrawal et al., 2021). In addition,
they constantly require external verification for their decisions, showing a
lack of confidence in working with PETs (Senarath and Arachchilage, 2018a). As
a result of this behaviour, developers fail to create software applications
with robust data protection guarantees, compromising end-user privacy and
holding organisations vulnerable to regulatory pressure (Senarath and
Arachchilage, 2018a). Therefore, it is important to change developers’
behaviour in accepting PETs and correctly integrating them into software.

To identify possible approaches to support this behavioural change, first, it
is required to understand how developers are currently using PETs, what makes
the integration of PETs challenging for them, and how these challenges can be
addressed. However, few empirical studies are dedicated to exploring the
developer perspective of utilising PETs (Sarathy et al., 2023; Agrawal et al.,
2021). In many cases, PETs are only a brief part of empirical studies that
explore developers’ privacy practices (Senarath and Arachchilage, 2018a;
Senarath et al., 2019; Spiekermann et al., 2019; Ibáñez and Olmeda, 2022;
Sanderson et al., 2023). Therefore, synthesising the knowledge in those
empirical studies, this Systematic Literature Review (SLR) provide a holistic
understanding of how to support developers in incorporating PETs into
software. The following research questions guide the SLR.

  1. RQ1 :

What existing PETs have developers integrated into the software to achieve
data protection, and how have these PETs been integrated?

  2. RQ2 :

What are the challenges developers face when integrating PETs into the
software they develop?

  3. RQ3 :

What solutions does the literature propose to tackle the challenges identified
in RQ2, and what are the limitations associated with these solutions?

The remainder of the article is organised as follows. Section 2 briefly
describes the PETs discussed throughout the SLR. Next, Section 3 discusses our
contribution to the body of knowledge. In Section 4, we outline the
methodology of the SLR followed by the findings of the SLR in Section 5. Then
Section 6 presents the implications of the results, along with future research
areas and limitations of the SLR. Finally, Section 7 presents the concluding
remarks of the SLR.

##  2\. Preliminaries

This section briefly describes the types of PETs discussed throughout our SLR
to guide the readers. We also outline the data protection capabilities of the
discussed PETs by explaining how they can be integrated into a hypothetical
software application scenario.

Software application scenario: A software company is developing a web-based
EHR (Electronic Health Record) system for three hospitals (A, B, C) to manage
patient data. The doctors and nurses can enter patient’s data into the system,
including name, age, zip code, race, gender, contact number, symptoms, and
diagnosis. Since healthcare data contain sensitive personal data, the
collected data are encrypted at storage. The EHR system is hosted on Amazon
Web Services (AWS), utilising its cloud infrastructure, storage, and services
for enhanced performance and scalability. The system incorporates machine
learning for diagnosis prediction. Further, it facilitates secure data sharing
with external research institutions. In addition, insurance companies can
register with the EHR system to receive patient health data for claims
approval. Finally, the EHR system enables the three hospitals to
collaboratively analyse patient data handled by their respective EHR systems
to obtain rich insights. However, they do not want to share their data during
this collaborative process.

####  2.0.1. Psuedonymisation

Psuedonymisation is a de-identification technique where an individual’s
personally identifiable information (PII) is replaced by pseudonyms
(artificial identifiers) (Hargitai et al., 2018). According to the General
Data Protection Regulation (GDPR), organisations utilising personal data
should employ pseudonymisation to achieve secure data storage (European
Commission, 2016). In the given application scenario, pseudonymisation can be
used in database tables, where the actual name of each patient is replaced by
a pseudonym patient# (# is a number different for each patient). In this way,
linking health data to the respective patients is minimised, thus improving
data protection in the application (Office, 2023).

####  2.0.2. K-Anonymity

K-anonymity is one of the popular forms of syntactic anonymisation, in which
anonymisation is achieved by changing the appearance of data (Sweeney, 2002).
A tabular dataset is said to be k-anonymised if a set of quasi-identifiers
111Quasi-identifiers are data attributes, excluding PII, that in combination
can uniquely identify a person (Sweeney, 2002). The quasi-identifiers of the
given application scenario are the age, zip code, race, and gender of a
patient. are repeating at least in k different rows (Sweeney, 2002). K-
anonymity can be achieved either through generalisation (replacing an
individual data value with a more general value) or suppression (removing data
values in a dataset to achieve anonymity) (Munilla Garrido et al., 2023;
Sweeney, 2002). In the given application, the ”race” data can be removed from
the dataset if it is not necessary for the functionality of the application
(suppression), the last three digits of the zip code can be replaced with the
‘*’ symbol (generalisation) and the age can be stored as a numerical range,
for example, 25 can be stored as 20-30 age range (generalisation). These steps
must be completed so that values for age, zip code, race, and gender in the
dataset repeat at least in k rows (Sweeney, 2002). In this manner, the
specificity of the patient data is minimised, thus minimising their
identifiability (Office, 2023).

####  2.0.3. Onion Routing

Onion routing is used to camouflage the communication that occurs in public
networks (Goldschlag et al., 1999). This technique routes network users’
encrypted messages through a series of intermediate servers before reaching
their destination (Goldschlag et al., 1999). In this way, the data
communicated and the information about who is communicating with whom are
hidden (Goldschlag et al., 1999). In the given example, onion routing can be
used to anonymise the communication between the end-users (doctors, nurses,
and insurance companies) and the web-based EHR system.

####  2.0.4. Homomorphic Encryption

Homomorphic encryption (HE) is an encryption technique which supports
computation over encrypted data without decrypting them (Raisaro et al., 2019;
Goswami et al., 2020). In the given application scenario, suppose a doctor in
hospital A must know the number of COVID-19 patients who visited the hospital
within a specific time period. If the EHR system has integrated HE, it can
perform addition on the encrypted data to return the total COVID-19 patients
to the doctor. The result will be decrypted on the client side of the system.
This way, personal data are hidden even during the computations, thus
enhancing the data protection of the system (Office, 2023).

####  2.0.5. Federated Learning

Federated learning (FL) can perform machine learning using remotely existing
data without bringing them to one location (Zhang et al., 2021). In this
technique, a central server contains a global machine-learning model and
copies of this model is sent to every remote node that contains the training
data (Hegiste et al., 2022). These copies (local models) are then trained
locally at the remote nodes using the data stored in them (Hegiste et al.,
2022). The updates done to the local models are communicated back to the
global model, where it aggregates the updates from all remote nodes (Hegiste
et al., 2022). This process is repeated throughout the training process. In
the given application, the three hospitals can utilise FL to train a patient
similarity detection model to determine clinical trial participants (Navaz et
al., 2023). In this manner, the data collected separately by the hospitals is
kept private at their original sites while valuable insights are extracted
from them (Office, 2023).

####  2.0.6. Differential Privacy

Differential privacy (DP) is a cryptographic technique where random noise is
added to the data query results of a dataset (Sarathy et al., 2023; Dwork et
al., 2019). The amount of noise added must make minimal changes to the query
results when an individual’s data is added or removed from the dataset (Dwork
et al., 2019). In this manner, it is challenging to identify the respective
owners of the data included in the dataset (Office, 2023). DP is a semantic
anonymisation technique, where anonymisation is achieved by changing the
meaning of data (Hargitai et al., 2018). However, the added noise decreases
the accuracy of the data. Therefore, DP would be much more suitable for
systems that analyse aggregated statistical results in data (e.g., census data
analysis) rather than for systems which depends on accurate individual-level
analysis (e.g., tax calculation) (Office, 2023; Munilla Garrido et al., 2023).
In the example application, suppose the doctors are required to identify the
number of diabetic patients based on different age ranges (e.g., 10-15,
16-20). The system can utilise DP to query this, assuring data protection. In
this way, even if the results are less accurate due to the added noise, the
doctors can understand the relationship between people’s age and the
likelihood of developing diabetes through the aggregated results.

####  2.0.7. Synthetic Data

Synthetic data is artificially generated data that mimics the statistical
properties of real data. Different techniques to generate synthetic data
include machine learning, deep learning, and agent-based modelling (Assefa et
al., 2021). In the given application scenario, the EHR system can provide a
feature to generate a synthetic dataset replacing the real patient data so
that the data can be securely shared with external research institutes without
compromising the sensitive personal data of the patients.

####  2.0.8. Secure Multi-Party Computation

Multiple parties can jointly perform a computation over a function using their
private inputs through secure multi-party computation (SMPC) (Agrawal et al.,
2021). In SMPC, every party contributing to the computation only knows their
own input and the output generated through the computation (Agrawal et al.,
2021). Suppose in the given application scenario, hospitals A, B, and C are
required to jointly identify people who inject drugs (PWID) that frequently
visit their emergency wards. For this, the EHR system can use SMPC to use
emergency ward patient lists in each hospital and identify the common PWID
patients who visited all three hospitals without sharing the patient lists
among the hospitals.

####  2.0.9. Zero-Knowledge Proof

Zero-knowledge proof (ZKP) is a cryptographic technique which enables one
party (prover) to convince another party (verifier) about the truthfulness of
a statement without exposing additional information bound to the statement
(Liu et al., 2021a). Suppose in the given example, an insurance company must
know whether a patient’s blood sugar level is higher than a certain amount to
approve the patient’s insurance claims. Using ZKP, the system only proves to
the insurance company whether the patient’s blood sugar level is above or
below the expected level without sharing additional personal details (e.g.,
exact blood sugar level or the different tests or medications taken). In this
instance, ZKP achieve data protection by minimising the patient’s data used
for a particular process (Office, 2023).

####  2.0.10. Trusted Execution Environment

Trusted execution environment (TEE) is an isolated and tamper-resistant secure
area in a computing device’s processor (Wang et al., 2020). TEE ensure the
integrity and confidentiality of codes and data loaded into it, even from
privileged sources such as the operating system (Wang et al., 2020; Office,
2023). In the given example scenario, the AWS nitro enclave
222https://aws.amazon.com/ec2/nitro/nitro-enclaves/ feature can be used to
create such isolated computing environments. Then, sensitive processes such as
diagnosis prediction can be conducted inside that secure environment, ensuring
that sensitive data used for that process and the generated predictions are
handled securely.

##  3\. Related Work

PETs empower software to extract insights from end-user data while minimising
the risks of privacy violations (Agrawal et al., 2021). Due to this data
protection capability of PETs, researchers have continuously explored ways to
improve the existing PETs or introduce new and more robust PETs (Lo et al.,
2022; Zhang et al., 2016; Archer et al., 2022; Liu et al., 2021b; Baunsgaard
et al., 2021; Liu et al., 2021a). Thus, PETs are becoming an active research
area in the privacy domain, with various secondary studies333Secondary studies
analyse existing data relating to a specific research question to synthesise
knowledge and answer that research question. These studies depend on the data
collected by primary studies, which are the studies that collect new data to
address a specific research question (Kitchenham and Charters, 2007) offering
distinct perspectives on them.

Existing secondary studies on PETs have heavily focused on analysing the
privacy protection capabilities of PETs along different application domains
(Antunes et al., 2022; Jamil et al., 2022; Sun et al., 2020; Kim et al., 2021;
Wu et al., 2014). These studies primarily concentrated on domains such as
healthcare (Antunes et al., 2022; Coelho et al., 2023; Dankar and El Emam,
2013; Hernandez et al., 2022; Myrzashova et al., 2023; Naz et al., 2022;
Sikandar et al., 2023), transportation (Jamil et al., 2022; Sohan and
Basalamah, 2023; Xing et al., 2022), smart infrastructures (K et al., 2022;
Curzon et al., 2019), and communication (Sun et al., 2020). Further, there
exist some studies that discuss more specific application scenarios, such as
federated learning for image processing (KhoKhar et al., 2022), differential
privacy for location-based services (Kim et al., 2021), homomorphic encryption
to outsource computation in deep learning (Podschwadt et al., 2022),
searchable encryption for cloud computing (How and Heng, 2022), and
blockchain-powered homomorphic encryption to analyse biometric data (Wu et
al., 2014).

On the other hand, some secondary studies attempted to reveal the technical
limitations (Dankar and El Emam, 2013) and challenges of PETs (Lo et al.,
2022; Shanmugarasa et al., 2023; Podschwadt et al., 2022; Witt et al., 2023;
Zhang et al., 2022a). A study by Dankar et al. (Dankar and El Emam, 2013)
discussed limitations of differential privacy, such as the theoretical nature
of algorithm variables and the lack of applicability due to the reduction in
data utility (Dankar and El Emam, 2013). In addition, the technical challenges
encountered when deploying PETs were heavily discussed, focusing on federated
learning (Lo et al., 2022; Zhang et al., 2022a; Witt et al., 2023). The
studies pointed out the architectural level challenges encountered due to the
decentralised design of federated learning, such as communication difficulties
between remote devices and the global machine learning model (Lo et al., 2022;
Zhang et al., 2022a; Witt et al., 2023), scalability issues (Lo et al., 2022;
Witt et al., 2023) and negative effect on the global model performance due to
the heterogeneity in client data (Lo et al., 2022; Zhang et al., 2022a).

In addition, several existing works attempted to synthesise the foundational
knowledge of PETs (Acar et al., 2018; Martins et al., 2017; Lo et al., 2022).
The theoretical presentation of different homomorphic encryption algorithms
was discussed in (Acar et al., 2018; Martins et al., 2017). Further, Lo et al.
(Lo et al., 2022) conducted an in-depth review using 231 federated learning-
related studies to understand the background, requirement analysis,
implementation, evaluation, and architecture design-based knowledge needed to
develop federated learning systems. As another way of structuring and
organising PETs-related knowledge, several secondary studies attempted to
classify the knowledge of PETs. Yin et al. (Antunes et al., 2022) classified
the privacy risks of federated learning under five aspects (who, what, when,
where, and why) and provided an additional categorisation of existing
federated learning schemes based on the mechanisms they employ, namely
encryption-based, perturbation-based, anonymisation-based, and hybrid. A
similar mechanism-based taxonomy is also presented in (Yaqoob et al., 2023),
where it focuses on the de-identification mechanisms in the context of
microdata.

Overall, PETs-related secondary studies spanned various facets, including
presenting the potential applications under different domains, technical
limitations and challenges, and knowledge classifications. While these
synthesising directions are valuable, having a holistic view of the developer
perspective regarding PETs is also essential. Since developers are leading
roles in software development, the adoption of PETs in the software industry
lies in developers’ capability to incorporate PETs into software (Senarath et
al., 2019). Therefore, contrasting to the existing secondary studies, our SLR
attempts to understand how developers are currently integrating PETs into
software, what challenges they face during the integration of PETs, and what
solutions the literature provides to remedy the identified challenges and the
limitations of those solutions. The insights of our work are valuable to
identify directions to encourage and support developers to create PETs-
embedded software, thus fostering a privacy-preserving digital environment.

##  4\. Methodology

The methodology of this SLR followed the guidelines proposed by Kitchenham and
Charters, which offer a scientific and reproducible approach to conducting
SLRs in the Software Engineering domain (Kitchenham and Charters, 2007).
According to these guidelines, we organised our SLR along three stages:
_planning, conducting_ and _reporting_. This section describes the planning
and conducting stages in detail, while the reporting stage is presented in
Section 5.

###  4.1. Planning

In the planning stage, we established a protocol defining the components
required to conduct this SLR. These components include the research questions
required to guide the SLR, the search terms to identify the relevant
publications, the data sources to search for relevant publications, and the
selection criteria to determine the publications to be included in the SLR.
Defining these components before conducting the SLR was essential to reduce
the potential researcher bias during the conducting stage (Kitchenham and
Charters, 2007).

####  4.1.1. Formulating the Research Questions

Well-formulated research questions are essential to reflect the scope of an
SLR accurately (Kitchenham and Charters, 2007). Therefore, we used the PICOC
(Population, Intervention, Comparison, Outcome, Context) framework, which
introduces five elements to define focused research questions (Petticrew and
Roberts, 2006; Kitchenham and Charters, 2007). These elements include the
_population_ that we are interested in (software developers in our case),
_intervention_ examined under the SLR (PETs), _comparison_ done against the
intervention, _outcomes_ that we are interested in (data protection), and the
_context_ considered (which is software development in our case). It is worth
noting that the element ”comparison” was excluded in this SLR since it does
not intend to compare PETs against any other intervention(s). We used these
PICOC elements as a guide to identify the keywords required to structure the
research questions mentioned in Section 1. Table 1 depicts the PICOC elements,
their descriptions and the respective keywords identified using those
elements.

Table 1. The PICOC elements, their descriptions (Kitchenham and Charters, 2007; Petticrew and Roberts, 2006), and the keywords derived from the PICOC elements to structure the research questions and define the search strings. N/A = Not Applicable PICOC element |  Description | Keyword
---|---|---
Population |  What is the Software Engineer (SE) role, category of SEs, or the application area the SLR is interested in? | software developer
Intervention |  What software engineering method, technology, tool or process is the SLR interested in? | Privacy Enhancing Technologies
Comparison |  What software engineering method, technology, tool or process with which the intervention is being compared? | N/A
Outcomes |  What are the important results for practitioners? | data protection
Context |  What is the context within which the intervention is delivered? | software development

####  4.1.2. Formulating the Search Strings

After the research questions were formulated, we determined the search strings
needed to identify publications relevant to the research questions. We first
used the keywords outlined in Table 1 as the primary search strings. Then, we
considered the spelling variations (e.g. anonymisation and anonymization),
synonyms (e.g. developer and programmer), abbreviations (e.g. PETs), and
closely connected terms (data protection and privacy) of the primary search
strings to identify additional search strings. Expanding the collection of
search strings ensured that relevant publications were not overlooked
(Kitchenham and Charters, 2007). Table 6 in Appendix A contains the entire
collection of search strings defined in this SLR.

####  4.1.3. Selecting the Data Sources

As the next step, we selected scholarly data sources from which we could
identify relevant publications for the SLR. We considered three types of data
sources: _digital databases, conference proceedings_ , and _journal
proceedings_. We considered the six most cited digital databases for our SLR:
_IEEE Xplore 444https://ieeexplore.ieee.org/, ACM Digital
Library555https://dl.acm.org/, Springer Link 666https://link.springer.com/,
Scopus777https://www.scopus.com/, Sage888https://journals.sagepub.com/, and
Google Scholar999https://scholar.google.com/_. For journal and conference
proceedings, we selected the top-tier venues that publishes work in privacy
and security, software engineering (SE), human-computer interaction (HCI), and
information systems (IS). These research tracks were considered as the
research questions of this study involved humans (software developers),
software applications, and data protection. We considered 13 conferences and
11 journals to search publications, which are detailed in Table 2.

Table 2. Selected conference and journal proceedings which are categorised according to the respective research track. Track |  Conferences |  Journals
---|---|---
Privacy and Security |  • ACM Computer and Communications Security (CCS) • USENIX Security Symposium (USENIX-Security) • IEEE Symposium on Security and Privacy (S&P) • Network and Distributed System Security (NDSS) • Symposium On Usable Privacy and Security (SOUPS) • Proceedings on Privacy Enhancing Technologies (PoPETs) |  • IEEE Transactions on Information Forensics and Security (TIFS) • Computers and Security (Comput Secur) • Security and Communication Networks (Secur. Commun. Netw.) • ACM Transactions on Privacy and Security (TOPS) • IEEE Transactions on Dependable and Secure Computing (IEEE Trans. Dependable Secure Comput.)
Software Engineering (SE) |  • International Conference on Software Engineering (ICSE) • ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE) • International Conference on Automated Software Engineering (ASE) |  • IEEE Transactions on Software Engineering (TSE)
Human Computer Interaction (HCI) |  • ACM Conference on Human Factors in Computing Systems (CHI) • The Web Conference (WWW) |  • IEEE Transactions on Mobile Computing (IEEE Trans. Mob. Comput.) • IEEE Transactions on Human-Machine Systems (IEEE Trans. Hum.-Mach. Syst.)
Information Systems (IS) |  • International Conference on Management of Data (SIGMOD) • Conference on Information and Knowledge Management (CIKM) |  • IEEE Transactions on Industrial Informatics (IEEE Trans. Ind. Inform.) • Information Sciences (Inf. Sci.) • Information Fusion (Inf. Fusion)

####  4.1.4. Study Selection Criteria

In this stage, we defined selection criteria to determine the publications to
be included or excluded from the SLR (Kitchenham and Charters, 2007). They
were defined based on the research questions, study quality (e.g., peer-
reviewed articles), study type (e.g., research articles, review articles, or
white papers) and metadata (e.g., language, publication type, and published
year) (Oam, 2007). Table 3 presents the inclusion criteria (IC) and exclusion
criteria (EC) defined for this SLR.

Table 3. The selection criteria (inclusion and exclusion criteria) used to
select the most relevant publications for this SLR. The publications that
satisfied all inclusion criteria and none of the exclusion criteria were
included in the SLR. Inclusion Criteria
---
IC1: The publication answers at least one research question.
IC2: The publication is published in a peer-reviewed venue: _such studies have
a certain validity in their findings(Zbiciak and Markiewicz, 2023). Hence,
including them increases the quality of the SLR._
IC3: The publication is the most recent version, if it has previously
published versions.
IC4: The publication is published after 2016: _to make sure that the effect of
regulations is reflected, we included studies published from 2016, which is
the year that the EU’s GDPR was entered into force(Commission, 2023)._
IC5: The publication presents empirical studies conducted involving software
developers.
IC6: The publication is written in English.
Exclusion Criteria
EC1: The publication is a poster, short paper, ongoing study, concept paper,
opinion paper, technical paper, white paper, tutorial, abstract, report, news
article, book chapter, secondary study, or tertiary study.

###  4.2. Conducting the SLR

Once we finalised the SLR protocol, we searched for the relevant publications
in the selected data sources. Then, the identified publications were evaluated
against the decided selection criteria to filter and select the most relevant
ones. The key information was then extracted from these selected studies to
get familiarised with the findings of the selected publications. Finally, we
conducted a thorough qualitative analysis of the studies to answer the defined
research questions (R1, R2, and R3). These processes are explained in the
following sections.

####  4.2.1. Search and Selection Strategy

This SLR employed three different search processes to identify primary
publications from the selected data sources outlined in Section 4.1.3: 1)
automatic search on digital databases (Kitchenham and Charters, 2007), 2)
manual search on conference and journal proceedings (Kitchenham and Charters,
2007), 3) bi-directional snowballing (identifying papers from the reference
lists and the citations of a particular study) (Wohlin, 2014). Then, the
identified publications were evaluated using the selection criteria mentioned
in Table 3. This evaluation resulted in a total of 39 suitable publications
for this SLR, which are depicted in Table 4 along with their references. The
publications are sorted alphabetically according to the first author’ last
name. The three search and selection strategies were initially conducted
during May-July 2023. However, to incorporate the recent developments, we
subsequently performed a second round of search and selection activities in
November 2023. Figure 1 illustrates the search and selection strategy of this
SLR. This figure also states the number of articles excluded and the reasons
for exclusion.

Table 4. The list of the 39 publications selected for the SLR. Authors | Reference | Authors | Reference
---|---|---|---
Agrawal et.al (2021) | (Collier and Stewart, 2022) | Keküllüoğlu and Acar (2023) | (Keküllüoğlu and Acar, 2023)
Alhazmi and Arachchilage (2021) | (Alhazmi and Arachchilage, 2021) | Klymenko et.al (2022) | (Klymenko et al., 2022)
Alkhatib et.al (2020) | (Alkhatib et al., 2021) | Li et.al (2018) | (Li et al., 2018)
Alomar and Egelman (2022) | (Alomar and Egelman, 2022) | Munilla et.al (2023) | (Munilla Garrido et al., 2023)
Baldassarre et.al (2022) | (Baldassarre et al., 2022) | Peixoto et.al (2023) | (Peixoto et al., 2023)
Barbala et.al (2023) | (Barbala et al., 2023) | Perera et.al (2020) | (Perera et al., 2019)
Berk et.al (2023) | (Berk et al., 2023) | Peretz et.al (2021) | (Arizon-Peretz et al., 2021)
Boenisch et.al (2021) | (Boenisch et al., 2021) | Ribak (2019) | (Ribak, 2019)
Chen et.al (2018) | (Chen et al., 2018) | Rocha et.al (2023) | (Rocha et al., 2023)
Cobigo et.al (2020) | (Cobigo et al., 2020) | Sanderson et.al (2023) | (Sanderson et al., 2023)
Collier and Stewart (2022) | (Collier and Stewart, 2022) | Sarathy et.al (2023) | (Sarathy et al., 2023)
Dias et.al (2020) | (Dias Canedo et al., 2020) | Senarath and Arachchilage (2018) | (Senarath and Arachchilage, 2018a)
Dwork et.al (2019) | (Dwork et al., 2019) | Senarath and Arachchilage (2018) | (Senarath and Arachchilage, 2018b)
Ekambaranathan et.al (2021) | (Ekambaranathan et al., 2021) | Senarath et.al (2019) | (Senarath et al., 2019)
Greene and Shilton (2018) | (Greene and Shilton, 2018) | Spiekermann (2018) | (Spiekermann et al., 2019)
Hadar et.al (2018) | (Hadar et al., 2018) | Stahl et.al (2022) | (Stahl et al., 2022)
Hargitai et.al (2018) | (Hargitai et al., 2018) | Tahaei et.al (2021) | (Tahaei et al., 2021)
Horstmann et.al (2023) | (Horstmann et al., 2024a) | Zhang et.al (2018) | (Zhang et al., 2021)
Ibáñez and Olmeda (2022) | (Ibáñez and Olmeda, 2022) |  |
Iwaya et.al (2023) | (Iwaya et al., 2023) |  |

##### Digital database search

An automatic search was performed on the six selected digital databases. The
advanced search features of the digital databases and the search strings
presented in Table 6 were used to create a refined _search query_. In this
search query, quotation marks (” ”) were used to enclose multiple words
together, ensuring that the search results included the exact match (e.g.,
”software engineer”). In addition, the asterisk wildcard (*) replaced any
unknown characters in a string. For instance, the term developer* was used to
retrieve studies that contain the words ‘developer’ or ‘developers’. Further,
the ‘AND’ and ‘OR’ Boolean operators were used to construct a more
sophisticated and logical query. The final search query used to search the
digital libraries is as follows:

_(developer* OR programmer* OR ”software engineer” OR ”software engineers” OR
”software community” OR ”software industry” OR ”software system” OR ”software
systems” OR ”software creator” OR ”software creators” OR coder*) AND (PETs OR
”privacy enhancing technology” OR ”privacy enhancing technologies” OR ”privacy
preserving technology” OR ”privacy preserving technologies” OR ”privacy
enhancing technique” OR ”privacy enhancing techniques” OR ”privacy preserving
technique” OR ”privacy preserving techniques” OR ”privacy protection
technology” OR ”privacy protection technologies” OR ”privacy protection
technique” OR ”privacy protection techniques” OR ”data protection
technologies” OR ”data protection techniques” OR anonymisation OR
anonymization OR pseudonymisation OR pseudonymization OR ”synthetic data” OR
encryption OR ”zero knowledge proof” OR ”differential privacy” OR ”multi party
computing” OR ”federated learning”) AND (privacy OR ”data protection”) AND
(”software development” OR ”developing software” OR ”developing applications”
OR ”application development” OR ”system development” OR ”developing systems”
OR programming OR coding OR ”creating software” OR ”creating applications” OR
”software creation” OR ”application creation”)_

The database search resulted in a total of 1,867 publications. We then
screened the abstracts of those publications to exclude the ones that did not
satisfy the selection criteria. If the abstracts were not detailed enough to
make a decision, we screened the full text of the study. After screening the
publications from digital databases, we selected 22 publications, as shown in
Figure 1.

##### Conference and journal proceedings search

We manually searched the selected conferences and journals mentioned in Table
2 to identify additional publications which might have been overlooked during
the digital database search. The search resulted in 70 publications,
comprising 42 conference papers and 28 journal articles. Subsequently, seven
publications were selected based on the selection criteria.

##### Bi-directional snowballing

We supplemented the search process with a snowballing search to expand the
article coverage (Wohlin, 2014). The 22 publications selected from the digital
databases and seven publications selected from proceedings were used as the
initial articles of the snowballing process. Then, from the reference lists
(i.e., backward snowballing) and citations (i.e., forward snowballing) to
those articles, ten new studies were selected.

Figure 1. The search and selection strategy of the SLR. The separate phases
indicate the three search processes used to identify relevant publications. A
total of 39 primary articles were selected at the end of this process. n =
number of papers, IC# = Inclusion Criteria, EC# = Exclusion Criteria

During the search and selection process, it was necessary to assess the
reliability of the selection decisions to minimise the researcher bias.
Therefore, Cohen’s Kappa statistic was used to measure the level of agreement
between the authors (Landis and Koch, 1977). This statistic resulted in 0.88,
which is a nearly perfect agreement. The authors then discussed the
discrepancies and took appropriate actions to resolve them. For example, there
was a disagreement about including publications that did not explicitly
mention the term ‘PETs’ yet discussed developers’ technical privacy behaviour.
The authors discussed and collectively decided that those papers satisfied
inclusion criteria (IC1) in Table 3. This decision was taken because those
studies might indirectly shape how the software developers perceived and
incorporated PETs in their software. For instance, software developers who
lack knowledge of privacy regulations might not know that PETs can be used as
a technical solution to adhere to those regulations.

####  4.2.2. Data Extraction and Analysis

The authors employed the reflexive thematic analysis proposed by Braun &
Clarke (Braun and Clarke, 2021) to analyse the selected primary publications.
Reflexive thematic analysis encourages researchers to engage with their own
experience, knowledge, and perspective to delve deeper into the data and
extract rich meaning behind them. This method particularly suits our study due
to the diverse expertise of the authors. All authors have industrial
experience as software developers, and some authors are well-established
researchers in software privacy. The reflexivity offered by this dual
perspective forms a strong foundation for our study, which aims to explore
PETs in the context of software development.

Before the analysis phase, the authors extracted data from the selected
primary studies and recorded them in a tabular format which included the
following fields.

  * •

General information: _title, authors, author’s contact details, published
date, published venue, reference, notes_

  * •

Study Design: _study type, methodology, details about the data set, follow up
experiments_

  * •

Data fields specific to the underline research questions

  * •

Other data: _limitations, future work, additional notes, our insights_

We examined the extracted data to familiarise ourselves with the content of
the selected publications (Braun and Clarke, 2021). This familiarisation
process allowed us to understand the key findings of the publications and
build initial analytical thoughts on the common patterns and relationships in
the findings. For example, after reading the extracted data, the authors
discussed how the software development life cycle (SDLC) stages are related to
the challenges in integrating PETs into software.

After the familiarisation phase, the collected articles were open-coded
(coding without a predefined coding scheme (Braun and Clarke, 2021)) using
NVivo101010https://lumivero.com/products/nvivo/, a qualitative data analysis
software which provides interfaces and features to easily conduct and manage
the processes in qualitative analysis. Both semantic codes (surface meaning)
and latent codes (underpinning ideas behind the surface meaning) were
generated during the coding process (Braun and Clarke, 2021). For example, the
following excerpt semantically describes the users’ inability to demand
software privacy from the developers.

> _”Educate the market and end-users [about privacy], then developers will be
> forced to meet their requirements”_ (Alkhatib et al., 2021)

However, we attributed this to a more latent code - ”lack of perceived
responsibility”, as the developer was trying to pass the responsibility of
protecting privacy to the end-users. In contrast, the following excerpt was
attributed to a more straightforward (semantic) code - ”unawareness of PETs”.

> _”Differential privacy? No, I do not [know it]”_ (Ibáñez and Olmeda, 2022)

Four iterative rounds of coding were conducted to extract as much meaning out
of the publications. Then, the identified codes were organised under different
themes based on their similarities and patterns. For example, we aggregated
codes ”evaluating performance” and ”evaluating utility” under the theme
”evaluation of PETs”, which was related to explaining how developers assessed
PETs. Subsequently, the themes were categorised under the defined research
questions. The codes that did not fit the finalised themes were removed from
the analysis process. Since using the concept of reflexivity led us to
interpret the codes subjectively, applying inter-coder agreement to determine
the final set of codes was not needed (Braun and Clarke, 2021). Instead, we
collectively compared the codes and discussed their differences as the themes
began to emerge.

Figure 2. The overview of the themes identified from the reflexive thematic
analysis of the Systematic Literature Review (SLR) and the main findings under
each theme. The themes are categorised under respective research questions.
The figure also mentions the sections that discuss each theme. RQ# = Research
Question

##  5\. Results

This section presents the results identified from the reflexive thematic
analysis of the SLR. As shown in Figure 2, we uncovered insightful findings
into the types of PETs that developers have integrated into software and how
they have integrated them (RQ1), the difficulties they encountered during the
integration of PETs (RQ2), and the solutions introduced in the literature to
address the identified difficulties (RQ3).

###  5.1. Integration of PETs into Software: Motivation, Application and
Evaluation

Our analysis revealed six types of PETs that developers have integrated into
their software. These included long-established PETs, such as pseudonymisation
(Hargitai et al., 2018), k-anonymity (Hargitai et al., 2018), and onion
routing (Collier and Stewart, 2022). In addition, developers also integrated
emerging PETs including, federated learning (Zhang et al., 2021), differential
privacy (Dwork et al., 2019), and synthetic data (Sarathy et al., 2023).
Software developers integrated the identified PETs into software motivated by
three main reasons: the end-user privacy protection (Dwork et al., 2019;
Collier and Stewart, 2022; Zhang et al., 2021), regulatory compliance (Ribak,
2019; Agrawal et al., 2021) and opportunity for secure data collaboration
(Sanderson et al., 2023; Hargitai et al., 2018). Further, they used evaluation
criteria, including scalability (Zhang et al., 2021), efficiency (Zhang et
al., 2021), and performance (Collier and Stewart, 2022; Zhang et al., 2021),
to assess PETs before selecting them or during their integration. The
identified application scenarios demonstrated the privacy-preserving
capabilities of PETs in different software domains and fields. These included
healthcare (Sanderson et al., 2023), finance (Hargitai et al., 2018), legal
(Hargitai et al., 2018), government services (Hargitai et al., 2018),
telecommunication (Zhang et al., 2021; Collier and Stewart, 2022) and machine
learning (ML) (Sanderson et al., 2023). These results are summarised in Table
5 with references to the respective publications. In the following
subsections, we report these findings in detail.

Table 5. The instances where Privacy Enhancing Technologies (PETs) were integrated into software by developers. The table depicts the PETs used in the reported instances, the empirical studies that reported the instances, the reasons for using the reported PETs, the related software domains related to the application instances, and the criteria used to evaluate the reported PETs. ”-” was used when the studies did not provide specific details. PET | Reference | Reason(s) |  Domain/field |  How was the PET used |  | Evaluation
---
criteria
Pseudonymisation | (Hargitai et al., 2018) | privacy protection |  legal |  They had an application to evaluate legal papers and automatically identify personal data items, such as names and addresses. The system then relabelled the specified data using pseudonyms. | -
| (Hargitai et al., 2018) | privacy protection |  government services |  The sensitive data was masked. The developers were reluctant to explain the specifics of the application scenario fearing potential privacy risks. | -
K-anonymity | (Hargitai et al., 2018) |  | compliance
---
collaboration
finance |  Developers did not mention the fine details of the application but stated they used suppression and generalisation. The authors claimed the developers used a version of k-anonymity. | -
| (Munilla Garrido et al., 2023) | compliance | - |  Generalised individual numeric values to a numerical range | -
| (Munilla Garrido et al., 2023) |  | compliance
---
- |  Removed personally identifiable information (PII) from the data sets | -
| (Sanderson et al., 2023) | privacy protection |  machine learning |  Removed personally identifiable information (PII) from the data sets | -
Onion routing | (Collier and Stewart, 2022) | privacy protection |  telecommunication |  The user’s internet traffic was bounced through a relay of intermediate servers so that the Internet Service Provider cannot identify the origin and destination of the communication. | performance
Federated Learning | (Sanderson et al., 2023) |  | privacy protection
---
collaboration
healthcare |  Different research institutes collaboratively analysed genomic data without sharing each other’s data into a centralised location. | -
| (Zhang et al., 2021) |  | compliance
---
telecommunication |  Ericsson was planning to deploy differential privacy so that they can learn from their customers data which were distributed across different countries. |  | efficiency
---
scalability
performance
Differential Privacy |  (Sanderson et al., 2023), (Dwork et al., 2019) | privacy protection | - |  The study did not provide details of the integration process | -
Synthetic data | (Sanderson et al., 2023) | privacy protection |  machine learning |  Replaced the machine learning datasets that included sensitive data. | -

####  5.1.1. Pseudonymisation

An empirical study by Hargitai et al. (Hargitai et al., 2018) revealed two
instances where developers used pseudonymisation. In the first instance, a
developer from the legal sector explained how they developed software to
automatically identify personal data items such as names and addresses and
then relabel them using pseudonyms (Hargitai et al., 2018). They were mainly
motivated by the need to protect the public’s privacy, as legal documents
contain highly sensitive information regarding them. In the second instance,
an application developed for government services also used pseudonymisation to
mask sensitive data in its datasets (Hargitai et al., 2018). These datasets
were obtained from municipalities and contained sensitive data collected from
the public. Therefore, to protect the public’s privacy, developers anonymised
the datasets using pseudonymisation. Further, they collaborated with their
organisation’s business, legal, and security units, and the customers to
decide which sensitive data items to mask.

####  5.1.2. K-anonymity

Three publications mentioned how developers used k-anonymity in software
(Hargitai et al., 2018; Munilla Garrido et al., 2023; Sanderson et al., 2023).
Each reported application scenario used suppression, generalisation, or both
to achieve k-anonymity.

According to an interview study conducted by Hargitai et al. (Hargitai et al.,
2018), developers working in the finance domain implemented k-anonymity to
anonymise their datasets, primarily to comply with privacy regulations
(Hargitai et al., 2018). Apart from this primary motivation, they were also
influenced by the ability to safely collaborate data with external parties for
research or business purposes. Such collaborations are otherwise challenging
due to privacy concerns (Sanderson et al., 2023). However, during these
interviews, the developers did not provide specific details about the
integration process of PETs. They only mentioned using a combination of
suppression and generalisation techniques without revealing further
information. In addition, the developers also mentioned that multidisciplinary
actors, including legal, customer service and IT support, collaborated to
decide the data fields that must be anonymised (Hargitai et al., 2018).

In addition, an interview study by Garrido et al. (Munilla Garrido et al.,
2023) revealed two instances where developers used k-anonymity. In both
instances, k-anonymity was used to abide by privacy regulations when using
end-user data for secondary purposes. According to regulations such as GDPR,
collected personal data cannot be used beyond their original purpose without
the explicit consent of the data owners (e.g., GDPR article 5: personal data
processing (European Commission, 2016)). To comply with this data protection
principle, developers anonymised the datasets by mapping the individual
numeric data items to numeric ranges (generalisation) and removing PII,
including names and social security numbers(suppression). In both cases, the
link between the data and their owners was removed, making those data no
longer identified as ‘personal data’, thus refraining from breaking the
privacy regulations (Munilla Garrido et al., 2023).

Further, an interview study conducted by Sanderson et al. (Sanderson et al.,
2023), which investigated the ethical practices of artificial intelligence
researchers and software developers, also mentioned the usage of suppression.
During this study, a developer mentioned using suppression to eliminate PII
from datasets to protect the privacy of the data owners. However, further
details about the application of suppression (e.g., data fields that the
developers suppressed) were absent.

####  5.1.3. Onion routing

Only one publication discussed how software developers used onion routing
(Collier and Stewart, 2022). A case study conducted by Collier et al. (Collier
and Stewart, 2022) interviewed developers of the Tor browser to explore their
privacy practices. Fearing how the Internet can threaten the privacy of its
users, these developers invented the Tor browser using onion routing. In Tor,
onion routing directs users’ Internet traffic over a network of intermediary
servers before reaching its destination. Due to this approach, the origin and
destination of the communications are kept hidden from the Internet Service
Provider (ISP). As a result, the users could browse the Internet anonymously,
which protected their privacy (Collier and Stewart, 2022).

During this empirical study, developers expressed that they defined a threat
model 111111identify a set of risks and their mitigation discourses by
analysing particular use cases, attacks, and defences (Collier and Stewart,
2022) before developing the Tor browser. Such threat modelling allowed the
developers to make the best development decisions to improve the anonymity of
the browsing experience. In addition, the study mentioned that developers used
performance as a metric to evaluate the onion routing technique. For instance,
during the development of the Tor browser, developers thought of including
”padding traffic”, i.e., fake traffic, to elevate the anonymity offered by the
onion routing technique. However, they later decided to discard this idea as
it would have created a significant performance overhead, slowing down the
browsing experience of the users (Collier and Stewart, 2022).

####  5.1.4. Federated Learning

Two empirical studies reported how developers used federated learning in
software (Sanderson et al., 2023; Zhang et al., 2021). Sanderson et al.
(Sanderson et al., 2023) reported a scenario in which federated learning was
incorporated into a healthcare application. In this scenario, multiple health
institutions wanted to collaboratively analyse genomics data, which holds a
wealth of insights about humans. However, since genomics data are highly
sensitive personal data, the institutions did not want to share their data.
Hence, by using federated learning in the analysis process, developers
protected the privacy of the data owners while allowing the institutions to
gain insights from the genomics data (Sanderson et al., 2023).

In addition, a case study conducted with Ericsson’s developers highlighted how
they were planning to use federated learning to ensure regulatory compliance
(Zhang et al., 2021). Ericsson, a leader in the telecommunication field, could
not transfer their worldwide customer data to a centralised location due to
strict privacy regulations in some countries, which restricted moving data out
of their jurisdiction. To address such regulations, the developers planned to
utilise federated learning, enabling them to gain insights from decentralised
customer data.

Further, developers of Ericsson evaluated federated learning (Zhang et al.,
2021) using multiple criteria before incorporating it. They were concerned
about smoothly managing resources (e.g., communication bandwidth) when remote
clients grow, i.e., scalability assessment. In addition, this potential growth
in the customer base has led them to assess the efficiency of federated
learning. With the increase in remote clients, developers anticipated high
communication congestion with the global machine learning model, leading them
to consider communication efficiency. Moreover, they were also concerned about
how the data heterogeneity in remote clients could impact the performance of
the global model.

####  5.1.5. Differential Privacy

None of the empirical studies included in our SLR provided comprehensive real-
world scenarios for integrating differential privacy. Only two instances were
found where developers simply acknowledged using differential privacy in their
applications without providing additional details (Dwork et al., 2019;
Sanderson et al., 2023).

However, some empirical studies reported developers’ opinions about the
accuracy of differentially private data (Munilla Garrido et al., 2023;
Senarath and Arachchilage, 2018b). Developers stated that the usage of
differential privacy depends on the specific software use cases (Munilla
Garrido et al., 2023; Senarath and Arachchilage, 2018b). For example, a
financial application interested in calculating the yearly budget requires a
higher accuracy, thus eliminating the use of differential privacy since it
adds noise to the generated query results (Munilla Garrido et al., 2023). In
addition, some developers commented on how the data quality can decide whether
or not to use differential privacy. For example, sensor-collected data, such
as GPS locations, naturally has a slight inaccuracy to them (Munilla Garrido
et al., 2023). Therefore, using differential privacy on such data further
increases the inaccuracy by introducing additional noise, thus making the data
unusable (Munilla Garrido et al., 2023).

####  5.1.6. Synthetic Data

The usage of synthetic data was mentioned in one publication (Sanderson et
al., 2023). According to the publication, ML developers chose synthetic data
over datasets containing sensitive information, responding to privacy concerns
associated with them. However, it was not mentioned how developers generated
the synthetic datasets to mimic the properties of the replaced datasets.

In addition, two selected publications suggested using synthetic data for
testing the configuration of other PETs (Sarathy et al., 2023; Munilla Garrido
et al., 2023). For example, after configuring differential privacy, developers
can use synthetic data to assess whether the expected accuracy level is
achieved in the data query results. This approach eliminates the necessity to
test differential privacy on actual data, thus further reducing privacy risks
(Sarathy et al., 2023; Munilla Garrido et al., 2023).

###  5.2. Challenges Faced by Developers During the Integration of PETs

Our analysis uncovered challenges that either refrained developers from
embedding PETs into software or made them integrate PETs ineffectively where
desired data protection guarantees were not achieved. Some challenges were
caused by internal factors stemming from developers’ lack of awareness (Ibáñez
and Olmeda, 2022; Sanderson et al., 2023; Barbala et al., 2023) and knowledge
of PETs (Senarath and Arachchilage, 2018b; Sarathy et al., 2023) and the
inability to prioritise privacy concerns in software (Chen et al., 2018;
Ekambaranathan et al., 2021; Alomar and Egelman, 2022; Hadar et al., 2018). On
the other hand, some challenges were beyond developers’ control, which
included the lack of maturity of the software development life cycle (SDLC) to
accommodate PETs into software (Iwaya et al., 2023; Alkhatib et al., 2021;
Keküllüoğlu and Acar, 2023) and the increased software development cost due to
the inner complexities of PETs (Hargitai et al., 2018; Agrawal et al., 2021;
Sanderson et al., 2023).

####  5.2.1. Lack of awareness about PETs

To integrate PETs into software, developers must first be aware of the
existence of such technologies. However, our analysis revealed that some
developers were still unaware of PETs (Ibáñez and Olmeda, 2022; Sanderson et
al., 2023; Barbala et al., 2023; Senarath and Arachchilage, 2018b). One
publication indicated how developers directly expressed their unawareness of
PETs:”Differential privacy? No, I do not [know it]” (Ibáñez and Olmeda, 2022).
Sometimes, developers resorted to traditional PETs such as k-anonymity or
pseudonymisation, even if unsuitable for a given application scenario
(Hargitai et al., 2018). They failed to acknowledge the existence of other
PETs that would be more suitable for their application scenarios than the
traditional PETs (Hargitai et al., 2018). This preference towards traditional
PETs was also witnessed during empirical studies where the developers were
asked to embed privacy in a given experimental application scenario (Senarath
and Arachchilage, 2018b).

In other cases, developers’ unawareness of PETs was displayed through their
incompetent decisions to overcome privacy-related roadblocks encountered
during software development (Sanderson et al., 2023; Barbala et al., 2023;
Ibáñez and Olmeda, 2022). For instance, developers sometimes restricted the
collection and usage of data to overcome the regulatory pressure (Sanderson et
al., 2023; Barbala et al., 2023). This seemingly cautious approach displayed
the ”better safe than sorry” mentality (Barbala et al., 2023) of the
developers. However, the root cause of such behaviour can be traced to
developers’ lack of awareness about the existing PETs and their privacy-
enhancing capabilities (Senarath and Arachchilage, 2018b).

####  5.2.2. Lack of PETs-related knowledge

Some developers were aware of PETs but lacked the proper knowledge to
understand and integrate them effectively to address privacy concerns within
their software projects (Senarath and Arachchilage, 2018b; Sarathy et al.,
2023). Developers struggled to decide which PETs to use, when to apply PETs,
and what privacy level they should aim to achieve when applying PETs in a
given scenario (Senarath and Arachchilage, 2018b). Responding to these
uncertainties, developers sought external verification for their decisions,
displaying their lack of confidence in integrating PETs into software
(Senarath and Arachchilage, 2018b; Sarathy et al., 2023).

Additionally, when incorporating PETs with an algorithmic background into
software, developers struggled to understand how to set the parameters of the
algorithms, how these parameters affect the entire application (e.g., impact
on performance and utility) and what parameters must be changed to achieve the
desired privacy levels (Sarathy et al., 2023; Munilla Garrido et al., 2023).
For instance, some developers knew the concept of ”noise” in differential
privacy and how it affected their software’s data accuracy and privacy levels.
However, when initialising the noise value, they anchored to the other
existing projects or used the parameter settings stated in research studies
without deciding whether those noise values would suit their software
applications (Dwork et al., 2019).

Moreover, developers lacked the knowledge to resolve any vulnerabilities of
the PETs deployed in their applications (Hargitai et al., 2018; Senarath and
Arachchilage, 2018b). One such vulnerability is the de-anonymisation risk in
pseudonymised data (Hargitai et al., 2018). For example, L.Sweeney (Sweeney,
2000) showed how anonymised medical datasets can be de-anonymised by
identifying matching quasi-identifiers in publicly available voting lists.
Developers aware of this vulnerability in their applications resorted to
immature workarounds instead of taking measures to mitigate the vulnerability
(Hargitai et al., 2018). These workarounds included limiting access to the
pseudonymised data within the organisation and maintaining the secrecy of the
technical implementations (Hargitai et al., 2018).

Further, aggravating the lack of knowledge in PETs, there is an absence of
educational approaches for developers to learn about PETs (Tahaei et al.,
2021; Li et al., 2018; Tahaei et al., 2021; Agrawal et al., 2021; Ibáñez and
Olmeda, 2022). Developers voiced their difficulties in accessing updated
information on privacy concepts, a challenge that naturally extends to the
realm of PETs (Tahaei et al., 2021). In addition, educational resources, such
as research papers and online articles, contained complex information, making
it difficult for non-experts to understand the fine details of PETs (Li et
al., 2018; Tahaei et al., 2021; Agrawal et al., 2021). Moreover, developers
did not receive sufficient training opportunities to enhance their PETs-
related knowledge (Ibáñez and Olmeda, 2022; Arizon-Peretz et al., 2021; Stahl
et al., 2022). For example, developers expressed that their organisations
focused more on non-privacy-related training, such as avoiding workplace
harassment (Ibáñez and Olmeda, 2022). Even when organisations initiated
privacy training, those sessions lacked the delivery of technical aspects of
achieving privacy (Arizon-Peretz et al., 2021).

####  5.2.3. Inability to prioritise privacy concerns

As PETs come under the broader concept of privacy, developers’ ability to
prioritise privacy concerns is required to understand the need for PETs
(Collier and Stewart, 2022). However, according to our analysis, some
developers failed to prioritise privacy in software because they believed that
protecting privacy is neither important (Chen et al., 2018; Perera et al.,
2019; Alkhatib et al., 2021; Horstmann et al., 2024a) nor their responsibility
(Chen et al., 2018; Alomar and Egelman, 2022; Iwaya et al., 2023).

Empirical studies reported that some developers fail to perceive the
importance of addressing privacy concerns in their software (Chen et al.,
2018; Perera et al., 2019; Alkhatib et al., 2021). Developers believed that
limiting the excessive collection and analysis of data due to privacy concerns
was a roadblock to achieving unexplored benefits of data (Chen et al., 2018;
Ekambaranathan et al., 2021; Alomar and Egelman, 2022; Tahaei et al., 2021;
Arizon-Peretz et al., 2021). Therefore, developers had reservations about
implementing privacy protection principles, like data minimisation (Chen et
al., 2018; Perera et al., 2019; Senarath and Arachchilage, 2018b). In
addition, they also believed that ensuring privacy protection in software is
unnecessary as the end-users and the organisations did not demand enhanced
privacy levels in software (Spiekermann et al., 2019; Ibáñez and Olmeda, 2022;
Peixoto et al., 2023; Iwaya et al., 2023; Hadar et al., 2018; Arizon-Peretz et
al., 2021; Dias Canedo et al., 2020). For example, some organisations directly
advised developers to ignore privacy concerns (Spiekermann et al., 2019; Iwaya
et al., 2023; Hadar et al., 2018; Arizon-Peretz et al., 2021), while some
indirectly displayed their indifference to privacy by neglecting to provide
adequate privacy training (Ibáñez and Olmeda, 2022) or by failing to emphasise
the need for regulatory compliance (Dias Canedo et al., 2020). As a result,
developers attempted to deliver a working product while overlooking privacy
concerns, assuming that end-users and organisations value functionality more
than privacy (Alkhatib et al., 2021).

Further, developers who participated in the empirical studies often believed
safeguarding privacy was beyond their job description (Peixoto et al., 2023;
Hadar et al., 2018; Rocha et al., 2023). Hence, they were reluctant to take
responsibility for integrating privacy into the software they developed. They
held different views on who should safeguard privacy: software end-users (Chen
et al., 2018; Alomar and Egelman, 2022; Li et al., 2021; Alkhatib et al.,
2021; Agrawal et al., 2021), upper management in the organisation (Alomar and
Egelman, 2022; Tahaei et al., 2021; Iwaya et al., 2023; Hadar et al., 2018;
Ribak, 2019), specialised privacy teams (Alomar and Egelman, 2022; Alhazmi and
Arachchilage, 2021; Alkhatib et al., 2021), or mobile platforms into which
they released software (e.g., Android Play Store) (Alomar and Egelman, 2022;
Greene and Shilton, 2018). Developers believed that user-based privacy
measures, such as privacy policies and consent forms, are sufficient to
protect end-user privacy (Alomar and Egelman, 2022; Klymenko et al., 2022;
Iwaya et al., 2023; Cobigo et al., 2020; Ribak, 2019; Arizon-Peretz et al.,
2021). In addition, some developers believed that upper management should make
privacy decisions and direct privacy concerns to dedicated privacy experts
other than developers (Alomar and Egelman, 2022; Klymenko et al., 2022; Iwaya
et al., 2023; Cobigo et al., 2020; Ribak, 2019; Arizon-Peretz et al., 2021;
Klymenko et al., 2022; Alhazmi and Arachchilage, 2021; Alkhatib et al., 2021).
Additionally, developers assumed that marketplaces provided correct and
complete privacy definitions and guidelines, limiting their exploration of
privacy concepts (Greene and Shilton, 2018). Moreover, they had marketplaces
accountable for automatically detecting privacy vulnerabilities with their
software, overlooking the proactive mitigation of privacy issues (Alomar and
Egelman, 2022). These beliefs and actions demonstrated how developers passed
on the responsibility of protecting user privacy to other parties rather than
accepting that they also have a fair share in protecting it (Hadar et al.,
2018).

####  5.2.4. Inadequate maturity of the software development life cycle (SDLC)
to support the integration of PETs

The SDLC is the systematic methodology that guides the decisions and actions
of developers through the various stages of software creation, from
requirement gathering to developing and maintaining the software (van den
Bosch et al., 1982). However, our analysis indicated that the current SDLC
practices were not transformed to support integrating PETs into software
(Iwaya et al., 2023; Alkhatib et al., 2021; Keküllüoğlu and Acar, 2023;
Klymenko et al., 2022).

The privacy specifications were ignored during the requirement gathering
stage, making privacy an afterthought in software development (Alomar and
Egelman, 2022; Alkhatib et al., 2021; Iwaya et al., 2023). A study by Peixoto
et.al (Peixoto et al., 2023) reported how developers directly expressed that
privacy was not a concern of their projects - _”Never…in any project I
participated in here (company), we focused on that (privacy)”_ (Peixoto et
al., 2023). This lack of planning made developers improvise the technical
integration of privacy, leading to a struggle with inadequate resources (e.g.,
time and developers) required for the process (Iwaya et al., 2023; Perera et
al., 2019; Peixoto et al., 2023). One of the main contributors to ignoring
privacy as a requirement was that the development teams were unaware of the
potential privacy risks of their software (Peixoto et al., 2023; Iwaya et al.,
2023; Berk et al., 2023; Alkhatib et al., 2021). This outcome occurred due to
the lack of standard risk assessment methodologies, such as privacy impact
assessments (PIAs), used during software development (Li et al., 2021;
Alkhatib et al., 2021; Keküllüoğlu and Acar, 2023; Senarath and Arachchilage,
2018a). Due to this absence of risk identification, developers failed to
understand the need for technical measures, such as PETs, to mitigate
potential privacy risks (Tahaei et al., 2021).

In addition, despite being the leading roles in software development,
developers were not actively engaged in privacy-related discussions (Alomar
and Egelman, 2022; Iwaya et al., 2023). Instead, decisions regarding
implementing technical privacy measures, such as PETs, often came from higher
management of the organisations (Klymenko et al., 2022). In some cases, this
left developers powerless to take action through technical solutions such as
PETs, even when they discovered privacy vulnerabilities in their systems
(Iwaya et al., 2023).

Further, developers displayed limited skills in generating system designs with
privacy in mind (Senarath and Arachchilage, 2018b; Perera et al., 2019). As
system designs are the blueprints for the development phase, overlooking
privacy considerations during this stage leads to ignoring privacy concerns
during the development stage (Senarath and Arachchilage, 2018b). Two empirical
studies reported how developers struggled to include adequate technical
privacy measures, like PETs, when asked to create software designs
incorporating privacy (Senarath and Arachchilage, 2018b; Perera et al., 2019).
This inability demonstrated that creating privacy-based designs, particularly
those incorporating PETs, is not a well-established step in the SDLCs that
developers follow (Senarath and Arachchilage, 2018b; Perera et al., 2019).

####  5.2.5. Integrating PETs increases software development cost

Developers often aim to reduce the time-to-market of software to gain a
competitive advantage (Tahaei et al., 2021). However, developers saw
integrating PETs into software as an obstacle to this goal because of the
increased software development cost incurred from the inner complexities of
PETs (Agrawal et al., 2021; Sarathy et al., 2023; Munilla Garrido et al.,
2023).

PETs, particularly the emerging ones, such as differential privacy and
homomorphic encryption, contain many variables that need fine-tuning to
achieve the required privacy guarantees (Agrawal et al., 2021; Munilla Garrido
et al., 2023). Consequently, the variable adjustment is time-consuming and
requires careful consideration, as each variable could significantly impact
the outcomes of PETs (Munilla Garrido et al., 2023; Agrawal et al., 2021).
Developers sometimes ignored PETs due to this difficulty, which negatively
impacted the data protection achieved through the software they developed. For
instance, during an empirical study conducted to explore organisational
strategies to anonymise data (Hargitai et al., 2018), one developer mentioned
how their team considered synthetic data but later decided against it because
they needed to adjust many variables to generate properties of the real
datasets. In addition, some publications reported that minor alterations to
the variables resulted in drastic changes to the performance, utility and even
the privacy assurance of the entire application (Hargitai et al., 2018;
Agrawal et al., 2021; Sanderson et al., 2023). Due to this high sensitivity,
developers needed to be extra cautious when calibrating the variables of PETs,
not only during their initialisation but also when updating the applications
(Agrawal et al., 2021).

Developers also mentioned how the existing software architectures make the
integration of PETs more resource-consuming (Zhang et al., 2021; Munilla
Garrido et al., 2023; Agrawal et al., 2021). For instance, in federated
learning architecture, data heterogeneity across different remote clients
affects the performance of their learning models. As a result, developers
required substantial time to rectify data standards in remote clients (Zhang
et al., 2021).

Tools like libraries (SEAL, 2023; Wang et al., 2016; Team, 2017), frameworks
(He et al., 2019; Yuan et al., 2017), or visualisation aids (Gaboardi et al.,
2016; Nanayakkara et al., 2022) exist to streamline the integration of PETs
into software. However, developers who are not experts in PETs found it
difficult to use these tools (Agrawal et al., 2021; Sarathy et al., 2023).
Developers highlighted issues with PET-related libraries, citing concerns
about the ideal level of information abstraction (Sarathy et al., 2023;
Agrawal et al., 2021). Some libraries exposed excessively complex operations,
making it challenging to create customised applications (Agrawal et al.,
2021). In contrast, others lacked sufficient background information for
informed decision-making, presenting difficulties for non-experts (Sarathy et
al., 2023; Agrawal et al., 2021).

In addition, two interview-based studies found that some developers faced
difficulties using tools developed to integrate differential privacy into
software (Sarathy et al., 2023; Munilla Garrido et al., 2023). These
challenges stemmed from the tools not aligning with developers’ current data
analysis workflows (Sarathy et al., 2023; Munilla Garrido et al., 2023). They
lacked options to visualise the data query results and their accuracy levels
after adding noise (Sarathy et al., 2023; Munilla Garrido et al., 2023).
Moreover, they excluded options to test differential privacy configurations
using synthetic datasets (Sarathy et al., 2023; Munilla Garrido et al., 2023).
Further, these tools lacked sufficient export options for generating outputs
in multiple file formats, such as comma-separated values (CSVs) and Jupyter
Notebook files, which are commonly used for data analysis (Sarathy et al.,
2023).

###  5.3. Proposed Solutions to Resolve the Identified Challenges

The literature suggested solutions to address only three challenges identified
in Section 5.2: lack of PETs-related knowledge, inadequate maturity of SDLC,
and reducing the development cost of integrating PETs into software. We also
captured the limitations of these solutions to identify the areas for
improvement.

####  5.3.1. Enhancing the knowledge of PETs

The literature suggested a PETs-related knowledge base (Baldassarre et al.,
2022), knowledge-sharing mechanisms (Dwork et al., 2019; Li et al., 2021), and
privacy tutorials and frameworks with a technical touch (Rocha et al., 2023;
Sarathy et al., 2023) to enhance the developers’ knowledge about PETs.

The Privacy Knowledge Base (PKB) tool developed by Barletta et al.
(Baldassarre et al., 2022) aimed to support developers’ decisions during
privacy-oriented software development. This tool allows developers to enter a
software vulnerability they require to resolve along with the type of
architecture of their software (e.g., client-server architecture). Then, the
tool suggested suitable PETs to address the entered vulnerability. Using the
PKB tool, developers can gradually learn how PETs can be helpful in data
protection by mitigating software vulnerabilities. Therefore, we considered
this tool as an approach to enhance the developers’ knowledge of PETs, in
addition to its original goal of supporting privacy decisions. However, the
tool did not cover more advanced knowledge concepts of PETs, such as to
integrate the selected PETs into software technically. Furthermore, even
though the tool’s usability and operability were evaluated, its effectiveness
in educating developers is yet to be assessed (Baldassarre et al., 2022).

In addition, two solutions emphasised learning about PETs through knowledge-
sharing. Dwork et al. (Dwork et al., 2019) proposed the ”Epsilon Registry,” a
knowledge archive into which organisations who have already deployed
differential privacy can enter the details of their integration scenarios.
This registry allows developers to learn from the experiences and best
practices of others who have already integrated differential privacy into
software, such as configuring the noise value. However, organisations may have
low incentives to disclose such knowledge voluntarily (Dwork et al., 2019). A
similar behaviour was also seen in a study conducted by Hargitai et al.
(Hargitai et al., 2018), where developers were reluctant to disclose the
details of their implementation of anonymisation techniques. In such
instances, Dwork et al. (Dwork et al., 2019) suggested using the coercive
power of law to influence information disclosure. Another knowledge-sharing
solution proposed by Li et al. (Li et al., 2021) suggested online developer
forums to provide templates for privacy-related posts and encourage developers
to exchange their privacy practices. The authors suggested that the forums
establish guidelines that prompt developers to ask for better data practices
from other developers. However, the identified knowledge-sharing solutions
were conceptual and not evaluated through experimental studies (Li et al.,
2021).

Furthermore, some publications suggested readily available tutorials to
enhance the knowledge of PETs (Sarathy et al., 2023; Alhazmi and Arachchilage,
2021). Sarathy et al. (Sarathy et al., 2023) discussed that the content of
such tutorials should be simple, accompanied by code snippets, mathematical
examples and visualisation mechanisms for better understanding. In addition,
researchers advocated the design of privacy tutorials and frameworks to
associate regulatory principles with relevant technical measures (Rocha et
al., 2023). For instance, Rocha et al. (Rocha et al., 2023) proposed a
framework suggesting technical approaches to achieve principles in the
Brazilian General Data Protection Law (LGPD) 121212Brazilian General Data
Protection Law is the English translation of Lei Geral de Proteção de Dados
Pessoais, LGPD, in Portuguese (Dias Canedo et al., 2020). For example, this
framework suggested using anonymisation for the ‘data security’ principle of
LGPD. However, the framework failed to provide the exact PETs to be employed
(e.g., PETs to achieve anonymisation).

####  5.3.2. Improving the SDLC to support the integration of PETs

Three studies provided solutions to transform the SDLC to support the
integration of PETs into software (Baldassarre et al., 2022; Perera et al.,
2019; Li et al., 2018). These solutions focused on the design and development
stages of the SDLC.

Our analysis stage identified two solutions that guide developers in creating
privacy-oriented system designs focusing on PETs (Baldassarre et al., 2022;
Perera et al., 2019). The PKB tool described in Section 5.2.2 also suggested
privacy patterns, which are practical design solutions to address privacy
concerns. The PETs suggested by the tool are mentioned alongside the privacy
patterns to convey how each pattern is achieved technically. Therefore, we
categorised the PKB tool as an approach towards creating system designs by
considering PETs. The second solution, presented by Perera et al. (Perera et
al., 2019), included a set of privacy by design guidelines customised to
address privacy concerns in five stages of the IoT data workflow (acquisition,
preprocessing, processing and analysis, storage, and dissemination). For
example, ‘hidden data routing’ was a guideline to anonymise personal data
during the data acquisition and dissemination stages. However, this framework
only suggested the expected privacy-preserving functionality (e.g., hidden
data routing) rather than mentioning the specific PETs to utilise (e.g., onion
routing).

Moving on to improving the development stage of the SDLC, we identified the
Coconut - Android Studio plugin, which aimed to guide developers in resolving
privacy risks during software development (Li et al., 2018). It provided a way
to document data handling practices through customised annotations. These
annotations reported aspects such as the purpose, frequency, granularity, and
visibility of a data-handling code snippet. The study did not explicitly state
how PETs were supported by the tool, but we captured such instances through
its usability experiment. For example, when a developer attempted to collect
fine-grained location data, the plugin provided a real-time warning,
indicating that coarse-grained location collection was sufficient. In this
instance, the coarse-grained location collection is a location anonymisation
technique achieved through generalisation (Fan and Gote, 2021). However, the
controlled nature of the usability experiment and the limited participation of
only 18 developers limited the applicability of the findings to a larger
population of developers (Li et al., 2018).

####  5.3.3. Reducing the development cost required for the integration of
PETs

We identified three solutions proposed to reduce the software development cost
of integrating PETs into software (Zhang et al., 2021; Munilla Garrido et al.,
2023; Agrawal et al., 2021). However, none of these three solutions were
evaluated in the software development context.

Zhang et al. (Zhang et al., 2021) proposed five prerequisites to consider in a
software architecture before designing a federated learning system. These
included providing services for continuous real-time model learning, efficient
resource utilisation for model training at remote clients, streamlined
communication with central servers, performance evaluation mechanisms for
machine learning models in remote clients, developing scalable architectures,
and establishing secure connections between edge clients and the central
server. By adhering to these criteria, developers can reduce misunderstandings
and revisions during the integration of federated learning.

In addition, two solutions focused on enhancing developers’ usage of PETs
based support tools (Munilla Garrido et al., 2023; Agrawal et al., 2021).
Garrido et al. (Munilla Garrido et al., 2023) studied the developers’ standard
data analysis workflow and then defined ten key desiderata that differential
privacy tools (e.g., libraries) should satisfy. Their effort was to align the
functionality of such tools with the current data analysis workflow of
developers. For example, the authors proposed that differential privacy tools
should provide ways to visualise the data query results and the accuracy
achieved. Moreover, Agrawal et al. (Agrawal et al., 2021) suggested a two way
approach to improver Moreover, Agrawal et al. suggested a two-way approach to
improve the adoption of PETs related support tools. e the adoption of PETs
related support tools. Since the existing libraries for PETs are complex and
suited for expert usage, the authors suggested that experts in PETs first use
the libraries and design components for common operations. Then, non-experts
should integrate those components into systems.

##  6\. Discussion

This SLR analysed 39 empirical studies by following the guidelines of
Kitchenham and Charters (Kitchenham and Charters, 2007) to understand how
developers can be encouraged and guided to incorporate PETs into software. For
this purpose, we first uncovered how developers currently using PETs (RQ1),
such as pseudonymisation (Hargitai et al., 2018), k-anonymity (Hargitai et
al., 2018), onion routing (Collier and Stewart, 2022), differential privacy
(Dwork et al., 2019), federated learning (Zhang et al., 2021), and synthetic
data (Sarathy et al., 2023). Then, we discovered the challenges they face
while integrating PETs (RQ2), ranging from internal challenges like limited
awareness (Ibáñez and Olmeda, 2022), insufficient knowledge (Senarath and
Arachchilage, 2018b), and inadequate emphasis on privacy (Chen et al., 2018)
to external obstacles such as a lack of SDLC support (Iwaya et al., 2023) and
increased development costs (Agrawal et al., 2021). Finally, we identified
solutions (RQ3) proposed to address the uncovered challenges in RQ2
(Baldassarre et al., 2022; Li et al., 2018), which had limitations around
their comprehensiveness and generalisability.

These results led to three implications. First, comparing developers’ current
usage of PETs with the commendable research conducted around PETs, it is
questionable whether the broader developer community widely and satisfactorily
uses PETs. Second, the challenges of integrating PETs express a need to
identify directions to encourage the acceptance and usage of PETs within
developers. Third, concrete solutions are required to address the identified
challenges effectively, integrating seamlessly with developers’ workflows and
preferences for heightened usefulness.

In this section, we delve into these implications, suggesting future research
avenues to identify research gaps. Further, we outline the limitations of the
SLR and the attempts taken to reduce them.

###  6.1. Research Efforts in PETs and Their Reflection on Software Developers

From the results discussed in 5.1, we observed some disparities between the
theoretical advancements of PETs and their translation in developers’ privacy
practices. As presented in Table 5, one such significant observation was that
developers used a limited variety of PETs in a limited number of instances.
This observation was unexpected given the wide range of PETs and extensive
application scenarios discussed in PETs-related literature (Lo et al., 2022;
Zhang et al., 2016; Archer et al., 2022; Liu et al., 2021b; Baunsgaard et al.,
2021; Liu et al., 2021a). Some of the PETs that were not investigated in the
empirical studies are homomorphic encryption (Raisaro et al., 2019; Goswami et
al., 2020; Baunsgaard et al., 2021; Yuan et al., 2017), secure multi-party
computation (Liu et al., 2021b; Baunsgaard et al., 2021; Kussel et al., 2022),
zero-knowledge proof (Liu et al., 2021a), and trusted execution environments
(Bittau et al., 2017; Hunt et al., 2016), which are known to be highly
applicable in the privacy-preserving software development context. Further,
none of the empirical studies reported PETs-embedded mobile software
applications. This oversight was surprising since the mobile application
domain is a leading software domain (Chen et al., 2018; Li et al., 2021) in
which the incorporation of PETs has already proven feasible (Goswami et al.,
2020; Zhang et al., 2022b; Suruliraj and Orji, 2022; Caputo et al., 2020).

Another recurring trend was the lack of detailed explanations of the steps
developers followed when integrating PETs into software. The empirical studies
did not report why and how developers selected the corresponding PET(s) for
their applications, how they addressed the limitations of PETs, if any, and
how they tested the configured PETs. Even when explaining the evaluation
process of PETs, the publications only reported the evaluation criteria that
developers considered and did not inquire into the quantitative or qualitative
methods used to evaluate PETs against other system requirements (e.g., reduced
response time to user requests (Raisaro et al., 2019)). It is also important
to note that none of the publications mentioned how developers evaluated the
‘privacy levels’ achieved through PETs, even though ‘privacy protection’ was
the most cited motivation to integrate PETs, as shown in Table 5.

This abstract information contrasts with the literature on PETs, where
researchers offer more insightful descriptions of the approaches taken while
integrating PETs into software (Raisaro et al., 2019; Suruliraj and Orji,
2022; Kessler et al., 2019; Archer et al., 2022; Caputo et al., 2020;
Baunsgaard et al., 2021). For example, the authors of MEDCO (Raisaro et al.,
2019), a system to explore distributed clinical data using homomorphic
encryption and differential privacy, explained how they quantitatively
evaluated the scalability and efficiency of the system by changing the data
query sizes and dataset size. However, such details regarding the integration
of PETs done by developers were absent in the selected publications.

Furthermore, empirical studies made minimal effort to explore the existence
and usage of the tooling support to simplify the integration of PETs. As
discussed in Section 5.2, a few developers were aware of the limitations of
such tooling support (Agrawal et al., 2021); however, they did not mention
specifically what tools they were referring to or whether they used those
tools when developing their applications. Therefore, it is unclear how the
broader developer community uses the libraries (SEAL, 2023; Wang et al., 2016;
Team, 2017), frameworks (He et al., 2019; Yuan et al., 2017), and interfaces
(Gaboardi et al., 2016; Nanayakkara et al., 2022) discussed in the literature.
In addition, to make PETs easily blend into the development workflow,
scientists have integrated PETs-related modules into the commonly used
development systems such as Apache SystemDS (an ML system designed to cover
the end-to-end data science workflow) (Baunsgaard et al., 2022) and SAP HANA
(a relational database management system) (Kessler et al., 2019). However,
these research efforts were also not reflected in the real-life integration
scenarios mentioned in the selected studies.

The selected empirical studies may have overlooked other integration scenarios
of PETs, contributing to the disparity between research efforts and their
translation in developers’ data protection practices. There exist other large-
scale commercial applications that use PETs, such as Google GBoard (Xu et al.,
2023), Apple and Google’s Exposure Notification Privacy-preserving Analytics
System (ENPA) (Apple and Google, 2021), and MyHealthMyData (MHMD) Horizon
project 131313http://www.myhealthmydata.eu/ for privacy-preserving medical
data sharing. However, such applications were not covered by the selected
empirical studies. On the other hand, developers are sometimes reluctant to
disclose the details of PETs embedded software, fearing privacy attacks
against their integration (Hargitai et al., 2018). Either way, the observed
lack of detailed explanations leaves an open question about the adoption of
PETs by the broader developer community, thus impeding the chances to uncover
more avenues to encourage developers’ behaviour in integrating PETs into
software.

Therefore, we encourage researchers to conduct more empirical studies to
better understand how developers incorporate PETs into software. If developers
are reluctant to disclose details about their prior experiences, the studies
can provide hands-on exercises to gain real-time observation of their
competency in working with PETs. It is also noteworthy to consider the
diversity of the participants along different aspects, such as expertise
level, age, gender, nationality or community, privacy knowledge levels, and
the region in which they work. This diversity supports the higher
generalisability in the study results. Another way to improve the
generalisability of the results is to investigate developers outside North
American and European regions, which are rarely considered in existing
empirical studies (Iwaya et al., 2023; Ribak, 2019). Focusing on such
understudied geographical areas also leads to identifying the role of cultural
influence in the developers’ data protection practices at a global scale.

###  6.2. Are Developers Ready to Accept and Use PETs in Software Development?

The challenges outlined in Section 5.2 extend beyond conventional technical
barriers, reaching into the psychological aspects of developers. These
multifaceted challenges raise uncertainty about whether developers can accept
and incorporate PETs into their development workflows. To closely examine this
uncertainty, we turn to the Theory of Planned Behaviour (TPB), an analytical
framework that sheds light on individuals’ intention to engage in a particular
behaviour (Ajzen, 1991). According to TPB, the intention to conduct a
behaviour is influenced by three factors: attitudes (favourable or
unfavourable evaluation), subjective norms (perception of others’ view towards
the behaviour) and perceived behavioural control (perceived ease or difficulty
in performing the behaviour) (Ajzen, 1991). The following subsections discuss
how the identified challenges affect these three factors.

####  6.2.1. Attitudes

People tend to develop a positive attitude toward a behaviour when it produces
favourable outcomes (Ajzen, 1991). However, the challenges outlined in Section
5.2 indicate that developers hardly perceive favourable attitudes towards
integrating PETs. When developers lack awareness and knowledge about the
existing PETs, they might not fully understand the benefits of PETs, such as
the privacy-protecting abilities, mitigating the risk of violating privacy
regulations and enhanced business opportunities (e.g., collaboration). This
perception causes the developers to have a neutral view towards integrating
PETs. Further, the absence of a systematic methodology to integrate PETs
(e.g., SDLC) and the increased software development cost can evoke a sense of
burden among developers regarding the integration process of PETs (Senarath
and Arachchilage, 2018b). Therefore, the challenging nature of incorporating
PETs into software makes it difficult for developers to instil favourable
attitudes towards it.

####  6.2.2. Subjective Norms

The social background of developers has a critical hand in shaping the
developers’ privacy perspective (Ribak, 2019; Spiekermann et al., 2019; Alomar
and Egelman, 2022; Ekambaranathan et al., 2021). For example, studies claim
that developers who are parents in real life have a higher perceived
responsibility to protect privacy when developing applications for children
(Ekambaranathan et al., 2021). Therefore, developers might perceive protecting
privacy in different ways. On the other hand, organisations that value
consumer privacy or comply with privacy regulations can make developers work
towards common privacy goals regardless of the differences in their
perceptions (Arizon-Peretz et al., 2021). However, our findings in Section 5.2
speak otherwise. When organisations explicitly instruct developers to
disregard privacy aspects (Spiekermann et al., 2019; Iwaya et al., 2023; Hadar
et al., 2018; Arizon-Peretz et al., 2021) or fail to support developers to
cater privacy concerns, developers might perceive a lack of value in privacy
protection within their organisations. This perception could negatively
influence their privacy practices, including integrating PETs into software.
Additionally, when privacy requirements are not formally defined for a
software application, developers might not fully comprehend the demand
customers place on privacy and the need for PETs to satisfy those demands.

####  6.2.3. Perceived behavioural control

According to Ajzen (Ajzen, 1991), the intention to engage in a behaviour is
positively influenced by the belief that it can be performed easily. The
adequate resources and opportunities facilitating the behaviour determine the
level of ease in conducting it (Ajzen, 1991). According to the challenges
discussed in Section 5.2, developers find it difficult to experience such ease
when integrating PETs into software. Developers lacked even the fundamental
knowledge of PETs, such as selecting suitable PET(s) for a given application
scenario (Senarath and Arachchilage, 2018b; Sarathy et al., 2023; Dwork et
al., 2019; Hargitai et al., 2018), which made them struggle to make informed
decisions when incorporating PETs into the software they develop. In addition,
the primary studies also discussed how the software development cost would
increase due to the inner complexities of PETs requiring ample resources in
terms of time, computational ability and expert support to mitigate such
challenges. However, such privilege is absent for every developer, as some
might work in start-ups or small-scale companies where resources are limited
(Perera et al., 2019; Iwaya et al., 2023). Therefore, the challenging nature
of integrating PETs into software can make developers perceive it as a
difficult behaviour to perform.

By analysing the identified challenges about the TPB, it is clear that
developers’ attitudes, subjective norms and perceived behavioural control have
lower power in influencing the intention to develop PETs-embedded software.
Therefore, concrete solutions are required to prepare developers to accept and
use PETs as part of their development workflow. We also urge researchers to
develop customised technology acceptance models to understand how developers
can be influenced to accept and use PETs in the software development context,
thus facilitating their adoption within the broader developer community. Such
models can be influenced by existing technology acceptance models such as
UTAUT (Unified Theory of Acceptance and Use of Technology) (Venkatesh et al.,
2003) and TAM (Technology Acceptance Model) (Davis, 1985).

###  6.3. Mitigating the Challenges

The identified solutions in 5.3 that answer RQ3 were not concrete enough to
address the challenges encountered by developers when integrating PETs. They
were not entirely dedicated to resolving the challenge they attempted to
answer. For example, for a PETs-based learning approach to be useful, it
should answer the exact knowledge gaps that developers have regarding PETs.
However, we did not observe such determination in most identified solutions.
On the other hand, the identified solutions were not evaluated with a
considerably large and diverse set of developers. Therefore, the applicability
of such solutions in the developer community is questionable. TThis absence of
concrete approaches to resolving the PETs-centric challenges the developers
face can further discourage them from integrating PETs into software. Thus, in
this section, we will provide insights to improve the identified solutions in
Section 5.3 to better align them with software developers’ preferences and
workflows. Further, we will suggest guidelines to mitigate the unanswered
challenges identified in Section 5.2, such as developers’ lack of awareness of
PETs and inability to prioritise privacy concerns.

####  6.3.1. Enhancing the awareness of PETs

Awareness of PETs is essential for developers to know that privacy can be
achieved technically. Otherwise, as discussed in Section 5.2, developers will
resort to immature privacy practices (Sanderson et al., 2023; Barbala et al.,
2023) or use only traditional PETs (Hargitai et al., 2018; Senarath and
Arachchilage, 2018b) to achieve data protection in software. As several
seminal works have suggested, a sensible place to start enhancing _privacy_
awareness would be through education provided in computer science course
modules (Horstmann et al., 2024b; Berk et al., 2023; Senarath and
Arachchilage, 2018a). We suggest extending this idea by including PETs-related
content in those modules. In this way, a proactive mindset could be built in
developers towards integrating PETs in their software during their formative
years as novices. Moreover, competitions targeted at promoting PETs, such as
the ”PETs prize challenges”141414https://petsprizechallenges.com/, should be
actively promoted among the developer community. This initiative not only
fosters a culture of innovation but also serves as a platform to raise
awareness of PETs, encouraging developers to explore and understand diverse
PETs and their potential applications.

In addition, organisations’ ability to enhance _privacy_ awareness of
developers through training sessions, code reviews and discussions between
colleagues are suggested in privacy-related publications (Arizon-Peretz et
al., 2021; Tahaei et al., 2021). However, none of those publications
emphasised including technical aspects, such as PETs, in those initiatives.
Therefore, software organisations can consider further improving such
initiatives by including PETs. In this way, the organisations can convince the
technical feasibility of privacy using PETs, thus making the concept of PETs
closer to developers.

Further, empirical studies sparingly analysed developers’ awareness of
different types of PETs and their capabilities. Thus, future research can
provide a comprehensive understanding of developers’ level of awareness in
PETs, thereby promoting strategies to improve the awareness if needed.

####  6.3.2. Enhancing the knowledge of PETs

The lack of knowledge in PETs is a fundamental yet significant challenge the
developers face (Alhazmi and Arachchilage, 2021; Senarath and Arachchilage,
2018a). The absence of theoretical and practical knowledge of PETs negatively
impacts the developers’ confidence in their ability, i.e., self-efficacy
(Bandura, 1977), to effectively integrate PETs into software. As self-efficacy
is a factor affecting the motivation to achieve desired goals (Gamagedara
Arachchilage and Hameed, 2020), we argue that low self-efficacy arising from
the absence of knowledge of PETs demotivates the privacy-preserving
development behaviour of software developers, leading them not to integrate
PETs into software or integrate them ineffectively (Hargitai et al., 2018; Li
et al., 2018; Munilla Garrido et al., 2023). On the other hand, the
researchers’ effort in introducing new tools or methodologies to support the
integration of PETs will be less useful since the developers fail to
effectively utilise them without understanding PETs (Dwork et al., 2019).
Thus, it is crucial to educate developers in a way that increases their self-
efficacy to integrate PETs and their ability to utilise existing PETs-related
support tools.

However, despite the importance of educating developers on PETs, none of the
proposed educational approaches in literature were deemed. They should address
the exact knowledge requirements of developers, such as selecting suitable
PETs for software, calibrating PETs, evaluating the integration decisions, and
rectifying the limitations found in PETs. Moreover, the educational approaches
should equally focus on providing theoretical and practical knowledge about
PETs. For this, they can design the teaching content into different levels
according to Bloom’s taxonomy (Bloom et al., 1984), starting from lower
learning levels, such as understanding concepts, to higher learning levels,
such as applying the learnt concepts. In addition, they should consider the
preferences that developers seek from educational resources, such as context-
based learning (Berk et al., 2023), quick solutions (e.g., code snippets) (Li
et al., 2018) and simple yet informative content delivery (Perera et al.,
2019).

In addition, as a fundamental step towards enhancing the knowledge of PETs, we
suggest educators incorporate PETs into ethics-related modules taught to
computer science students (i.e., novice developers). Shilton et al. (Shilton
et al., 2020) introduced a game-based learning tool to help computer science
students understand how to achieve privacy in software applications by
following privacy by design guidelines (Andrade et al., 2023). The authors
experimentally showed that the tool influenced the students to learn more
about privacy concepts during technical lessons. Therefore, further research
can extend such interventions to include content on PETs, a part of the
privacy domain.

Further, developers can be educated about PETs by providing adequate training
sessions in software organisations (Senarath and Arachchilage, 2018a). For
such training sessions to be useful, the delivered knowledge should be
actively adapted to the organisational practices. Moreover, novel
interventions, such as the previously discussed game-based approaches, can
also be used in training sessions to provide developers with hands-on
experience in utilising PETs. If such tools were made openly accessible,
resource-limited organisations (e.g., startups) could also utilise them to
educate their developers on PETs flexibly without needing extra time and money
to organise special training sessions.

####  6.3.3. Towards prioritising privacy concerns

As identified in Section 5.3, developers failed to see the need for PETs as
they did not prioritise privacy concerns during software development. This
ignorance calls for organisations and regulatory bodies to develop strategies
emphasising the significance of protecting privacy and how PETs can achieve
privacy.

Organisational privacy standards have the power to influence developers’
privacy practices (Arizon-Peretz et al., 2021; Dias Canedo et al., 2020; Iwaya
et al., 2023). Developers usually follow organisational privacy policies to
verify their privacy practices (Dias Canedo et al., 2020; Iwaya et al., 2023).
Therefore, organisations should properly establish and communicate privacy
policies with the developers. These policies can further include PETs, where
personal data needs to be processed. Moreover, by maintaining systematic
methodologies to integrate PETs (e.g., SDLC), organisations can convince
developers that protecting privacy is part of their daily technical work. This
approach also holds developers responsible for upholding software privacy
standards throughout software development. In the future, more research can
evaluate how organisations play a role in instigating the importance and
responsibility of protecting privacy, motivating developers to use PETs to
protect their consumers’ data.

In addition, privacy regulations (e.g., GDPR) can convince the importance of
protecting privacy to software developers. However, such regulations seem
distant for developers as non-technical people, such as regulators, developed
them (Horstmann et al., 2024a). Hence, privacy regulations can be presented
with a technical touch to minimise this gap. For instance, they can include
the types of PETs, their code examples and PETs-related tools that developers
can use to achieve data protection. In this way, developers can identify the
importance of addressing privacy concerns and the technical feasibility of
privacy facilitated by PETs.

####  6.3.4. Improving the SDLC to support the integration of PETs

SDLC is essential in providing structured guidance to developers throughout
the entire software development process, from requirement gathering to
software deployment and maintenance (van den Bosch et al., 1982). Therefore,
to successfully integrate PETs into software, every stage in the SDLC must
actively support the incorporation of PETs. However, drawing from our results
presented in Sections 5.2 and 5.3, we noticed that past empirical studies have
not attempted to elicit insights into how the integration of PETs is related
to the testing, deployment, and maintenance stages of the SDLC. Therefore,
future research can focus on the challenges and improvements along these
stages, considering integrating PETs into software.

Privacy requirement gathering is the first step in the privacy-preserving
software development process (Iwaya et al., 2023; Senarath and Arachchilage,
2018a). However, none of the empirical studies provided well-structured
approaches to elicit privacy requirements, which is required to identify the
need for PETs. Highlighting the importance of prioritising privacy from the
outset of software development, Iwaya et al. (Iwaya et al., 2023) proposed
considering privacy as a non-negotiable feature. Additionally, Senarath and
Arachchilage (Senarath and Arachchilage, 2018a) proposed defining privacy
requirements alongside the PETs needed to achieve them. However, these were
only conceptual suggestions, not solutions with clear implementation steps.

However, real-world development environments complicate privacy requirement
gathering, requiring more than conceptual guidance. The collaborative
contribution of different stakeholders (e.g., customers, investors, and
developers) introduces challenges such as communication difficulties stemming
from knowledge, terminology, and privacy expectation differences between the
stakeholders (Oetzel and Spiekermann, 2014; Sanderson et al., 2023). Further,
privacy requirements extend beyond project initiation, requiring reassessment
and adaptation throughout the SDLC (Perera et al., 2019; Oetzel and
Spiekermann, 2014). Thus, future research should introduce concrete privacy
requirement-gathering approaches that cater to such collaborative efforts and
end-to-end management during software development.

Further, our analysis revealed a lack of explicit emphasis on documentation
during the integration of PETs. The significance of documentation became
apparent through examples like the ’Epsilon Registry’ (Dwork et al., 2019) and
the Coconut plugin tool (Li et al., 2018). The ‘Epsilon Registry’ allowed for
recording detailed decisions in successful differential privacy integration,
providing valuable insights for other developers struggling to make
integration decisions around differential privacy (Dwork et al., 2019).
Similarly, the Coconut plugin employed annotations to document data handling
behaviours, enhancing the transparency of the privacy-preserving coding
practices (Li et al., 2018). Therefore, we advocate that developers maintain
robust documentation practices while integrating PETs. Further, researchers
can explore the aspect of documentation more when developing approaches for a
privacy-preserving SDLC.

Moreover, we noted a lack of SDLC-related solutions to support the integration
of PETs in legacy systems. Developers working on legacy software must consider
several other critical aspects when incorporating new components into their
existing software, making the integration of PETs into them not
straightforward. These include assessing the existing architectural
limitations, identifying potential impacts on existing functionalities,
determining resource allocation for the implementation, and addressing any
interoperability challenges (Zhang et al., 2021). Further, legacy software
might need significant changes to incorporate PETs, which can increase
software development costs (Zhang et al., 2021). Such complexities can
pressure developers not to integrate PETs into legacy software. Alternatively,
developers may opt for PETs that impose minimal tension on the existing
software architecture, even if such choices may not suit their applications.
Therefore, future studies can reflect more on the unique challenges developers
face when integrating PETs into legacy software.

Further, future studies can invest in developing an SDLC framework or a tool
to support end-to-end privacy, of which PETs would naturally be a part.
Microsoft Security Development Lifecycle 151515https://www.microsoft.com/en-
us/securityengineering/sdl is an industrial-level SDLC frameworks that guides
security integration. Such interventions can be leveraged to develop a similar
SDLC framework for privacy, also focusing on PETs. These research efforts
should also encompass often-overlooked stages such as testing, deployment, and
maintenance. In this direction, we suggest researchers investigate how
different SDLC methodologies, such as Agile, Waterfall or V model (Kasauli et
al., 2020), can be adapted to incorporate PETs effectively.

####  6.3.5. Reducing the development costs

Our findings also indicate that PETs researchers focus on achieving
performance of PETs than their practicality in software development context
(Klymenko et al., 2022). This is a probable cause for developers to struggle
with the increased software development cost when integrating PETs. Drawing
from the results presented in Section 5.3.3, an initial step towards enhancing
the practicality of PETs is to gain insights into developers’ existing
development workflow. These insights can assist researchers in tailoring PETs
and their supporting tools to align seamlessly with software development,
reducing friction and enhancing adoption by developers.

A practical example of this approach can be observed where functionalities
required for deploying federated learning were integrated into Apache
SystemDS, a machine learning system designed to cover the end-to-end data
science workflow (Baunsgaard et al., 2022). In this instance, embedding
federated learning capabilities within an existing and widely used support
system causes minimal disruptions to the ML workflow of developers.
Additionally, using an existing system to support the integration of PETs
eliminates the time and effort required to familiarise with a new federated
learning support tool. Similarly, we encourage researchers to study the
feasibility of incorporating the valuable findings of PETs in widely used
development environments (e.g., Android Studio
161616https://developer.android.com/studio), frameworks (e.g., AngularJS
171717https://angularjs.org/), or database systems (e.g., Oracle
181818https://www.oracle.com/) in the software industry. This way, developers
can quickly adopt and integrate PETs into their existing workflows.

###  6.4. Limitations

This SLR consists of a set of limitations that can affect the validity of the
study findings. In this section, we discuss these limitations under the
validity classification proposed by Runeson and Höst (Runeson and Höst, 2009),
including construct validity, internal validity, external validity and
reliability. Further, we explain the measures taken to minimise the identified
limitations.

####  6.4.1. Construct Validity

Limitations to construct validity can arise when the methods employed in a
study do not accurately align with what the researchers intended to
investigate (Runeson and Höst, 2009). First, our research questions might not
comprehensively explain why developers struggle to use PETs for privacy-
preserving software development. We used the PICOC framework to mitigate this
limitation (Petticrew and Roberts, 2006; Kitchenham and Charters, 2007), which
guided us in identifying keywords to define well-structured research questions
reflecting the study’s scope. Second, the search strings we defined to
identify publications might not be suitable to retrieve publications that
answer the research questions. We used the main keywords derived from the
PICOC framework as the primary search strings, to minimise this limitation. As
these keywords are also components of the defined research questions, they can
identify publications related to the defined research questions.

####  6.4.2. Internal Validity

Internal validity is the extent to which the design and conduct of the study
are likely to prevent systematic errors, such as missing relevant publications
during search and selection (Kitchenham and Charters, 2007). The search
strings we defined might not retrieve all the relevant publications that
answer our defined questions. To avoid this limitation, we first defined
alternative search strings based on synonyms, abbreviations and spelling
variations of the main search keywords we derived from the PICOC framework.
Second, we conducted a rigorous search for publications in multiple data
sources, including six digital libraries, 13 conferences, and 11 journals, so
the relevant publications are less likely to be overlooked. In addition, we
further expanded the coverage of the publications by manually searching the
references and citations of the selected papers (snowballing method) (Wohlin,
2014).

####  6.4.3. External Validity

External validity refers to the extent to which study findings can be
generalised (Runeson and Höst, 2009). The generalisability of our findings
might be limited due to the low number of selected empirical studies.
Therefore, there is a need to conduct more research into PETs with a focus on
software developers to validate our results. Nevertheless, our study will be a
foundation for future investigations in this evolving and critical
intersection of software development and PET.

####  6.4.4. Reliability

Reliability refers to the extent to which the SLR depends on the specific
researchers (Runeson and Höst, 2009). Due to the background and expertise of
the authors, this SLR could be biased towards specific researchers when
selecting publications for analysis. To reduce this bias, the steps in the SLR
methodology, including defining the research questions, creating the search
strings, and defining the selection criteria and data sources, were all
planned and verified among the author group before conducting the SLR
(Kitchenham and Charters, 2007). Further, the empirical studies selected for
the SLR were validated using the inter-rater agreement score calculated
between the authors using Cohen’s Kappa measurement (Landis and Koch, 1977).
Finally, during the reflexive thematic analysis, all authors used reflexivity
to construct the codes and themes collaboratively to synthesise the results.

##  7\. Conclusion

PETs are technical measures that offer data protection by design and default
(Garrido et al., 2022; Office, 2023). Therefore, by embedding PETs into
software applications, data breaches can be minimised, protecting the privacy
of their end-users. Further, by improving the data protection in software
through PETs, software organisations can manage regulatory pressure and
enhance end-user trust (Senarath and Arachchilage, 2018a; Senarath et al.,
2019). However, to benefit from the data protection capabilities of PETs,
software developers must actively and correctly embed PETs into software.
Therefore, to identify approaches to encourage such behaviour in developers,
we conducted an SLR synthesising the knowledge regarding the developers’
current usage of PETs, challenges they encounter during the integration of
PETs and solutions proposed to address the identified challenges along with
their limitations. Our SLR reported instances where developers incorporated
six different PETs into software (Hargitai et al., 2018; Sanderson et al.,
2023). However, due to the absence of fine details in those scenarios, it is
still unclear how the broader developer community adopts PETs. Moreover,
developers encountered multiple challenges when integrating PETs into
software, including personal challenges (e.g., limited awareness of PETs
(Ibáñez and Olmeda, 2022)) and external challenges (e.g., the increased
development cost (Iwaya et al., 2023)). The identified challenges hint that
the developers are still not ready to accept and use PETs in software.
Additionally, existing solutions that address the identified challenges are
either not entirely dedicated to addressing them or lack generalisability
(Baldassarre et al., 2022; Li et al., 2018; Munilla Garrido et al., 2023).
This absence of concrete solutions further aggravates the PETs-related
challenges faced by developers. Based on the SLR findings and their
implications, the adoption of PETs by the wider developer community may not be
in the near future. Therefore, while dedicated efforts towards improving the
capabilities of PETs are essential, it is equally important to understand how
to improve developers’ privacy-preserving development behaviour by taking PETs
on board. We believe our study inspires this cause, encouraging researchers to
investigate more into developer aspects in incorporating PETs into software,
educators and practitioners to develop PETs-based learning interventions for
developers, and organisations to identify and reduce the barriers integrating
PETs within the development environment.

## References

  * (1)
  * Acar et al. (2018) Abbas Acar, Hidayet Aksu, A. Selcuk Uluagac, and Mauro Conti. 2018\.  A survey on homomorphic encryption schemes: Theory and implementation.  https://doi.org/10.1145/3214303
  * Agrawal et al. (2021) Nitin Agrawal, Reuben Binns, Max Van Kleek, Kim Laine, and Nigel Shadbolt. 2021.  Exploring Design and Governance Challenges in the Development of Privacy-Preserving Computation _(CHI ’21)_. Association for Computing Machinery, New York, NY, USA, Article 68, 13 pages.  https://doi.org/10.1145/3411764.3445677
  * Ajzen (1991) Icek Ajzen. 1991\.  The theory of planned behavior.  _Organizational Behavior and Human Decision Processes_ 50, 2 (1991), 179–211.  https://doi.org/10.1016/0749-5978(91)90020-T
  * Alhazmi and Arachchilage (2021) Abdulrahman Alhazmi and Nalin Asanka Gamagedara Arachchilage. 2021\.  I’m All Ears! Listening to Software Developers on Putting GDPR Principles into Software Development Practice.  _Personal Ubiquitous Comput._ 25, 5 (may 2021), 879–892.  https://doi.org/10.1007/s00779-021-01544-1
  * Alkhatib et al. (2021) Sami Alkhatib, Jenny Waycott, George Buchanan, Marthie Grobler, and Shuo Wang. 2021\.  Privacy by Design in Aged Care Monitoring Devices? Well, Not Quite Yet!. In _Proceedings of the 32nd Australian Conference on Human-Computer Interaction_ _(OzCHI ’20)_. Association for Computing Machinery, New York, NY, USA, 492–505.  https://doi.org/10.1145/3441000.3441049
  * Alomar and Egelman (2022) Noura Alomar and Serge Egelman. 2022.  Developers say the darnedest things: Privacy compliance processes followed by developers of child-directed apps.  _Proc. Priv. Enhancing Technol._ 2022, 4 (Oct. 2022), 250–273.
  * Andrade et al. (2023) Vinícius Camargo Andrade, Rhodrigo Deda Gomes, Sheila Reinehr, Cinthia Obladen De Almendra Freitas, and Andreia Malucelli. 2023.  Privacy by Design and Software Engineering: A Systematic Literature Review. In _Proceedings of the XXI Brazilian Symposium on Software Quality_ (Curitiba, Brazil) _(SBQS ’22)_. Association for Computing Machinery, New York, NY, USA, Article 18, 10 pages.  https://doi.org/10.1145/3571473.3571480
  * Antunes et al. (2022) Rodolfo Stoffel Antunes, Cristiano André Da Costa, Arne Küderle, Imrana Abdullahi Yari, and Björn Eskofier. 2022.  Federated Learning for Healthcare: Systematic Review and Architecture Proposal.  _ACM Transactions on Intelligent Systems and Technology_ 13, 4 (Aug 2022), 1–23.  https://doi.org/10.1145/3501813
  * Apple and Google (2021) Apple and Google. 2021\.  Exposure Notification Privacy-preserving Analytics (ENPA).  https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ENPA_White_Paper.pdf
  * Archer et al. (2022) Dave Archer, Michael A August, Georgios Bouloukakis, Christopher Davison, Mamadou H Diallo, Dhrubajyoti Ghosh, Christopher T Graves, Michael Hay, Xi He, Peeter Laud, Steve Lu, Ashwin Machanavajjhala, Sharad Mehrotra, Gerome Miklau, Alisa Pankova, Shantanu Sharma, Nalini Venkatasubramanian, Guoxi Wang, and Roberto Yus. 2022.  Transitioning from testbeds to ships: an experience study in deploying the TIPPERS Internet of Things platform to the US Navy.  _Journal of Defense Modeling & Simulation_ 19, 3 (Jul 2022), 501–517.  https://doi.org/10.1177/1548512920956383
  * Arizon-Peretz et al. (2021) Renana Arizon-Peretz, Irit Hadar, Gil Luria, and Sofia Sherman. 2021\.  Understanding developers’ privacy and security mindsets via climate theory.  _Empir Software Eng_ 26, 6 (Nov 2021), 123\.  https://doi.org/10.1007/s10664-021-09995-z
  * Assefa et al. (2021) Samuel A. Assefa, Danial Dervovic, Mahmoud Mahfouz, Robert E. Tillman, Prashant Reddy, and Manuela Veloso. 2021.  Generating Synthetic Data in Finance: Opportunities, Challenges and Pitfalls. In _Proceedings of the First ACM International Conference on AI in Finance_ (New York, New York) _(ICAIF ’20)_. Association for Computing Machinery, New York, NY, USA, Article 44, 8 pages.  https://doi.org/10.1145/3383455.3422554
  * Baldassarre et al. (2022) M.T. Baldassarre, V.S. Barletta, D. Caivano, A. Piccinno, and M. Scalera. 2022.  Privacy Knowledge Base for Supporting Decision-Making in Software Development.  _Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)_ 13198 LNCS (2022), 147–157.  https://doi.org/10.1007/978-3-030-98388-8_14
  * Bandura (1977) Albert Bandura. 1977\.  Self-efficacy: Toward a unifying theory of behavioral change.  _Psychological Review_ 84, 2 (1977), 191–215.  https://doi.org/10.1037/0033-295X.84.2.191