A Conceptual Consent Request Framework for Mobile Devices

Abstract

The General Data Protection Regulation (GDPR) identifies consent as one of the legal bases for personal data processing and requires that it should be freely given, specific, informed, unambiguous, understandable, and easily revocable. Unfortunately, current technical mechanisms for obtaining consent often do not comply with these requirements. The conceptual consent request framework for mobile devices that is presented in this paper, addresses this issue by following the GDPR requirements on consent and offering a unified user interface for mobile apps. The proposed conceptual framework is evaluated via the development of a City Explorer app with four consent request approaches (custom, functionality-based, app-based, and usage-based) integrated into it. The evaluation shows that the functionality-based consent, which was integrated into the City Explorer app, achieved the best evaluation results and the highest average system usability scale (SUS) score. The functionality-based consent also scored the highest number of SUS points among the four consent templates when evaluated separately from the app. Additionally, we discuss the framework’s reusability and its integration into other mobile apps of different contexts.

1. Introduction

The General Data Protection Regulation (GDPR), which came into force in 2018, defines, in Art.6(1)(a), consent as one of the legal bases for personal data processing. According to Art.4(11), consent should be a “freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her”. Unfortunately, the current technical solutions for obtaining consent often do not comply with the GDPR consent requirements [1]. For example, cookies are placed on users’ computers prior to obtaining consent, there is not enough information provided in order to fulfill the “informed” requirement of the GDPR, or there is no consent withdrawal mechanism.

In order to combat non-compliance with the GDPR, data protection authorities (DPAs) can impose fines (GDPR Art.83) or order corrective measures (GDPR Art.58(2)). Already there have been multiple cases concerning consent requests where DPAs fined companies or ordered them to change their consent request procedures because of a GDPR breach. For instance, “Family Service” was fined in 2021 by the Belgian DPA for transferring personal data to third parties without obtaining valid informed consent [2]. The Norwegian DPA concluded that the way “Smartere Utdanning AS” obtained consent for the data processing from the data subjects was not compliant with the GDPR and ordered them to improve their technical means for obtaining consent [3]. Thus, there is a clear need for guidelines and best practices in terms of consent request design and development.

When it comes to consent and privacy notice research, broadly speaking, privacy researchers have explored the conceptualization of consent and relevant dimensions thereof (c.f., [4]), the development of informative tools and technologies (c.f., [5]), or experimentation in order to better understand the effectiveness of consent requests and privacy notices (c.f., [6]). However, the focus to date has primarily been on web platforms with mobile apps receiving limited attention. Considering the prevalence of mobile devices, there is a need for dedicated research that explores how consent requests can be effectively implemented in mobile apps.

In order to address this gap, we propose a conceptual framework for Consent reqUests foR mobiLE Devices (CURLED), which follows the GDPR requirements on consent and offers a unified user interface (UI) for mobile apps. Even though our proposal is based on the GDPR requirements on consent, it can easily be adapted to cater to other jurisdictions and/or consent requirements specified in national data protection laws. Concretely we make the following contributions:

• We propose the CURLED conceptual framework, which incorporates four different consent request variations for mobile apps: custom, functionality-based, app-based, and usage-based;
• We demonstrate the applicability of the different consent mechanisms in a mobile setting by incorporating them into our City Explorer mobile app prototype; and
• We perform a comparative analysis of the effectiveness of the various consent requests by conducting a usability evaluation.

The remainder of the paper is structured as follows. First, we provide an overview of research concerning the consent request topic. Then we describe the methodology, the GDPR consent requirements, and the use case scenario that guided our research. Following on from this, we provide an overview of the proposed consent request approaches and our mobile app concept, and discuss the framework’s reusability. Thereafter, we present the usability evaluation results of the mobile app prototype. Finally, we present our conclusions and discuss future work.

2. Related Work

Existing work on consent for personal data processing can be divided into three main themes: (i) the categorization of consent or its dimensions, (ii) consent or privacy notices solutions and prototypes, and (iii) the evaluation of privacy notices and existing consent request mechanisms.

As for consent categorization, Steinsbekk et al. [4] identify five types of consent models, namely blanket consent (i.e., consent is given for all current and future purposes), broad consent (i.e., consent is granted for a limited set of current and future purposes), specific consent (i.e., consent is connected to a specific purpose), no consent (i.e., no processing is allowed), and dynamic consent (i.e., new consent is required for each new purpose). Maler [7] divides consent mechanisms into three main categories: opt-in (i.e., an individual takes an action to consent), opt-out (i.e., an individual gives passive consent by not revoking it), unconsented (i.e., when it is not possible to obtain consent or when consent is not needed). Schaub et al. [8] investigate the design of privacy notices and construct a privacy notice design space with four dimensions: timing (i.e., when the notice should be shown), channel (i.e., what medium is used to show the notice), modality (i.e., the ways of user interaction), and control (i.e., options to adjust consent).

In terms of proposed consent solutions, most of the papers focus on privacy policy visualizations. Costante et al. [5] propose a machine-learning solution to analyze privacy policies and deliver a structured version of them to users. Similarly, the cookie-watcher prototype [9] attempts to improve the understandability of cookie information but uses textual descriptions as in typical privacy policies. Kelley et al. [10] developed a privacy label in the style of a “nutrition label” that helps users find the information more quickly. Reeder et al. [11] visualized security policies, concerning permissions in the Windows operating system, with the help of the expandable grids. Railean and Reinhardt [12] propose some design improvements for consent requests in the form of privacy labels. Habib et al. [13] developed and tested icons to help users easily find privacy policies on websites. In addition to the privacy policy visualizations, there was an attempt to lift the burden of policy reading by introducing a Platform for Privacy Preferences (P3P) user agent [14] (P3P is a machine-readable format for the website privacy policies). When using this agent, users have to specify their privacy preferences once and the agent compares their preferences with the P3P website privacy policy and informs the user if they match. P3P was never widely adopted, which consequently hindered the adoption of the user agent. Jesus et al. [15] offer to provide users with a receipt after they have given their consent, which could improve the memorability of consent information. Drozd and Kirrane [16,17] designed and evaluated several alternative web application consent requests. In turn, obtaining consent on mobile devices is analyzed in the papers in terms of mobile app permissions [18,19].

The literature on consent and privacy notice evaluation points out the difficulty of privacy notice comprehension [6,20,21], the use of manipulative techniques or dark patterns to trick users into providing consent for more data processing [22,23,24], and non-compliance with the GDPR when it comes to website cookie consent requests [25,26,27,28,29].

As outlined above, existing research on consent mostly focuses on tools and technologies for the web as opposed to mobile apps where there is a need for different consent request approaches. Some literature touches upon consent for mobile devices in terms of mobile app permissions. However, contrary to app permissions, which provide only information about what access is required, consent requests should contain more detailed information about the intended data processing, which makes permission settings unsuitable for obtaining informed consent. To address this gap, we propose a conceptual consent request framework with a universal UI that follows the GDPR consent requirements and significantly advances the state of the art in terms of consent guidelines and best practices for mobile apps.

3. Methodology and Background

Before describing the consent request framework, its integration into our mobile app prototype, and its usability evaluation, we provide details with respect to the overarching methodology, the necessary background concerning the GDPR consent request requirements, and the use case used to guide our work.

3.1. Methodology

We selected the Design Science Research (DSR) [30] methodology as the overarching methodology for the development and evaluation of the consent request framework and the corresponding prototypes. The research problem identification is the DSR starting point that is followed by the reasoning for the solution necessity. The development of a research artifact begins after the goal specification. The results of the development are evaluated and all the stakeholders are informed about the evaluation outcome. The Action Research (AR) [31] methodology, which involves an iterative approach to artifact development, complemented the DSR by allowing for the progressive consent request framework refinements. AR starts with the identification of a problem that is subsequently resolved. Then, the solution is assessed and improved if the assessment results are unsatisfactory.

3.2. GDPR Consent Request Requirements

We defined the requirements for our consent request framework based on both the text of the GDPR relating to consent and its interpretation by the Working Party on the Protection of Individuals with regard to the Processing of Personal Data (also known as the Article 29 Working Party—a predecessor of the European Data Protection Board) in the Guidelines on consent under Regulation 2016/6791 [32] where the notion of consent (as defined by the GDPR) and its requirements are thoroughly analyzed and explained in detail. Our consent request framework complies with the following GDPR consent requirements: (i) Freely given—The consent request should provide real choice to the data subjects (GDPR Art.4(11), Art.7(4)); (ii) Specific—The consent request should be presented separately, tied to specific purposes, and provide separate opt-in for each purpose (GDPR Art.4(11)); (iii) Informed—The consent request should provide enough information for laypeople to understand personal data processing details and to make a choice (GDPR Art.4(11)); (iv) Unambiguous—The consent should be deliberately granted by the data subjects (GDPR Art.4(11)); (v) Understandable—The consent request should be formulated clearly and in plain language (GDPR Art.7(2)); (vi) Prior to the data processing—The data can be processed only after the consent has been granted (GDPR Art.6(1)); and (vii) Easily revocable—The data subjects should be able to withdraw their consent as easily as they granted it (GDPR Art.7(3)).

3.3. Exemplifying Use Case

To guide the development of our consent request framework and mobile app concepts, we used the following exemplifying use case scenario:

Eva and Peter, who moved to Vienna for work, want to adjust to the new city as easily as possible. They install all the relevant apps offered by the city of Vienna and are presented with the CURLED-based personal data processing consent request. Peter is a recent supporter of the citizen science concept and would like to contribute his data to improve the city of Vienna via its apps. Eva does not mind providing her data to have a better city but would rather agree to a consent request tailored to her needs based on app usage.

4. The Conceptual Consent Request Framework & The City Explorer App

In this section, we first present the CURLED conceptual framework. Following on from this, we describe our City Explorer app prototype and the integration of the CURLED-based consent requests into it. Finally, we discuss the CURLED framework’s reusability.

4.1. General CURLED Framework Concept

The general CURLED concept is designed based on the following mobile app usage flow. Upon installing the CURLED-based mobile app, users must decide whether they would like to provide consent for the app to process their data. Personal data are required for the app features to work correctly. If users do not want to use the app and select their consent, they proceed to uninstall the app and no longer interact with the system. If users decide to use the app, however, without their data being processed, they can choose the no-processing option. It permits users to use the application but substantially limits their ability to interact with most application components because only the basic functionality is available without personal data processing. If users want to use more advanced app features that involve personal data processing, they need to specify their consent for data processing. In our CURLED conceptual framework, we allow to select from the following consent request variations: (i) custom consent request; (ii) functionality-based consent request; (iii) app-based consent request; and (iv) usage-based consent request. These consent request variations are summarized in

Table 1. Summary of the consent request variations.

Consent Requests	Custom Consent Request	Functionality-Based Consent Request	App-Based Consent Request	Usage-Based Consent Request
Data processing options	No data processing	No data processing	No data processing	No data processing
	Not applicable	Basic functionality Enhanced functionality Maximum functionality	Improve your city Earn rewards Maximum benefits	Generation of user consent based on app usage.
	Custom consent request	Custom consent request	Custom consent request	Custom consent request

.

4.1.1. Custom Consent Request

With the custom consent, users can adjust the consent to their liking. It permits application usage; however, depending on the users’ consent compilation, it may limit their ability to interact with certain application components.

4.1.2. Functionality- and App-Based Consent Requests

Based on the app features, different purpose (i.e., app function) groupings could be arranged into various templates. The app owners identify how they can group purposes for data processing to offer users predefined consent combinations with, for example, gradually decreasing privacy levels. If users are presented with such a consent template but are not satisfied with the offered options, they are able to further customize their consent before app usage. For our use case, we identified two possible feature-based templates for consent requests: functionality-based and app-based consent requests. In the functionality-based template, the purposes are arranged into basic, enhanced, and maximum functionality groups, offering a gradually increasing number of working features in the app and, as a result, decreasing privacy levels for data processing. The app-based template arranges app features into groups depending on the app context. For example, if the app offers challenges with rewards for users and the personal data could be processed to improve the city’s infrastructure, the purposes could be organized into improve your city, earn rewards, and maximum benefits groups.

4.1.3. Usage-Based Consent Request

The usage-based consent allows users to enjoy a fully functional app for a specific time period. For that period, users have to consent to the data processing needed for all purposes. Once this time has elapsed, users are presented with the consent request generated based on their app usage. Users can either accept the generated usage-based consent or, alternatively, users can customize their consent settings.

Overall, the consent that users provide throughout their application usage determines how they are able to interact with the system. If the given consent is insufficient for a particular app feature, users can return to the consent settings in order to modify their selection accordingly.

4.2. City Explorer App Prototype

The general City Explorer app concept consists of four modules: info map, problem reporter, shop, and profile. The info map module aims to help users discover parks, restaurants, bicycle rental stations, and other points of interest in the city. As part of the map module, users can also submit reviews for these landmarks. The reporter module provides users with an interface to submit problems they encounter around the city. Both the info map and the reporter modules include a scoring system that rewards users with points based on their activity. The shop module allows users to “exchange” the points, they’ve earned through reviews and problem reporting, for tickets to various city museums. In addition to the above three core modules, the app provides an option for users to create a profile where they can identify themselves by their full name, add a profile picture, and input their address. Then, these personal data can be automatically prefilled in the app forms in the core modules to save users time. In order to assess the applicability of the CURLED conceptual framework, we first developed the low-fidelity wireframes, which roughly visualized the envisaged app design and its features, and then developed the fully functional City Explorer app prototype. For the development of the low-fidelity app wireframes, we extended the above general app concept by identifying all data and purposes for data processing as well as the dependencies among them and the proposed consent request variations.

In Figure 1, we show, as an example, the dependencies for the info map module of the City Explorer app concept. The data, the processing of which is required for this module, are depicted in red at the top. The red solid arrows pointing at these data show what data are needed for a corresponding purpose in blue in the middle.

We specify data processing for each purpose separately because, based on the Article 29 Working Party interpretation of the consent definition (GDPR Art.4(11)), consent should be tied to specific purposes. We also show that some purposes depend on other purposes and cannot work without them. The blue dotted arrows represent these interdependencies between purposes. For example, for users to review a location in the info map module (i.e., make use of the purpose “leave review and assign scores”), that location should be shown on a map (i.e., purpose “show on map location groups”) and since the app shows locations nearby, the map should show the user’s current location (i.e., purpose “show current location on map”) as well. The figure also illustrates (in green dashed arrows) the relations between consent options and purposes. For instance, the enhanced functionality consent option does not offer the “show activity statistics” app feature, which is offered only by the maximum functionality option in the info map module. With the black solid arrows pointing from the consent options, we show that the purposes of certain consent options are inherited by other consent options situated below them. In the example with the enhanced functionality consent option, the functionalities from the no processing and basic functionality options are inherited by the enhanced functionality consent and three new purposes are added to the inherited ones.

In order to identify usability issues at the beginning of the app and the consent request concept development, we conducted a heuristic evaluation [33] of the low-fidelity wireframes with five expert evaluators that had UI design and software development backgrounds. A heuristic evaluation is a usability engineering method “for finding usability problems in a user interface design by having a small set of evaluators examine the interface and judge its compliance with recognized usability principles” [34]. We made the wireframe evaluation more efficient and closer to the real app evaluation by organizing the wireframes into a dynamic low-fidelity wireframe app prototype (https://short.wu.ac.at/CEFigma) with the help of the Figma prototyping tool for the collaborative interface design.

The evaluators identified three major issues (e.g., there were no error prevention measures on some pages) and five minor issues (e.g., the titles were not at the same height), which were easily fixable. The issue severity was estimated according to the severity rating proposed by Jakob Nielsen [35] and the ease of fixing was assessed according to Olson’s ease of fixing rating [36].

The issues were addressed in the final City Explorer app prototype. The cross-platform (iOS/Android) source code of which, the video demo, and the installation package together with the installation instructions for smartphones with the Android Operating System, version 9 Pie or later, are available online at https://short.wu.ac.at/CESource, https://short.wu.ac.at/CEVideo, https://short.wu.ac.at/CEIntallation, and https://short.wu.ac.at/CEInstallationInstructions respectively.

4.3. CURLED-Based Consent Requests Applied to the City Explorer App

The City Explorer app was designed in a manner such that we could incorporate and evaluate all four CURLED-based consent requests (custom, functionality-based, app-based, and usage-based). Below, we describe these consent approaches, which have been integrated into the City Explorer app, in detail.

4.3.1. Custom Consent Request

The custom consent request, the screenshot of which is depicted in Figure 2a, presents users with a selection of sliders that can be used to provide consent for each application feature (i.e., data processing purpose). When using this consent request, users can scroll through and review the list of purposes and the corresponding data processing. If the users are interested in more details about the storage, processing, and sharing of their personal information for each purpose separately, they can tap on the information icon in the upper right corner of each purpose card. When the information icon is tapped, the detailed view of the data processing for the corresponding purpose slides up, as shown in Figure 2b.

4.3.2. Functionality-Based Consent Request

The functionality-based consent request allows users to agree to one of the following purpose combinations: basic functionality, enhanced functionality, and maximum functionality. The basic functionality combination offers basic app features and, at the same time, a high level of privacy, because only a small amount of personal data is needed in order to be able to offer those basic features. The enhanced functionality combination includes more app features; however, it requires more data to be processed and, as a result, offers a medium privacy level. The maximum functionality consent encompasses all app features. However, it provides the lowest privacy level, since for users to enjoy a fully functional app, the largest amount of data needs to be processed. Additionally, as per the GDPR requirements, users have an option not to agree to the data processing or create their own custom consent as described previously.

Figure 3a shows the screenshot of the purpose groupings list that the users can select from by tapping on the grouping card. Once the consent grouping is selected, the list of purposes with the corresponding required data that belong to the selected grouping can be reviewed by the user. The consent, in this case, is granted by tapping on the “I Agree” button. The screenshot in Figure 3b shows a part of such a list of purposes. Detailed information about the data processing that is required for a specific purpose (see Figure 3c) is available by tapping the information icon.

4.3.3. App-Based Consent Request

The app-based consent request provides users with consent combinations tailored to the app context. Every app provider can identify the benefits of their app and group app features based on those benefits. In the case of the City Explorer app, in addition to the already standard no data processing, custom functionality, and full functionality (that is called maximum benefits in our case), we identified features that can be grouped into the “improve your city” and “earn rewards” categories. The “improve your city” group is suitable, for example, for the supporters of the citizen science concept and helps them contribute to city improvement. The “earn rewards” category consists of all purposes that allow users to earn points for app usage and exchange them for tickets.

As can be seen in the screenshot presented in Figure 4a, the design of the app-based consent request coincides with the design of the consent request approaches described above. Each feature group lists its purposes, as shown in Figure 4b, while Figure 4c depicts an example of how we provide the details of the data processing for each purpose. Similar to the functionality-based consent request, the feature group is selected by tapping on the group card, and the consent is granted by tapping on the “I Agree” button after the review of the corresponding purpose list with the required data. A detailed overview of the data processing is available upon demand.

4.3.4. Usage-Based Consent Request

The usage-based consent request provides users with the possibility of generating their consent based on their app usage if they select the “personalized functionality” option (see Figure 5a). Upon tapping on the “personalized functionality” card, users are asked to review and accept all data processing for a short period of time for the app to learn what functionalities are regularly used. When the application obtains this information, consent is automatically generated for users based on their app usage patterns, and users are presented with personalized consent tailored to their needs. An example of such a generated consent request is shown in Figure 5b. As per our other consent request approaches, which follow the GDPR requirements on consent, users also have an option not to agree to the data processing (i.e., select the “no data processing” option), as well as to compile their own set of active app functionalities (i.e., select the “custom functionality” option). The usage-based consent request also provides detailed information about data processing for each purpose (see Figure 5c).

4.4. CURLED Conceptual Framework Reusability

The CURLED conceptual framework can be implemented in mobile apps with different contexts.

4.4.1. Consent Content Compilation

The approach that was applied for the content compilation of the City Explorer app consent request can be reused to compile the consent requests content for various mobile app contexts. The approach consists of the following steps:

• Identification of all purposes for data processing based on the app concept.
• Definition of the data, the processing of which, is needed for each purpose.
• Identification of the required data processing.
• Specification of the interdependencies among purposes.
• Selection of a suitable consent request approach, from the ones presented in Section 4.3, based on the information received from the previous steps.
• Where necessary, definition of the inheritance relations among purposes that belong to certain consent options of the selected consent request approach.

4.4.2. Application Programming Interface for Consent Requests

In order to facilitate the ease of use of the CURLED conceptual framework, we developed a reusable Flutter-based consent widget that can be integrated into every Flutter mobile app. The effectiveness of the consent widget has been verified by the widget’s integration into the City Explorer app and its reusability has been tested via two additional demo applications. The cross-platform (iOS/Android) source code, the installation package for smartphones with Android Operating System, version 9 Pie or later, and the video demo of the first demo app as well as the cross-platform (iOS/Android) source code, the installation package for smartphones with Android Operating System, version 9 Pie or later, and the video demo of the second demo app are available online at https://short.wu.ac.at/PSource, https://short.wu.ac.at/PInstallation, https://short.wu.ac.at/PVideo, https://short.wu.ac.at/LFSource, https://short.wu.ac.at/LFInstallation, and https://short.wu.ac.at/LFVideo respectively.

In order to simplify the integration of the consent widget, we provide an Application Programming Interface (API) that describes the widget’s correct implementation. The consent widget’s source code and the API are available online at https://short.wu.ac.at/curled. The details about the architecture and the implementation of the consent request framework via the consent widget are additionally explained in Appendix A.

5. Usability Evaluation

We assessed the usability of the City Explorer app prototype and the integrated consent request framework by conducting a usability evaluation in an asynchronous remote way [37] with the help of a think-aloud method [38,39,40]. The prototype was evaluated by 50 participants. They were university students who in turn recruited additional participants not directly associated with the university. The demographic data of the participants are presented in

Table 2. Demographic data of the usability evaluation participants.

Demographic Data Category	Subcategory	%
Gender	Male	66%
	Female	34%
Age Group	16 to 25 years old	52%
	26 to 35 years old	38%
	36 to 45 years old	4%
	55 years old and over	4%
	46 to 55 years old	2%
Education	High school graduate	54%
	Master’s degree	16%
	Bachelor’s degree	12%
	Some college, no degree	8%
	Some high school	8%
	Trade/Technical/Vocational training	2%
Country of origin	Austria	64%
	Serbia	12%
	Germany	8%
	Hungary	8%
	Croatia	4%
	North Macedonia	4%
Smartphone usage skills	Proficient	44%
	Competent	30%
	Expert	24%
	Advanced beginner	2%
Daily Internet usage	3–6 h	50%
	1–3 h	34%
	6–8 h	6%
	8+ h	6%
	Less than 1 h	4%
Daily smartphone usage	1–3 h	56%
	3–6 h	28%
	6–8 h	10%
	Less than 1 h	4%
	8+ h	2%
Preferred device for Internet surfing	Smartphone	54%
	Laptop	28%
	Desktop computer	14%
	Tablet	4%
Privacy vs. Convenience preference	Privacy	56%
	Convenience	44%

. As mentioned earlier, we integrated all four consent options into the City Explorer app and assigned one of them randomly upon the app installation. Figure 6a shows the distribution of convenience and privacy preferences of the participants across different consent options.

We instructed the participants to record their screens while testing the prototype and, at the same time, to think aloud and record their spoken thoughts in order to gain insights into the reasons for the possible app usage difficulties as well as into the general user experience of the CURLED framework. The participants were asked to test the City Explorer app in general, and they did not know that we were particularly interested in the evaluation of the consent request framework. In addition to the think-aloud method, we measured user performance (e.g., completion success rates, errors, etc.) [41] and asked users to fill in a post-evaluation remote questionnaire [42]. The questionnaire (see Appendix B) was examined for confusing and leading questions and was improved together with two experts. It contained single-choice, rating-scale, and open-ended questions that gave an overview of the participants’ demographics as well as of the CURLED-based prototype assessment. In order to conduct the evaluation as close as possible to real-life situations and to make sure that the evaluation is ecologically valid [43], we developed the City Explorer app prototype as a cross-platform app that could be installed on Android Operating System version 9 Pie or later and iOS 12 or later; we based the content for the consent request on the apps offered by the city of Vienna; and we asked users to test the City Explorer app in the natural setting while visiting places in their cities. The initial intention was to test the app prototype with students in a single city; however, due to the COVID-19 pandemic and people moving to their home countries, we removed this limitation. One of four consent requests (custom, functionality-based, app-based, and usage-based) that had been integrated into the City Explorer app (see Section 4.3) was randomly assigned upon the app installation. The participants tested our City Explorer app prototype by completing the predefined tasks summarized in

Table 3. The City Explorer app prototype and CURLED-based consent requests usability evaluation assignments.

Task #	Text of the Task
T1	Report three issues that you encounter in your city (e.g., graffiti on the wall, trash on the street, broken bench in the park, broken traffic lights, etc.)
T2	Make a profile picture.
T3	Leave a review of a bicycle rent station. If there are no bicycle stations in your city, please review any point of interest.
T4	Leave a review of a park.
T5	Leave a review of a point of interest.
T6	Exchange some of your scores for three tickets of your choice.
T7	Have a look (in the statistics section) at how many scores you have earned by reporting issues in your city.

, while walking in their cities. When the participants finished the tasks, they were asked to tap “Go to Survey” in the app settings menu and fill in the post-evaluation questionnaire.

5.1. Overall Satisfaction and Memorability

In general, users were satisfied with the City Explorer app. Fifty-four percent of the participants were either satisfied (48%) or very satisfied (6%) with the app. Twenty percent evaluated the app neutrally. Twenty-six percent of the participants reported dissatisfaction. Figure 6b shows the distribution of this satisfaction evaluation across different consent options that were integrated into the app. The City Explorer app prototype with the functionality-based consent achieved the best results with 73% satisfied participants, no “not at all satisfied”, and only 9% unsatisfied users. The prototype with the usage-based consent received the second-best evaluation results. Eight percent of the participants were very satisfied and 54% were satisfied with it. Twenty-three percent of the respondents gave a neutral assessment and 15% were unsatisfied with the prototype that contained the usage-based consent. The City Explorer app prototype with the custom consent request was evaluated slightly worse than the one with the usage-based consent with 8% of the respondents being very satisfied, 33%—satisfied, 25%—neutral, another 25%—unsatisfied, and 8% being not at all satisfied. The prototype with the app-based consent received the last place in the evaluation. Even though 7% of the participants were very satisfied with the prototype, 36% were satisfied with it, and 14% remained neutral toward the prototype; 42% of the participants still assessed the prototype as unsatisfactory (21%—unsatisfied and 21%—not at all satisfied).

When we asked users if they were overall satisfied with the way consent for the data processing was requested in the app prototype, 33% of the participants reported satisfaction, 38% of the users remained neutral, and 29% were dissatisfied with the consent request. Figure 6c shows, separately for four CURLED-based consent requests, the evaluation of the user’s overall satisfaction with the consent requests in the app prototype. Again, the functionality-based consent has the highest percentage of satisfied users (27%—satisfied, 18%—very satisfied), no “not at all satisfied” users, and only 9% of those who were unsatisfied. Forty-five percent of the respondents were neither satisfied nor dissatisfied with the functionality-based consent request. The usage-based consent received similar, however, only slightly better results than the app-based consent request. 8% of the participants were very satisfied with both usage-based and app-based consent requests. The same percentage (8%) of the respondents were not at all satisfied with both consent request versions. Fifteen percent and 17% of the users were satisfied with the usage-based and app-based consent requests, respectively. Forty-six percent gave a neutral evaluation to the usage-based consent and 42%—to the app-based consent request. Twenty-three percent of users who evaluated the usage-based consent and 25% of those who evaluated the app-based consent were unsatisfied with it. The custom consent has the same number (41%) of satisfied users (33%—very satisfied, 8%—satisfied) as it has of dissatisfied users (33%—not at all satisfied, 8%—unsatisfied). The rest evaluated it neutrally. This is the worst result among the four consent requests.

As to the memorability of the given consent, almost all participants reported that they remembered (albeit to a lesser or greater extent) their consent for the data processing (see Figure 7a). Again, the functionality-based consent is the leader of this evaluation. Eighty-one percent of participants reported that they remembered, either very well (45%) or well (36%), the consent they granted. Eighteen percent remembered their consent “to some extent”. Seventy-five percent of the respondents, who evaluated the prototype with the custom consent request, remembered their consent very well (58%) and well (17%). Twenty-five percent selected “to some extent” when evaluating the custom consent memorability. The usage-based consent request was slightly less memorable, with 54% of the users who remembered their consent very well, 8%—well, 31%—to some extent, and 8% of those who remembered little about what data processing they had consented to. The app-based consent request appeared to be the least memorable to the users. Still, 21% of the participants reported that they remembered their consent very well and 14%—well. Forty-three percent remembered their consent to some extent and 7%—only a little. The app-based consent was the only consent request that had users (14%) who did not remember their consent.

5.2. Time Perception

In general, more than half of the participants positively evaluated the time spent on the tasks. Forty-six percent of the participants were satisfied with the time it took them to complete the tasks, and for 6%, it took even less than they expected. Twenty percent of the users think that it took them too long, but it was worthwhile. The rest still considered the process to be time-consuming. Again, the City Explorer app with the functionality-based consent performs better, than with other consent requests, in terms of the assessment of the time needed for the task completion (see Figure 7b). Seventy-three percent of the respondents selected “about the right amount of time” and 9%—“it took less than I thought it would” in the questionnaire. Eighteen percent still found the task completion process to be too long. As to the City Explorer app prototype with the app-based consent request, 50% of the participants were satisfied with the time necessary to complete the tasks, 36% thought it had taken them too long but it had been worthwhile, and 14% selected “too long”. The custom and the usage-based consent requests were evaluated similarly to each other and had the highest number of respondents, 42% and 38% respectively, for whom it took too long to complete the tasks. Nevertheless, 33% of the participants who evaluated the City Explorer app prototype with custom consent and 31% of those who evaluated the prototype with usage-based consent, reported that the time spent on tasks was of about the right amount. In both cases, for the 8% of the participants, it took less than they thought it would to complete the tasks. The rest of the respondents, 17% and 23% respectively, considered the tasks to be too long, but it was still worthwhile to complete them.

Additionally, we asked the participants to assess the time it took to give their consent for the data processing. Figure 7c shows that users assessed it similarly to the time spent on the tasks in terms of the consent request ranking. The functionality-based consent received the best evaluation. Almost two-thirds of the participants (64%) replied that it had taken them about the right amount of time to provide their consent. For the 27% of the respondents, giving their consent via the functionality-based consent request was too long but worthwhile, and only 9% considered the process to be too long. The second best result was achieved by the app-based consent request with 42% of the users who were satisfied with the time they needed to provide their consent. One-third (33%) of the participants evaluated the time for granting this consent as too long but worthwhile and the rest (25%) as simply too long. Forty-two percent of those who evaluated the City Explorer app prototype with the custom consent were satisfied with the time they had spent on giving their consent; seventeen percent perceived the process to be too long but worthwhile; and for others, it took too long. The usage-based consent received the worst results in time perception. Forty-six percent of participants answered that it had taken them too long to give their consent. Twenty-three percent found that the consent process took too long, however, it was beneficial. For another 23% of the respondents, granting their consent took about the right amount of time, and, for the 8%, it took even less than they expected.

5.3. Adjectival Description

We prompted our participants to select adjectives that they would use to describe the City Explorer app prototype and the consent request that they were evaluating. For this, we used the list of adjectives from Microsoft Desirability Toolkit [44], which we adapted to our use case. Irrespective of the consent options, the participants describe the City Explorer app prototype predominantly positively. The users chose the following positive adjectives when evaluating the app prototype: “easy to use” (46%), “useful” (38%), “innovative” (33%), “helpful” (32%), “clear” (32%), “efficient” (32%), “usable” (30%), “effective” (30%), “familiar” (28%), “valuable” (27%), “fast” (25%), “engaging” (22%), “friendly” (22%), “effortless” (20%), “intuitive” (19%), “organized” (16%), “understandable” (16%), “inviting” (16%), “fresh” (12%), “appealing” (10%), “flexible” (10%), “impressive” (10%), and “satisfying” (10%). A few negative adjectives were still selected to describe the app prototype. The participants found it to be “time-consuming” (22%), “annoying” (18%), “confusing” (18%), “boring” (12%), “dated” (10%), “complex” (8%), and “ineffective” (8%).

The distribution of the above adjectives across the consent options integrated into the app prototype is presented in Figure 8.

The City Explorer app prototype with the functionality-based consent request received the best evaluation with 22 positive and only four negative adjectives selected to describe the app prototype. Moreover, the percentage of the participants who voted for separate positive adjectives is the highest, and of those who voted for each negative adjective is the lowest among the four integrated consent requests. The app prototype with the usage-based consent request achieved similarly good results when compared to the app prototype with the functionality-based consent. In total, 22 positive and six negative adjectives were selected to describe it. However, the number of the users’ votes per adjective slightly decreased for the positive adjectives and increased for the negative adjectives. The app prototype with the app-based consent request collected 22 positive and seven negative adjectives. Even though the number of positive adjectives is the same as in the app prototypes with the functionality- and usage-based consents, the number of respondents per adjective is lower, whereas for the negative adjectives this number, as well as the total number of the negative adjectives, is higher. The City Explorer app prototype with the custom consent has the lowest number of eighteen positive adjectives in total. The number of participants per adjective is also the lowest among the four consent requests integrated into the app prototype. Even though the app prototype with the custom consent was described with five negative adjectives, which is less than in the app prototypes with the usage- and app-based consent requests, more than half of those who evaluated the app with the custom consent request (58%) described the app as “time-consuming”.

We also asked the participants to describe, separately from the app prototype, the way their consent was requested from them by using the same list of adjectives as for the app prototype description. Figure 9 depicts the results of this evaluation. In terms of the consent request ranking, these results are consistent with the way the City Explorer app prototype has been described using adjectives. The functionality-based consent request again achieved the best results by collecting fifteen positive and only seven negative adjectives. The usage-based consent is the second best with fifteen positive and eight negative adjectives. The app-based consent request collected 16 positive and 12 negative adjectives. Even though the number of positive adjectives is a bit higher than in the functionality- and usage-based consents, the number of respondents per adjective is lower. The custom consent received thirteen positive adjectives and the same number of negative adjectives, which is the worst result of this evaluation.

5.4. System Usability Scale Scores

Based on the participants’ replies to the questionnaire, we calculated the system usability scale (SUS) score of the City Explorer app and, separately, of each consent option. SUS is a technology-independent ten-item questionnaire with five response options ranging from strongly disagree to strongly agree [45]. The SUS scores can be interpreted with the help of the 6-point adjective scale [46] where the artifacts with the mean SUS scores up to 25 are described as the worst imaginable, 25–38 as poor, 38–52 as OK, 52–74 as good, 74–85 as excellent, and 85–100 as the best imaginable. The ranges exclude the lower endpoint and include the upper endpoint.

The results of our evaluation, divided into consent options, are shown in Figure 10. The City Explorer app prototype with the functionality-based consent achieved the highest average score of 72.27. The prototype with the usage-based and custom consents followed with the SUS scores of 67.71 and 55, respectively. The prototype with the app-based consent received 49.11 points. Based on the adjective scale, our app prototype with the functionality-based consent falls under the higher end of the good category and approaches the excellent category. The SUS scores of the app with the usage-based and custom consent options are also described as good. The app with the app-based consent is described as OK. However, its SUS score is on the higher end of the OK category and approaches the good category.

It is not surprising that across the board the various consent requests received lower separate SUS scores than the app prototype as a whole because, typically, users are more excited about the app functionalities and are not interested in as well as anticipate difficulties with configuring app settings [47]. The average SUS score of the functionality-based consent is the highest among the four consent options and equals 58.86. The usage-based consent scored 56.54, the custom consent—48.27, and the app-based consent—48.21. According to the adjective scale, the functionality-based and the usage-based consents belong to the good category; and the custom and the app-based consents belong to the OK category.

6. Discussion

The CURLED conceptual framework offers four consent request approaches to seeking user consent for personal data processing. While the functionality-based consent request demonstrated the best outcomes in our specific use case and within the context of the City Explorer app, it is important to acknowledge that the custom, app-based, and usage-based consent requests may be favored by certain application developers. By understanding the features of each consent request variation and its evaluation results, developers can tailor the user consent experience to align with app functionalities, as well as enhance transparency and user control over personal data processing. The evaluation of the CURLED conceptual framework integrated into the City Explorer app produced the following takeaways.

6.1. Functional Alignment of Consent Request Information

The evaluation results show that the functionality-based consent option was favored overall by the majority of participants, as it consistently received the most positive evaluations. Such result suggests that this consent request representation aligned more closely with user preferences and expectations, as well as with the overall app capabilities. The ability to grant consent based on the specific purpose combinations, ranging from high to low levels of privacy, resonated well with participants. This indicates that, in our use case, the functionality-based consent request managed to effectively, and in a logical manner, convey the app features that would be available to users upon selecting any of its purpose combinations. This finding implies that, in general, developers should keep in mind that a seamless connection between the data processing that users consent to and the functionalities made available in an app could foster user satisfaction and reduce the likelihood of user frustration stemming from unmet expectations.

6.2. Customization and Ease of Use

The custom consent request, while offering a high degree of customization and satisfying more than one-third of the users, was perceived by others as unsatisfactory and overly complex, leading to lower user satisfaction ratings overall. This suggests that while users prefer having customization, in general, it should not come at the expense of simplicity and ease of use. Striking the right balance between customization and simplicity is important to avoid overwhelming users and compromising their experience. Further supporting insights into this can be drawn from the adjectival description of the City Explorer app prototype and the different consent request options. The selected adjectives like “familiar”, “usable”, “effortless”, and “intuitive” highlight the significance of designing consent mechanisms that align with users’ existing mental models and are easy to navigate. Incorporating familiar elements and intuitive interfaces could enhance user acceptance and adoption of consent requests.

6.3. Task Completion Time

The usage-based consent request gathered mixed feedback from participants. On one hand, some participants expressed satisfaction with this approach. On the other hand, the usage-based consent request received the least favorable evaluation in terms of time perception, with a high percentage of participants finding it to be time-consuming. The perception of usage-based consent as time-consuming can be attributed to the nature of this consent request itself. Given the need for users to grant consent for all data processing for a brief period of time upfront, in order to allow the app to learn and analyze their usage patterns, users were presented with all the details regarding data processing at once and were asked to provide their consent. The process of granting such consent involved a noticeable amount of time and attention on the part of the users. The delay in actual app interaction caused by the perceived longer time that was necessary to give consent might have resulted in users’ feeling that the usage-based consent request had not adequately catered to their immediate needs and preferences, contributing to a sense of frustration.

Additionally, the adjectives chosen by participants during the evaluation of consent request variations, such as “efficient”, “fast”, “time-consuming” and “annoying” indicate that users value a consent process that is efficient, quick, straightforward, and does not unnecessarily prolong their interaction with the consent request. This suggests that prioritizing efficiency in obtaining consent can contribute to a positive user experience.

6.4. App Benefits and User Concerns

User satisfaction evaluation of the app-based consent request was mixed, with some participants expressing dissatisfaction or annoyance. One possible reason for the varied reactions to the app-based consent request could be the interplay between promised benefits and perceived privacy risks. While users generally appreciated the prospect of receiving rewards or benefits in exchange for the processing of their data, they could have questioned the app motives, feeling some concern about how their data will be used to deliver these benefits. This, in turn, could trigger a higher level of scrutiny during the consent process, leading to increased reported annoyance levels. Another reason for user dissatisfaction could lie in the fact that the perceived value of the benefits offered in exchange for data processing might differ from user to user. Some users who do not perceive the benefits as valuable might focus more on the privacy implications, leading to a negative evaluation. In order to improve user satisfaction, app developers should carefully consider how they present app benefits while ensuring transparency concerning personal data processing.

6.5. Cognitive Load

The proposed consent requests might have imposed different levels of cognitive load on users during the evaluation process resulting in varying levels of user satisfaction. For instance, despite its aim to automate the consent request generation and ease the burden of granting consent for users, the usage-based consent request might have caused user annoyance due to the initial learning curve it demands. In the case of the City Explorer app prototype with usage-based consent, users were required to give their consent for all potential future data processing scenarios right from the beginning in order to enable the app to learn and analyze their usage patterns. As a result, users had to digest a substantial amount of information regarding data processing in a single interaction. Additionally, unlike the other consent request variations, where users were mainly focusing on the immediate functionalities or benefits, usage-based consent required users to engage in an evaluation of the long-term implications of their consent.

Enhancing user knowledge about future data processing through comprehensive details is beneficial, yet developers should also focus on mitigating cognitive burden, for example, by gradually disclosing data processing information.

6.6. UI Design and Data Processing Description

While analyzing the evaluation videos, we observed that users exhibited a clear understanding of the UI design elements and the accompanying data processing details. Additionally, there was no explicit negative feedback from participants concerning the features of the UI design which suggests that users did not encounter any particular design facets that could have been disruptive, counter-intuitive, or triggered confusion.

7. Limitations

It is essential to recognize that the evaluation results, presented in this paper, are specific to our exemplifying use case scenario and the City Explorer app prototype context and may not directly generalize to all app contexts and functionalities. Additionally, the usability evaluation primarily involved university students and participants recruited by them, which does not fully represent the diverse population of potential app users. The efforts were made to make the evaluation closer to real-life situations by using a cross-platform app and asking participants to test it in natural settings; however, the asynchronous remote approach to evaluation might have introduced limitations in capturing non-verbal cues and immediate clarification of user actions or feedback. The Hawthorne effect was mitigated by emphasizing to the participants the importance of honest and unbiased feedback and by ensuring participants’ anonymity. The threat of the self-report bias was addressed by carefully designing the questionnaire, ensuring clarity and neutrality in the questions, and providing clear instructions to participants to encourage accurate and unbiased reporting. In order to minimize the researchers’ bias, multiple researchers were involved in the result analysis process.

8. Conclusions

In this paper, we proposed the Consent reqUests foR mobiLE Devices (CURLED) framework, which is based on both the text of the GDPR relating to consent and its interpretation by the Working Party on the Protection of Individuals with regard to the Processing of Personal Data. The CURLED concept gives data subjects control over personal data processing via four consent requests (custom, functionality-based, app-based, and usage-based). The applicability of the proposed consent mechanisms in a mobile setting was demonstrated by incorporating them into the City Explorer mobile app prototype. Additionally, we performed a comparative analysis of the CURLED-based consent requests by conducting a usability evaluation that provided valuable insights into the effectiveness of different consent request options.

Based on the evaluation results, we conclude that the City Explorer app was generally well-received by users, with the majority of participants reporting satisfaction with the app. In the City Explorer app prototype context, the functionality-based consent request was the most successful in terms of user satisfaction, memorability, the time necessary for granting consent, adjectival description, and the mean SUS score. Even though the functionality-based consent request received the best results in our exemplifying use case and the City Explorer app context, the custom, app-based, and usage-based consent requests could potentially be preferred by some app vendors. Thus, in order to facilitate the reusability of the CURLED framework, encompassing all four consent requests, in addition to providing access to the source code, we developed a Flutter-based consent widget that can be used in every Flutter mobile app, and provided an API that describes the widget’s correct application.

The artifacts and the evaluation results presented in this work can serve as a baseline for comparison with future consent request implementations or as a reference point for similar studies in the future. Additionally, by helping to understand how different consent options are perceived by the users, the evaluation results can be used to identify areas for improvement in the consent request approaches of the existing mobile apps, or to guide the development of future consent mechanisms and best practices in this area.

In our future work, we plan to extend the framework to cater to additional consent requirements arising from other jurisdictions and national data protection laws of different countries.