11institutetext: TU Berlin, Information Systems Engineering, Berlin, Germany
11email: {nl, f.kirsten, fp<EMAIL_ADDRESS>
# Streamlining personal data access requests:
From obstructive procedures to automated web workflows

Nicola Leschke  0000-0003-0657-602X Florian Kirsten  0000-0002-9202-6640
Frank Pallas  0000-0002-5543-0265 Elias Grünewald  0000-0001-9076-9240

###### Abstract

Transparency and data portability are two core principles of modern privacy
legislations such as the GDPR. From the regulatory perspective, providing
individuals (data subjects) with access to their data is a main building block
for implementing these. Different from other privacy principles and respective
regulatory provisions, however, this right to data access has so far only seen
marginal technical reflection. Processes related to performing _data subject
access requests (DSARs)_ are thus still to be executed manually, hindering the
concept of data access from unfolding its full potential.

To tackle this problem, we present an automated approach to the execution of
DSARs, employing modern techniques of web automation. In particular, we
propose a generic DSAR workflow model, a corresponding formal language for
representing the particular workflows of different service providers
(controllers), a publicly accessible and extendable workflow repository, and a
browser-based execution engine, altogether providing “one-click” DSARs. To
validate our approach and technical concepts, we examine, formalize and make
publicly available the DSAR workflows of 15 widely used service providers and
implement the execution engine in a publicly available browser extension.
Altogether, we thereby pave the way for automated data subject access requests
and lay the groundwork for a broad variety of subsequent technical means
helping web users to better understand their privacy-related exposure to
different service providers.

###### Keywords:

Data Subject Access Request Process Automation Web Automation Privacy Privacy
Engineering Data Access Data Portability GDPR

1.5(-3cm, -8cm)

Preprint (2023-05-04) before final copy-editing of an accepted peer-reviewed
paper to appear in the
Proceedings of the 23th International Conference on Web Engineering (ICWE
2023).
The Version of Record can be found here:
https://link.springer.com/conference/icwe

##  1 Introduction

Modern privacy regulations such as the GDPR or the CCPA comprise a broad
variety of obligations to be fulfilled by service providers (_controllers_)
processing personal data of individuals (_data subjects_). Besides concepts
broadly recognized in the technical domain – such as security, data
minimization/anonymization, etc. – this also includes provisions and rights
regarding _transparency_ and _data portability_. Taking the GDPR as a
blueprint example for other privacy regulations herein, users have a right to
access (RtA), obligating service providers to provide them with “a copy of the
personal data undergoing processing” (Art. 15 (3)) upon request.

This right is considered essential in empowering data subjects to make well-
informed and self-sovereign decisions regarding, e.g., which services (not) to
use (anymore), which data to share with them, etc. [17]. In addition, the RtA
is also an indispensable prerequisite for exercising other privacy rights
[32], such as the right to rectification or deletion (Art. 16/17) and also
facilitates novel practices of data reuse for individual as well as collective
purposes [34, 40, 33].

The manifold possible benefits notwithstanding, the RtA is rarely used in
practice. Some even say it is “ignored, inefficient, underused and/or
obsolete” [5, p. 4]. This lack of use can largely be attributed to the fact
that request processes as implemented in practice are tedious and error-prone
from the perspective of data subjects who, in turn, all too often abstain from
pursuing data access or from successfully completing a respective request [9].

To address these shortcomings, we propose to render DSARs more accessible and
less obstructive for data subjects by means of web automation and a higher
order process automation language explicitly tailored to the specifics of
DSARs. In particular, we contribute:

  * •

a generalized data access process model covering manual, web-based and API-
driven DSAR implementations found in practice

  * •

a formalized data access request process automation language (DARPAL)
facilitating the automation of data access requests for said three cases
across a broad variety of service providers

  * •

a fully functional prototype of a browser-based runtime and a corresponding
process repository allowing for “one-click” data access request, and

  * •

an initial corpus of 15 provider-specific, automatically executable DARPAL
documents particularly including the most important large-scale service
providers and thereby demonstrating the practical viability of our approach.

These contributions unfold as follows: In sect. 2, we introduce relevant
background and related work from the legal and process perspective to DSARs as
well as on web automation in general. On this basis, we delineate our general
approach in sect. 3, develop our generalized process model in sect. 4, and
subsequently transfer it into our DARPAL language (sect. 5). Prototypical
implementations for the runtime and the process repository as well as the
initial corpus are presented in sect. 6, followed by a discussion and
conclusion (sect. 7).

##  2 Background & Related Work

Relevant background and related work regards the legal givens for DSARs and
respective challenges and shortcomings, real-world implementations of data
access processes, and web automation in general. These foundations shall be
briefly introduced before delineating our approach.

###  2.1 Right to Data Access

At the core of any modern privacy regulation is the right of data subjects to
know whether and, if so, what data about them is being processed and by what
means. This includes transparency information that can be obtained before the
data is processed (ex-ante transparency) [20, 21], for example through privacy
statements, as well as after the data has been processed (ex-post
transparency) [23]. One important part of ex-post transparency is the RtA,
which includes the right to obtain a copy of the personal data undergoing
processing.

Under the GDPR, for instance, the RtA is defined in Art. 15. Besides general
obligations addressing ex-ante transparency as defined in Art. 15(1), Art.
15(3) declares that data subjects have the right to receive, upon request, a
copy of all personal data relating to them and processed by a controller. In
the following, we will refer to a respective request as “ _data subject access
request (DSAR)_ ”. Closely related to the RtA is the right to data
portability, as codified in Art. 20 GDPR. It grants data subjects the right to
receive a copy of personal data they provided in a “ _structured, commonly
used and machine-readable format_ ”. Despite this difference of scope, service
providers often do not differentiate between data access and data portability
[10, p. 79f] and handle both with the same functionality and interfaces like
“checkout” dashboards or “archive downloads”. To avoid overly legalese
elaborations, we will thus not further distinguish between RtA and RtDP herein
but rather refer to them conjointly as RtA and to said interfaces as “ _RtA
endpoints_ ”.

As for the practical implementation of such data access, various challenges
have been identified, ranging from controllers not fulfilling their
obligations in matters of data completeness [3, 9, 30] or response time111The
controller has to fulfill the request without delay, but no later than within
30 days that might even be extended up to 60 days, if the data subject is
informed about the delay in the first 30 days (Art. 12 (3) GDPR). [9, 25, 39]
over a lack of authentication processes, enabling the unauthorized access to
personal data [10, 11, 15], to incomprehensible responses [9, 30, 40]. Last
but not least, data subjects often have difficulties locating the RtA endpoint
[35]. Altogether, this severely hinders the execution of the RtA, raising the
question of how the process of executing data requests can be streamlined and
made more accessible.

###  2.2 Data Access Process

From a data subjects perspective, the execution of a DSAR is composed of two
sub-processes: the actual data access process (which we will refer to as DAP),
and the privacy enactment, which covers all subsequent activities building
upon the data retrieved through the DAP, such as data mapping, visualization,
exploration, or (collective) decisionmaking [3, 30, 40]. However, these
enactment activities are rather subject to socio-technical and human-computer-
interface research and shall therefore be considered out of scope herein.
Real-world implementations of DAPs, in turn, can be categorized into one of
the following three distinct approaches:

Manual DAPs require data subjects to identify the responsible data protection
officer and make a written (mail, e-mail) or oral (e.g., phone call) request
to get a copy of the data, which may either be received via e-mail or as a
printed copy [9, 35, 39]. From the perspective of a data subject, these manual
processes cannot be automated, except from using text generation tools that
assist in formulating proper request texts.222Examples of such DAP specific
text generators are datenanfragen.de or mydatadoneright.eu.

Web-based DAPs, in turn, use a web form as RtA endpoint. In this process, the
data subject needs to identify the URL of the form, fill in the form fields
and submit the request form.333Instructions for such processes can for example
be found at justgetmydata.com. The subsequent communication is usually handled
via e-mail, allowing for a download of the retrieved data [39]. Such a web-
based process is somewhat more automated than a manual process, nonetheless,
it offers even more automation potential.

Finally, API-based DAPs are characterized by enabling third-party tools to
handle authentication, configuration, and request through, e.g., a
(standardized) API as proposed in [22], privacy dashboards [37], or personal
information management systems (PIMS) [24]. Basically, this approach can
facilitate tools that fully automate the RtA on the data subject side.444An
API-based DAP is followed, e.g., by the aeon prototype (aeon.technology) that
integrates a few big service providers. However, such processes are, in
practice, rarely implemented [10, 39, 35].

###  2.3 Web Automation

As there are many repetitive tasks to handle in the daily interaction with
websites, approaches to automate those tasks have been widely discussed [8,
13, 29], culminating in the research area of web automation. Web automation
tools can be applied for different purposes and audiences: from allowing
developers to automatically test web pages [31, 38], over business use-cases
involving abstractions of manual work [4, 29], to improved accessibility, e.g.
for visually-impaired users [7, 36]. The to-be-automated tasks and
corresponding actions are wrapped in a so-called macro [13]. In general, two
approaches for generating macros can be distinguished: declaring a sequence of
actions (sometimes referred to as handcrafting [36]), like, e.g., used in
Chickenfoot [8], and programming by demonstration (PBD) [6, 13, 29]. The
latter approach is more attractive for end-users, like the data subjects in
the RtA process, because it requires less [28] or even no programming
knowledge at all [6]. Therefore, we concentrate on PBD, which can be executed
in two steps: first, a list of tasks needs to be identified, and then these
tasks are automated by using record and replay techniques [12]. Those tasks
can either be reconstructed by observing user actions [12, 28] or application
states [13, 26].

Above-mentioned traditional PBD mainly addresses single page applications,
however, in modern web applications, the to-be-automated tasks might be
distributed across web pages. For that specific case, an intersection with AI-
enabled robotic process automation (RPA) [27, 1] can be identified, resulting
in the research field of web RPA [2, 16].

##  3 Proposed Approach

As identified in sect. 2.1, current real-world implementations of the RtA
broadly lead to data subjects not being able to or abstaining from actually
exerting it. There is thus a significant need for improving the prevailing
status quo of data access. Given their broad use in practice (especially by
large-scale service providers) and their already semi-automated nature, we
here see particular potential in the automation of web-based DAPs. More
specifically, the primary goal behind the work presented herein is to automate
the request-parts of DAPs, which are the necessary basis for subsequent data
checkouts (for a more detailed analysis of the DAP, see sect. 4 below) and to
thereby make them more accessible and less obstructive for data subjects. In
addition, albeit less focused on herein, we also want to pave the way for
technically supported DAPs for manual and API-driven approaches across highly
variable and provider-specific interfaces.

In a first step, we propose a generalized process model for DAPs that covers
manual, web-based, and API-driven DAPs and a broad variety of respective real-
world implementations. In particular, this model distinguishes between the
sub-processes for submitting a request (data request process, _DRP_) and for
checking out the personal data after provision (data checkout process, _DCP_).
Of these, we thenceforth primarily focus on the DRP (see above).

Building upon that process model, we introduce a formal language called DARPAL
allowing to represent provider-specific, heterogeneous DRPs – which we refer
to as provider-specific _DRP specifications_ herein – in a unified,
formalized, and to-be-executed form. To fulfill the primary goal, such a
representation must comprise all automation-relevant parameters, such as the
specific RtA endpoint or the to-be-automated workflow itself, as well as the
parameters available for customizing the data to be retrieved. In addition,
the language shall be defined in such a way that it also covers manual and
API-driven approaches to facilitate later extensions in line with the
secondary goal.

Based on this language, we aim to make respective provider-specific DRP
specifications automatically executable on the data subject side without any
intermediary party being involved in the actual DRP execution. In addition,
actually executing such DRPs should be as accessible and easy-to-use as
possible for data subjects. Employing modern techniques of web automation, we
thus strive to provide a browser-based execution engine particularly tailored
to the specific givens of DRPs that automates respective requests as far as
possible using the parameters provided in a DRP specification. Last but not
least, we also aim to make DRP specifications codified in our formal language
publicly available and accessible in an extensible process repository and to
pre-fill this repository with a base corpus of formalized DRP specifications
for broadly used service providers, especially including GAFA555GAFA
represents the four tech-companies Google, Apple, Facebook, and Amazon..

Together, these components – language, browser-based execution engine, process
repository, and base corpus – shall then provide the necessary basis for “one-
click” DRPs. At the same time, successfully automating DRPs for a substantial
number of service providers also validates the suitability of our generalized
process model and our formal language. All these components shall thus be
elaborated on in more detail below.

##  4 Modeling Data Access Processes

Data subjects wishing to exercise their RtA are following a data access
process (DAP), a generalized depiction of which is given in fig. 1. In
general, the DAP can be simplified as a sequential process that can be divided
into two sub-processes [35], which we denote data request process (DRP) and
data checkout process (DCP), and that can be delineated as follows:

Figure 1: Generic data access process

Data Request Process (DRP): To initiate a DRP, a data subject first has to
identify and navigate to the controller-specific RtA endpoint. Secondly, some
providers require providing further request parameters, e.g., a specific time
frame that should be contained in the retrieved data, while others are
satisfied by the statement that data access is requested. Afterwards, the
request can be sent. Of particular interest to reach our primary goal are web-
based DRPs, which can be refined as depicted in fig. 2. Within this approach,
the RtA endpoint is represented as a web-page or -form, and also the
customization is made via a web-form. In most cases, the web form is only
available for authenticated users, so sometimes further authentication
processes are dismissed, but in other cases, there are (multiple)
authentication steps in place [14].

Figure 2: Model of a web-based DRP

Even though these steps seem to be quite easy to handle, in reality, the DRP
is quite complicated. For instance, it has been empirically shown that even
the very first step is far from straightforward for data subjects, who already
struggled in identifying the correct RtA endpoint [3]. This is due to the fact
that RtA endpoint addresses are either wrapped in lengthy privacy policies or
are de-coupled from the main service experience, e.g., a web form is only
accessible via privacy settings hidden in some menu [35]. Additionally, the
request parameters to be provided can be complex and hard to understand. For
example, a non-technical data subject can hardly judge which data format
should be used for the download [35].

Data Checkout Process (DCP): After the request was successfully made (and,
thus, the DRP completed), the DCP starts with a waiting period, the duration
of which can range from a few seconds (e.g., Google Takeout) up to the legally
specified maximum of 30 days. During this period, the service provider
processes the request and creates the response.666Respective provider-side
processes are considered out of scope herein. Then, some service providers
send the compiled data directly to the data subject, while others send a
notification that it is available for download [9]. Finally, the data subject
can access and save a copy of the data. Within the DCP, clarification can be
required [35] at various stages, arising from both the service provider (see,
e.g., [5]) and the data subject side, especially when above-mentioned
challenges with the RtA emerge.

Authentication: Throughout the whole DAP, multiple authentication steps might
be required, which can vary from weak evidence like giving the full name of
the data subject [14], logging into a user account or a verified mail account
[25], to proving the identity with an ID-card [9]. Again, data subjects often
fail in the authentication steps (or are at least demotivated from
proceeding), especially since some authentication processes require multiple
clarification messages between the data subject and the service provider,
ultimately leading to a DAP not being completed successfully [35]. However,
Joris et al. [25] found that only a fraction of service providers included in
their study had implemented at least one identification measure. This can lead
to an abuse of the RtA, as already mentioned above.

End of Process: After the DCP has successfully finished, the enactment phase
can be started. In some cases, feedback to the service provider is required,
especially if the received data is incomplete. This may lead to a renewed DCP.
Furthermore, the process can also end with an error [35]. Data subjects abort
the process at various points because they no longer know what to do [9] or
because the service provider does not respond (in time) or refuses to process
the request [39].

##  5 DARPAL: Process Automation Language

Based on the general process depicted above, we now define a formal automation
language specifically tailored to the domain of DRPs. Our _data access request
process automation language (DARPAL)_ is provided as JSON Schema specification
and pays regard to the particularities of DRPs as follows:

First, DARPAL allows specifying the requestInterface, reflecting the RtA
endpoint from section 2.1 above, in a way that covers as many real-world DRP-
implementations as possible. In the light of the different DAP categories to
be found in practice and their specifics (see section 2.2), DARPAL thus allows
to specify different request interface attributes for manual, web-based, and
api-based DRPs. For each of these cases, it must be specified whether it is
available and the respective means of authentication (e.g. “password” or “id-
card”) can be specified. Besides this, the definition of the request interface
attributes varies between said three cases: In case of a manual process, the
interface is an $address$, $email$, or $phone$ number, while for web-based
DRPs it is the $startUrl$ of the request form and for APIs it is the
$endpointUrl$ and possibly an additional set of $apiParameters$.

For web-based request interfaces – which we consider the primary target for
automating DRPs herein – a generic second-level field $workflowContainer$ is
introduced. It is of type object and has the sub-fields $automationEngine$,
$workflow$, $version$, and $verified$. We decided to provide a generic
solution allowing for different automation engines to be used for executing
the ultimate workflow. Therefore we need to reference the automation engine.
The workflow itself is also an array of objects specific to the respective
automation engine. These objects are not subject to further constraints
(except for being a JSON object), because they are of an engine-specific
format. The fields $version$ and $verified$, in turn, serve secondary purposes
that shall not be discussed in more detail here.

Table 1: First and second-level building blocks of DARPAL. Mandatory elements are denoted by a *. meta |  |  |  | requestInterface |
---|---|---|---|---|---
name* |  |  |  | manual |
version* |  |  |  |  | available*
_hash* |  |  |  |  | address
|  |  |  |  | email
requestParameter |  |  |  |  | phone
timeRange* |  |  |  |  | authentication
| allTime* |  |  | webinterface |
| customRange* |  |  |  | available*
mediaQuality |  |  |  |  | startUrl
dataFormat* |  |  |  |  | authentication
additionalProperties |  |  |  |  | workflowContainer
|  |  |  | api |
|  |  |  |  | available*
|  |  |  |  | endpoint
|  |  |  |  | authentication
|  |  |  |  | apiParameters

Besides the so-structured requestInterface definition, the second concept that
needs to be reflected by DARPAL are request parameters, which refine the
content of the copy that is to be requested. For example, Facebook has a
“download your information” page for logged-in users with a request form that
has many options regarding the file format and content of the DSAR, while
LinkedIn has a web form where authenticated users have the choice between
requesting a full copy or selected general information blocks. Given that
these parameters become relevant independently from the automation level of
the interface (e.g., the file format can be of relevance for manual DRPs as
well), they are specified in a separate requestParameter section.

Following our model depicted in fig. 2, we allow for the fields $timeRange$,
describing the period for which the copy is created, $dataFormat$, describing
the file type of the copy, $mediaQuality$, describing the preferred quality of
media files within the copy, and $categories$ if only specific types of
personal data shall be included in the copy. Service-specific other fields can
be provided via the $additionalProperties$ field. For example, Linkedin allows
to select special $categories$ of personal data that shall be requested.

For identifying provider-specific DARPAL documents, we additionally need to
provide meta information in a third DARPAL section. These meta-information
especially include the name of the service provider the document refers to, as
well as information about the version and a hash of the document. Together,
these three sections make up the DARPAL document structure depicted in table
1. Additionally, there are some fields that are required for document
identification, however, they have no further semantic meaning and are
therefore not elaborated here. The respective JSON-Schema definition also
providing more details on field formats / data types etc. is available
online.777github.com/DaSKITA/darpal

##  6 Prototypical Implementation

To make DRPs as accessible as possible, we implemented the _“data access
request assistant (DARA)”_ system, consisting of a process repository
component pre-filled with 15 real-world DARPAL
specifications888github.com/DaSKITA/darpal-documents, an automation engine in
the form of a publicly available browser extension and a user interface,
altogether providing fully functional “one-click” DRPs. A general overview can
be found in fig. 3. Each of these components shall be elaborated on in more
detail below.

Figure 3: Architecture of the DARA system

Process Repository: The storage and processing of the available DRP
specifications is done in a separate process repository, which we refer to as
DARA API999github.com/DaSKITA/dara-api. In addition to providing automation
engines with the necessary DRP specifications, the process repository is also
conceptualized (but not yet implemented) to handle quality assurance and
lifecycle management of the stored DARPAL documents101010For instance,
statistics on successful and failed local workflow executions shall in future
versions be reported back to the repository. With this data, likely outdated
and dysfunctional workflows could be marked respectively.. It was realized as
Python-based REST-API via FastAPI. For each covered service provider, it
offers a separate endpoint with GET, POST and DELETE routes.

Currently, the DARA API includes a base corpus of 15 DARPAL specifications,
describing the DRPs of broadly used service providers. These are retrieved and
employed by both, the DARA extension and the DARA frontend. The workflows
within the specifications are enriched with signals reporting the status of
the DAP to the frontend. For example, we send a “started execution” event to
the execution environment for proper handling as soon as the provider’s DRP
page was loaded successfully and no redirection to a login portal occurred.
Statistics collection and crowdsourcing functionalities were not yet
implemented in the current prototype, however, they are planned for future
versions.

Browser Extension: For our prototype, we chose an approach based on a browser
extension because of the accessible and cross-platform installation procedure
through the browsers’ extension stores. To execute the DRP in the user’s
browser, we built the DARA extension111111github.com/DaSKITA/dara-extension
based on the Automa 121212www.automa.site project. The Automa automation
engine uses a simple block-based user interface to build browser workflows. We
configured Automa to include a content-script in our frontend, which listens
for user commands like the execution of a particular DRP or, respectively, the
workflow it includes.

When an automated DRP is triggered, either directly via the extension or via
the frontend, the DARA extension executes it in a new browser tab, which is
automatically opened in the background. After successful execution, this tab
is closed and a “success” signal is sent to the frontend. However, if the
execution fails or takes longer than expected, an “interaction required”
signal is sent, and the user can switch to the background tab. To additionally
enable non-technical users to add or update (individual, local) DRP
specifications, we build upon the workflow recording functionality of Automa.
We modified the recording functionality so that per default, XPath is used to
select HTML elements, as in our experience XPath provided a more stable
selector than using CSS classes.

Frontend: Via a dashboard131313github.com/DaSKITA/dara-frontend, the user is
first asked to install the DARA extension. Afterwards, the user assesses the
DRP specifications available via the DARA API and selects the service provider
for which a DRP shall be executed. While executing a DRP in a non-active tab
through the web extension, the user is informed about the execution state and
in case manual interaction is required, the option to switch to the browser-
tab in question is displayed. Currently, the frontend is available in German,
with further languages to be added soon.

Preliminary User Study: In a preliminary pre-study, we asked 14 users (not
familiar with our implementation before) to request their data from two of the
fifteen service providers we provide DARPAL specifications for. For the first
chosen service, the users had to follow the DRP without the use of our
prototype or any other instructions. It took them on average 4.3 minutes to
finish the DRP. 29% of the users were not able to successfully send a request
at all. Overall, only half of the user group considered executing their RtA
again. The second service was requested using our prototype. The users chose
to send a request to Amazon, Apple, Google, Instagram, LinkedIn, and Vinted.
In all cases, it took them less than two minutes to complete the request (with
an average of one minute), and 86% of the users stated they are willing to
repeat the process on a regular basis, with the same and other service
providers.

Even though being of highly preliminary nature and hardly generalizable so
far, these results are definitely encouraging and at least support the basic
viability of our approach. Following up on the more technical groundwork
presented herein, a more in-depth user study is planned in the near future.

##  7 Discussion & Conclusion

With our contributions as a whole, we provide significant improvements for
data subjects exercising their RtA. Formerly tedious web-based data requests
are condensed into automated “one-click” DRPs. Still, the approach pursued
herein carries inherent needs for creating a multitude of provider-specific
DARPAL documents separately. Our prototype partially tackles this problem with
a dedicated recording function. Still, service providers immensely obfuscate
their page sources, perform random changes to the document object model, or
follow other strategies preventing effective web automation. Future versions
of our prototype aim to counteract this problem with crowdsourcing features.
Nonetheless, such options also include abuse potentials (spamming, security
and trust issues etc.). Thwarting these remains a nontrivial challenge.
Perspectively, DRP automation could substantially profit from documented APIs,
which unfortunately exist far too rarely so far. We, thus, emphasize the
regulatory need for documented APIs [18], optimally with queryable metadata
according to Art. 15(1) GDPR.

Further developments in DARPAL could include a generic process representation,
which could then be consumed by different automation engines and translated
into their specific representation before execution. For the moment, however,
we used Automa as the mere engine and workflow format and did not run into
relevant limitations. For greater interoperability, however, others should be
supported as well.

We encourage data subjects to request their data from as many services as
possible. However, we solely addressed the DRP herein, while the DCP and
enactment processes are not yet included. Still, they are very important to
make access requests useful. In particular, the received data packages need to
be prepared for actual interpretation, summary, risk identification, or
visualization. Only with such data post-processing, data subjects can actually
make sovereign evaluations and decisions regarding their usage and the
processing activities of a service offering [40]. Respective functionalities
are natural candidates for extending our solution further in the future. This
would also be in line with requests from two of our study participants
explicitly asking for data retrieval and analysis support to also be provided.
Still, our approach shall serve as stable ground for respective upcoming work
dealing with the actual data presentation tasks needed for a meaningful
enactment stage.

Another promising next step for fostering the RtA across platforms is to
extend the scope from webpage-based services to, e.g., native mobile apps (for
instance through deep-linking). Similarly, our system could also be integrated
with Personal Information Management Systems (PIMS) or Personal Data Stores
(PDS) [24]. These aim to manage granular data access based on, among others,
purpose-specific consent provisions for selected categories of personal data.
Our contributions can be used to import such data, possibly also to perform
data transfers in the vein of the RtDP.

Altogether, the contributions presented herein thus provide a solid ground for
much more structured, automated, and sovereign DRPs, illustrating that and how
web automation can fill a gap left open by existing regulations. This can not
only have an instant effect on the actual exercise of the RtA, but also pave
the way for a broad variety of future research endeavors in the context of the
RtA, the RtDP, and technically mediated ex-post transparency in general.

####  7.0.1 Acknowledgements.

We thank our students Majed Idilbi, Christopher Liebig, Ann-Sophie
Messerschmid, Moriel Pevzner, Dominic Strempel, and Kjell Lillie-Stolze, who
contributed to the initial proof-of-concept within the scope of a study
project [19]. Special thanks go to Johanna Washington, who kindly supported us
to conduct the user experiment.

The work behind this paper was partially conducted within the project DaSKITA,
supported under grant no. 28V2307A19 by funds of the Federal Ministry for the
Environment, Nature Conservation, Nuclear Safety and Consumer Protection
(BMUV) based on a decision of the Parliament of the Federal Republic of
Germany via the Federal Office for Agriculture and Food (BLE) under the
innovation support program.

## References

  * [1] van der Aalst, W.M.P., Bichler, M., Heinzl, A.: Robotic process automation. Business & Information Systems Engineering 60(4), 269–272 (2018-08-01). https://doi.org/10.1007/s12599-018-0542-4
  * [2] Agostinelli, S., Lupia, M., Marrella, A., Mecella, M.: Automated generation of executable rpa scripts from user interface logs. In: Business Process Management: Blockchain and Robotic Process Automation Forum: BPM 2020 Blockchain and RPA Forum, Seville, Spain, September 13–18, 2020, Proceedings 18\. pp. 116–131. Springer (2020)
  * [3] Alizadeh, F., Jakobi, T., Boden, A., Stevens, G., Boldt, J.: GDPR reality check - claiming and investigating personally identifiable data from companies. In: 2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). pp. 120–129 (2020). https://doi.org/10.1109/EuroSPW51379.2020.00025
  * [4] Amershi, S., Mahmud, J., Nichols, J., Lau, T., Ruiz, G.A.: LiveAction: Automating web task model generation. ACM Transactions on Interactive Intelligent Systems 3(3), 1–23 (2013). https://doi.org/10.1145/2533670.2533672
  * [5] Ausloos, J., Dewitte, P.: Shattering one-way mirrors – data subject access rights in practice. International Data Privacy Law 8(1), 4–28 (2018). https://doi.org/10.1093/idpl/ipy001
  * [6] Barman, S., Chasins, S., Bodik, R., Gulwani, S.: Ringer: web automation by demonstration. In: Proceedings of the 2016 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications. pp. 748–764. OOPSLA 2016, Association for Computing Machinery (2016). https://doi.org/10.1145/2983990.2984020
  * [7] Bigham, J.P., Lau, T., Nichols, J.: Trailblazer: enabling blind users to blaze trails through the web. In: Proceedings of the 14th international conference on Intelligent user interfaces. pp. 177–186 (2009)
  * [8] Bolin, M., Webber, M., Rha, P., Wilson, T., Miller, R.C.: Automation and customization of rendered web pages. In: Proceedings of the 18th Annual ACM Symposium on User Interface Software and Technology. p. 163–172. UIST ’05, Association for Computing Machinery, New York, NY, USA (2005). https://doi.org/10.1145/1095034.1095062
  * [9] Bowyer, A., Holt, J., Go Jefferies, J., Wilson, R., Kirk, D., David Smeddinck, J.: Human-GDPR interaction: Practical experiences of accessing personal data. In: Proceedings of the 2022 CHI Conference on Human Factors in Computing Systems. pp. 1–19. CHI ’22, Association for Computing Machinery (2022). https://doi.org/10.1145/3491102.3501947
  * [10] Bufalieri, L., Morgia, M.L., Mei, A., Stefa, J.: GDPR: When the right to access personal data becomes a threat. In: 2020 IEEE International Conference on Web Services (ICWS). pp. 75–83 (2020). https://doi.org/10.1109/ICWS49710.2020.00017
  * [11] Cagnazzo, M., Holz, T., Pohlmann, N.: Gdpirated–stealing personal information on-and offline. In: Computer Security–ESORICS 2019: 24th European Symposium on Research in Computer Security, Luxembourg, September 23–27, 2019, Proceedings, Part II 24. pp. 367–386. Springer (2019)
  * [12] Chasins, S., Barman, S., Bodik, R., Gulwani, S.: Browser Record and Replay as a Building Block for End-User Web Automation Tools. In: Proceedings of the 24th International Conference on World Wide Web. pp. 179–182. WWW ’15 Companion, Association for Computing Machinery, New York, NY, USA (May 2015). https://doi.org/10.1145/2740908.2742849
  * [13] Cypher, A., Halbert, D.C.: Watch what I do: programming by demonstration. MIT press (1993)
  * [14] Di Martino, M., Meers, I., Quax, P., Andries, K., Lamotte, W.: Revisiting identification issues in GDPR ‘right of access’ policies: a technical and longitudinal analysis. Proceedings on Privacy Enhancing Technologies 2022(2), 95–113 (2022)
  * [15] Di Martino, M., Robyns, P., Weyts, W., Quax, P., Lamotte, W., Andries, K.: Personal information leakage by abusing the GDPR ’right of access’. In: Fifteenth Symposium on Usable Privacy and Security (SOUPS 2019). pp. 371–385. USENIX (2019)
  * [16] Dong, R., Huang, Z., Lam, I.I., Chen, Y., Wang, X.: WebRobot: web robotic process automation using interactive programming-by-demonstration. In: Proceedings of the 43rd ACM SIGPLAN International Conference on Programming Language Design and Implementation. pp. 152–167. PLDI 2022, Association for Computing Machinery (2022). https://doi.org/10.1145/3519939.3523711
  * [17] Fialová, E.: Data portability and informational self-determination. Masaryk University Journal of Law and Technology 8(1), 45–55 (2014)
  * [18] Gill, D., Metzger, J.: Data access through data portability. European Data Protection Law Review 8(2), 221–237 (2022)
  * [19] Grünewald, E., Pallas, F.: Datensouveränität für Verbraucher:innen: Technische Ansätze durch KI-basierte Transparenz und Auskunft im Kontext der DSGVO. pp. 1 – 17. Alexander Boden, Timo Jakobi, Gunnar Stevens, Christian Bala (Hgg.): Verbraucherdatenschutz - Technik und Regulation zur Unterstützung des Individuums (2021). https://doi.org/10.18418/978-3-96043-095-7_02
  * [20] Grünewald, E., Pallas, F.: TILT: A GDPR-aligned transparency information language and toolkit for practical privacy engineering. In: Proceedings of the 2021 Conference on Fairness, Accountability, and Transparency. FAccT ’21, Association for Computing Machinery, New York, NY, USA (2021). https://doi.org/10.1145/3442188.3445925
  * [21] Grünewald, E., Wille, P., Pallas, F., Borges, M.C., Ulbricht, M.R.: TIRA: An OpenAPI extension and toolbox for GDPR transparency in RESTful architectures. In: 2021 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE Computer Society (2021)
  * [22] Hansen, M., Jensen, M.: A generic data model for implementing right of access requests. In: Gryszczyńska, A., Polański, P., Gruschka, N., Rannenberg, K., Adamczyk, M. (eds.) Privacy Technologies and Policy. pp. 3–22. Lecture Notes in Computer Science, Springer (2022). https://doi.org/10.1007/978-3-031-07315-11
  * [23] Hildebrandt, M.: Behavioural biometric profiling and transparancy enhancing tools. Fidis Deliverable 7.12 (2009). https://doi.org/10.13140/RG.2.2.21363.32808
  * [24] Janssen, H., Cobbe, J., Singh, J.: Personal information management systems: a user-centric privacy utopia? Published in Internet Policy Review (18 December 2020) 9(4), 1–25 (2020)
  * [25] Joris, G., Mechant, P., De Marez, L.: Exercising the right of access: a benchmark for future GDPR evaluations. In: 70th Annual ICA Conference : Open Communication, Proceedings (2020)
  * [26] Lau, T., Wolfman, S.A., Domingos, P., Weld, D.S.: Programming by demonstration using version space algebra. Machine Learning 53, 111–156 (2003)
  * [27] Leno, V., Dumas, M., Maggi, F.M., La Rosa, M.: Multi-perspective process model discovery for robotic process automation. In: Proceedings of the Doctoral Consortium Papers Presented at the 30th International Conference on Advanced Information Systems Engineering (CAiSE). vol. 2114, pp. 37–45. CEUR-WS (2018)
  * [28] Leshed, G., Haber, E.M., Matthews, T., Lau, T.: Coscripter: Automating & sharing how-to knowledge in the enterprise. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. p. 1719–1728. CHI ’08, Association for Computing Machinery, New York, NY, USA (2008). https://doi.org/10.1145/1357054.1357323
  * [29] Little, G., Lau, T.A., Cypher, A., Lin, J., Haber, E.M., Kandogan, E.: Koala: Capture, share, automate, personalize business processes on the web. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. p. 943–946. CHI ’07, Association for Computing Machinery, New York, NY, USA (2007). https://doi.org/10.1145/1240624.1240767
  * [30] Mahieu, R., Asghari, H., van Eeten, M.: Collectively exercising the right of access: individual effort, societal effect. Internet Policy Review 7(3) (2018)
  * [31] Mickens, J., Elson, J., Howell, J.: Mugshot: Deterministic capture and replay for javascript applications. In: Proceedings of the 7th USENIX Conference on Networked Systems Design and Implementation. p. 11. USENIX Association (2010)
  * [32] Murmann, P., Fischer-Hübner, S.: Tools for achieving usable ex post transparency: a survey. IEEE Access 5, 22965–22991 (2017)
  * [33] Pallas, F., Hartmann, D., Heinrich, P., Kipke, J., Grünewald, E.: Configurable per-query data minimization for privacy-compliant web APIs. In: Proceedings of the 2022 ICWE International Conference on Web Engineering, Bari (2022). https://doi.org/10.1007/978-3-031-09917-522
  * [34] Pallas, F., Ulbricht, M.R., Tai, S., Peikert, T., Reppenhagen, M., Wenzel, D., Wille, P., Wolf, K.: Towards application-layer purpose-based access control. In: Proceedings of the 35th Annual ACM Symposium on Applied Computing. pp. 1288–1296 (2020)
  * [35] Petelka, J., Oreglia, E., Finn, M., Srinivasan, J.: Generating practices: Investigations into the double embedding of GDPR and data access policies. Proceedings of the ACM on Human-Computer Interaction 6(CSCW2), 1–26 (2022)
  * [36] Puzis, Y., Borodin, Y., Puzis, R., Ramakrishnan, I.: Predictive web automation assistant for people with vision impairments. In: Proceedings of the 22nd international conference on World Wide Web. pp. 1031–1040 (2013)
  * [37] Schufrin, M., Reynolds, S.L., Kuijper, A., Kohlhammer, J.: A visualization interface to improve the transparency of collected personal data on the internet. IEEE Transactions on Visualization and Computer Graphics 27(2), 1840–1849 (2021). https://doi.org/10.1109/TVCG.2020.3028946
  * [38] Sharma, M., Angmo, R.: Web based automation testing and tools. International Journal of Computer Science and Information Technologies 5(1), 908–912 (2014)
  * [39] Urban, T., Tatang, D., Degeling, M., Holz, T., Pohlmann, N.: A study on subject data access in online advertising after the GDPR. In: Pérez-Solà, C., Navarro-Arribas, G., Biryukov, A., Garcia-Alfaro, J. (eds.) Data Privacy Management, Cryptocurrencies and Blockchain Technology. pp. 61–79. Lecture Notes in Computer Science, Springer (2019). https://doi.org/10.1007/978-3-030-31500-95
  * [40] Veys, S., Serrano, D., Stamos, M., Herman, M., Reitinger, N., Mazurek, M.L., Ur, B.: Pursuing usable and useful data downloads under GDPR/CCPA access rights via co-design. In: SOUPS @ USENIX Security Symposium (2021)