Intent-aware Permission Architecture: A Model for Rethinking

Informed Consent for Android Apps

Md Rashedur Rahman, Elizabeth Miller, Moinul Hossain and Aisha Ali-Gombe

Department of Computer & Information Sciences, Towson University, Towson, Maryland, U.S.A.

Keywords:

Android App, App Permission, Privacy, Privacy Sensitivity.

Abstract:

As data privacy continues to be a crucial human-right concern as recognized by the UN, regulatory agencies

have demanded developers obtain user permission before accessing user-sensitive data. Mainly through the

use of privacy policies statements, developers fulﬁll their legal requirements to keep users abreast of the re-

quests for their data. In addition, platforms such as Android enforces explicit permission request using the

permission model. Nonetheless, recent research has shown that service providers hardly make full disclosure

when requesting data in these statements. Neither is the current permission model designed to provide ade-

quate informed consent. Often users have no clear understanding of the reason and scope of usage of the data

request. This paper proposes an unambiguous, informed consent process that provides developers with a stan-

dardized method for declaring Intent. Our proposed Intent-aware permission architecture extends the current

Android permission model with a precise mechanism for full disclosure of purpose and scope limitation. The

design of which is based on an ontology study of data requests purposes. The overarching objective of this

model is to ensure end-users are adequately informed before making decisions on their data. Additionally, this

model has the potential to improve trust between end-users and developers.

1 INTRODUCTION

As of 2021, there are 2.8 billion active Android de-

vice users, representing 75 percent of the total global

mobile users. From social media to online pur-

chases, ﬁnancial services, banking, music, and enter-

tainment, mobile applications leverage the sophistica-

tion of smart devices’ sensors coupled with their in-

creasing processing power and mobility to provide the

needed functionalities to end-users. A good number

of these apps, however, utilize the design of smart de-

vices to store and process valuable and sensitive con-

crete and behavioral data that can potentially be used

to abuse and infringe on user privacy.

By design, Android is built with a permission

model that ensures requests to access speciﬁc user and

device-sensitive data are explicitly granted by the de-

vice user at runtime. Although improved over the last

few years from the its original designed, the current

1-time ﬁne-grained dynamic permission model is still

yet to address two salient user privacy issues related

to Intent: 1) purpose limitation and 2) scope of us-

age or data transfer. It is a well-documented concern

in behavioral and usability research that most device

users have no clear understanding of why their data

was requested by an app. In addition to Android’s

own permission model, additional solutions were also

proposed in the literature to check apps’ accesses in

exploiting user data (Brutschy et al., 2015; Liu et al.,

2016b; Beresford et al., 2011; Zhou et al., 2011; Nau-

man et al., 2010; Jeon et al., 2012; Bugiel et al.,

2013). However, much like the current Android per-

mission model, these solutions have not covered the

declaration of the developer’s Intent mainly because

there were no laws in place that protect the users’

rights to be adequately informed. Nevertheless, with

the recent expansion of privacy regulations world-

wide, particularly the European General Data Protec-

tion Regulation (GDPR) and the California Consumer

Privacy Act (CCPA), the request for user-sensitive

data needs to go through a mandatory and explicit

declaration of Intent guided by purpose limitation.

The sections of these current privacy laws related

to consent mandated that data request must be made

clear and unambiguous. In addition, the regulations

further state that the processing of user-sensitive data

is limited to the ”legitimate purposes” that were ”ex-

plicitly speciﬁed” to the data subject, thus further

emphasizing the need for service providers to place

and make purpose limitation explicit during consent

154

Rahman, M., Miller, E., Hossain, M. and Ali-Gombe, A.

Intent-aware Permission Architecture: A Model for Rethinking Informed Consent for Android Apps.

DOI: 10.5220/0010882900003120

In Proceedings of the 8th International Conference on Information Systems Security and Privacy (ICISSP 2022), pages 154-164

ISBN: 978-989-758-553-1; ISSN: 2184-4356

agreement. Although the use of privacy policy state-

ments to notify users about data requests has been

adopted by many Android providers for some time

now, however, some of these developers often hide

behind complex legal jargon to make ambiguous and,

most a times, vague declaration of consent. As doc-

umented in the works of (Gluck et al., 2016; Reiden-

berg et al., 2015), these legal documents are usually

hard to parse and understand by average users and

even experts.

To address this privacy concern, we argue that a

technical implementation that provide a standard-

ize mechanism for developers to explicitly and un-

ambiguously declare Intent programmatically is re-

quired. Thus, this research presents a redesign of

the Android access permission model to include a

ﬁne-grained classiﬁcation of purposes and mapping

purpose-to-scope to create Intent labels, which devel-

opers must explicitly declare. Each Intent label de-

ﬁnes the purpose for data request and whether or not

the data will be used only on the device or transferred.

Our proposed Intent-aware permission model extends

the current model with a mechanism for developers

to comply with the privacy law requirements, particu-

larly the user’s right to be informed by clearly deﬁn-

ing the purpose and scope limitations at the point of

data request. Compared to most exiting works that

target permission reduction or privacy enforcement,

to the best of our knowledge, this is the ﬁrst research

that addresses the issue of Intent disclosure for mobile

apps informed consent. In summary, this paper makes

the following contributions:

1. An in-depth ontology study of privacy policy

statements that examines the terms and language se-

mantics used by experts to declare purpose for data

request. This study creates Intent labels which are ag-

gregated into distinctive categories to cover different

usage for diverse data groups.

2. A new Intent-aware permission model that

leverages the developed Intent labels above to cre-

ate a standardized mechanism for developers to easily

comply with the requirement of the law (users’ rights

to be clearly and unambiguously informed) while im-

posing very minimal changes to the Android APIs.

3. Our model also provides an interface for users

to review the Intents (purpose and scope limitations)

during permission request, thus equipping them with

adequate knowledge and authority to make an in-

formed consent.

The rest of the article is organized as follows:

In Section 2, we provide the detailed background of

the Android permission model, including its revisions

and drawbacks and the motivation for the need for full

disclosure and informed consent. Section 3 describes

the design and implementation of our new permis-

sion model. Section 4 provides a detailed evaluation,

discussion, and limitation of the proposed permission

model. Section 5 presents the literature review and

Section 6 concludes the paper.

2 BACKGROUND

2.1 Android Permission Model

On Android, user and system applications such as

Twitter and Google Maps execute in their sandboxes

and maintain their instance of the runtime environ-

ment. The kernel layer lies at the bottom of the archi-

tecture and manages system resources through the ﬁle

system, memory and process management, resource

allocation, and synchronization. Given the sensitive

nature of data and resources hosted on our mobile

devices, Android has categorized the different data

and resources groups into low-risk and high-risk re-

sources. Generally, any upper-level applications’ re-

quests for data and resources are made through the

Android permission model which which sits in the

middle layer, a bridge between device resources in

Kernel space and Application programs. Over the last

decade, this permission model has gone through in-

tense scrutiny and modiﬁcation by the research com-

munity and the industry. It has morphed from a ﬂawed

all or none-model to a more ﬁne-grained 1-time per-

mission system. Nonetheless, while this system pro-

vides program tools for requesting user consent on the

data, crucial information about the consent, such as

why the data is requested and the scope within which

the data will be used, are often ignored. This valuable

information on the purpose and scope of the request is

excluded entirely in the Permission model, thus leav-

ing the entire consent process without a key crucial

component - full disclosure. Much like in medical

practice, to explicitly and adequately seek consent on

user data, a provider must disclose the data group,

access type, purpose, and scope of the data request,

however in the current Android Permission model,

only the data group is disclosed.

2.2 Privacy Policy Statements

The General Data Protection Regulation (GDPR)

(GDPR, 2021) of the EU and The California Con-

sumer Privacy Act (CCPA) (CCPA, 2021) of the state

of California seeks to address this lack of proper con-

sent and other privacy issues by enacting data protec-

tion laws and regulations with speciﬁc sections ded-

icated to the deﬁnition of consent (Das et al., 2018).

Intent-aware Permission Architecture: A Model for Rethinking Informed Consent for Android Apps

155

Other bodies such as Brazilian Data Protection Law

(LGPD), Personal Information Protection Commis-

sion, Japan have also introduced new regulations to

protect the privacy of the user while maintaining a

fair and cooperative sharing of information with the

tech service providers. The commonalities among all

these regulations worldwide lie in the requirement of

a user’s informed, unambiguous, and explicit consent

and purpose limitation while sharing certain privacy-

sensitive information. To adhere to the requirements

of these laws, most services, both online and mo-

bile providers, have adopted the use of privacy pol-

icy statements to seek user consent and declare pur-

pose(s) for data requests. However, related work in

privacy research has shown that, in an attempt to

cover the needed legal concerns by service providers,

privacy policies are often drafted as complex, long,

and vague statements, thus making it harder for av-

erage users to understand (Cate, 2010; Jensen and

Potts, 2004; Gluck et al., 2016). This practice is even

more complicated on mobile and wearable devices

where unclear and lengthy privacy statements are pre-

sented to users often one time to seek consent and de-

clare purpose (Gluck et al., 2016). This combination

of length and ambiguity in privacy policy statements

have rendered the highly worked-out privacy regula-

tions ineffective in protecting average users.

3 PROPOSED ANDROID

PERMISSION MODEL

As discussed in Section 2, the ambiguity in the con-

sent process poses a signiﬁcant threat to user privacy.

Hence, this paper seeks to address this threat with

a simpliﬁed and standardized informed consent pro-

cess, which will require the developers to clearly and

explicitly declare the purpose and scope for data re-

quests. Our solution is geared toward improving gen-

eral user privacy and trust between end-users and de-

velopers as well as will be helping developers to com-

ply with the consent section of the new privacy reg-

ulations. The design of our proposed approach is

threefold - (1) the creation of comprehensive Intent

labels that leverages ontology study of data request

purposes, (2) the integration of the new model into the

Android framework, and (3) Permission UI redesign

to include Intent description

3.1 Intent Labels

The Intent in the context of this research is a map-

ping of purpose-to-scope limitation. Speciﬁcally, pur-

pose limitation describes the developer’s clear inten-

tion of why speciﬁc data is requested and the asso-

ciated event or purpose for its usage. In contrast,

scope limitation deﬁnes the scope within which the

developer will use the data, i.e., whether the data

will be used on the user device or out of the device.

The logical mapping between these two variables de-

scribes the developer’s Intent. Android being a het-

erogeneous platform, is associated with multiple dif-

ferent hardware manufacturers and millions of App

developers. As such, a simple descriptive approach

to deﬁning Intent as adopted by Apple (Hutchinson,

) will lead to the same complex issues we’ve identi-

ﬁed for privacy policy statements, i.e., lengthy, am-

biguous, and vague description of purpose and scope.

Hence, much like the aggregation of permission, In-

tent for data requests must be aggregated into distinc-

tive categories that cover different usage for diverse

data groups. Therefore, we must deﬁne ﬁne-grain on-

tology of purposes for each data group and then map

them to the scope of the request. However, since there

is no known ontology for purpose limitation termi-

nologies, we must rely on extensive language analysis

of Android apps’ privacy policy statements.

3.1.1 Ontology Generation

Our goal is to acquire the terms and language used by

experts and policy statement writers to declare pur-

pose for data request. Our ontology of purpose work-

ﬂow is divided into 5 distinct steps: i) Language Ex-

traction, ii) Data Grouping, iii) Aligning Data Cluster

to Permission, iv) Purpose Simpliﬁcation, and v) Pur-

pose Synonymization.

Phase 1: Language Extraction. The objective here

is to extract language used by Android app develop-

ers for purpose declaration into a corpus database. We

begin this process with the selection of privacy policy

statements for apps that fall into the following cate-

gories - i) popular apps (currently covered 80 apps

and games) by the Big Techs that maintain proper

compliance with the privacy regulations and are ex-

pected to share extensive reasons for accessing user

data, ii) representative apps from selected categories

such as social media, ﬁnance, travel and local, shop-

ping etc. This criterion ensures the accuracy of lan-

guage semantics whilst maintaining diversity.

For each privacy policy statement in our list, we

leverage a heuristic approach inspired by the work of

Breaux et al. (Breaux and Schaub, 2014) for language

decomposition. This approach utilizes a data-verb-

purpose mapping to identify the relationship between

object, action verb, and a purpose for the data request.

With this approach, the ﬁrst step is to manually de-

construct a privacy policy document into chunks of

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

156

statements based on an action verb that we termed

Requesting verbs. Statements containing at least

one Requesting verb will be added to a candidate

list. The survey of existing literature indicates that

the most commonly used action verbs for requesting

permission on user data are collect, access, trans-

fer, share, retain, use (Breaux and Schaub, 2014;

Breaux et al., 2014). Each statement in our candi-

date list is then further decomposed into three com-

ponents: the object representing the requested data;

the verb, which denotes the type of request; and the

event, which shows the purpose for which the data

will be used. Next, we extract the purpose description

portion of this relation and its corresponding data and

add them to the language database. In our study of 80

apps, we extracted more than 1000 statements, which

corresponds to 1000 data units and purpose descrip-

tion statements (which are either single words, simple

phrases, or complex expressions). Figure 1 illustrates

the language decomposition process for a single state-

ment from the TikTok’s privacy policy statement.

Purpose

Data

Requesting

Verb

Figure 1: An illustration of Language Extraction of TikTok

App’s Privacy Policy Statement.

Phase 2: Data Grouping. Based on the collected

data in the corpus database, we group similar data

types into clusters. For this purpose, we applied a se-

mantic ﬁltering approach (Doan et al., 2012) to iden-

tify and cluster the different expressions of logically

related data in our corpus database. For example, in

Figure 1, name and phone number can be simpliﬁed

as contact information. In another example, Loca-

tion data and Navigation data have the same seman-

tic meaning in the context of data requests, hence can

be logically grouped into a single unit. We created a

separate table in the corpus database to store different

data groups and their corresponding purpose descrip-

tions. Additional metadata for the name of the app

and its category is also included.

Phase 3: Aligning Data Cluster to Permission.

Next, we establish a relationship between the data

clusters, their purpose descriptions, and the standard

Android permission labels. This process is crucial

to implement the Intent-aware consent process. The

mapping allows developers to easily select an Intent

label for a particular permission during app develop-

ment and for users to review the Intent during per-

mission approval at runtime. as shown in Figure

1, the permission needed to access contacts or ad-

dress book is the READ CONTACTS permission. In

another example, user data that belongs to the lo-

cation cluster (location data, navigation data, etc.)

are mapped to the ACCESS FINE LOCATION and

ACCESS NETWORK STATE permissions. The data

grouping table from phase 1 is modiﬁed to include

the additional column for permissions.

Phase 4: Purpose Simpliﬁcation. Our review of

the corpus database showed that the purpose descrip-

tion is often presented either as a single word, a

phrase, and in most cases, as a complex expression.

In this phase, the goal is to simplify the language

and streamline each purpose description. We lever-

aged the manual grammar reduction technique (San-

taholma, 2007) to simplify all complex purpose de-

scriptions. For example, according to one privacy pol-

icy, “we require your data to run or tailor our ser-

vices, including with more relevant information such

as local trends, articles, advertisements, and sugges-

tions for people to follow.” This purpose is reduced

to personalizing content depending on localization.

In Figure 1, the Tiktok developers declared that- “we

will access and collect the names and phone numbers

and match that information against existing users in

the platform,” can be simpliﬁed to - discovering other

users on the platform.

Phase 5: Purpose Synonymization. The purpose

description language developed in Phase 4 is fur-

ther simpliﬁed by combining purposes that have the

same meaning or are closely related. The objec-

tive of this step is to reduce information redun-

dancy and generate much simpler purpose state-

ment that conveys clear and succinct intent. In this

step, we aim for a one or two-word description for

each purpose description. For example, the reduced

grammars for Content personalization, personaliz-

ing content depending on localization, Preferred re-

sources, and so on are all streamlined into CON-

TENT PERSONALIZATION. Similarly, the reduced

form of purpose taken from Tiktok statement in Fig-

ure 1 is reduced to USER CONNECT.

3.1.2 Scope Limitation

Scope Limitation is the second attribute of the Intent

label for data requests that specify the scope of usage.

In this phase, we manually explore the corpus of our

Intent-aware Permission Architecture: A Model for Rethinking Informed Consent for Android Apps

157

ciated with different data groups and Intents from the

developer’s perspective. Unfortunately, there is a lack

of proper disclosure as to whether the collected data

will remain on the device or will be transferred even

for the categories of apps we chose for analysis. In

very few instances, the scope may be implicitly in-

ferred from the requesting verb. For example, where

the requesting verb is “transfer”, then the scope will

assume a deﬁnite OFF DEVICE status. Other am-

biguous requesting verbs such as access, use, collect,

etc., do not provide adequate clarity as to whether or

not the data will be used on the device or otherwise.

Thus, we use a combination of heuristic and logical

reasoning to identify if a purpose can be achieved

strictly ON DEVICE or OFF DEVICE. For instance,

in the Tiktok statement in Figure 1, the scope is not

directly mentioned. However, based on the language

analysis, it can be assumed that the contact data may

be used both on and off the device; hence, the Scope

Limitation considered as OFF DEVICE.

Using the derived ontology of purpose terms, their

data group mapping and the classiﬁcation of scope

limitations above, we then create a strict mapping of

purpose-to-scope to form Intent labels. Table 1, illus-

trate some example of our derived Intent Labels.

3.2 Framework Modiﬁcation

The next task in our proposed permission model after

the aggregation and creation of Intent labels (purpose-

to-scope mapping) is to modify the Android frame-

work so that a developer can leverage our Intent la-

bels to explicitly declare purpose and scope when re-

questing permission to sensitive user data. The An-

droid framework is a set of APIs that allows devel-

opers to create apps and interact with the user, de-

vice and access user data and resources. In the cur-

rent framework, access to speciﬁc user-sensitive data

is made through specialized APIs such as the request-

Permission() function. These function calls currently

take two parameters—the permission and the request

mode.

In our new permission model, we modify the

framework such that additional data structures that

hold the Intent labels are deﬁned. Next, we mod-

ify the requestPermission functions to include three

additional parameters for the Intent labels (purpose

and scope) and user-speciﬁc purpose descriptions. We

then create a program mapping between permissions

and Intent labels such that when a developer chooses

speciﬁc permission, an associated list of approved

purposes for that speciﬁc permission will be popu-

lated. These changes are introduced primarily in the

internal framework code with minimal changes to the

Android developer’s SDK. During app development,

alongside the permission, the developer can choose

from the available Intent label the purpose and scope

limitations of their data requests.

3.3 Permission UI Redesign

The primary objective of the new permission model

is to ensure users are better informed about why their

data is requested and the scope of data usage. Thus,

the ﬁnal task in the design of this model is to mod-

ify the permission check UI such that additional in-

formation for the Intent label is displayed to the user

at runtime. In the current model, permission request

API calls trigger a dialogue box for a user to accept

or deny permission. However, the user is not pro-

vided with the purpose and scope of the data request.

Thus, in our proposed model, we added another dia-

logue box to render the Intent label (purpose-to-scope

limitation) along with the Permission Name. Further-

more, a developer-speciﬁc purpose description or link

to complete privacy statement will also be shown to

the user. We will maintain the two buttons for ac-

cepting or denying the permission. This would give

a comprehensive depiction of the overall purpose of

the request to the user. The user gets to allow the re-

quest based on their satisfaction with the developer’s

chosen Intent. In general, these changes to the per-

mission check dialogue would aid users in making an

informed decision while accepting or denying the per-

mission.

3.4 Implementation

We implemented a prototype of our new permission

model on version 10 of the Android Open Source

Project (AOSP) (Android, 2021). Firstly, we added

two new Enums called - PermissionReasonEnum and

DataScopeEnum to address the purpose and scope

limitations respectively. In the current implemen-

tation, PermissionReasonEnum and DataScopeEnum

are formulated based on the use cases of the fol-

lowing privacy sensitive resources: Location Data,

SMS, Camera, Contact, Device ID, and Call Logs.

We would be extending this implementation further

in the future to address every privacy sensitive data

types in the Android System. Next, we create a new

class called PermissionWithReason with four mem-

ber variables—String permissionName, Permission-

ReasonEnum permissionReasonTitle, String permis-

sionReasonDescription, and DataScopeEnum dataS-

cope. Using case-switch conditional statements, the

implementation of the PermissionWithReason forces

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

158

Table 1: Intent Label to permission mapping.

Data Type Permission Intent Scope

AUTHENTICATION ON DEVICE

Fingerprint USE FINGERPRINT

SECURITY ON DEVICE

ADVERTISEMENT OFF DEVICE

APP EXPERIENCE OFF DEVICE

APP SERVICE OFF DEVICE

CONTENT PERSONALIZATION OFF DEVICE

DIAGNOSTICS OFF DEVICE

ENHANCED SERVICE OFF DEVICE

FRAUD DETECTION OFF DEVICE

PERSONALIZED OFFERS OFF DEVICE

Location ACCESS FINE LOCATION

TRACKING OFF DEVICE

the desired mapping for the Intent labels i.e., map cer-

tain purpose to restricted scope.

In our current implementation, we utilized method

overloading of the requestPermission() function

(which is a scenario of having more than one method

with the same name, but different signatures) to ad-

dress the additional deﬁnition of Intent and back-

ward compatibility to the existing framework. As

mentioned earlier, in the current framework, the re-

questPermission function takes two parameters—a

string array of permission names and code. We then

overload this method with an additional implementa-

tion that takes an ArrayList of PermissionWithReason

class as an additional parameter. To properly declare

Intent, developers are required to use this new func-

tion during app development. They will ﬁrst need

to create an instance(s) of the PermissionWithReason

with their permission name, and then choose the ap-

propriate enum for purpose and scope and then pro-

vide a description of the purpose in string form. Mul-

tiple instances of this class can be created for different

permissions and then passed to the requestPermission

function in an ArrayList.

4 EVALUATION

4.1 Evaluation

To test the effectiveness and usability of our proposed

permission model in terms of functionality and com-

patibility, we conducted two types of evaluations—

functional and performance testings. Our evaluation

method seeks to answer the following questions:

• How easy is it for developers to adopt the pro-

posed permission model for new app development

and backward compatibility with existing apps

built with an old framework?

• What is the performance impact of the new model

on a device after the framework modiﬁcation?

4.1.1 Functional Testing

The functional testing experiment provides a clear

description of how our new permission model can

be built into the exiting Android framework and de-

ployed onto a device. Additionally, this test answers

how easy it is for developers to adopt our framework

and its support for backward compatibility.

We implemented our proposed framework on An-

droid 10 using the Android Open Source Project. Af-

ter adding all the required data types, classes, and

functions to the project, we build and compiled a new

system image containing the new framework code.

Additionally, an SDK containing the new requestPer-

mission method call is also generated. This new sys-

tem image is then ﬂashed into an already created An-

droid Virtual Device (AVD), and the path to the new

SDK is added to the Android studio. Due to tech-

nical and legal constraints in ROM modiﬁcation for

new Android devices (LionGuest-Studios, 2021; Dav-

eTheTytnIIGuy, ), we built and test our prototype only

on an AVD. Nonetheless, we are conﬁdent that our

model can easily be adopted and deployed by Android

and/or any Hardware manufacturer on a real device

without any challenges.

New App Development. To test the ease of use

for developers, we develop a Test app called ”Sam-

pleGPSTesting”. ”SampleGPSTesting” is a lo-

cation detection app that shows current Latitude

and Longitude value based on the user’s current

location. By design, this app require LOCA-

TION data and INTERNET access to accomplish

its app functionality, and hence it request for the

android.permission.ACCESS FINE LOCATION and

android.permission.-INTERNET permissions from

the user in the ﬁrst activity. Thus, in develop-

ing this program, we called the requestPermission

function with four parameters supplying the con-

text, list of permissions, requestCode, List of per-

missionWithReasons. This app is compiled and ex-

ecuted in the emulator. Figure 2 is a screenshot

Intent-aware Permission Architecture: A Model for Rethinking Informed Consent for Android Apps

159

Figure 2: A screenshot of the Permission UI showing the In-

tent labels and description for the SampleGPSTesting app.

of the permission UI dialogue box showing purpose

limitation (NAVIGATION), developer-speciﬁc pur-

pose description (To access...), and scope limitation

(ON DEVICE) of the location data requested by the

SampleGPSTesting.

Modiﬁcation of Exiting App. In this experiment,

we aim to examine how easy is it for develop-

ers to modify existing apps to incorporate the addi-

tional information for purpose and scope during per-

mission requests. We use a case study-based ap-

proach where we modify an existing open-source An-

droid application—Phonograph (AbouZeid, 2020)—

to directly use our proposed framework. We

downloaded the source code from Github and ex-

amined the permission list built into its manifest

ﬁle. This app is designed as a music player and

has the following permission list WAKE LOCK,

READ EXTERNAL STORAGE etc. Based on our

current implementation of the new permission model,

only the READ EXTERNAL STORAGE permission

accesses sensitive data, and thus we mapped this per-

mission to its API call and then manually trace the

API call to identify why access to read the device

storage is requested. Our evaluation shows that the

Phonograph app must read songs from an external

storage unit on the device before playing it. Thus,

with this deducted reasoning, we modiﬁed the app’s

permission requesting functions to use our new re-

questPermission function with PLAY MUSIC pur-

pose and an ON DEVICE scope. After compiling and

generation the apk, we installed the app on our AVD

that runs the modiﬁed version of our framework. As

shown in Figure 3, the modiﬁed app displayed to the

user the requested permission, its purpose limitation,

description, and scope limitation. This additional in-

formation will help users of the Phonograph app in

making informed decisions whether to allow or deny

access to read their external storage.

Figure 3: The screenshot of the Permission UI showing the

Intent labels and description for Phonograph after it was

modiﬁed to use the proposed model.

(a) Twitter (b) Muslim Pro

Figure 4: The screenshots of the Permission UI showing

the Intent labels and description for currently exiting appli-

cations that were compiled with old SDKs.

Backward Compatibility. In the second case

study, we aim to address backward compatibility with

existing apps that use the old framework. In real-

world application scenarios, if Android adopts this

permission model, we can expect all new apps to im-

mediately follow our proposed new model. However,

it will take some time for exiting apps to adapt and

modify, and as such old framework may continue to

exist before being permanently phased out. Thus, our

framework is designed to support backward compat-

ibility and ensure that our new framework does not

break currently exiting applications that were com-

piled with old SDKs. To analyze this requirement, we

installed some existing apps from Google PlayStore

in our framework-modiﬁed AVD. Our results suggest

none of the apps break. All the apps functioned as ex-

pected on the new image. Figure 4 showed the screen-

shots for two apps: Twitter (Twitter, 2021) and Mus-

lim Pro (MuslimPro, 2021). Because both apps were

not compiled with the new framework, the purpose

and scope have defaulted to the NOT PROVIDED.

These case studies conclude that developers can

easily adapt our proposed Framework to create new

apps and update their existing apps. Additionally,

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

160

0.42 0.42

0.48 0.48

0.65

1.77

1.84

2.98

0.5

1.5

2.5

3.5

5 10 25 50

Time in milliseconds

Number of permissions

Current Framework Proposed Framework

Figure 5: Performance chart.

the last test shows our model is backward compatible

with unmodiﬁed apps.

4.1.2 Performance Evaluation

Our framework modiﬁcation and UI redesign phases

have the potential of imposing some performance

overheads particularly in terms of app’s start time. In

this evaluation we seek to determine whether there

would be any signiﬁcant delay in the activity start

time, which can degrade the user’s satisfaction with

the system. We developed a demo app containing 5,

10, 25, and 50 permissions with corresponding pur-

poses and scopes to conduct this test. We change

the number of permissions the app asks for each ex-

ecution and record the activity start time for both

the unmodiﬁed framework and our proposed Android

Framework. The Intent parameters are only provided

when executing the apps in the proposed framework.

All the performance tests were conducted on an AVD

with 16 GB RAM.

Figure 5 shows the comparison between the app’s

initial start time when using the existing framework

versus the proposed framework. As expected, there is

a slight increase in the app’s initial start time, which

also increases linearly with an increase in the num-

ber of permissions. An analysis of this performance

penalty suggests that the additional loop added to

generate the AlertBox and the conditional mapping

of purpose-to-scope limitation are responsible for in-

creasing the app’s initial start time. Given that the

average requested permission for Android apps as

documented by Pew Research is 5, this performance

penalty will be very negligible for most apps.

4.2 Discussion and Limitation

Our evaluation results showed the proposed frame-

work can signiﬁcantly improve user data privacy on

Android applications by enforcing current privacy

laws. In addition, we have shown that our imple-

mentation is easy to build and deploy by device man-

ufactures and can easily be adopted by developers.

Furthermore, our backward compatibility test showed

that exiting apps can still work with the new frame-

work. While our implementation has addressed some

critical challenges, it has some important limitations

that we hope to address in future work.

• Blind Trust: Currently, the existing system blindly

trusts that the developer will only be using the re-

quired data for the declared purpose, and there is

no mechanism to check if the developer choose to

use the data otherwise. Thus, in our future work,

we hope to develop a more trustful permission ar-

chitecture using memory analysis backward prop-

agation to ensure that data requested for a partic-

ular purpose and on-device scope are enforced.

• Multi-Purpose Request: Our current implementa-

tion is limited to a single purpose. We plan to

implement a multi-purpose scope to improve the

usability of the proposed permission model.

• Usability Testing: Our evaluation is focused en-

tirely on the functional architecture of our pro-

posed Permission model. Given that this is a

user privacy-preserving technique, the usability

of the system between users from various groups

and backgrounds would be investigated as part of

our future work. In addition, the usability tests

on developers will also be conducted to under-

stand their adaptability and comfort in the pro-

posed model. These testings will help us create

a more usable dialogue prompt, streamlined pur-

pose categorization, and Intent labels.

5 Related Work

5.1 Low-level Modiﬁcation

Several studies have explored the introduction of ﬁne

controls over permissions at the framework, the mid-

dle layer, or the operating system-level using different

strategies (Beresford et al., 2011; Zhou et al., 2011;

Brutschy et al., 2015; Nauman et al., 2010; Jeon et al.,

2012; Liu et al., 2016b; Caputo et al., 2021). Pro-

posed techniques such as Mockdroid (Beresford et al.,

2011), and TISSA (Zhou et al., 2011) facilitate users

to control access whenever access to the resource is

attempted by providing dummy information instead

of the real one. This strategy allows most applications

to continue execution at the expense of potential use-

fulness. Apex (Nauman et al., 2010) propose a mech-

anism for users to carefully grant permissions to apps

Intent-aware Permission Architecture: A Model for Rethinking Informed Consent for Android Apps

161

based on runtime contextual information, such as the

device location or how frequently a resource has been

previously used. Other solutions such as (Hornyack

et al., 2011; Shinde and Sambare, 2015; Liu et al.,

2016a; Rashidi et al., 2016; Chen et al., 2017; Raval

et al., 2019) proposed permission conﬁguration in-

terface that will allow users to control the activities

of third-party apps. FlaskDroid (Bugiel et al., 2013)

on the other hand, provides compulsory access con-

trol on Android’s middleware and kernel layers to

avert unwanted information disclosure. Some recent

solutions, such as (Caputo et al., 2021) focused on

anonymization of data to preserve the privacy of the

user. In (Qu et al., 2020), authors introduce an au-

tomatic permission management model, which col-

lectively considers the risk of the permission, func-

tionalities of the app, and user’s privacy requirement.

However, none of these solutions helps users under-

stand the Intent of the developer. Furthermore, there

is no policy integrated into the fabric of Android OS

to reveal the Intent behind each permission, making it

more difﬁcult for users to make informed decisions.

5.2 Application-level Modiﬁcation

AppIntent (Yang et al., 2013) proposes an

application-level solution that aims to control

information dissemination by identifying if the user

intends the transmission. Though this solution is

much related to our proposed method, it is a reactive

approach that does not consider introducing the

developer’s Intent for the data request in the Android

permission process. In contrast, our work takes a

proactive approach that provides end-users with an

explicit declaration of the developer’s Intent upfront

during permission requests. Other app-level ﬁne-

grain permission or permission reduction solutions

are (Jeon et al., 2012; Backes et al., 2012; Backes

et al., 2013; Davis and Chen, 2013; Zhang and

Yin, 2014; Brutschy et al., 2015; Ali-Gombe et al.,

2016). Dr. Android (Jeon et al., 2012) retroﬁts

apps to allow for the speciﬁcation of ﬁne-grained

variants of Android permissions by accumulating

existing permission into a taxonomy, each of which

admits some common strategies for deriving sub-

permissions. In (Do et al., 2014; Chen et al., 2019),

the authors introduce a permission removal approach

to mitigate privacy leaks in Android. Appguard

(Backes et al., 2012; Backes et al., 2013) and

RetroSkeleton (Davis and Chen, 2013) are both an

app-agnostic ﬂexible and dynamic policy re-writing

solutions designed towards enhancing security and

privacy in untrusted Android applications. Capper

(Zhang and Yin, 2014) is an app-level taint tracking

system that examines sensitive data ﬂow from source

to sink. SHAMDROID (Brutschy et al., 2015)

proposes a permission slicing, and reduction solution

aims at degrading apps functionality in the resource

constraint systems like Android. priVy(Ali-Gombe

et al., 2016) is a portable, ﬁne-grained access control

solution designed to achieve permission reduction in

the Android native content providers. While these

solutions are geared towards permission reduction

and enhancing user privacy, unlike our proposed

solution, these solutions do not explicitly state the

developer’s purpose and scope for requesting the

user data, thus hindering users’ ability to make

an informed decision. Other related work such as

Flowverine provides an app developer with the tools

to build a privacy-aware and secured app (Gomes

et al., 2020). Although this mechanism allows the

system to track a certain app’s data ﬂow, it does not

give the user control over their data. Conﬁgurable

User Privacy Approach (CUPA) (Alkindi et al.,

2020), proposes a conﬁguration mechanism for users

to have complete control over the data ﬂow of the

app and can intercept if necessary. This solution,

however, lies in the lack of technical knowledge of

the user to deﬁne the required policies. In contrast,

our solution builds an aggregated labels for Intent

based on a extensive ontology study, which are then

used for deﬁning purpose and scope limitations. The

combination of the proposed Intent speciﬁcation,

scope, and description makes it easier for users to

decide whether to allow or deny the request for their

privacy-sensitive data at runtime.

6 CONCLUSION

User data privacy is a fundamental human right that

tech companies and service providers, particularly

mobile providers, often violate and abuse. In this

paper, we extended the current Android permission

model to address this issue. Our model ensures users

can make an informed decision with adequate infor-

mation before approving data access on Android de-

vices. The design of our model includes a manual

aggregation of request purposes which is mapped to

scope limitation to form Intent labels. These Intent

labels are then built into the new permission model

for easy categorization of purpose-to-scope limita-

tion. Our evaluation showed the new model could

aid apps to comply with the requirements of the cur-

rent regulations while incurring very minimal perfor-

mance overhead. In addition, the minimal changes

required by the developer make the adoption of this

model easy while still providing backward compati-

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

162

bility for non-complying apps.

ACKNOWLEDGEMENTS

This work is supported by the National Science Foun-

dation (NSF) Grant Number 1850054 and Towson

University OSPR Pilot Research Seed Grant.

REFERENCES

AbouZeid, K. (2020). Phonograph - A material designed

local music player for Android. https://github.com/

kabouzeid/Phonograph. (Accessed on June 15, 2021).

Ali-Gombe, A., Richard III, G. G., Ahmed, I., and Rous-

sev, V. (2016). Don’t touch that column: Portable,

ﬁne-grained access control for android’s native con-

tent providers. In Proceedings of the 9th ACM Con-

ference on Security & Privacy in Wireless and Mobile

Networks, pages 79–90.

Alkindi, Z., Sarrab, M., and Alzidi, N. (2020). Cupa: A

conﬁgurable user privacy approach for android mo-

bile application. In 2020 7th IEEE International

Conference on Cyber Security and Cloud Computing

(CSCloud)/2020 6th IEEE International Conference

on Edge Computing and Scalable Cloud (EdgeCom),

pages 216–221. IEEE.

Android (2021). Android open source project. https:

//source.android.com/. (Accessed on June 1, 2021).

Backes, M., Gerling, S., Hammer, C., Maffei, M., and von

Styp-Rekowsky, P. (2012). Appguard-real-time policy

enforcement for third-party applications.

Backes, M., Gerling, S., Hammer, C., Maffei, M., and

von Styp-Rekowsky, P. (2013). Appguard–enforcing

user requirements on android apps. In International

Conference on TOOLS and Algorithms for the Con-

struction and Analysis of Systems, pages 543–548.

Springer.

Beresford, A. R., Rice, A., Skehin, N., and Sohan, R.

(2011). Mockdroid: trading privacy for application

functionality on smartphones. In Proceedings of the

12th workshop on mobile computing systems and ap-

plications, pages 49–54.

Breaux, T. D., Hibshi, H., and Rao, A. (2014). Eddy, a for-

mal language for specifying and analyzing data ﬂow

speciﬁcations for conﬂicting privacy requirements.

Requirements Engineering, 19(3):281–307.

Breaux, T. D. and Schaub, F. (2014). Scaling requirements

extraction to the crowd: Experiments with privacy

policies. In 2014 IEEE 22nd International Require-

ments Engineering Conference (RE), pages 163–172.

IEEE.

Brutschy, L., Ferrara, P., Tripp, O., and Pistoia, M. (2015).

Shamdroid: gracefully degrading functionality in the

presence of limited resource access. ACM SIGPLAN

Notices, 50(10):316–331.

Bugiel, S., Heuser, S., and Sadeghi, A.-R. (2013). Flexi-

ble and ﬁne-grained mandatory access control on an-

droid for diverse security and privacy policies. In 22nd

USENIX Security Symposium, pages 131–146.

Caputo, D., Pagano, F., Bottino, G., Verderame, L., and

Merlo, A. (2021). You can’t always get what you

want: towards user-controlled privacy on android.

arXiv preprint arXiv:2106.02483.

Cate, F. H. (2010). The limits of notice and choice. IEEE

Security & Privacy, 8(2):59–62.

CCPA (2021). California consumer privacy act (ccpa).

https://oag.ca.gov/privacy/ccpa. (Accessed on May

29, 2021).

Chen, X., Huang, H., Zhu, S., Li, Q., and Guan, Q. (2017).

Sweetdroid: Toward a context-sensitive privacy pol-

icy enforcement framework for android os. In Pro-

ceedings of the 2017 on Workshop on Privacy in the

Electronic Society, pages 75–86.

Chen, Y., Zha, M., Zhang, N., Xu, D., Zhao, Q., Feng, X.,

Yuan, K., Suya, F., Tian, Y., Chen, K., et al. (2019).

Demystifying hidden privacy settings in mobile apps.

In Proceedings of IEEE Symposium on Security and

Privacy, pages 570–586. IEEE.

Das, A., Acar, G., Borisov, N., and Pradeep, A. (2018).

The web’s sixth sense: A study of scripts accessing

smartphone sensors. In Proceedings of the 2018 ACM

SIGSAC Conference on Computer and Communica-

tions Security, pages 1515–1532.

DaveTheTytnIIGuy. Is ﬂashing roms legal? well i

went straight to the big guys. https://forum.xda-

developers.com/t/is-ﬂashing-roms-legal-well-i-went-

straight-to-the-big-guys.598449/. (Accessed on June

15, 2021).

Davis, B. and Chen, H. (2013). Retroskeleton: Retroﬁtting

android apps. In Proceeding of the 11th annual inter-

national conference on Mobile systems, applications,

and services, pages 181–192.

Do, Q., Martini, B., and Choo, K.-K. R. (2014). Enhanc-

ing user privacy on android mobile devices via per-

missions removal. In Proceedings of the 47th Hawaii

International Conference on System Sciences, pages

5070–5079. IEEE.

Doan, S., Ohno-Machado, L., and Collier, N. (2012). En-

hancing twitter data analysis with simple semantic ﬁl-

tering: Example in tracking inﬂuenza-like illnesses. In

2012 iEEE second international conference on health-

care informatics, imaging and systems biology, pages

62–71. IEEE.

GDPR (2021). General data protection regulation- gdpr.

https://gdpr-info.eu/. (Accessed on May 29, 2021).

Gluck, J., Schaub, F., Friedman, A., Habib, H., Sadeh, N.,

Cranor, L. F., and Agarwal, Y. (2016). How short

is too short? implications of length and framing on

the effectiveness of privacy notices. In Twelfth Sym-

posium on Usable Privacy and Security ({SOUPS}

2016), pages 321–340.

Intent-aware Permission Architecture: A Model for Rethinking Informed Consent for Android Apps

163

Gomes, E., Zavalyshyn, I., Santos, N., Silva, J., and Legay,

A. (2020). Flowverine: Leveraging dataﬂow program-

ming for building privacy-sensitive android applica-

tions. In Proceedings of 19th IEEE International Con-

ference On Trust, Security And Privacy In Computing

And Communications (TrustCom)(to appear).

Hornyack, P., Han, S., Jung, J., Schechter, S., and Wether-

all, D. (2011). These aren’t the droids you’re looking

for: retroﬁtting android to protect data from imperi-

ous applications. In Proceedings of the 18th ACM

conference on Computer and communications secu-

rity, pages 639–652.

Hutchinson, A. Apple ofﬁcially launches new

app tracking permissions as part of ios 14.5.

https://www.socialmediatoday.com/news/apple-

ofﬁcially-launches-new-app-tracking-permissions-

as-part-of-ios-145/599057/. (Accessed on June 15,

2021).

Jensen, C. and Potts, C. (2004). Privacy policies as

decision-making tools: an evaluation of online pri-

vacy notices. In Proceedings of the SIGCHI confer-

ence on Human Factors in Computing Systems, pages

471–478.

Jeon, J., Micinski, K. K., Vaughan, J. A., Fogel, A., Reddy,

N., Foster, J. S., and Millstein, T. (2012). Dr. android

and mr. hide: ﬁne-grained permissions in android ap-

plications. In Proceedings of the second ACM work-

shop on Security and privacy in smartphones and mo-

bile devices, pages 3–14.

LionGuest-Studios (2021). Method overloading. https:

//www.youtube.com/watch?v=ffsyQcSOnFw. (Ac-

cessed on June 15, 2021).

Liu, B., Andersen, M. S., Schaub, F., Almuhimedi, H.,

Zhang, S. A., Sadeh, N., Agarwal, Y., and Acquisti,

A. (2016a). Follow my recommendations: A person-

alized privacy assistant for mobile app permissions. In

Twelfth Symposium on Usable Privacy and Security

({SOUPS} 2016), pages 27–41.

Liu, R., Liang, J., Cao, J., Zhang, K., Gao, W., Yang, L.,

and Yu, R. (2016b). Understanding mobile users’ pri-

vacy expectations: A recommendation-based method

through crowdsourcing. IEEE Transactions on Ser-

vices Computing, 12(2):304–318.

MuslimPro (2021). The most popular muslim app! https:

//www.muslimpro.com/. (Accessed on June 1, 2021).

Nauman, M., Khan, S., and Zhang, X. (2010). Apex: ex-

tending android permission model and enforcement

with user-deﬁned runtime constraints. In Proceedings

of the 5th ACM symposium on information, computer

and communications security, pages 328–332.

Qu, Y., Du, S., Li, S., Meng, Y., Zhang, L., and Zhu, H.

(2020). Automatic permission optimization frame-

work for privacy enhancement of mobile applications.

IEEE Internet of Things Journal.

Rashidi, B., Fung, C., and Vu, T. (2016). Android ﬁne-

grained permission control system with real-time ex-

pert recommendations. Pervasive and Mobile Com-

puting, 32:62–77.

Raval, N., Razeen, A., Machanavajjhala, A., Cox, L. P., and

Warﬁeld, A. (2019). Permissions plugins as android

apps. In Proceedings of the 17th Annual International

Conference on Mobile Systems, Applications, and Ser-

vices, pages 180–192.

Reidenberg, J. R., Breaux, T., Cranor, L. F., French, B.,

Grannis, A., Graves, J. T., Liu, F., McDonald, A., Nor-

ton, T. B., and Ramanath, R. (2015). Disagreeable

privacy policies: Mismatches between meaning and

users’ understanding. Berkeley Tech. LJ, 30:39.

Santaholma, M. E. (2007). Grammar sharing techniques

for rule-based multilingual nlp systems. In Proceed-

ings of the 16th Nordic Conference of Computational

Linguistics (NODALIDA).

Shinde, S. S. and Sambare, S. S. (2015). Enhancement

on privacy permission management for android apps.

In 2015 Global Conference on Communication Tech-

nologies (GCCT), pages 838–842. IEEE.

Twitter (2021). Twitter. https://twitter.com/. (Accessed on

June 1, 2021).

Yang, Z., Yang, M., Zhang, Y., Gu, G., Ning, P., and Wang,

X. S. (2013). Appintent: Analyzing sensitive data

transmission in android for privacy leakage detection.

In Proceedings of ACM SIGSAC conference on Com-

puter & communications security, pages 1043–1054.

Zhang, M. and Yin, H. (2014). Efﬁcient, context-aware

privacy leakage conﬁnement for android applications

without ﬁrmware modding. In Proceedings of the 9th

ACM symposium on Information, computer and com-

munications security, pages 259–270.

Zhou, Y., Zhang, X., Jiang, X., and Freeh, V. W. (2011).

Taming information-stealing smartphone applications

(on android). In Proceedings of International confer-

ence on Trust and trustworthy computing, pages 93–

107. Springer.

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

164