11institutetext: Norwegian Computing Center, Oslo, Norway 22institutetext:
Software Improvement Group, Amsterdam, The Netherlands

# Helping Code Reviewer Prioritize: Pinpointing Personal Data and its
Processing††thanks: This paper has been accepted at the 22nd International
Conference on Intelligent Software Methodologies, Tools and Techniques
(SOMET2023).

Feiyang Tang 11 Bjarte M. Østvold 11 Magiel Bruntink 22

###### Abstract

Ensuring compliance with the General Data Protection Regulation (GDPR) is a
crucial aspect of software development. This task, due to its time-consuming
nature and requirement for specialized knowledge, is often deferred or
delegated to specialized code reviewers. These reviewers, particularly when
external to the development organization, may lack detailed knowledge of the
software under review, necessitating the prioritization of their resources.

To address this, we have designed two specialized views of a codebase to help
code reviewers in prioritizing their work related to personal data: one view
displays the types of personal data representation, while the other provides
an abstract depiction of personal data processing, complemented by an optional
detailed exploration of specific code snippets. Leveraging static analysis,
our method identifies personal data-related code segments, thereby expediting
the review process. Our approach, evaluated on four open-source GitHub
applications, demonstrated a precision rate of 0.87 in identifying personal
data flows. Additionally, we fact-checked the privacy statements of 15 Android
applications. This solution, designed to augment the efficiency of GDPR-
related privacy analysis tasks such as the Record of Processing Activities
(ROPA), aims to conserve resources, thereby saving time and enhancing
productivity for code reviewers.

###### Keywords:

Personal data processing GDPR analysis Static analysis Code review.

##  1 Introduction

In the 21st century, companies have been collecting and distributing massive
amounts of personal data [1]. The sheer volume and capacity to access and
integrate data in unprecedented ways is novel [14]. To protect individual
rights, the European Union’s General Data Protection Regulation (GDPR)
requires substantial data protection, posing both challenges and opportunities
for global software companies and imposing severe fines for non-compliance
[7]. Article 30 of the GDPR necessitates the creation of a detailed document,
the Records of Processing Activities (ROPA), to ensure GDPR compliance. This
document, which must be readily accessible to the supervisory authority, can
be challenging to construct. Code reviewers often play a crucial role in this
process, tasked with analyzing extensive codebases for GDPR-relevant aspects.
Their findings not only help ensure compliance but also assist in the
formation of the intricate ROPA, a task that can be quite demanding.

While the manual identification of personal data and its processing in the
codebase is an inevitable part of a code reviewer’s work, our goal is to
facilitate the rapid pinpointing and understanding of relevant code fragments.
To this end, we propose an approach that identifies and abstracts both
personal data and its processing in the codebase. Our solution provides two
specialized views: one that emphasizes the types of personal data, and another
that outlines an abstract perspective of data processing flows.

These views aim to empower code reviewers by streamlining the task of locating
and comprehending personal data processing within the software. By providing a
focused direction, highlighting key code fragments, and supplying task-
specific information through different views, our approach conserves time and
effort. This multi-faceted assistance greatly simplifies GDPR-related tasks,
such as the formation of a ROPA.

The three main components of our approach are:

  * •

A set of adaptable static analysis rules for pinpointing personal data and its
processing in source code. (Refer to Section 3.1, identification in Figure 1)

  * •

A collection of flow patterns derived from large-scale analysis, which
simplifies identified code fragments containing a data flow into abstracted
code snippets. These snippets capture the context and manner in which personal
data is processed. (Refer to Section 3.2, abstraction in Figure 1)

  * •

Two specialized views provide code reviewers with options for displaying
information about personal data or flow-specific information, depending on
their specific task, thereby reducing manual work. (Refer to Section 3.3,
presentation in Figure 1)

We demonstrate the effectiveness of our approach by 1) achieving high
precision and generating corresponding ROPAs compared to published privacy
statements for four trending GitHub projects and 2) evaluating the accuracy of
privacy statements provided by 15 popular Android applications from the Google
Play store.

##  2 Challenges in Personal Data Identification

Identifying personal data within extensive codebases poses a significant
challenge for code reviewers, especially given the diversity of personal data
types and the lack of standardized patterns for their identification. This
issue is further complicated by the reality that personal data may be either
directly or indirectly associated with an individual, a relationship that can
vary across cultural, linguistic, and domain-specific contexts. Privacy
statements often describe personal data collection and processing in broad
terms, making it difficult to pinpoint what data is collected and how it is
processed within the source code.

When reviewing code for GDPR-relevant aspects, code reviewers often resort to
manual techniques such as keyword searching, filtering, and grepping to
identify potential areas of concern. However, these methods can be time-
consuming and often yield an overwhelming number of results, making it
challenging to discern the key areas of focus. There is a clear need for a
more abstract, categorized view of the results that could help reviewers
identify and focus on the most relevant code fragments.

##### User Requirement Study

In order to grasp the challenges faced by code reviewers in GDPR-related
tasks, we undertook a user requirement study with six experienced code
reviewers from a medium-sized European software company. They were selected
based on their experience, familiarity with GDPR tasks, and diverse European
representation. The research, primarily focused on European data formats, did
not consider formats outside the EU. The interviews elicited key issues in
privacy analysis tasks, preferred presentation formats, and the potential of
an abstract view of results.

During the structured interviews, participants discussed the most challenging
facets of their privacy analysis tasks, the desired format for the
presentation of findings, and their views on the possible advantages of having
an abstract, categorized overview of the results. The study highlighted that
identifying personal data within source code remains a significant hurdle for
reviewers. This challenge arises primarily due to the fluctuating context and
semantics. Participants voiced a preference for a results presentation that
offers ample context and underscores potential areas of concern, such as
personal data processing.

There was unanimous agreement among participants about the potential benefits
of incorporating an automated, abstract presentation of the results into their
workflows. They preferred comprehensive coverage, even if it occasionally
introduced false positives, on the condition that their manual examination
could be concentrated on a smaller, more relevant segment of the software.
While this study has certain limitations, such as a smaller sample size and
potential bias due to the limited participant selection, it does provide
valuable initial insights into the needs and preferences of code reviewers
tasked with GDPR-related duties in Europe.

##### Presentation Design

Current static analysis tools offer some flexibility in results grouping and
presentation. For instance, tools like FindBugs and ESLint allow results to be
grouped by various criteria, such as bug category/name, code location, and bug
ranking. However, these tools often lack the ability to provide a task-
specific view that aligns with the code reviewers’ current analysis focus.
Such a view could allow reviewers to focus on personal data and its
processing, thereby simplifying the analysis process and making it more
efficient.

###  2.1 The Role of Code Reviewers in ROPA Creation

In the context of GDPR compliance, code reviewers often play a crucial role in
creating a Record of Processing Activities (ROPA). A ROPA should contain
detailed information about personal data processing, such as the categories of
individuals and personal data, recipients of personal data, details of
transfers to third countries, retention schedules, and technical and
organizational security measures. Code reviewers, through their thorough
analysis of the codebase, contribute significantly to the collection of this
information, thereby helping to ensure GDPR compliance.

##  3 Constructing Task-Specific Views for Code Reviewers

We propose an approach that creates two distinct views, providing code
reviewers with varying levels of information about personal data types and
their processing within the codebase. Our approach employs static analysis to
identify personal data and the source code where the processing of such data
occurs. The result of the static analysis comprises identified code fragments
that match the specified patterns. We introduce an abstracted flow
representation that simplifies each identified code fragment, capturing the
essence of personal data processing. This flow representation not only
translates effectively into a more comprehensible format but also facilitates
labeling and grouping of code fragments, presenting the results to code
reviewers in a unified and efficient manner for analysis.

Source code Code fragments with flows Simplified Code snippets Two views:
personal data and processing identification(Section 3.1)abstraction(Section
3.2)presentation(Section 3.3) Figure 1: Overview of our approach

Figure 1 presents an overview of our approach, which consists of three major
phases: pattern matching with static analysis, abstraction of code fragments
to generate flow representations, and creation of the two task-specific views
for code reviewers.

###  3.1 Pattern Matching on Source Code

The first phase of our approach involves static analysis to pinpoint code
fragments that contain or process personal data. For this task, we employ
Semgrep, a powerful static analysis tool well-regarded for its flexibility and
efficiency in analyzing voluminous source code files [9]. Semgrep’s multi-
language support and local data flow analysis capabilities are instrumental to
our endeavor. This section elaborates on our rules for identifying personal
data sources and sinks, and the subsequent extraction of flows.

####  3.1.1 Identification of Personal Data and Processing

The concept of sources and sinks is vital to our approach. In the context of
our analysis, sources refer to personal data, while sinks represent different
forms of personal data processing. We define personal data as 1) literal
personal data in source code text (constants identified via real values), and
2) variables (identified via name identifier). As for personal data
processing, it refers to any distinct action or operation performed on
personal data. Our rules for identifying personal data and its processing
currently support Java, JavaScript, and TypeScript. Nevertheless, our rules
applicable to plain-text personal data can be extended to the majority of
Semgrep-supported languages. Semgrep parses the source code to build an
abstract syntax tree (AST) for taint analysis, similar to how ESLint processes
JavaScript code. This method enables us to efficiently identify sources,
sinks, and data types. We further augment Semgrep’s identification process
with pattern matching.

####  3.1.2 Crafting Identification Rules

Literal personal data identification relies on matching specified regular
expressions, such as the syntax of national ID numbers. For variable sources,
we have established a default list of personal data identifiers, covering data
from 10 categories: Account, Contact, Personal ID, Online identifier,
Location, Feedback, Health, National ID, Technical, and Financial.

These distinct identifiers are used to construct Semgrep rules with regular
expressions (regex). To reduce false positives and enhance recall, we apply
restrictions to the regex rules. For instance, to identify all human names in
source code, we improve precision and cover first, last, and full names by
using regex such as (?i).(?:first|given|full|last|sur(?!geon)
)[s/(;)|,=!>]name).

Simultaneously, we identify potential sinks, which represent distinct actions
of personal data processing. We utilize the majority of verbs from Section 3
of the Data Privacy Vocabulary (DPV) [10] to identify relevant processes.
These verbs are utilized to generate corresponding regex for our taint
analysis rules, and specific conditions are incorporated to pinpoint relevant
sinks in the code effectively.

APIs are extensively used to implement functionalities in current software
development. We performed a simple static analysis on the 20 most popular
libraries each from Maven and npm (40 in total), followed by a manual
inspection to filter out false positives. The resulting list consists of
potential sink methods, predominantly related to databases from prominent
providers such as AWS and Google Firebase. These API methods, akin to the verb
identifiers, serve as sinks for our analysis. We categorize sinks into six
classes: Manipulation, Transportation, Creation/Deletion, Database,
Encryption, and Log.

Table 1: Source and sink category abbreviations Source type | Abbreviation |  |  | Sink type | Abbreviation
---|---|---|---|---|---
Account | ACC |  |  | Manipulation | M
Contact | CON |  |  | Transportation | T
Personal ID | PID |  |  | Creation/Deletion | C/D
Online identifier | OID |  |  | Database | D
Location | LOC |  |  | Encryption | E
Feedback | FEE |  |  | Log | L
Health | HEA |  |  |  |
National ID | NID |  |  |  |
Technical | TEC |  |  |  |
Financial | FIN |  |  |  |

####  3.1.3 Flow Extraction and Semgrep Output

Once sources and sinks have been identified, we need to understand how
personal data flows from the former to the latter. A flow represents a
sequence of operations, starting from a source, moving through intermediate
nodes (if any), and ending at a sink. We extend Semgrep’s capabilities to not
only identify but also comprehend these flows.

Semgrep’s output typically includes the code fragment where the flow ends,
i.e., the statement that processes personal data. However, we have customized
Semgrep to provide more detailed information, such as the precise location and
name of the source and sink, along with the code fragment. This information is
vital for code reviewers, helping them quickly locate and comprehend personal
data processing within the software.

##### Example: Application on ToolJet

To illustrate the effectiveness of our approach, we applied our rules to
ToolJet, a low-code, open-source framework for creating and deploying internal
tools. ToolJet was selected because of its popularity and extensive use of
personal data, making it a representative case study. The ease of access to
its source code also facilitated our analysis.

Figure 2(a) depicts an example of a rule we created to identify flows of
account-specific data into a manipulation sink in ToolJet. The corresponding
identified code snippet, an output of Semgrep that includes both the code
fragment and key information about the source and sink, is shown in Figure
2(b).

(a) Sample identification rule to find flows between account data and
manipulation sink

(b) Code fragment identified using the rule illustrated in Figure 2(a). In
this case, the flow originates from the source user.id and ends at the sink
update(). Along with the code fragment, Semgrep provides an accompanying
message that details the names of both the source and the sink involved in the
flow.

Figure 2: An example of pattern matching on ToolJet

###  3.2 Flow Patterns: Abstracting Personal Data Flows

A critical aspect of our approach is the abstraction of identified personal
data flows into more manageable and comprehensible representations. This step
facilitates the review and understanding of these flows, offering a more
streamlined approach to software privacy analysis. Here, we introduce the
concept of flow patterns, which are simplified, standardized representations
of personal data flows, distilled from the identified code fragments.

Semgrep outputs a statement of code, which corresponds to a chunk of a code
fragment that could span multiple lines in the source code, where the personal
data flow culminates. The value at the sink within this statement may not
necessarily be the original source, yet it definitely encapsulates the value
originating from the source. However, such code fragments can be intricate and
challenging to comprehend. In our work, we address this by abstracting each
result we capture, which represents a flow from a personal data source to a
processing sink. Our abstraction combines this code fragment with source and
sink information to depict the flow in a simplified form.

We applied our pattern-matching rules to over 20 open-source software projects
on GitHub (the top 20 trending ones across three languages: JavaScript,
TypeScript, and Java) and identified a vast number of personal data flow
instances. From these instances, we generalized the structure of more than
150,000 detected code snippets into a set of eight distinct flow patterns.

####  3.2.1 Defining Flow Patterns

The flow patterns, collectively denoted as $\mathcal{F}$, abstractly represent
various forms of personal data flows from a source to or via a sink. Each
pattern in $\mathcal{F}$ reflects a typical flow type, and Table 2 presents
these flow patterns alongside their English interpretations. The table also
introduces syntactic conventions for meta-variables used in the following
discussion. $E$ ranges over expressions, $m$ ranges over methods, and $v$
ranges over source variables. An expression with an underscore as an argument,
$E[\\_]$, signifies that the expression is not significant in terms of
personal data processing — it is neither a source nor a sink, nor does it
contain a value from a source.

In a flow pattern $E_{1}\xrightarrow{m}E_{2}$, a solid arrow $\rightarrow$
indicates that a value on the left-hand side (LHS) contributes to the value on
the right-hand side (RHS). If we are uncertain whether a value flows from the
LHS to the RHS, such as when the LHS value is processed and merely outputs a
Boolean to the RHS, we use a dashed arrow $\dashrightarrow$ to indicate that
the LHS value may not fully reach the RHS. Each pattern’s interpretation in
English is also provided in Table 2.

The flow patterns in $\mathcal{F}$ abstract the flows between sources and
sinks occurring in the identified code snippets. Table 3 offers eight examples
illustrating the code snippets corresponding to flow patterns, ordered
according to the flow patterns in Table 2.

These examples represent the different types of flows that may occur when
processing personal data in code snippets. By identifying, analyzing, and
categorizing these flows into simplified flow patterns, we can provide a
uniform view of the data flows in code, capturing the properties of sources
and sinks in a single flow, the pathway from source to sink, and any other
involved values. This abstraction step is crucial in creating an intuitive and
efficient approach to understanding personal data flows, thereby enhancing
privacy protection in software systems.

Table 2: The collection of flow patterns $\mathcal{F}$

Flow Patterns Translation to English $E[\\_]\xrightarrow{m}v$ A non-personal
data value flows via sink $m$ into a source $v$.
$v_{2}+E[\\_]\stackrel{{\scriptstyle m}}{{\dashrightarrow}}v_{1}$ Value from
source $v_{2}$ and non-personal data are both processed by sink $m$ and the
result flows into source $v_{1}$. $v_{2}(E[\\_])\xrightarrow{m}v_{1}$ Value
from source $v_{2}$ flows via sink $m$ into source $v_{1}$.
$v\stackrel{{\scriptstyle m}}{{\dashrightarrow}}E[\\_]$ Value from source $v$
gets processed by sink $m$ and the result flows into a new expression.
$v\xrightarrow{m}E[\\_]$ Value from source $v$ flows via sink $m$ into a new
expression, making it a new source. $v_{1}+v_{2}\stackrel{{\scriptstyle
m}}{{\rightarrow}}v_{1}$ Value from source $v_{2}$ flows via sink $m$ declared
by $v_{1}$ into source $v_{1}$. $v+E[\\_]\stackrel{{\scriptstyle
m}}{{\rightarrow}}v$ Value from source $v$ and non-personal data are both
processed by sink $m$ and the result flows into itself.
$v\stackrel{{\scriptstyle m}}{{\rightarrow}}m(v)$ Value from source $v$ flows
into sink $m$.

Table 3: Examples demonstrating the relationship between code snippets and
their corresponding flow pattern instances in $\mathcal{F}$. The examples are
related to the flow patterns listed in Table 2.

Code Snippet Flow Pattern Instance full_name = retrieve(record_data,2) E[_]
$\stackrel{{\scriptstyle\text{retrieve}}}{{\rightarrow}}$ full_name isFemale =
check(user_detail,’F’) user_detail+ E[_]
$\stackrel{{\scriptstyle\text{check}}}{{\dashrightarrow}}$ isFemale first_name
= UserInfo.get(2) UserInfo(E[_])
$\stackrel{{\scriptstyle\text{get}}}{{\rightarrow}}$ first_name choice =
match(name,list) name
$\stackrel{{\scriptstyle\text{match}}}{{\dashrightarrow}}$ choice choice =
UserInfo.retrieve(2) UserInfo
$\stackrel{{\scriptstyle\text{retrieve}}}{{\rightarrow}}$ choice
AccountInfo.update(userId,index) AccountInfo + userId
$\stackrel{{\scriptstyle\text{update}}}{{\rightarrow}}$ AccountInfo
AccountInfo.update(index) AccountInfo + E[_]
$\stackrel{{\scriptstyle\text{update}}}{{\rightarrow}}$ AccountInfo print(SSN)
SSN $\stackrel{{\scriptstyle\text{print}}}{{\rightarrow}}$ print(SSN)

###  3.3 Specialized Views for GDPR Analysis Tasks

As GDPR compliance tasks can vary in their requirements, we provide
specialized views to assist code reviewers in understanding and analyzing
personal data handling within the system. An overview of personal data types
and their distribution is useful when developing a broad understanding of
personal data usage, while a detailed analysis of each data flow is required
for tasks like constructing a Record of Processing Activities (ROPA) or
assessing the risk of personal data handling. By providing these specialized
views, we aim to support reviewers in efficiently and effectively performing
GDPR compliance tasks.

####  3.3.1 Personal Data Type View

The Personal Data Type View presents an overview of personal data identified
in the source code. This view is a hierarchical representation that
illustrates the distribution of personal data types. The tree-like structure
is automatically generated based on our static analysis findings, categorizing
personal data identifiers by their nature such as account information or
personal ID. For instance, all source names with a stem-identifier like
email_addr, email_id, e-mail, and email are grouped together. This overview
provides users with a clear image of the types of personal data and their
respective identifiers present in the source code. See Figure 3 for an
example.

Figure 3: Personal Data Type View of ToolJet

####  3.3.2 Detailed Flow View

For tasks requiring a deeper understanding of specific personal data flows, we
provide the Detailed Flow View. This view presents comprehensive information
about each identified flow, including the file path, source and sink names and
types, and abstract flow patterns. Furthermore, it offers the ability to link
to the actual location of the code fragments, supporting a deeper contextual
analysis when necessary. Features for filtering and ranking the identified
flows are also included, allowing reviewers to focus on specific flows or
those of high potential risk. An example of the Detailed Flow View is provided
in Table 4.

These specialized views are designed to be flexible and adaptable to various
GDPR compliance tasks. We incorporate grouping functionalities based on
feedback from potential users, allowing results to be organized by specific
source identifiers, file locations, or other relevant criteria. This
flexibility is designed to make our approach practical, user-friendly, and
adaptable to various GDPR compliance tasks.

Table 4: Detailed Flow View grouped by identifier ‘email’ in ToolJet (top 7
results displayed)

Path Source Sink Sink Type Flow Pattern Instance
server/src/services/organizations.service.ts users.email_addr
createQueryBuilder DB users.email_addr
$\stackrel{{\scriptstyle\text{createQueryBuilder}}}{{\rightarrow}}$ query
server/src/services/group_permissions.service.ts users.email
createQueryBuilder DB users.email
$\stackrel{{\scriptstyle\text{createQueryBuilder}}}{{\rightarrow}}$ query
server/src/services/users.service.ts email this.usersRepository.findOne DB
email+_ $\stackrel{{\scriptstyle\text{findOne}}}{{\rightarrow}}$ UserInfo
server/src/services/organizations.service.ts email_addr
this.usersService.create C/D email_addr+_
$\stackrel{{\scriptstyle\text{create}}}{{\rightarrow}}$ UserInfo
server/ee/services/oauth/oauth.service.ts email
this.usersService.findOrCreateByEmail C/D UserInfo+email
$\stackrel{{\scriptstyle\text{findOrCreateByEmail}}}{{\rightarrow}}$ UserInfo
server/src/services/users.service.ts email user.organizationUsers.sendData T
email $\stackrel{{\scriptstyle\text{sendData}}}{{\rightarrow}}$
sendData(email) server/src/services/organizations.service.ts email_addr
this.usersService.update M UserInfo+email_addr
$\stackrel{{\scriptstyle\text{update}}}{{\rightarrow}}$ UserInfo

In a Detailed Flow View, we present key information such as file path, source
and sink names and types, and flow pattern instances, which are displayed by
default. For example, Table 4 shows the Detailed Flow View for all source
identifier email identification results. This information can be used to
construct a ROPA using the official template provided by data protection
authorities or a research semantic model like CSM-ROPA [13]. By traversing
flow pattern instances in Table 4, users can generate a list of processing
related to personal data “email” and identify their location.

To better assist GDPR compliance, our Detailed Flow View should not be limited
to a fixed presentation style. Based on feedback and recommendations from
potential users, we incorporate grouping to simplify GDPR compliance. We also
refer to the ICO’s ROPA template [8], which specifies the information required
for GDPR compliance mentioned in Section 2.1, such as the categories of
individuals and personal data, categories of recipients of personal data,
transfer details to third countries, retention schedules, and technical and
organizational security measures. Thus, we group the results by various
attributes such as source and sink categories and their distinct identities,
which can help users answer ROPA queries.

Moreover, users can experiment with different grouping criteria while
examining the code. For example, they can group the results by a specific
source identifier or file name/location of interest. We aim to incorporate
GDPR-related grouping criteria to ease GDPR compliance and make our approach
more useful.

###  3.4 Implementation

In recognizing the contextual nature of personal data, we have designed a
flexible system allowing users to customize pattern-matching rules via a
Python script. This script simplifies the definition of flow syntax and the
addition of new identifiers. All our identification rules are open-source to
encourage collaborative enhancement of the system’s capabilities. The results
of our analysis are produced in the Standard Static Analysis Results
Interchange Format (SARIF), facilitating easy filtering and sorting based on
parameters such as rules or file locations.

For visualizing the findings, we employ the Mermaid diagramming tool to
automatically generate a personal data distribution graph. This visual
representation aids in the identification and selection of specific source
identifiers for further examination. Finally, we’ve adopted a SARIF viewer for
filtering and sorting functionalities, and designed an interactive interface
for the Specialized Views, offering users an adjustable and task-specific data
exploration experience.

##  4 Experiment

To assess our approach, we focus on open-source software that processes
personal data. The experiment consists of two parts. In the first part, we
analyze popular open-source projects from GitHub, manually evaluating the true
positives (TP) and false positives (FP) in the results to validate our
approach. We illustrate the usefulness of our two specialized views by
aligning them with the published privacy statements of four validation
applications, showcasing how these views can guide the creation of a ROPA. In
the second part, we apply our approach to 15 popular Android applications on
Google Play, scrutinizing the accuracy of the information given in the “Data
collected” section of Google Play’s “Data safety” section.

###  4.1 Validation: Analyzing Trending GitHub Applications

Since we have used ToolJet in the previous sections as an example, here we
select our analysis target from the trending repositories on GitHub list.
Among the repositories captured from the GitHub monthly trending list
(accessed on 6/Dec/2022) under three different languages:
Java111https://github.com/trending/java?since=monthly,
JavaScript222https://github.com/trending/javascript?since=monthly, and
TypeScript333https://github.com/trending/typescript?since=monthly, we selected
the top four complete applications, that are not a framework, an add-on, or a
tutorial: Rocket Chat444https://github.com/RocketChat/Rocket.Chat,
Telegram555https://github.com/DrKLO/Telegram,
Odoo666https://github.com/odoo/odoo, and
Joplin777https://github.com/laurent22/joplin. We now refer to them as
validation applications.

We display the time taken to complete the identification task on validation
applications and the number of identified flows in Table 5.

Table 5: Identified code snippet count and the time consumed for each application | Time | No. of Code Snippet
---|---|---
Rocket Chat (TypeScript) | 397 s | 6,935
Telegram (Java) | 562 s | 16,963
Odoo (JavaScript) | 916 s | 25,653
Joplin (TypeScript/JS) | 694 s | 17,299

(a) Rocket Chat

(b) Telegram

(c) Odoo

(d) Joplin

Figure 4: The overview statistics of identified flow under all possible
combinations of source and sink types as illustrated in heatmaps.

For large projects such as Odoo and Telegram, our analysis takes about 15
minutes to analyze 2,285 files (Odoo) using 70 static analysis rules. Odoo is
the business content management system with the highest number of identified
personal data flows among the four validation applications, indicating that it
processes a substantial amount of personal data.

Next, we validate our approach in two steps. First, we manually examine the
precision of identified code snippets, assessing whether they are related to
personal data processing. Figure 4 and a Personal Data Type View figure (akin
to Figure 3) form the initial perspective of our generated views. The four
heatmaps present overview statistics of the different categories of personal
data and its processing in the four validation applications. The overview
statistics indicate that all four applications collect a significant quantity
of account and contact information, which is understandable as they function
as identifiers for system users and communication mediums. However, we observe
that certain applications gather more categories of personal data from users,
such as Telegram, which collects nine categories of personal data, with the
majority stored in databases.

Table 6 summarizes the results of the code snippet detection in each example
application, as well as the precision calculated through manual inspection for
each identified flow provided in the Detailed Flow View. Given that this
evaluation requires manual inspection and we need to avoid false negatives, we
examine the code snippets identified by the static analysis using the
following criteria to determine their precision score888Precision =
TP/(TP+FP), where True Positives (TP) are identified results that meet both of
our criteria, while False Positives (FP) are identified results that do not
meet one of our criteria.:

  * •

Do the source and sink identifiers match their respective categories? For
instance, if the analysis intended to match “log” but instead matched “login”,
which is irrelevant to the context.

  * •

Do the source and sink matches qualify as personal data processing? For
instance<EMAIL_ADDRESS>was detected as a clear-text result for explicit
personal data in the system, although it is not personal data.

Table 6: Statistics showing the precision of different types of flows detected. ‘-’ marks the labels for which our approach detected less than 20 results. Sink types are: data creation/deletion (C/D), data manipulation (M), data transportation (T), database (DB), encryption (E) and log (L). Source types are: account (ACC), contact (CON), personal ID (PID), online identifier (OID), location (LOC), feedback (FEE), health (HEA), national ID (NID), technical (TEC), and financial (FIN). Application | Source | Basic Sink | Special Sink
---|---|---|---
|  | C/D | M | T | DB | E | L
Rocket Chat | ACC | 0.80 | 0.95 | 0.94 | 0.97 | - | -
| CON | 0.85 | 0.88 | 0.95 | 0.96 | - | -
| PID | 0.83 | 0.92 | 0.95 | 0.96 | - | -
| OID | - | 0.73 | 0.88 | - | - | -
| FEE | - | 0.82 | 0.91 | - | - | -
| LOC | - | - | 0.89 | - | - | -
Joplin | ACC | 0.88 | 0.93 | 0.96 | - | 0.89 | 0.95
| CON | 0.93 | 0.81 | 0.92 | - | 0.92 | 0.98
| PID | 0.81 | 0.89 | 0.95 | - | - | -
| OID | 0.79 | 0.87 | 0.84 | - | - | -
| FEE | 0.84 | 0.95 | 0.8 | - | - | -
| LOC | 0.91 | 0.86 | 0.89 | - | - | -
| TEC | - | 0.71 | - | - | - | -
Telegram | ACC | 0.89 | 0.92 | 0.96 | 0.87 | 0.86 | 0.96
| CON | 0.90 | 0.96 | 0.94 | 0.93 | 0.91 | 0.92
| PID | 0.84 | 0.93 | 0.89 | 0.86 | - | -
| OID | 0.70 | 0.73 | 0.81 | - | - | -
| FEE | - | - | - | - | - | -
| LOC | 0.92 | 0.90 | 0.95 | - | - | -
| TEC | - | - | - | - | - | -
| FIN | - | 0.94 | 0.97 | - | - | -
| NID | 0.86 | 0.96 | 0.94 | 0.88 | 0.91 | -
Odoo | ACC | 0.91 | 0.86 | 0.98 | 0.94 | - | 0.95
| CON | 0.84 | 0.87 | 0.93 | 0.92 | 0.92 | 0.96
| PID | 0.82 | 0.95 | 0.97 | 0.96 | - | -
| OID | - | 0.66 | 0.63 | - | - | 0.82
| FEE | - | - | 0.72 | - | - | -
| TEC | - | 0.89 | 0.95 | - | - | -
| FIN | 0.88 | 0.92 | 0.94 | 0.95 | 0.90 | 0.95

Our main objective is to lessen the manual workload for code reviewers in
identifying and analyzing personal data flows, though we recognize that manual
scrutiny continues to play a crucial role. A high level of precision in our
flow identification technique indicates that we can conserve resources by
directing code reviewers to potential areas of concern, and offering guidance
on the potential data flow paths and locations within their applications. This
aligns with our specialized views approach, enhancing the efficiency and
efficacy of GDPR compliance tasks.

For the manual analysis, we conducted a thorough evaluation of a
representative sample of the identified code snippets to estimate the
precision, rather than individually checking all code snippets identified.
Table 6 shows that the majority of flow types have a precision of at least
0.8, with an average of over 0.9 for categories with more than 500 identified
flows. Some categories of flows that have a smaller sample size have a lower
precision, ranging from 0.65 to 0.75. Although a precision of 0.8 might result
in 5K false positives for an application with 25K identified snippets (e.g.,
Odoo), our approach aims to assist developers and code reviewers in finding
possible directions and locations for personal data processing, thereby
reducing the overall time and effort spent on manual analysis.

Note that we do not include the number of occurrences of literal personal data
identified by the pattern matching, as their precision is typically less than
0.6. A precision of less than 0.6 indicates that developers and code reviewers
still need to devote considerable effort to exclude literal identification
results that are not relevant. Identifying literal personal data is difficult
due to its ambiguous and highly contextual nature.

Next, we leverage the attributes available in the detailed Detailed Flow View
to evaluate existing privacy statements. Figure 5 depicts an instance of a
flow identified through our Detailed Flow View (similar to Table 4). This flow
was identified by a rule pinpointing the flow of location data into a
transportation sink. When a flow is selected for deeper scrutiny, crucial
information such as the file location, rule type and name, abstract flow
pattern (displayed under “Rule Description”), source/sink identifiers, and the
original code are readily accessible.

By integrating the Detailed Flow View with the provided statistics and
heatmaps from the Personal Data Type View, we can guide ROPA development and
verify the accuracy of existing privacy statements. For mobile applications,
we additionally examine the accuracy of personal data processing disclosures
made to platforms like Google Play or Apple’s App Store. In situations where a
comprehensive privacy statement is absent, such as with
Joplin999https://joplinapp.org/privacy/, we illustrate how our views can be
employed for ROPA creation.

Figure 5: Example of an identified flow in the Detailed Flow View for Rocket
Chat

In order to establish a connection between ROPA requirements and our
specialized views, we reference Table 7 which addresses four critical
requirements outlined in Section 2.1. These can subsequently be incorporated
into a comprehensive ROPA. Furthermore, we juxtapose our results with the
published privacy statements of the chosen four applications.

Rocket Chat’s detailed and well-structured privacy
statement101010https://docs.rocket.chat/legal/privacy aligns closely with our
Personal Data Type View and Detailed Flow View. Telegram and Odoo also offer
comprehensive and lucid privacy policies. However, our experiment uncovered
that Telegram collects user feedback and financial data, an activity not
explicitly mentioned in their privacy statement. On the other hand, Joplin’s
privacy statement111111https://joplinapp.org/privacy/ is brief and lacks
specificity on the types of personal data collected, except for geolocation
data. We also discovered instances where some personal data is temporarily
stored without being disclosed in the statement.

Our approach demonstrated its effectiveness in covering personal data and its
processing in the selected validation applications, as compared to their
published privacy statements. Nonetheless, we also found instances where the
applications collected personal data beyond their disclosed policies. Personal
data logging is a sensitive matter and should be meticulously inspected and
documented.

Table 7: Fact-check the published privacy statements of the four applications
using the information supplied by our two specialized views. The missing
information is highlighted.

Application Data Captured via Views Aligned with ROPA Published Privacy
Statement/Policy Rocket Chat • Categories of personal data: ACC, CON, PID,
OID, FEE, LOC. • Categories of processing: basic processing: C/D, M, and T.
Minor logging personal data identified. • Transfer to a database or third-
party APIs: own database access identified on ACC, CON, and PID data, minor on
OID, FEE, and LOC data, no third-party database API detected. • Data
encryption or anonymization: Encryption on ACC, CON, PID, OID, FEE data. No
anonymization was identified. • Categories of personal data: personal ID (PID,
CON), account data (ACC), usage data (OID, FEE), location data (LOC), cookie
data (OID) • Categories of processing: for contact/identification: PID, CON;
for market/communication: PID, CON; for registration: ACC; for
maintenance/tech support/monitoring: OID, FEE; for functionalities: OID, LOC,
OID. • Transfer to a database or third-party APIs: no third-party services
mentioned, data outside of the USA might be transferred to services in the
USA. • Data encryption or anonymization: relevant security measures were taken
into account. Telegram • Categories of personal data: ACC, CON, PID, OID, FEE,
LOC, TEC, FIN, NID • Categories of processing: basic processing: C/D, M, and
T. Major logging ACC and CON data identified. • Transfer to a database or
third-party APIs: there are database calls for ACC, CON, PID, and NID data
identified to both internal and external databases. • Data encryption or
anonymization: there is major encryption on NID, ACC, and CON data. •
Categories of personal data: account data (ACC, PID), contact data (CON, ACC,
NID), location data (LOC), chats (OID), and cookies (TEC, OID) • Categories of
processing: for identification/account purposes (ACC, PID, NID); for
communication (CON, ACC); for improving services (TEC, OID); for
functionalities (LOC, TEC, OID). • Transfer to a database or third-party APIs:
data is saved in third-party provided data centers in the Netherlands for
European users, and end-to-end chats are not transmitted out of the device •
Data encryption or anonymization: “All data is stored heavily encrypted so
that local Telegram engineers or physical intruders cannot get access.” Odoo •
Categories of personal data: ACC, CON, PID, OID, FEE, TEC, FIN • Categories of
processing: basic processing: C/D, M, and T. Major logging ACC, CON, and FIN
data identified. • Transfer to a database or third-party APIs: there are
database calls for ACC, CON, PID, and FIN data identified to both internal and
external databases. • Data encryption or anonymization: there is encryption on
ACC, CON, PID, and FIN data. • Categories of personal data: account & contact
Data (ACC, CON), job application data (CON, PID), browser data (FEE, TEC),
customer databases (ACC, CON, PID, FIN), free trial session recording (FIN,
TEC, OID, FEE), In-App Purchase transaction data (FIN) • Categories of
processing: for the recruitment process (ACC, CON, PID); for maintaining and
improving services (FEE, TEC, OID); for providing services (ACC, PID),
answering requests (CON), and for billing management (FIN, CON, ACC) •
Transfer to a database or third-party APIs: “customer databases are hosted in
the Odoo Cloud Region closest to where they are based, and can request a
change of region” • Data encryption or anonymization: “info is securely
processed, stored and preserved from data loss and unauthorized access”.
Joplin • Categories of personal data: ACC, CON, PID, OID, FEE, LOC, TEC •
Categories of processing: basic processing: C/D, M, and T. Major logging
contact data identified. • Transfer to a database or third-party APIs: Almost
none, only less than 5 identified for ACC and LOC data to be passed into a
local temporary data model. • Data encryption or anonymization: There are
encryption measures on ACC and CON data identified. • Categories of personal
data: It is not mentioned in the privacy policy, only explicitly mentioned
geo-location data. • Categories of processing: Not mentioned. • Transfer to a
database or third-party APIs: Only mentioned: “Any data that Joplin saves,
such as notes or images, are saved to your own device and you are free to
delete this data at any time.” • Data encryption or anonymization: Not
mentioned.

###  4.2 Application: Assessing Google Play Data Safety Statements

To further highlight the applicability of our approach, we examined the top
three Android applications from Google Play (accessed on 8/Dec/2022, from the
U.S. store121212https://play.google.com/store/apps?gl=US) in five different
categories: communication, online shopping, weather, fitness/health, and
transportation. As the decompilation process generated some noise, potentially
distorting the count of data processing flows, we focused on assessing the
categories and distributions of personal data collected by the applications.

In our evaluation, we verified the “Data Safety” statements of 15 applications
against the Personal Data Type View and Detailed Flow View generated by our
approach. Table 8 presents the results, including the number of identified
flows for each personal data category, the coverage of their data safety
statements in Google Play, and the amount of personal data logged.

Table 8: Identified personal data types, their quantity, and how they are
covered by Google Play’s privacy policies. In column ‘Coverage’, ‘-’ indicates
the types of personal data identified by our approach but not covered in the
privacy statement; ‘+’ implies that there is coverage of all identified
personal data types in the privacy statement.

Android Apps ACC CON PID OID LOC FEE HEA NID TEC FIN Coverage Logging Discord
1621 791 31 399 159 107 - - 87 9 + 41 Kik 2065 1923 17 817 51 39 - - 46 31
-ACC, -LOC 133 Viber 1823 2093 101 740 219 42 - - 71 16 -ACC, -OID, -FEE, -TEC
82 Amazon 905 2762 1025 1623 634 198 42 - 231 129 -ACC 162 AliExpress 1244
2381 1730 2094 841 217 - - 309 261 -LOC, -FEE 217 Shein 1072 1967 965 978 409
96 - - 160 373 -LOC 62 The Weather Channel 239 2384 1291 1328 2623 172 - - 16
22 + 76 AccuWeather 176 2137 1102 1736 3321 98 - - 5 9 -PID, -OID, -ACC, -CON
41 Windy 312 246 567 803 1196 - - - - 14 -LOC 22 SamSung Health 273 182 31 98
685 44 1027 - 28 21 + 10 Google Fit 105 49 14 6 271 19 580 - 9 4 + 7 My
Fitness Pal 328 209 19 113 902 75 721 - 47 69 -PID 89 Uber 1497 1054 298 835
2094 511 - - 814 427 + 294 Trainline 469 107 244 54 626 - 4 82 562 -NID 104
Omio 724 151 457 72 729 - 12 205 710 -ACC, -NID, -OID 71

We found that our approach detected certain types of personal data not
disclosed in the Google Play data safety section. While Google allows
exceptions for “on-device access/processing” and “end-to-end encryption”, we
found instances where data left the device without being disclosed. For
example, location data in the online chatting app Kik and national ID data in
the transportation app Omio are transmitted outside the device, but this was
not stated in their respective Google Play disclosures.

Interestingly, we observed that applications across various domains commonly
collected account and contact data, with additional domain-specific types. For
instance, weather applications gathered significant location data, while
transportation/ticketing applications acquired national ID data from users.
Consistent with the GitHub projects evaluated earlier, all the apps logged
personal data. This assessment underscores the utility of our approach in
helping apps improve the accuracy of their data safety statements and increase
transparency in their data handling practices.

###  4.3 Threats to Validity

Our approach does not offer a fully automated solution for GDPR compliance
tasks, such as generating a ROPA, due to the lack of a natural language
processing module. This limitation makes it challenging to directly generate
or verify statements based on the output of our approach, which consists of
code snippets, fragments, labels, and additional details. As a result, manual
effort is required in our experiments, which consequently restricts the number
of applications we can feasibly validate (four in this study). Each
application must be open-source, widely used, gather diverse types of personal
data, and possess a publicly available privacy statement.

The primary threat to the validity of our experiments is the difficulty in
establishing a ground-truth set of actual data processing activities within
the source code. This is due to the necessity of domain knowledge from the
original development team, which is typically inaccessible. Consequently, it
is not feasible to accurately measure the recall value (TP/(TP+FN)) for our
approach.

In the context of fact-checking Google Play data safety statements, we are
unable to verify which types of personal data are sent outside of the device.
This limitation prevents us from fully assessing the accuracy of these
statements.

##  5 Related Work

Existing research on incorporating privacy-by-design (PbD) into the software
development life cycle lacks concrete tools to assist software developers in
designing and implementing GDPR-compliant systems [3]. Moreover, such PbD-
created systems lack standards for mapping particular legislative data
protection obligations, such as the GDPR.

Ferrara et al. propose a framework to adopt static analysis to assess GDPR
compliance [4]. However, this approach requires compiled bytecode, which may
not always be readily available during the development process. Arfelt et al.
provide a formal logic for monitoring GDPR compliance [2] and a functional
tool was developed by [6] for analyzing cross-border data transmission in
Android applications, which is limited in scope to a specific platform.

Some existing research focuses on the identification of personal data but does
not consider broader GDPR compliance aspects. Fugkeaw et al.[5] design a
technique to let enterprises automatically detect and handle personal data
stored in the local file system. ReCon[12] uses machine learning to detect
possible breaches of personal data by monitoring network traffic, requiring a
pre-trained ML model. van der Plas [11] identifies personal data in Git
commits using CodeBERT, a transformer model similar to RoBERT, but this
approach only focuses on the presence of personal data.

Our work aims to address these research gaps by providing a comprehensive
solution that does not rely on compiled bytecode, pre-trained ML models, or
platform-specific tools, and goes beyond merely identifying the presence of
personal data to ensure broader GDPR compliance during the software
development process.

##  6 Conclusion and Future Directions

Ensuring GDPR compliance demands detailed information on personal data
processing, often requiring significant manual effort. Our work strives to
lessen this burden by offering two specialized views — Personal Data Type View
and Detailed Flow View, facilitating code reviewers in identifying potential
data processing locations and providing necessary information. Our approach,
leveraging static analysis, has shown an average precision of 0.87 in our
experiments, demonstrating its effectiveness.

However, our approach has limitations. Currently, it is based on Semgrep for
static analysis, which captures intra-procedural data flows, leaving inter-
procedural flows unaccounted for. The adoption of the Semgrep Pro Engine,
offering inter-procedural analysis, could enhance our approach’s precision.

In conclusion, our approach presents specialized views, aiding in GDPR
compliance tasks, such as ROPA production, by reducing manual effort. With
further improvements, such as incorporating the Semgrep Pro Engine and
refining our identification rules, we aim to make the process of privacy
analysis more efficient and manageable for code reviewers.

## Acknowledgement

This paper is an extended version of work published in [15]. We would like to
extend our sincere gratitude to Rob van der Veer for his valuable insights and
contributions to this research. This work is part of the Privacy Matters
(PriMa) project. The PriMa project has received funding from European Union’s
Horizon 2020 research and innovation program under the Marie Skłodowska-Curie
grant agreement No. 860315.

## References

  * [1] Alharthi, A., Krotov, V., Bowman, M.: Addressing barriers to big data. Business Horizons 60(3), 285–292 (2017)
  * [2] Arfelt, E., Basin, D., Debois, S.: Monitoring the GDPR. In: European Symposium on Research in Computer Security. Springer (2019)
  * [3] Baldassarre, M.T., Barletta, V.S., Caivano, D., Scalera, M.: Integrating security and privacy in software development. Software Quality Journal 28(3), 987–1018 (2020)
  * [4] Ferrara, P., Spoto, F.: Static analysis for gdpr compliance. In: Italian Conference on Cybersecurity (2018)
  * [5] Fugkeaw, S., Chaturasrivilai, A., Tasungnoen, P., Techaudomthaworn, W.: Ap2i: Adaptive PII scanning and consent discovery system. In: 2021 13th International Conference on Knowledge and Smart Technology (KST). pp. 231–236. IEEE (2021)
  * [6] Guamán, D.S., Del Alamo, J.M., Caiza, J.C.: Gdpr compliance assessment for cross-border personal data transfers in android apps. IEEE Access 9, 15961–15982 (2021)
  * [7] Huth, D., Tanakol, A., Matthes, F.: Using enterprise architecture models for creating the record of processing activities (Art. 30 GDPR). In: 2019 IEEE 23rd International Enterprise Distributed Object Computing Conference (EDOC). pp. 98–104. IEEE (2019)
  * [8] ICO: How do we document our processing activities? information commissioner’s office. https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/documentation/how-do-we-document-our-processing-activities/, (Accessed on 04/29/2023)
  * [9] Naik, A., Mendelson, J., Sands, N., Wang, Y., Naik, M., Raghothaman, M.: Sporq: An interactive environment for exploring code using query-by-example. In: The 34th Annual ACM Symposium on User Interface Software and Technology. pp. 84–99 (2021)
  * [10] Pandit, H.J., Polleres, A., Bos, B., Brennan, R., Bruegger, B., Ekaputra, F.J., Fernández, J.D., Hamed, R.G., Kiesling, E., Lizar, M., et al.: Creating a vocabulary for data privacy. In: OTM Confederated International Conferences" On the Move to Meaningful Internet Systems". pp. 714–730. Springer (2019)
  * [11] van der Plas, N.: Detecting PII in Git commits. Master’s thesis - TU Delft (2022)
  * [12] Ren, J., Rao, A., Lindorfer, M., Legout, A., Choffnes, D.: Recon: Revealing and controlling PII leaks in mobile network traffic. In: Proceedings of the 14th Annual International Conference on Mobile Systems, Applications, and Services. pp. 361–374 (2016)
  * [13] Ryan, P., Pandit, H.J., Brennan, R.: A common semantic model of the gdpr register of processing activities. arXiv:2102.00980 (2021)
  * [14] Solove, D.J.: Access and aggregation: Public records, privacy and the constitution. Minn. L. Rev. 86, 1137 (2001)
  * [15] Tang., F., Østvold., B., Bruntink., M.: Identifying personal data processing for code review. In: Proceedings of the 9th International Conference on Information Systems Security and Privacy - ICISSP. pp. 568–575. INSTICC, SciTePress (2023). https://doi.org/10.5220/0011725700003405


# Denoising without access to clean data
using a partitioned autoencoder

Dan Stowell
Centre for Digital Music
School of Elec. Eng. and Computer Science
Queen Mary University of London  Richard E. Turner
Computational and Biological Learning Lab
Department of Engineering
University of Cambridge

###### Abstract

Training a denoising autoencoder neural network requires access to truly clean
data, a requirement which is often impractical. To remedy this, we introduce a
method to train an autoencoder using only noisy data, having examples with and
without the signal class of interest. The autoencoder learns a partitioned
representation of signal and noise, learning to reconstruct each separately.
We illustrate the method by denoising birdsong audio (available abundantly in
uncontrolled noisy datasets) using a convolutional autoencoder.

##  1 Introduction

An autoencoder (AE) is a neural network trained in unsupervised fashion, to
encode its input to some latent representation and to decode that
representation to a faithful reconstruction of its input. The autoencoder can
then be used as a codec, or to convert data to its latent representation for
downstream processing such as classification. The denoising autoencoder (DAE)
is a variant of this in which the inputs are combined with some corruption
(such as additive noise or masking), and the system is trained to recover the
clean, de-noised data [1]. The DAE training scheme can be used in denoising
applications, and is also a popular way to encourage the autoencoder to learn
a more meaningful latent representation of the data. Autoencoders including
the DAE have yielded leading results in recent years in deep learning for
signal processing [1, 2].

However, there is a significant problem with the DAE approach which hampers
its use in practical applications: it may often be impossible to supply truly
clean data. This is common in our application example—natural sound
recordings—but also for video, image and audio applications across many
domains. In fact, objects/events are often sparsely represented in data while
background and other noise are densely represented, meaning that it is often
easy to provide “noise-only” examples while difficult to provide “noise-free”
examples.

In this paper we propose an alternative approach to train an AE so that it can
perform denoising, given training data which can only be weakly labelled as
“noise-only” or “noise and possible signal”. The system learns a partitioned
latent representation, with identifiable noise and signal coefficients, and
can then perform denoising and/or recover a signal-only latent representation
for further analysis. The method is general-purpose; we illustrate it here
with an application to denoising birdsong audio spectrograms.

##  2 Partitioned autoencoders

A standard AE learns a function of the form
$\hat{\mathbf{X}}=g(f({\mathbf{X}}))$ where ${\mathbf{X}}$ is an input datum
(a matrix, in this paper), and the autoencoder is composed of encoder
$f(\cdot)$ and decoder $g(\cdot)$. The DAE learns a function
$\hat{\mathbf{X}}=g(f(u({\mathbf{X}})))$ where $u(\cdot)$ is a stochastic
noise corruption process. The training objective is such that
$\hat{\mathbf{X}}$ is encouraged to be as close to ${\mathbf{X}}$ as possible,
often $\sum_{i}{\|{\mathbf{X}}_{i}-\hat{\mathbf{X}}_{i}\|^{2}}$ where
$||\cdot||$ is the Frobenius norm and the sum is taken over a minibatch of
training data. (A minibatch is a small subset of training data used for one
iteration of stochastic gradient descent [SGD].) Given this objective, in
practice a DAE will learn to denoise its input to the extent that
${\mathbf{X}}$ itself is clean, having no incentive to “overshoot” and remove
any noise that may be intrinsic to the original ${\mathbf{X}}$. The latent
representation output from $f(\cdot)$ parametrises the manifold on which the
reconstructed signal data lie. Information about the noise present in each
datum is not captured, except implicitly as ${\mathbf{X}}-\hat{\mathbf{X}}$ if
$\hat{\mathbf{X}}$ is a good estimate.

Many equivalent parametrisations of the manifold may be possible, some
allowing a more semantic interpretation of each latent coefficient than
others, and the standard AE or DAE does not distinguish among these
parametrisations. There has been recent interest in adapting the training
schemes of autoencoders such that the latent representation is explicitly
semantic, capturing attributes of the input in specific subsets of the latent
variables [3, 4]. We refer to these as partitioned autoencoders since the
latent variables are partitioned into subsets which are treated differently
from each other during training. Crucially, in this prior work the training
scheme relies heavily on the existence of large structured datasets: in [4] a
balanced dataset of labelled digit images; in [3] a dataset of faces
constructed through systematic variation of attributes such as pose and
lighting. Without such known structure in the training data, their proposed
training schemes will be either impossible to apply, or biased by the presence
of unbalanced or correlated factors in the training data.

Our present motivation is to learn a denoising representation, trained using
data which does not contain truly clean examples. If we can develop a scheme
that learns to represent both signal and noise, but partitioning them into
separate latent coefficients, then we will be able to perform denoising or
further analysis by using only the “foreground” (signal) coefficients and
setting the remainder to zero. The scheme of [3] would be appropriate if the
SNR of each training example were known and systematically varied, but in
uncontrolled datasets this information is rarely available. Instead we propose
a scheme based on the observation that many scenarios consist of sparsely-
present foreground and densely-present background, and so noise-only training
data is much easier to come by than signal-only.

Our training scheme is based on a standard autoencoder reconstruction
objective, augmented with a structured regularisation of the latent variables.
In order to encourage the model to use the background latents to represent
noise and never to represent signal, we add a soft regulariser that penalises
foreground latent activation for the noise-only examples. For each training
example ${\mathbf{X}}$ associated with a weak label $y$ taking the value 1 if
the example is a “noise-only” example and 0 otherwise, we train an autoencoder
by minimising the following loss function:

$l({\mathbf{X}},y)=\|{\mathbf{X}}-\hat{\mathbf{X}}\|^{2}+\frac{\lambda
y}{{\bar{\mathbf{C}}}}\|{\mathbf{C}}\odot f({\mathbf{X}})\|^{2}$

where $\hat{\mathbf{X}}=g(f({\mathbf{X}}))$, $\lambda$ is a regularisation
coefficient, $\odot$ represents elementwise multiplication, ${\mathbf{C}}$ is
a masking matrix containing 1 for latents which should represent foreground
and 0 otherwise, and ${\bar{\mathbf{C}}}$ the mean value of ${\mathbf{C}}$. We
will construct our training minibatches with a fixed proportion of noise-only
items at each iteration. The value used for $\lambda$ will be relatively
large, to impose a soft constraint pushing a subset of the latent values to
zero in the case of noise-only items (Figure 1, Figure 2). This encourages the
learned representation to use the non-regularised latents for the foreground
signal. The parameters of $f(\cdot)$ and $g(\cdot)$ will be optimised through
SGD. Once trained, denoising is achieved by reconstructing using only the
foreground latents, i.e. setting the others to zero (Figure 3).

Figure 2 emphasises that the proportion of latents dedicated to foreground vs.
background, and the balance of “signal-plus-noise” and “noise-only” examples
in a minibatch, are independent configuration choices. We tend to reserve 25%
of latents for background, and 25% of a minibatch as noise-only; in our
evaluation we will evaluate the impact of varying the balance of latents.

Note that the regularisation scheme is asymmetric: it encourages some latents
to zero in certain cases, but it does not prevent them from being zero in the
other cases. In principle the system could simply never use those latents;
however the reconstruction cost encourages the system to use them to improve
reconstruction in cases where it has that freedom. The asymmetry also means
that the important aspect of data labelling is to identify “noise-only” items
with high precision. If some “noise-only” items are not labelled as such, the
system is free to represent them without making use of those latents. The
scheme can thus be used on datasets which are too large to label completely,
but in which a subset of noise-only examples can be identified.

Figure 1: Our training scheme aims to reconstruct all the minibatch items,
while regularising some of the latents.

Figure 2: Regularisation is applied to the subset of latents intended to
represent signal, and only for noise-only examples.

Figure 3: Once trained, the system can denoise by reconstructing using only a
subset of the latents (setting others to zero).

##  3 Convolutional partitioned autoencoder for audio spectrograms

The training scheme can be applied to various autoencoder architectures.
Convolutional neural networks have recently proven to be powerful for many
tasks, while relatively easy to train because they have far fewer free
parameters than an equivalent fully-connected network [2, 5]. In our
application we aim to extract information from audio spectrograms, indexed by
time and frequency. We will thus use an autoencoder which is convolutional in
time and fully-connected in frequency, as is standard for recent neural
network audio analysis [5]. Given an input matrix ${\mathbf{X}}$ indexed by
discrete time $n$ and frequency $h$, we define our encoding function to be

$f({\mathbf{X}})=mp(r({\mathbf{W}^{c}}\star({\mathbf{X}}-\hat{\mu})/\hat{\sigma}))$

where ${\mathbf{W}^{c}}$ is a tensor of coding weights indexed by time $m$
frequency $h$ and latent index $k$, $r(\cdot)$ is a rectified linear unit
nonlinearity, $mp(\cdot)$ represents the max-pooling operation applied along
the time axis, $\hat{\mu}$ and $\hat{\sigma}$ are the frequency-wise means and
standard deviations estimated from the training set and used for
normalisation, and $\star$ indicates one-dimensional convolution as follows:

$(A\star B)_{n,k}=\sum_{m=1}^{M}{\sum_{h=1}^{H}{a_{m,h,k}b_{n-m,h}}}\quad
n\in[1,N],k\in[1,K]$

resulting in a matrix indexed by time $n$ and latent index $k$.

Our decoding function is

$g(f({\mathbf{X}}))={\mathbf{W}^{d}}\star mp^{-1}(f({\mathbf{X}}))$

where ${\mathbf{W}^{d}}$ is a tensor of decoding weights, and $mp^{-1}(\cdot)$
is the inverse of the max-pooling operation (the approximate inverse, as the
non-maximal values are reconstituted by zeros).

In this temporally convolutional architecture, the mask matrix ${\mathbf{C}}$
is implemented as identical frame-wise mask matrices, with $k$ indexing the
set of latent time series.

Our data will be non-negative. Data normalisation at the input is important
for effective training, hence the use of $\hat{\mu}$ and $\hat{\sigma}$ [6].
However we do not undo the normalisation at the decoder outputs: the non-
negative target and the rectifier then give the property that the decoder
learns a non-negative parts-based reconstruction. We do not use bias units, as
we found the resulting system easier to train (cf. [7, 8]).

For the evaluation that follows, fixed configuration details are: input
spectrograms have 512 time frames and 32 frequency bins, and we use 32 latent
variables. Convolution filters have a length of 9 time frames. Our max-pooling
downsamples the time axis by a factor of 16. We train the network using
AdaDelta to control the SGD learning rates [9]. We do not use dropout. We
initialise the tensor of filters as a set of $K$ random orthogonal unit
vectors of length $MH$, reshaping this to the tensor of shape $M\times H\times
K$ (cf. [10]).

In this study we explore only a single-layer autoencoder. Our approach applies
straightforwardly to a deep autoencoder, and a deeper system would be expected
to have a broader ability to generalise.

Figure 4: Example of source separation with the proposed system. Upper: input
spectrogram, 1.5 seconds (birdsong, plus background noise including a notable
loud noise near the end). Middle: reconstructed signal spectrogram. Lower:
reconstructed noise spectrogram.

##  4 Evaluation

We test our approach using a task to denoise birdsong audio spectrograms
(Figure 4). As foreground we use recordings of chiff chaff (similarly to [11,
12]). For evaluation purposes we wish to add a background that offers a
substantial test: it should be diverse, nonstationary and contain significant
energy in the same frequency band as the birdsong. After considering many
available options we settled on recorded restaurant noise, which contains
multi-speaker human speech as well as diverse percussive sound events. We add
this background noise, both to create a known amount of “intrinsic” noise in
the examples, and to create “noise-only” examples.

Our system is implemented in the Theano framework [13] making use of GPU
processing. To create a diverse training/validation dataset within the
constraints of limited GPU memory, we take advantage of the approximate
additive nature of audio spectrograms as follows. In each experiment we load
30 seconds of signal, of intrinsic noise and extrinsic noise, and store their
spectrograms to the GPU. Then to generate each “signal-plus-noise” datum we
randomly sample 1.5 second segments from each of the three sources and mix
them. To generate a “noise only” datum we sample only from the extrinsic noise
source. This creates a large generative dataset within limited memory. We also
experimented with replacing the 30 second source material regularly throughout
training but this made little difference, so we do not employ that in the
present results.

Our audio sources use sample rate 22.05 kHz, analysed using 128 bin FFTs with
50% hop, and the frequency axis then reduced to 32 bins of interest for the
birdsong (1.7–7.2 kHz). Within this frequency band, we added intrinsic noise
to give an SNR -10 dB, then extrinsic noise to give an SNR of -30 dB. The
extrinsic noise corresponds to the “noise-only” items that would be provided
in practice. The intrinsic noise is added for evaluation only, to judge
whether the system can remove it (Figure 5). We study two cases where the
intrinsic and extrinsic noise sources are matched or unmatched.

Figure 5: For evaluation only (not for application), we construct our
“signal+noise” examples from clean signal plus added intrinsic noise, so that
we can evaluate SNR against the truly clean signal which the system never
accesses.

Figure 6: Reconstruction SNRs measured on the validation data, for the
partitioned AE or DAE. Intrinsic and extrinsic noise may be matched (upper
plot) or unmatched (lower plot). Experiments are performed separately with
three different noise source recordings, and the error bars show the range
across three experiments. The large error bars are due to individual
differences and not random variation (inspected by eye).

We test our partitioned AE at various settings for the proportion of latents
regularised, and also a standard DAE using the same training data, configured
to use the extrinsic noise as the additive corruption $u(\cdot)$ in the DAE
training process. In all cases we fix $\lambda=0.75$ and train with
minibatches of size 16, and $10^{6}$ iterations of SGD.

Results evaluated on separately-sampled validation data (Figure 6) show a
number of interesting properties. Firstly, all methods perform best against
their explicit objective in every case: i.e. their best SNR is the one
relating to their objective function (simple reconstruction for the proposed
system, reconstruction of the partly-clean input for the DAE). However, the
statistic of interest is reconstruction of the truly-clean spectrogram. In
matched conditions (upper plot), the proposed system strongly outperforms the
DAE on this measure. Its strong performance is stable across a broad range of
settings for the proportion of latents regularised (all except the extremes).
The poor results at the setting with regularisation of all latents (100%)
confirm that the regularisation used is strong: if applied to all latents, it
causes underfitting. It is not merely the presence of regularisation that
improves the results, but the partitioning scheme.

In unmatched conditions (lower plot) the strong performance is not sustained.
The DAE continues to perform well at its partial-denoising task, but our
proposed DAE fails to generalise across diverse background recordings. It
seems likely that this is due to the small size and depth of the current
setup: a single-layer autoencoder with only 32 convolutional filters has
limited ability to approximate arbitrary functions. The strong performance in
matched conditions suggests further study of the method with deeper networks.
However, note that matched conditions are common in applications such as ours,
where the noise-only examples can be taken from the main field recording
sessions.

##  5 Conclusions

We have introduced a partitioned autoencoder that can learn to denoise data
with better fidelity than a standard DAE, in the common practical case where
no noise-free examples are available for training. In matched conditions this
partitioned scheme makes better use of the available data than a DAE. Unlike a
DAE, our partitioned autoencoder learns to represent the signal and the noise
content, and can reconstruct either or both. This may be part of its advantage
over a standard DAE, which does not learn to represent the noise content.
Further work will explore deeper/wider architectures to improve the
generality, and use the representations to support classification and other
tasks.

##  6 Acknowledgments

We gratefully thank Pavel Linhart for recording the chiff chaff bird sounds
used in this study.

DS is supported by EPSRC Fellowship EP/L020505/1.

## References

  * [1] P. Vincent, H. Larochelle, I. Lajoie, Y. Bengio, and P.-A. Manzagol,  “Stacked denoising autoencoders: Learning useful representations in a deep network with a local denoising criterion,”  The Journal of Machine Learning Research, vol. 11, pp. 3371–3408, 2010.
  * [2] Y. LeCun, Y. Bengio, and G. Hinton,  “Deep learning,”  Nature, vol. 521, no. 7553, pp. 436–444, 2015.
  * [3] T. D. Kulkarni, W. Whitney, P. Kohli, and J. B. Tenenbaum,  “Deep convolutional inverse graphics network,”  arXiv preprint arXiv:1503.03167, 2015.
  * [4] B. Cheung, J. A. Livezey, A. K. Bansal, and B. A. Olshausen,  “Discovering hidden factors of variation in deep networks,”  arXiv preprint arXiv:1412.6583, 2014.
  * [5] S. Dieleman and B. Schrauwen,  “End-to-end learning for music audio,”  in Proc ICASSP, 2014, pp. 6964–6968.
  * [6] G. Montavon, G. Orr, and K.-R. Müller, Eds.,  Neural Networks: Tricks of the Trade,  Springer, 2012.
  * [7] T. L. Paine, P. Khorrami, W. Han, and T. S. Huang,  “An analysis of unsupervised pre-training in light of recent advances,”  arXiv preprint arXiv:1412.6597, 2014.
  * [8] R. Memisevic, K. Konda, and D. Krueger,  “Zero-bias autoencoders and the benefits of co-adapting features,”  arXiv preprint arXiv:1402.3337, 2014.
  * [9] M. D. Zeiler,  “Adadelta: an adaptive learning rate method,”  arXiv preprint arXiv:1212.5701, 2012.
  * [10] A. M. Saxe, J. L. McClelland, and S. Ganguli,  “Exact solutions to the nonlinear dynamics of learning in deep linear neural networks,”  arXiv preprint arXiv:1312.6120, 2013.
  * [11] D. Stowell and M. D. Plumbley,  “Segregating event streams and noise with a Markov renewal process model,”  Journal of Machine Learning Research, vol. 14, pp. 1891–1916, 2013,  preprint arXiv:1211.2972.
  * [12] D. Stowell, S. Muševič, J. Bonada, and M. D. Plumbley,  “Improved multiple birdsong tracking with distribution derivative method and Markov renewal process clustering,”  in Proceedings of the International Conference on Audio and Acoustic Signal Processing (ICASSP), 2013,  preprint arXiv:1302.3642.
  * [13] F. Bastien, P. Lamblin, R. Pascanu, J. Bergstra, I. J. Goodfellow, A. Bergeron, N. Bouchard, and Y. Bengio,  “Theano: new features and speed improvements,”  in Proceedings of NIPS 2012, 2012.