DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2018
Permission Based Risk Assessment for Enhancing Privacy of Android Users
MUHAMMAD RASHID IDRIS
KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE
Abstract
Mobile applications tend to access data beyond their intended functionality and share this data with third parties for various purposes including marketing, profiling and advertisement. This data also includes user’s personal information and access to this personal information without user’s consent put user’s privacy at risk. User’s Inability to easily find privacy friendly apps and befuddling permission requests paves the way for malicious apps to get access to user’s personal information.
Keeping in mind the different level of privacy aware users, we have presented a privacy enforcement framework in this thesis. This framework not only helps user to find alternative privacy friendly apps but also encourage users to review their privacy settings on the smartphone. An app discovery tool is developed to search privacy friendly apps amongst the group with similar functionality. The search results are sorted by privacy friendly score which is calculated using simplified version of risk assessment method known as EBIOS. Threat posed to personal information by various apps are then highlighted and presented to user in an easy-to-understand way before installing the app.
We have validated the results of our discovery tool by comparing them to the manual inspection of various functional groups i.e., group of applications with similar functionality. Two list of permissions, one created by subjective and manual analysis of abstract functionality of functional group called expert opinion and other created by our tool based on permissions requested by functional group are compared. Our tool has correctly identified the permissions which are similar to expert opinion.
Keywords: Android; Mobile apps; Privacy; Risk assessment; Principle of Least Privilege; EBIOS
ii
Referat
Mobila applikationer tenderar att ta del av data utanför deras tilltänkta funktionalitet och delar den här datan med tredjehands parter för olika syften som marknadsföring, profilering och reklam. Datan inkluderar även personlig information och tillgång till den personliga informationen utan användarens medvetande sätter användarens integritet i risk. Användares oförmåga att enkelt hitta integritetsvänliga appar och förvirrande godkännande förfrågningar öppnar vägen för illvilliga appar att få tillgång till användarens personliga information.
Med tanke på hur olika användare uppmärksammar integritetnivåer presenterar vi ett integritetsupprätthållande ramverk i den här uppsatsen. Ramverket hjälper inte bara användare att hitta integritetsvänliga appar utan uppmuntrar även användaren att granska integritetsinställningarna i sin telefon. Ett applikationsupptäckarverktyg utvecklades för att söka efter integritetsvänliga appar inom samma funktionsområde. Sökresultatet är sorterat efter en integritetsvänlighetspoäng beräknad med en förenklad version av riskbedömningsmetoden känd som EBIOS. Hot mot personlig information från olika appar uppmärksammas och presenteras på ett användarvänligt sätt innan appen installeras.
Vi har validerat resultatet från vårt applikationsupptäckarverktyg genom att jämföra det med en manuell inspektion av appar inom samma funktionsområde, exempelvist grupper av applikationer med liknande funktion. Två listor togs fram, en framtagen genom subjektiv och manuell analys av normal funktionalitet kallad expertutlåtande och en framtagen av vårt applikationsupptäckarverktyg baserat på funktionsområde. Vårt verktyg har korrekt identifierat godkännande i likhet med expertutlåtandet.
Nyckelord: Android; Mobila appar; Integritet; Riskbedömningsmetoden; Princip om lägst privilegium; EBIOS
iii
Acknowledgements
All praises be to Almighty Allah, the most merciful and compassionate, who gave me strength and ability to complete this thesis successfully. I am highly obliged to Research Institutes of Sweden (RISE) for giving me opportunity to complete my master’s thesis and be part of this prestigious institution.
I express my gratitude to Arash Vahidi, my supervisor at RISE, for his continuous supervision, help and encouragement throughout the thesis. During the course of this thesis Arash’s supervision proved to be invaluable in guiding me in the right direction.
I would also like to thank my examiner Prof. Sarunas Girdzijauskas for his helpful feedback and suggestions that improved my work significantly. I am also grateful to all the members of security group at RISE, Stockholm, who have provided valuable input whenever needed.
Finally, I would like to thank my family for being very supportive, patient and encouraging all along.
Stockholm, December 15, 2018 Muhammad Rashid Idris
iv
Contents
1. INTRODUCTION ...... 1
1.1 BACKGROUND ...... 2 1.2 PROBLEM STATEMENT ...... 3 1.3 PURPOSE & GOALS ...... 4 1.4 BENEFITS, ETHICS AND SUSTAINABILITY ...... 5 1.5 METHODOLOGY ...... 6 1.6 DELIMITATIONS ...... 8 1.7 THESIS OUTLINE ...... 8
2. BACKGROUND & RELATED WORK ...... 9
2.1 PRIVACY ...... 9 2.2 SMARTPHONE AND USER ASSETS ...... 10 2.3 ANDROID PLATFORM ...... 10 2.4 ANDROID ARCHITECTURE OVERVIEW ...... 12 2.5 ANDROID SECURITY OVERVIEW ...... 14 2.6 APS LIMITATIONS ...... 18 2.7 RELATED WORK ...... 24 3. PROPOSED FRAMEWORK ...... 26
3.1 OVERVIEW ...... 26 3.2 PRIVACY VISUALIZATION ...... 28 3.3 PERMISSIONS MANAGEMENT ...... 38 3.4 PRIVACY NUDGING ...... 40 4. IMPLEMENTATION ...... 43
4.1 PEF COMPONENTS ...... 43 4.2 EXECUTION ...... 47
5. EVALUATION & DISCUSSION ...... 50
5.1 POLP COMPLIANCE...... 50 5.2 PRIVACY VISUALIZATION ...... 54 5.3 PERMISSIONS GROUPING & CONTEXT ...... 57 5.4 GENERAL STATISTICS ...... 60 5.5 LIMITATIONS ...... 62
6. SUMMARY & FUTURE WORK ...... 64
6.1 FUTURE WORK ...... 64 6.2 FUTURE WORK ...... 65 BIBLIOGRAPHY ...... 67
APPENDIX 1 ...... 73
APPENDIX 2 ...... 75
v
Figures
Figure 1: Worldwide app store downloads [3] ...... 12 Figure 2: Number of apps available in various app stores [30] ...... 12 Figure 3: Android architecture [32] ...... 13 Figure 4: Android application sandboxing ...... 15 Figure 5. Permission mechanism to access system resources...... 15 Figure 6: Permission approval in different android versions...... 17 Figure 7: List of permissions requested by two apps with same functionality ...... 20 Figure 8: Different views of permissions presented to user...... 21 Figure 9: Permissions grouping and description...... 22 Figure 10: PEF phases for an app ...... 28 Figure 11: Existing and proposed permissions description ...... 35 Figure 12: Permissions management under three different levels ...... 40 Figure 13: Privacy nudge view under three different levels ...... 42 Figure 14: Visual representation of privacy friendliness score ...... 45 Figure 15: A view of requested permissions presented to user ...... 46 Figure 16: Search interface for PEF’s web-based app store ...... 49 Figure 17: Search results page showing the privacy friendly score for each app ...... 49 Figure 18: Grid view of search results generated by PEF ...... 55 Figure 19: List view of search results generated by PEF ...... 56 Figure 20: Basic view of PEF’s permission dialog ...... 58 Figure 21: Basic view of PEF’s permission dialog ...... 59 Figure 22: Apps with same number of permissions but different scores ...... 61 Figure 23: Privacy score for top 8 browsers ...... 62
vi
Tables
Table 1: EBIOS severity level and corresponding numeric value ...... 31 Table 2: Chosen permissions based on co-relation with the identity of user...... 33 Table 3: Proposed permissions group and corresponding dangerous permissions ...... 38 Table 4: Permission management settings under different privacy levels ...... 38 Table 5: PEF components and corresponding implementation level ...... 47 Table 6: Selected functional groups and their android category ...... 50 Table 7: Permission Policy for functional group “Navigation” generated by PEF. .... 51 Table 8: Permission Policy for functional group “web browser” generated by PEF. . 52 Table 9: Permission Policy for functional group “Photo Editor” generated by PEF. . 52 Table 10: Permission policy for functional group “Flashlight” generated by PEF. .... 53 Table 11: Permission Policy for functional group “weather” generated by PEF...... 53 Table 12: Number of privacy friendly alternative apps under each functional group . 60
vii
List of Acronyms
AnMa Android Marshmallow (Android OS v6, API version 23)
API Application Programmable Interface
APP Application or Mobile application
APS Android permissions system
ART Android Application Runtime
CIA Confidentiality, Integrity and Availability
DEX Dalvik Executable
DVM Dalvik Virtual Machine
GDPR General Data Protection Regulation
GID Group ID
GPS Geographic Positioning System
ICCID Integrated Circuit Card Identifier
IMEI International Mobile Equipment Identity
IMSI International Mobile Subscriber Identity.
IPC Inter-process communication
HAL Hardware abstraction layer
HPL High Privacy Level
LPL Low Privacy Level
MSISDN Mobile Station International Subscriber
MPL Medium Privacy level
NDK Native Development Kit
PoLP Principle of least privilege
viii
ix
Chapter 1
Introduction
The popularity of smartphones and other hand-held devices has increased exponentially in this decade. The support for third-party apps is primary reason for adoption of smartphones. Global smartphones shipment reached 1.4 billion in 2017 compared to 0.17 billion in 2009 [1]. With around 1.2 billion shipments in 2017, android based smartphones leading the market with a share of 85 percent [2]. Just like the hardware units, android based mobile applications are also dominating the application store with over 2.8 million applications which were downloaded over 95 billion times on various devices [3].
Smartphones are being used these days for variety of tasks such video conferencing, payments, audio/video recording, gaming, electronic identification, navigation etc. The apps provide the desired functionality by accessing the device’s hardware (i.e., GPS, camera) and the data from default apps and storage (i.e., contact list, files). With such extensive usage, users are carrying more and more sensitive personal data in their devices. This includes but not limited to user’s identity information, location information, contact list & correspondence, picture & videos and even bank details. Perspective of such personal data has attracted the attention of various players including governments. This data is accessed by apps beyond their intended functionality [4, 5] and by the third-party libraries used by the app. This data can be used for advertising, marketing, profiling and other purposes even without user’s consent [6, 7, 8, 9, 10, 11].
Keeping in mind the avowed privacy violations, platforms have devised various mechanism which can help users to have control over their data. One of such popular mechanisms is known as permission manager [12] with the help of permission manager a user can allow or deny the access to certain resource requested by an app. For example,
1 user may allow the navigational app to access its location information but deny access to contact list. However, the decision to allow or deny access to sensitive information is entirely delegated to users which can be a challenging for users who are not aware of risks and consequences associated with unwanted access to their data. Also, permission managers give same level of control to all users and thus users with reasonable security & privacy awareness don’t get enough control on their data.
The focus of this research is to study how a user can be better informed about the risks that an android app can pose to even before app installation and have better control over data that an app can access after app installation.
1.1 Background
Apps used in smartphones, are built for a specific functionality and based on that functionality grouped under specific category. In order to function, an app may need access to different resource(s) which could be device sensors or data stored in device. To access a particular resource, app require permission which user can allow or deny. For example, a navigational app needs to access device’s location accessible via GPS sensors in order to find the shortest path between two locations. User can grant the access to GPS sensor either before installing an app or during app usage. For each resource, a permission has been defined by android and application has to declare and use this permission via programming API’s provided by android in order to access the resource. For example, permission to access device’s storage is READ_EXTERNAL_STORAGE and permission to read events from calendar is READ_CALENDAR. Many individual permissions are grouped together based on resources e.g., the permissions to access device’s GPS location (ACCESS_FINE_LOCATION) and approximate location based on network (ACCESS_COARSE_LOCATION) are grouped under Location. User can see the individual permissions required by the app but can only approve or revoke on group level. All the permissions defined by an app are listed in app page in app store which user can review if desire to before installing an app.
In earlier1 versions of android, all permissions requested by app must be approved before installation, however with AnMa2, the permissions are approved in context, that means when the app requires a particular resource, it will ask user’s permissions to access that resource. The detail of this difference is explained in section 2.5.3.
AppOps is android’s permission manager which was introduced in android version 4.3 as a hidden feature and later removed in version 4.4.2. But it was re-introduced with AnMa but not as a separate app, instead it is merged in app details under settings. It allows
1 Before Android Marshmallow, Android OS version < 6, API version below 23 2 Android Marshmallow (AnMa), Android OS version 6, API version 23.
2 user to control group permissions for each app. If an app requires access to location and camera, user can revoke the access to any or both these resources. Since it’s not officially called AppOps anymore and neither does it is a separate app, but we will still refer this functionality as AppOps in rest of this thesis.
The apps violate the Principle of Least Privilege (PoLP) [13] when they request to access data that is not required for core functionality of the app. PoLP also known as Principle of minimal privilege or principle of least authority, requires that a module must only access those resources which is absolutely necessary for its legitimate operation. A module and resource in this principle is an abstraction and it can vary depending on the context i.e., module can be user, thread, component, system etc. In our context a module will be app and resource will be user’s personal information.
Along with violation of PoLP, there are some more issues around android permission system (APS) that compromises user’s privacy. The android permissions and their current grouping are vague and can’t help users to figure out the implications of requested permissions if approved [14, 15, 16]. The permissions grouping and presentation confuses the user which results in weak privacy decisions [15]. Apps come coupled with different advertising, analytics and other malicious libraries. Sometime app itself is not malicious but third-party libraries used within the app has malicious intent [17].
In this thesis, we will look into ways to improve the APS so that it can help user to take better security and privacy decisions and help in having better control over data. Since mobile ecosystem is multi-party system (developers, app stores, device vendors etc.) in which some parties are not in our control, such as developers who requests permissions in code at first place, we will put forward suggestions for such parties where applicable.
1.2 Problem statement
Current security model of android based smartphone relies on users for not only granting access to resource but also to decide about the privacy invasive nature of an application either before or after installation. Research by Kelly et al. [14] reveals that users are not well prepared to make informed privacy and security decisions about applications because they believe that permissions are vague, and at worst confusing, misleading, jargon-filled, and poorly grouped. This was further confirmed in a survey conducted by Benton et al. [15] which shows that the permissions dialog presented to users is ineffective because users can’t figure out the implications of permissions listed there and upon learning the implications of requested permissions, users showed an intent to uninstall the given app.
Apps tend to request more permissions than required and thus violating PoLP. Alenezi et al. [4] reviewed 71 top rated education apps and found that 80.3% apps have requested
3 more permissions than required. Felt et al. [16] reviewed 940 applications and found that one third of applications are over privileged. Stevens et al. [17] observed that third party ad libraries take advantage of undocumented permissions whenever possible.
Another problem with android permission model is that it considers all users as equal and with such a rigidness in permission system, desired trade-offs between functionality and security are not possible [18, 19].
APS defines the permissions at individual or fine-grained level however the user is only given control at group or coarse-grained level. For example, there are two permissions defined for device storage, READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE, but there is one control for both permissions called Storage. So, if an app requires both of these permissions, user can’t approve one of it and deny the other. With group level control, either both of these permissions will be approved, or both will be denied. Furthermore, many important permissions like INTERNET are always approved and can’t be controlled by user.
Current limitations and rigidities when combined with inadequate user’s decisions about security and privacy in permission-based model, puts the user’s data at high risk. We believe that the limitations in APS are all connected and can be abridged with a solution based on a holistic approach and thus the research question examined is:
Can user’s privacy about android apps be enhanced by preemptive risk assessment and by informing about the risks that android app can pose to user’s data?
1.3 Purpose & Goals
In light of our research question, the purpose of this master thesis project will be to propose, develop and evaluate a framework called Privacy Enforcement Framework (PEF) to cater the limitations in the current APS. This framework will address the issues at three stages 1) During search and before installing the apps and 2) after installation and 3) while using the app. The first stage will help user deciding whether an app is privacy friendly or invasive by assigning a privacy score to the app. Further the permissions requested by the app will be presented in new way which will informs users about the legitimate and illegitimate permission requests and the risks associated with those permissions. In second and third stage, user will be nudged about the resource access which will motivate the user to review and control the permissions with modified permission manager. In order to answer our research question, following goals are setup;
4
• Privacy visualisation: Pre-emptively view the privacy nature of an app visually. This goal has three sub-goals;
o Perform risk assessment: Calculate privacy friendly score for an app based on permissions it requests and severity of those permissions.
o Permissions grouping: Re-group & re-define the android permission description which should help user understanding the permissions request.
o Permissions contextualization: Introduce the permissions context based on functionality which will make permission request relevant and persuasive.
• Permissions Management: Propose the changes to existing permission manager with fine-grain control.
• Privacy nudging: Refine nudges with limited & time-bound access to resource, and privacy information.
1.4 Benefits, Ethics and sustainability
1.4.1 Benefits
Generally speaking, being able to find if an app is privacy invasive and to what extent can help all users who are using android based mobile phones and are worried about their personal information that might get used illegitimately. This work in this thesis can also help the open-source community that develops more privacy friendly apps and android operating system distributions.
1.4.2 Ethics
The major part of this study is about risk assessment of apps based on the requested permissions. We collect the app information using a non-official third-party API provided by AppBrain3 which crawls and collects data available on android’s official app store called Google Play4. The searching algorithm used by AppBrain is different than Google Play and thus the search results generated are similar but not exactly the same. Also, sometimes the API doesn’t respond or fail to parse the crawled information in which case list of permissions might not reflect all the permissions requested by the app. Regardless of anomalies, API serves its purpose well.
3 https://www.appbrain.com 4 https://play.google.com
5
Furthermore, the risk assessment method we have used is not an international standard and simplified from its original form. So, the privacy invasive nature of an app highlighted by our work is by no means the endorsement but a suggestion. It is merely based on permissions requested and the severity of those permissions which is defined by us and again not a standard.
1.4.3 Sustainability
Public concern over privacy of electronic data has risen tremendously in last two decades and as a result government and companies have been forced to draft policies and deploy mechanisms to enforce those policies for protection of personal information. General Data Protection Regulation (GDPR)5 is the recent example of such enforcement started by 25 May 2018 in Europe. Our work can contribute to all such mechanisms where user’s must be informed about the risks of granting access to certain resources within the domain of smartphones. It can also help users to have better and stricter control over their data.
In 2015, General Assembly of United Nations adopted the agenda known as Agenda 20306 which formulated 17 goals for sustainable development. The goal number 16 “peace, justice and strong institutions” talks about strengthening the rule of law and promoting human rights. Our work can contribute towards this goal because privacy of any form is recognized as fundamental human right by United Nations and many countries and international treaties.
1.5 Methodology
Methodology for the research project outline the course of actions that will be taken to ensure the quality of results. Quantitative and Qualitative are two basic methodologies and one of these methodologies must be selected for a research project. Each of these basic categories govern the subsequent philosophical assumptions, research methods, research approaches, research strategy, data collection and analysis methods. Quantitative research helps in verification or falsification of hypothesis by conducting experiments and measuring variables using statistics over the large datasets. Qualitative methodology, on the other hand, requires smaller datasets and helps in formulating provisional hypothesis and theories by understanding meanings, opinions, and behaviors.
For this study, we will choose qualitative methodology because we are proposing a framework which will help in enhancing the user’s awareness about the privacy nature of android applications so that user can take better privacy & security decisions regarding
5 https://eugdpr.org/ 6 http://www.undp.org/content/gcp/en/home/2030agenda/post-2015-development-agenda.html
6 its personal information that an app can access. The output of this method can be influenced by other subjective opinions about an app in terms privacy and can change the user decision and hence can’t be quantified.
1.5.1 Philosophical assumptions
After choosing the research methodology, philosophical assumptions are the foremost important step that helps steer the whole research. There are four core assumptions outlined by Håkansson [20] are Positivism, Realism, Interpretivism, and Criticalism. Other than positivism, all three work with qualitative research.
In order to answer the research question posed in this research, we assume realism and interpretivism as philosophical assumption. Realism assumes that things, in the reality, exists, regardless how it is perceived or regardless of theories people have about it. Interpretivism assumes that reality is interpreted by individuals based on meanings assigned to phenomenon. Since privacy is a very subjective matter, users can have different opinions, perspectives and experiences when it comes to privacy so it can be interpreted differently. Privacy violation by mobile apps is now well known and based on permissions requested by apps, we will analyze which apps can be privacy invasive.
1.5.2 Research methods
Research methods includes the procedures of initiating, carrying out and completing the research task. Håkansson [20] has outlined 8 research methods namely Experimental, Non-experimental, Descriptive, Analytical, Fundamental, Applied, Conceptual and Empirical. Although many research methods can be used with qualitative research, but we have two research methods Applied and Conceptual suits our research.
Applied research method builds on existing research to solve known problems or answering specific questions. The result is usually usable practical tool or application. With conceptual research method, either new concept is presented, or an existing concept is investigated and improved. Since the practical problems are known at hand in this research and in one part of our solution, we have developed an application that can help solve that problems. In the other part, we have developed a new concept which is about having different levels of privacy for different users within same solution.
1.5.3 Research approaches
Research approaches are used to validate or falsify the hypothesis, establish views about phenomenon, and to draw conclusions. The common research approaches described by Håkansson [20] as;
7
• Inductive: This approach is used with qualitative research and draws conclusion based on data collected via behaviors, opinion and experiences. It is also used to formulate an artifact.
• Deductive: This approach is used with quantitative research and is used to test theories and validate hypothesis based on large data sets.
• Abductive: This approach is a hybrid of inductive and deductive approach used with both quantitative and qualitative research and is used to draw conclusion based on incomplete dataset and preconditions.
We will use an Abductive approach because we collect permissions data of an app and based on that we conclude that whether an app is privacy invasive or privacy friendly. Even though permissions are one of the major factors in deciding the privacy nature, but it is not the only factor and many other subjective factors can affect the result such as the repute of app developer. That makes our conclusion “likely or possible” and not final.
1.6 Delimitations
The scope of this thesis is limited to privacy aspect in which we have aimed to enhance the user’s understanding about the risks associated with permissions requested by apps. We have considered only the android based apps and permission system in this thesis. The apps data that we collect are only from Play Store.
Another limitation in our work is that users have to install app via the Google Play which is the official android app store. Even though our work gives users an ability to search privacy friendly apps, but after finding a desired app, user is redirected to Google Play for installation.
1.7 Thesis outline
Chapter 2 describes necessary background about Android architecture, permission base security model and issues related to this model. Towards the end of this chapter, we will outline the related work. Chapter 3 presents PEF, its design, components and working. Chapter 4 explains the implementation detail of parts of PEF. Chapter 5 evaluates the PEF and Chapter 6 presents the summary and future work.
8
Chapter 2
Background & Related Work
2.1 Privacy
Privacy is a diverse concept which encompass many aspects of human life. It is highly subjective issue and varies between persons, places and time. A classical distinction between different spheres of privacy: solitude, intimacy, reserve and anonymity, is already made by Westin [21]. Roughly based on this, a more recent definition by Solove [22] covers the following dimensions of privacy:
a) The right to be let alone
b) Limited access to the self
c) Secrecy
d) Control of personal information
e) Personhood and
f) Intimacy
When looking privacy in the modern e-world of connectivity, personal information becomes the foremost important factor [23]. It involves the technical, legal and political issues surrounding personal data collection, storage and distribution by various entities including third parties. Though personal data can be made secure while stored or in transit using various security mechanisms e.g., encryption, but all privacy aspects can’t be cover by security. GDPR [24] which is recent form of The Right to Privacy [25] states
9 that personal data must be collected with consent when needed and should not be used beyond the declared purpose. It also states that one should be aware, be able to update or delete the information held by others. Even though the GDPR only protects the EU citizens but the principles on which it is based can be applied for everyone.
2.2 Smartphone and user assets
Smartphones are becoming extremely powerful with time not in terms of just hardware (processing power, graphics and storage), but also in terms of capabilities. From making a simple phone calls and sending text messages, smartphones are now able to serve as an identity gadget used as e-Wallets and electronic authentications and with such capabilities, smartphone holds diverse data about a person. This includes, but not limited to;
• Contact lists
• Correspondence (Call logs and messages)
• Proximity (Location)
• Multimedia (Photos, audios, videos)
• Schedule (Calendar information)
• Health
• Financial and banking data
• Etc.
All this data is subject to invasion by various companies, advertisers, marketers, hackers, secret agencies and sometimes governments. This data is accessed by smartphone applications which collects and transmits to developers and to third parties.
There have been many data breaches in last fifteen years [26] however the recent breach of data in which Facebook provided the data of 50 million profiles to a data analytic company that used it for US presidential election [27]. In another incident, early 2018, US army bases were exposed using the data collected by a health and fitness app called Strava [28].
2.3 Android Platform
Android, acquired by Google in 2007, is an open source platform and software stack for various kind of devices. The android platform is built upon three building blocks namely Devices & hardware, Android operating system and Android Application Runtime
10
(ART). Being open source in nature, supported by many hardware vendors and with lot of customization & features, android enjoys the biggest market share of mobile ecosystem [3]. Out of 1.2 billion smartphone shipments in 2017, 85% were based on android [2]. Though android was initially built for smartphones, but it now supports watches, TVs, tablets and cars. There are more than twenty-four thousand unique devices produced by over 1300 different brands of different industries [29].
Google Play is the official android Appstore and will be referred as android app store or app store in this thesis. Along with in-built default apps and device specific apps, android allows everyone to put an app on the app store. App store hosts around 2.8 million apps as of January 2018 [30]. The availability of huge number of apps has attracted a large user base which has downloaded these apps over 82 billion times on as many as two billion active devices [31].
Android also has some unofficial stores which hosts limited apps. These stores host vendor specific apps or open source apps for modified android operating system. Samsung Galaxy apps7, F-Droid8, Amazon Appstore9, GetJar10 are few of such unofficial and vendor specific android stores. The closest competitor to android is iOS11 which is used by devices from Apple Inc12. There is about one billion iOS based active devices. Apple has its own application store called App Store13 which hosts around two million apps which were downloaded over 25 billion times. Apart from android and apple app stores, Windows Appstore14 by Microsoft and Blackberry world by Blackberry also exist with limited market share.
Android app store has more number of apps compared to any other popular app store [30]. Figure 1 shows that the android applications are downloaded as much as three times more compared to Apple apps store [3]. With well documented APIs, splendid community support and comparatively easy and user-friendly development, android developer and user base is growing faster than ever.
7 http://seller.samsungapps.com/ 8 https://f-droid.org/contribute/ 9 http://www.amazon.com/mobile-apps 10 http://developer.getjar.mobi/ 11 https://www.apple.com/ios 12 https://www.apple.com 13 https://www.apple.com/ios/app-store/ 14 https://www.microsoft.com/en-us/store/b/home
11
100
80
60
40
20 NUMBER OF DOWNLOADS IN BILLIONS 0 2014 2015 2016
Apple app store Google Play
Figure 1: Worldwide app store downloads [3]
3,000,000 2,800,000
2,500,000 2,200,000
2,000,000
1,500,000
1,000,000 669,000 600,000
500,000 234,500
0 Google Play Apple App Windows Store Amazon Blackberry Store Appstore World
Figure 2: Number of apps available in various app stores [30]
2.4 Android architecture overview
Android is a software stack comprising of various components. As depicted in figure 3 [32], it has five layers comprising of kernel, hardware abstraction layer (HAL), ART, native libraries, JAVA API framework and system applications.
Android is based on Linux kernel 2.6 and with that it inherits the advantage of all the security features such as process isolation, secure IPC, user-based permissions model of Linux.
12
On the second level, we have HAL that consist of library modules called drivers which provides standard interfaces for the device’s hardware.
Figure 3: Android architecture [32]
With android version 5.0 (API level 21), Dalvik Virtual Machine (DVM) is replaced by ART as application runtime environment. ART executes each application in individual process using Dalvik Executables (DEX) files. ART supported applications are backward compatible which means those applications can be run on DVM. The native C/C++ libraries are the basis of services like ART and HAL. These libraries can also be accessed by applications using android Native Development Kit (NDK).
13
At fourth layer, all the features of android operating system can be accessed using Java API framework. This framework provides the building blocks such as view system, content providers and various managers including resource manager, notification manager, activity manager etc.
Finally, they system apps layer has some core applications called system applications for basic functionalities such as phone calls, SMS messaging, internet browsing, contacts management etc. The core apps can be used by developers to extend the functionality of custom apps.
2.5 Android security overview
In Android platform, the security mechanism is built and enforced at different levels. For the sake of this thesis, security at two levels i.e., operating system level and application level are described below.
2.5.1 Kernel level security
Android platform has built upon Linux kernel which with continuous development and improvements, has become very stable and is used worldwide in many security-sensitive environments. So, on kernel level android inherits the same security features as any other Linux-kernel based system. In Linux operating system, more than one application can have the same user permissions. However, in android operating system, the concept of isolating called application sandbox is used in which each application is assigned a unique user ID (UID) and a group ID (GID) upon installation. Each application runs in its own process with all the data and files in a sandbox, see figure 4.
The data and files are accessible to application via UID and not accessible to any other application which is same as UNIX-style file permissions in which files of one user is protected from another user. Having said that, UID can be shared between applications which are signed by same self-signed certificate. This way applications can share their data and files and even the permissions. So, if one application has access to device’s location and other application has access to device’s camera, then essentially both applications with shared UID have access to location and camera. Access to different resources like camera, filesystem etc. is governed by application permissions which is explained in next section. Along with kernel level process-based security, android operating system also uses the secure Inter process communication (IPC) which facilitate the communication between multiple applications each running in its own processes.
14
Figure 4: Android application sandboxing
2.5.2 Application-level security
The second most important aspect of android platform’s security is the application-level security enforced by Permission-based model. Permissions are used to access protected APIs with which application gets the access to device’s and other application’s functionality and resources, see figure 5. For example, application will require ACCESS_FINE_LOCATION permission to determine the device’s GPS location, SEND_SMS permission will authorize application to send SMS, and READ_CONTACTS permission will be required to read the phone contacts on the device.
Figure 5. Permission mechanism to access system resources.
15
In order to access these resources, application has to first declare all the permissions it needs in one of its building blocks (a text file) called AndroidManifest.xml and then it has to request user to approve the access. In earlier versions of android, all permissions must be approved before installation but in newer version user can control individual permissions even after installation. The detail of this difference is explained in next section.
All the components of an application including third party libraries inherit the permissions from the host application. If an application tries to access a resource for which it is not capable of, security exception is thrown and without proper exception handling, application behave unexpectedly or might even break.
Android has pre-defined 128 permissions15 for critical resources known as system permissions. Along with system permissions, an application can define custom permissions which can be used by other applications to interact and share data. The system permissions are grouped under four protection level based on how critical the resource is. A brief description of protection levels is as follows.
Dangerous This is high-risk level as name suggests and permissions under this level are used to protect very sensitive functionality or resources. With these permissions, an application can access user’s private data. Since these permissions can be privacy invasive, user’s approval is required to continue either at install time or at the time of use.
Normal This is low-risk level and permissions under this level are used to protect less secure functionality or resources. The normal permissions are automatically granted to applications if requested without user’s approval. However, user can always review these permissions even before installing the application.
Signature A signature level permission is automatically assigned if and only if the application requesting it and the application which declared that permissions uses the same certificate for signing the applications. Just like normal permissions, user’s approval is not required for permissions with this protection level.
Signature|Privileged This protection level includes the permission that are granted by the system if the application is part of the system image or it is signed by the same certificate that is used
15 https://developer.android.com/reference/android/Manifest.permission
16
to sign the system image installed on that device. This permission is usually used by vendors when vendor specific apps are either of part of the operating system distribution or it needs permission to share data with system apps.
2.5.3 Permission approval in different android versions
Before AnMa, android had install-time permissions approval mechanism. All the permissions that application requires must be approved before installation. The permissions are presented to user in a dialog before installation for review, see figure 6(a), user can either accept all permissions and continue with installation, or deny the permissions, in which case installation will abort. Once all permissions are approved and application is installed, applications get lifetime access to approved resources with no mechanism to control those permissions afterwards.
(a) (b) (c) Install time permissions prompt Permission prompt at run time in Permission control in AnMa before AnMa AnMa
Figure 6: Permission approval in different android versions.
With AnMa, Google replaced the install-time permissions prompt with run-time approval. Apps are installed with no access by default and whenever an app requires an
17 access to resources, it ask user to approve. Figure 6(b) shows the runtime permission to access audio hardware by the app. This approval is taken for granted for all future request by that application until or unless user explicitly revoke this access in permission manager. Also, permissions are not presented to user before installation, however user can see permission details on application page in app store. Furthermore, user can manage permissions for an application in device under Settings > Apps > {App} > Permissions, see figure 6(c).
2.6 APS limitations
The focus of this thesis will be on permissions-based security. As summarized in section 1.2, there are number of limitations with APS which are explained in this section in detail.
2.6.1 Violation of PoLP
With current android permissions model, an application can claim any number of permissions regardless of its functionality which makes an app over privileged and thus violating the PoLP. Felt et al. [16] reviewed 940 applications and found that one third of applications are over privileged. Over half of these over privileged apps claimed one extra permissions, and rest claimed more than one extra permissions. An application can be made over privileged with either malicious intent or it could be result of developer’s incompetency or it could be because of future proofing16.
Once an application gets access to a resource then it is not just the core app functionality that can access that resource but also all the third-party libraries used in the application. Use of libraries on one hand speeds up the development process but on the other hand can pose serious security and privacy threat. Stevens et al. [17] shows that even prevalent libraries may be privacy invasive. It is possible that app itself is not over privileged, but some of the libraries are, especially if same library is used in different type of applications. We categories this violation as inoffensive and offensive.
• Inoffensive violation We call violation as inoffensive if application has declared more permissions than needed but none of those permissions are used either by app’s functionality not by third party libraries used by the app. That means application have declared the permissions in their AndroidManifest.xml but have not referenced any method or class that requires that particular permission. Inoffensive violation though not harmful but is still not advised. This violation may occur for two
16 Future proofing is the term used by Google Play in which developer requires more permissions for the functionality that is planned for future. https://play.google.com/about/privacy-security-deception/permissions/
18
reasons. Firstly because of developer’s incompetency, where a developer doesn’t know what permissions an application requires and tends to include all similar permissions for a functionality. Secondly, because of future proofing, where developers tend to include permissions that might be required by an application in future versions.
• Context violation Applications with context violation claims permissions for itself or for third-party libraries and use those permissions for purpose other than their core functionality. Generally speaking, an application can have a limited and specific functionality and for that specific functionality it only requires specific permissions. So, claiming and using permissions beyond the functionality of app violates the PoLP by context and we can call these apps “over privileged app by context”. Unlike inoffensive violation, contextual violation however, is always deceptive if not malicious. User’s data is the only target for such violation. Context violation in case of some permissions can be justified, for example, the location permission may be required by third party ad library to serve location specific ads.
To exemplify, we chose two apps namely Super-Bright LED Flashlight17 and Flashlight – Torch LED Light18. Both apps use device’s camera flash as flashlight and thus requires access to camera of device. In the permissions list of first app, see figure 7(a), we can see that it only requires one dangerous permission which is camera. However, the second app, see figure 7(b), along with camera, requests many other dangerous permissions including location, microphone, photos/media/files, phone status etc. which are not required for flashlight functionality and thus violates the PoLP.
2.6.2 Missing Permissions contextualization
As explained in section 2.5.3, the permissions were presented in a dialog to user for approval at install time before AnMa. This dialog shows the name of resource it requires and a short description of related permission, see figure 8(a). The description is by default hidden but user can tap on arrow in front of permission to see it, see figure 8(b). The permission presented in this dialog are at group level and that means user doesn’t get to know what permissions will be approved under this group. Sometimes group constitute of “read” and “write” permission e.g., permission to access storage. Sometimes group constitute of different but related permissions e.g., precise location and approximate location.
17 https://play.google.com/store/apps/details?id=com.surpax.ledflashlight.panel 18 https://play.google.com/store/apps/details?id=com.happyhollow.flash.torchlight
19
(a) (b) Permissions required by Super-Bright LED Permissions required by Flashlight – Torch LED Flashlight Light
Figure 7: List of permissions requested by two apps with same functionality
In order to see permissions in bit of more detail, user have to click “Permission details” on applications’ page in application store. This dialog, see figure 8(c), not only display the dangerous permission at fine-grained level grouped under “permission group”, but also lists the normal permissions. For example, “approximate location” and “precise location” are grouped under “Location”. Also, the “read” and “write” permissions are displayed wherever possible e.g., under “Photo/Media/Files”. Another thing to note is that this dialog displays a different description compared to first dialog and this description is bit more technical.
The basic problem here is that the context of permission usage is missing in all the dialogs that user can access. Though all dialogs indicate what will be accessed, but user has no idea in which context it will be used i.e., which particular functionality of an app requires this resource. In this particular example, the application Multi Calculator19, requires lot of permissions that has nothing to do with its functionality. Location
19 https://play.google.com/store/apps/details?id=com.gomo.calculator
20 permission might be required to show targeted ads and camera might be required to scan mathematical equations but access to calendar, identity, app history can’t be justified in context of calculator functionality.
(a) (b) (c) Permissions presented to user Permissions presented to user in Permissions view from in compact form expanded form application page
Figure 8: Different views of permissions presented to user.
2.6.3 Privacy visualization
App store being a pivot place, shows a lot of information about applications. It shows the application description, link to privacy policy, rating, comments, permission details etc. One important thing related to permissions and access to resources that is missing is privacy visualization through which user can have a quick indication about the privacy nature of the app e.g., if the app is privacy friendly and only requires the permissions that are absolutely essential for its functionality or the app is privacy invasive in which case it must be requesting access to resource that is not essential for its core functionality. Lack of this visualization makes it very difficult for a user to take informed privacy decisions. Currently if user has to assess the privacy invasive nature, he has to see if an application requires permissions which are not required by the its functionality. User can
21 also read the other people’s comments or read the privacy policy etc. Based on all these factors, user may form an opinion about the privacy nature of the app. This approach will be really cumbersome if user has to go through multiple apps before choosing one. It can also be erroneous since it is all based on subjective parameters as per understanding of user.
2.6.4 Permissions grouping
Permissions are grouped together for better understanding in android, but this grouping is done with vague descriptions. Consider a permission GET_ACCOUNTS which refers to google play account and other application accounts like Facebook, Tumblr, Google etc. This permission is listed under two groups, Contacts and Identity, see figure 9(a). This means if access to any of the either contact or identity is granted, the app can access accounts on the device.
(a) (b) Permission duplication in groups Same groups with different names
Figure 9: Permissions grouping and description.
22
Similarly, the group Storage and Photos/Media/Files are duplicates and requires exactly the same permissions and even have the same permission descriptions, see figure 9(b). The permissions list in figure 9 is for Messenger20 app from play store.
2.6.5 Missing fine-grained permissions approval
Many permissions are used in android at fine-grain level but requires approval at group level. For example, the permission ACCESS_COARSE_LOCATION (network-based location) and ACCESS_FINE_LOCATION (GPS based location) are grouped under Location. If the application requires the permissions READ_CONTACTS, WRITE_CONTACTS and GET_ACCOUNTS, these three permissions are grouped under Contacts. Even though user can see the permissions at fine-grain level under permission detail on android app store, see figure 8(c), but user can’t control these permissions at fine-grain level. Instead user get the control in permission manager at group level, see figure 6(c). With the group level control, user can’t turn on or off the individual permission under the particular group.
2.6.6 Missing privacy nudging
Nudges are an alternative way of communicating with users for privacy related choices. This approach is gaining attraction as it can assist user in taking optimal privacy decisions or review the existing settings [33, 34]. Nudge usually involves an interaction with user in which user is either asked about something to which user must respond e.g., approving or denying access to some resource, or user is presented with an information about something e.g., battery low on device. The first type of interaction is called active or interactive nudge, and later is called semi-active nudge. Another type of nudge in which user is neither asked nor presented with any information, instead some sort of indicator is placed in device without effecting user’s current activity e.g., notification icon in notification bar or dimming the screen light etc. The interaction approach requires users to frequently review and adjust privacy settings. However, users tend to forget to revoke the access that they have authorized previously, or they can get lazy to review the permissions.
Android does support all three type of nudges but the problem with android nudges in current form is that these nudges don’t provide any privacy related information about the risks with approving permissions and since without any information, users can’t be motivated to review the privacy related settings for an app.
20 https://play.google.com/store/apps/details?id=com.facebook.orca
23
2.7 Related work
2.7.1 PoLP Compliance
Fel et al [16] presented a tool call Stowaway, that detects violation of least privilege principle in compiled android applications. They have created a permission map in which they have listed all permissions and corresponding API calls. The tool check all the API calls made in code and compares it permissions map. They analyzed 940 apps and found that one third are overprivileged.
Martini et al. [35] has presented a solution to cater the over-privileged apps by context. The solution is to remove the permissions by reverse engineering the app i.e., removing the permissions that doesn’t affect the actual functionality of app and then repackaging the app. The major downside of this solution is that while repackaging the app can’t be signed with the original certificate and application will fail to get any future updates because of signature mismatch. So, in order to update an app, user has to uninstall the app first, download newer version and then run the permission removal tool again. Another problem with this solution is that application become unstable and it might become unresponsive or simply crashes. That may be because of lack of proper exception handling when an application wants to access a resource, but corresponding permission is removed.
Another solution SDroid presented by Biswas et al. [36] to fix this solution by defining a permission policy by creating a database of minimal-set of permissions required by certain category of application. By using a custom installer, user is presented and asked about all the permissions that doesn’t satisfy the permission policy i.e., has permissions that doesn’t belong to set of permissions of that category. The limitation of this work is that it is using google play’s categories which are very broad. Also, it requires a custom installer that a user needs to install first and must use that for subsequent installations.
2.7.2 Permission visualization & assessment
As mentioned earlier in problem statement, the permissions request and permissions detail dialog are ineffective, and users can’t really make efficient privacy decisions based on those dialogs. Currently applications in android app store have star ratings given by users. Vallee et al. [37] suggested to have ratings based on privacy aspects of applications as well which should be shown along with general ratings to give an idea about privacy invasive nature of an app. They also suggested to have better visualization of permissions to help understand the permissions.
24
Hamed et al. [38] is another solution for privacy visualization in which privacy score is calculated based on permissions severity and permissions interaction. The severity is calculated based on a privacy risk assessment by CNIL called EBIOS. They have assumed that privacy risk depends on the number of permissions approved in user’s device, however we have assumed that the risk depends on the requested permissions that are beyond the actual functionality of app.
Mylonas et al. [46] also used customized EBIOS method for risk assessment and focused on user-centric approach. Users are asked five questions to which they can reply on EBIOS scale before installing an application and based on reply the risk assessment parameters are adjusted. User’s answer can be subjective here and might or might not include the permissions context. Also, it can be cumbersome for users to answer five questions before installing an app.
Kelly et al. [39] designed an interface called “Privacy Facts” in order to provide security and privacy related information to users when they are making privacy related decision about an app in a clearer style. In this interface privacy facts based on permissions used are presented without any technical terms. This interface also highlights the third-party libraries (i.e., advertising, analytics) being used by this application.
2.7.3 Privacy nudges
“Styx” designed and evaluated by Bat el al [40], monitors the apps, and warns the user about what can be inferred by the apps through collected data. For example, Styx warns the user that an app can guess the user’s gender if it gets the access to list of installed apps on device. The effectiveness of Styx in informing user about potential privacy risk was shown with the help of study with 55 participants.
25
Chapter 3
Proposed Framework
We have highlighted few of the issues with android permission system in section 2.6 and existing solutions to cater those issues. The existing solutions typically fixes a specific limitation which help users at one level but not others. In this chapter we will present a Privacy Enforcement Framework (PEF) which will solve these issues holistically.
3.1 Overview
3.1.1 Privacy levels
Android app store and AppOps are very rigid in nature because they empower all users to have control over their data with the same set of options. User can grant an app to access the location and once granted, it will not be revoked automatically even if application is closed down. This access can only be revoked specifically via AppOps. Granting access before or during context and revoking after using an app is a tedious work. A privacy aware user would like to revoke access automatically when application is closed or after certain amount of time to avoid such hassle. A user might also want to grant restricted access to resource e.g., write-only access to device storage. The current version of AppOps doesn’t have such flexibility and thus fails to cater the needs of users with medium or high privacy awareness.
To cater the needs of users with different privacy awareness level, we propose different levels of privacy configuration. Research [10] has clustered 725 participants selected using Amazon’s Mechanical Turk (AMT) into four segments based on their comfort level with apps accessing data via permissions. Two types are extreme i.e., the user which are not
26 concerned and the ones who are highly concerned with the permissions requested by apps. The remaining two segments are of the moderate users who falls within the two extreme profiles. Based on this, we propose three levels of privacy settings i.e., high, medium and low for highly concerned, moderately concerned and unconcerned users respectively. The levels will be referred in rest of this document as High Privacy Level (HPL), Medium Privacy Level (MPL) and Low Privacy Level (LPL). This is the primary component of our framework and it will govern the settings for PoLP compliance, permissions visualization, permissions management, and nudges.
3.1.2 Enforcement phases
PEF enforce privacy in three phases i.e., a) Privacy visualization: helps in finding privacy friendly app, b) Privacy nudging: informs user about the data being accessed while using the app and c) Privacy review: helps in reviewing the app permissions.
In a first phase, privacy visualization, Apps will be shown with a privacy friendly score which will be calculated based on the permissions requested by the apps and category of app. User can also review the permissions of individual apps which will be presented in intuitive way. User can choose the best privacy friendly app by just looking at the privacy score. This first phase can only be effective if alternate apps are available. In case there are no alternative, then user is left with two choices, either not to install a privacy invasive app or install the app but grant minimal access to app for resources and review the access periodically.
After installing and while using an app, the second phase of enforcement kicks in which users are informed via nudges about the access to resource by the app at runtime. These runtime nudges will not only ask user to approve or deny the access, but will also notify about the request’s stats such as how many times such data request has been made by this app in last 30 days etc. Based on that stats, users will be offered to review the permission preferences.
In the third phase of enforcement, access to resources can be made limited or revoked altogether. In this phase user can adjust permissions preferences via AppOps. AppOps will have course-grained or fine-grained permission configuration based on the user’s privacy level. The user will go through phase one only once for each application however the other two phases will keep iterating until the app is installed and being used by user. The PEF phases for an app are shown in figure 10.
27
Privacy Privacy nudging Privacy review visualization
Figure 10: PEF phases for an app
3.2 Privacy Visualization
Currently the android app store doesn’t not help users in choosing privacy friendly apps in any way. The only way to get an idea about privacy invasive nature of app is to view the app permissions which itself are hidden at the end of the app page. Once an app is downloaded the user can control the access to different resource using AppOps as explained in section 1.1. Privacy visualization phase will help user in finding privacy friendly apps by looking at privacy score derived from requested permissions and category of app. After finding the app, user will be shown the permissions required by the app and their context if available. User will also be informed about permissions that might be dangerous but in required for the core functionality of the app. This phase involves number of steps that contribute towards visualization i.e., PoLP compliance, permissions score calculation, permissions grouping and permissions context.
3.2.1 PoLP compliance
With current android permissions model, the apps violate the PoLP by over claiming the permissions. As explained in section 2.6.1, there can be two types of violation, inoffensive and context.
3.2.1.1 Inoffensive compliance Though inoffensive violation is not harmful and doesn’t pose any threat to user’s privacy, but it is still not advised. A quick and simple static code scan would suffice to check if all requested permissions are actually referenced by some class or method in the code. Developers can’t be relied for applying such scans, because if they were careful enough,
28 they shouldn’t have included extra permissions at first place. Though there are some tools available to make sure that they are complying with least privilege principle, but these tools are limited to certain IDE (Integrated Development Environment) such as Eclipse. One of such tools is presented by Vidas et al. [5]. Android developer policy center states;
“Permission requests should make sense to users, and should be limited to the critical information necessary to implement your app. Don't request access to information that you don't need. You may only request access to the user data that is necessary to implement existing features or services in your application. Don't attempt to "future proof" your access to user data by requesting access to information that might benefit services or features that have not yet been implemented.” [41]
However, the enforcement of this policy is not rigorous enough and applications get passed to store and eventually downloaded by users. We suggest that this policy should be enforced at a) Development phase, where build process should not be successful until unreferenced permissions exists in code. The static code scan should be implemented in Android’s official IDE called Android Studio and b) App publishing phase, since people use different development tools and environment but majority of them publish the applications at android’s official store. Application should not be approved until or unless it complies to least privilege principle.
3.2.1.2 Context compliance Contextual violation however, is always deceptive if not malicious and user’s data is the only target for such violation. Context compliance is also suggested in android developer policy as;
“Request permissions in context where possible. Request access to user data in context (via incremental auth) whenever you can, so that users understand why you need the data.” [41]
Although app’s request for data only when needed is a convincing but requested permissions before installing makes an application deceptive. To make an application trustworthy, we propose to establish a functional group of applications and permissions policy for each functional group.
Functional Group
29
Currently android has 32 categories21 (see appendix 1) under which various applications can be grouped. These categories are very broad, and each category has variety of applications. Consider an example of category called Communication22, under this category variety of apps are listed such as web browsers, text chat apps, audio/video chat apps, SSH clients, email clients, etc. Broadly speaking, all these kinds of apps are involved in some sort of communication, but functional communication is lot different and thus requires different permissions. For example, the communication in video chat application requires access to mic and camera at least, but communication of SSH client, doesn’t need that. So even though these applications are in same category, the core functionality is very different. We propose to define functional groups for each category which will help to create realistic permissions policy for each group. A non-exhaustive list of functional groups for Communication category may include web browser, SSH client, video chat, email client etc.
Permission Policy Permission policy is merely a set of permissions that should be allowed for a specific functional group. To define permission policy for specific functional group, a set of top 25 applications will be selected among the search results. The top 25 apps might not be privacy friendly but it these will be very relevant and usable and thus most relevant permissions can be extracted for the set of apps. The frequency of permissions requested by selected applications will be calculated for each permission. The threshold value for a permission to be included in permission policy is 100% i.e., if a permission is requested by all the selected top 25 applications, then that permissions will be part of permission policy and will not be considered invasive. All the permissions which end up in permission policy are allowed by default and permissions which can’t be included in permissions policy will be considered invasive and privacy score will be calculated based on the severity of invasive permissions. For invasive permissions, the permission context and technical detail provided by developers should be reviewed by user. With a satisfactory and convincing context usage, permissions beyond policy can be accepted.
3.2.2 Permissions Risk Assessment
Permissions risk assessment is required to visualize the privacy. Unfortunately, to best of our knowledge, there are no standardized privacy risk assessment methods available in smartphones context. Existing research have used either custom or have modified the general privacy risk assessment method for smartphones. We have also adjusted EBIOS
21 https://support.google.com/googleplay/android-developer/answer/113475?hl=en 22 https://play.google.com/store/apps/category/COMMUNICATION?hl=en
30 devised by French data protection authority, CNIL [42] in this research. We suggest a dynamic model for privacy risk assessment that will calculate a score which will be adapted into a visual representation that will indicate how much privacy friendly an application is. The score is based on the number of permissions and severity of permissions requested beyond the defined permission policy. This method covers the complete privacy risk management from risk identification to removal. The main phases of this method are;
1. Identify in what context personal data will be processed, 2. Identify possible feared events in identified context. Based on CIA, the feared events defined in EBIOS are; a. Unauthorized access to personal data b. Undesirable change of personal data c. Loss of personal data 3. Identify the possible threats, if required, 4. Identify the risks involved, if required, 5. Identify the measures to be taken to treat risks.
For each feared event, EBIOS based privacy impact assessment requires to;
1. Determine the potential impacts 2. Estimate severity 3. Identify the threats to personal data supporting assets that could lead to this feared event 4. Determine its likelihood.
For our research, we only need to estimate the severity which is based on the level of identification of personal data and prejudicial effect of potential impacts. EBIOS severity scale has four levels and each level defines the severity equivalent to numeric value, see table 1. The details of four severity levels defined in EBIOS can be found in [42], page 12 & 13.
Level of identification / prejudicial effects Corresponding severity < 5 1. Negligible = 5 2. Limited = 6 3. Significant > 6 4. Maximum Table 1: EBIOS severity level and corresponding numeric value
In context of our research, the subjects are the android device users and asset is their personal data stored or generated by device. The users install the mobile apps which are potentially risk sources and app permissions are the gateway to personal data which can
31 result in a threat. Since the android permissions are the only barrier that bars or allows the apps to access user’s assets, we need to classify the permissions linked to asset that can be used to identify the individual on EBIOS scale. The severity level of permission is derived by finding the co-relation of asset with the identity of user, weaker the co- relation, lower the severity score. We have chosen 19 dangerous permissions and assigned the severity score which is summarized in table 2. The reasoning for the assigned severity score for each permission is as follows:
• READ_PHONE_STATE: This permission can give access to various identifiers such as IMEI, ICCID, IMSI, MSISDN that can uniquely identify the device and subscriber [43]. Although IMEI and ICCID can’t be used to identify the user, but IMSI and MSISDN can be used to identify the subscriber since it is public information in various part of the world. Since this information can be used to impersonate by cloning the sim card, so, we will assign a maximum value to identification and prejudicial effects for this permission.
• GET_ACCOUNTS: This permission will also get the maximum value for severity because this permission if approved will let the app access the user’s accounts (Google, Facebook, Tumblr etc) and authentication data [43]. With the help of account information, a user can easily be identified, and accounts can be used for phishing attacks.
• CALL_PHONE, SEND_SMS, PROCESS_OUTGOING_CALLs, RECEIVE_WAP_PUSH: These permissions can be used to make phone calls and send message to other subscribers without consent and may cost users as well [44]. Since these permissions could cost users money and automated calls and SMS are used for two-way authentications as well, so these permissions can cost financially and approval to secure systems without consent, so these permissions will also get the maximum value for identification and prejudicial effects.
• READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE: These permissions are not only used to access the files on device but also used to read/write various temporary files and data to device storage. We will assign limited severity value to these permissions as these permissions are often have a legitimate use [43, 44].
• READ_CALL_LOG, READ_SMS, RECEIVE_SMS, RECEIVE_MMS, READ_CONTACTS, READ_CALENDAR: All though these permissions do gives access to user’s personal information but with this personal information it is not easy to identify the user [43]. So, we will assign limited value to identification and significant value to prejudicial effects.
32
• ACCESS_FINE_LOCATION, ACCESS_COURSE_LOCATION: With the help of these permissions, apps can locate the device. These permissions can be used for tracking, but identity of user can’t be determined [44], so we assign the limited severity value to these permissions.
• CAMERA, RECORD_AUDIO: The permissions lets app to record audio/video or take pictures. These permissions are not generally considered invasive [43] because user identity can’t be revealed by just taking picture and recording an audio/video. So, we can assign negligible value to these permissions.
Permissions Level of Identification + Severity Prejudicial effects.
READ_PHONE_STATE 4+4 4 GET_ACCOUNTS 4+4 4 CALL_PHONE 4+4 4 SEND_SMS 4+4 4 PROCESS_OUTGOING_CALLS 4+4 4 RECEIVE_WAP_PUSH 4+4 4 READ_CALL_LOG 2+3 2 READ_SMS 2+3 2 RECEIVE_SMS 2+3 2 RECEIVE_MMS 2+3 2 READ_CONTACTS 2+3 2 READ_CALENDAR 2+3 2 WRITE_CALENDAR 2+3 2 READ_EXTERNAL_STORAGE 2+2 1 WRITE_EXTERNAL_STORAGE 2+2 1 ACCESS_FINE_LOCATION 2+1 1 ACCESS_COARSE_LOCATION 2+1 1 RECORD_AUDIO 1+1 1 CAMERA 1+1 1
Table 2: Chosen permissions based on co-relation with the identity of user.
Based on the severity score in table 2, risk assessment or privacy invasive score can be calculated as per following equation.
,
!"#$ = &(!( ∗ !*) (-.
Where !"#$ is the privacy invasive score on a scale of 0 to 44 (sum of severity score of all permissions is 44), !( is each privacy invasive permission identified, !* is the severity
33 score of permission. We need to convert !"#$ to a scale of 0 – 5 using the following equation for visual representation using following equation.
(1234) !"#$0 = (!"#$ ) ∗ (5234)
Where !"#$0 is privacy invasive score within range of 0 – 5, 5234 and 1234 are current and new maximum score which are 44 and 5 respectively. With positive visualization, we need to show user the privacy friendly score of an app rather than privacy invasive score so by reverse scoring, we will convert !"#$0 into final privacy friendly score using following simple equation.
!67$ = 1234 − !"#$0
The final privacy friendly score is !67$ within the range of 0 – 5 which can be attached to each app and shown to user.
3.2.3 Permissions contextualization
If an app is complying to PoLP, we know that the permissions it requires will be used by its core functionality. However, the permissions detail of an app doesn’t show the context in which a particular permission will be used. The problem of missing permission’s context is explained in section 2.6.2. According to android’s developer policy;
“Permission requests should make sense to users, and should be limited to the critical information necessary to implement your app.” [41]
Although android has implemented contextualization, but it is delayed until run time. However, user want to understand why a particular permission will be required even before installing the application. The contextualization will help user in understanding the privacy invasive nature of an application.
Consider an example of an application Facebook23, the permission dialogs for this app shows that it requires access to read the text messages along with other resources. In app description it is not mentioned that which of its functionality requires access to text messages. The generic READ_SMS permission description “read your text messages (SMS or MMS)” also doesn’t indicate any functionality attached to it, see figure 11 (a). However, if we make the permission description contextual, for example, instead of generic description “read your text messages (SMS or MMS)”, replace it with “Use to
23 https://play.google.com/store/apps/details?id=com.facebook.katana
34 confirm the phone number by finding a code sent to you via SMS”, then it becomes very clear and relevant to the functionality of the app, see figure 11 (b). Now even though this description has made this permission relevant, but this doesn’t mean that this application will only use it for said purpose. It still can use it for some other covert operation and that can be the case with any other permissions as well. Using the resources beyond any mentioned functionality is also a serious issue but we don’t intend to cover that in this research work.
There are two ways to enforce the permissions contextualization. Firstly, developers can add the permissions contextual detail in the app description or include a link (URL) which explains that. For example, Facebook app description contains the links for its privacy policy, its support and few other things. Similarly, they can add a URL for permission contextual details in there. They already have a web page for such details which can be found on this URL24 but it is not included in the app description. Advantage to this approach is that it requires no change at either API, or app store level. The problem with this approach is that it will be optional and too subjective, and it solely depends on app developer or company if they want to add it or not and to what extent of details, they want to put in it. Since the description is a free text without any format, and is hidden by default, user has to make few extra taps to see the full details and then he has to find the contextual details in there which makes this approach cumbrous and thus less effective.
(a) (b) Generic description Proposed contextual description
Figure 11: Existing and proposed permissions description
The second approach to this problem is to handle it at API level. Each android app has a AndroidManifest.xml file which along with other important information also lists all
24 https://www.facebook.com/help/210676372433246
35 the permissions used by an application. If an app is using third party libraries, then each library defines their permissions in their own manifests and eventually their permissions are merged into the main manifest during build process. If both application and third- party library requires the same permission, then the descriptions from each manifest should be merged together as well. Permissions in manifest file are defined using
It has two attributes android:name which specifies the name of the permission and android:maxSdkVersion indicates the highest version of API that should requires it. We propose to add another attribute of type string to permission element namely android:Context and just like android:name, the new attribute should be made mandatory. The value for this attribute needs to be self-explanatory and by that we mean it should be concise enough for user to glance yet clear enough to understand the context under which it will be used.
Once this new attribute is made mandatory for permission element, all the new applications, or the updates to existing application have to add contextual descriptions.
3.2.4 Permissions grouping
Better grouping of android permissions with well-defined descriptions can effectively warn users about the risks they can be posed to. As explained earlier, android permissions are vaguely grouped (see appendix 2 for current grouping) with some permissions duplicated in more than one group. In order the make the groups and their description more readable and understandable, we suggest new grouping for android permissions which are defined below. Also, the table 3 lists these groups and permissions that should fall in those groups.
25 https://developer.android.com/guide/topics/manifest/uses-permission-element.html
36
1. User’s Identity This group will constitute of permissions that can reveal user’s and/or device identity. The permissions that such as GET_ACCOUNTS can reveal the user’s own contact card or other user accounts such Facebook, Tumblr etc. Similarly, permission like READ_PHONE_STATE can reveal the IMEI/IMSE and SIM provider.
2. User’s Data All the permissions that can access the data stored on device memory including photos/media/files will be grouped under Data.
3. User’s Correspondence Permissions that can access correspondence such as SMS/MMS messages, call logs, phone etc. can be grouped under correspondence. Some of the permissions can actually start correspondence without user’s interaction will also be falls under this group.
4. User’s Proximity This group will be composed of permissions that can reveals user’s location. Currently there are two permissions which can reveal user’s exact or approximate location.
5. User’s Schedule Permissions that are read and add/modify the calendar entries on user’s device will be categorized under this group.
6. User’s Context The permissions that can access devices that can be used to record audio or video without user’s knowledge such as microphone or camera(s) will fall under this group.
Permission Group Permissions Identity • READ_PHONE_STATE • GET_ACCOUNTS
Data • READ_EXTERNAL_STORAGE WRITE_EXTERNAL_STORAGE Correspondence • SEND_SMS • RECEIVE_SMS • READ_SMS
• RECEIVE_WAP_PUSH
37
• RECEIVE_MMS • CALL_PHONE • READ_CONTACTS • WRITE_CONTACTS • READ_CALL_LOG • WRITE_CALL_LOG • PROCESS_OUTGOING_CALLS
Proximity • ACCESS_FINE_LOCATION ACCESS_COARSE_LOCATION Schedule • READ_CALENDAR WRITE_CALENDAR Backdrop CAMERA RECORD_AUDIO Table 3: Proposed permissions group and corresponding dangerous permissions
3.3 Permissions management
AppOps is a great functionality that is available in AnMa which allows users to change app permissions. However as explained in section 2.6.5, this functionality only allows to control dangerous permissions and not the other important permissions such as INTERNET. Also, the fine-grained permissions control is currently missing in this functionality and only allows to control the dangerous permissions course-grained level or group level. We propose a flexible version of AppOps in which a) normal permissions can also be controlled, and b) permissions can be controlled at fine-grain level. Proposed AppOps will have different views and control options based on the privacy level that user has selected. Table 4 shows the difference of control options between three different privacy levels.
Control LPL MPL HPL Dangerous permission management Ö Ö Ö at Coarse-grained level Dangerous permission management Not viewable Read only Ö at fine-grained level Normal permissions management Not viewable Read only Ö Permission approval options. 1. Always Allow 1. Always allow 1. Allow for now 2. Allow for now 2. Allow for 12 hrs 3. Allow for 36 hrs 4. Allow for 7 days Table 4: Permission management settings under different privacy levels
38
• HPL: With HPL, user will be able to manage normal and dangerous permissions on coarse and fine-grained level. For example, if an application asks for user’s approximate and exact location (both are grouped under Location), user can approve both or one of them or none. The normal permissions are by default approved upon installation of an application, but if user has this privacy level, these permissions will not be approved, and user will approve it during runtime if needed. For example, internet is one of the popular normal permission that is used by applications, but user can’t turn it off. With this privacy level, user will be able to turn off this and other normal permissions. Also, while approving a permission, user will have option to approve for one time, for a specific time period. With this level user can’t approve lifetime access26 to any resource.
• MPL: When it comes to MPL, user can see the dangerous permissions at fine- grained level, but can only approve at group level. So, if an application asks for user’s approximate and exaction location (grouped under Location), user can approve both or none with one switch at group level. This is similar to what Android Marshmallow currently has but user can’t see the permissions at fine- grained level. Unlike, HPL, user also can’t approve a permission for certain period of time and so it only has two options i.e., one-time approval or always.
• LPL: LPL corresponds to current permissions approval model of Android Marshmallow. Under LPL, a user can only approve the dangerous permissions and that too at coarse-grained or group level. User will not be able to see the normal permissions or fine-grained dangerous permissions. With this level, once a permission is approved, it will be considered approved for that application until or unless it is unapproved through global or application’s permission settings. However, if a permission is denied, user will be asked again when application needs it. Multimedia
The different interface for each level of privacy for proposed AppOps can be seen in figure 12. Currently permissions can only be managed for each application individually. In a privacy level view, user will have options to configure permissions globally. So instead of turning location off for each individual application, user can turn off location in privacy view and that will be applied to all applications. The permissions will be governed by the global settings, but user can always override the permissions on application level.
26 Lifetime access is same as “always allow”. This doesn’t mean that once access is granted it can’t be revoked, it means that app will not ask for permission for this resource again, but user can’t still revoke the access in AppOps.
39
3.4 Privacy Nudging
With the help of privacy nudges, not only users can be informed about the potential privacy and security risks, but they can be motivated to review and adjust the security and privacy settings time to time. Privacy nudges can enforce the privacy by influencing the user’s choice about privacy and security. With our framework, nudges will be presented to user based on their privacy levels. In this thesis we will only deal with active or interactive nudges i.e., prompts that request access to resource.
(a) (b) (c) High Privacy Level - HPL Medium Privacy - MPL Low Privacy Level - LPL
Figure 12: Permissions management under three different levels
The content of privacy nudge will change as per the privacy level of user. The contents include the number of options from which user can choose to allow life time access, limited access or no access at all. Along with options, users will be presented with privacy information related to that resource. Table 5 shows the options and information that will be presented to user based on the privacy levels.
• HPL: With HPL, while approving a permission, user will have option to approve for one time, for a specific time period i.e., 12 hrs., or 36 hrs., or 7 days. This privacy information about the requested resource will show a) basic information
40
i.e., number of apps that have access to this resource, b) frequency information i.e., how many times this resource was accessed and c) background usage i.e., how many apps have accessed this resource while not in use.
• MPL: Under this privacy level, user will have two options to either grant a lifetime or one-time access to resource. This privacy information about the requested resource will show a) basic information i.e., number of apps that have access to this resource, b) frequency information i.e., how many times this resource was accessed.
• LPL: With LPL, user can either grant lifetime access or deny it. Once an app got lifetime access to resource, it will not ask user about this resource again however user can still revoke this access in AppOps. This privacy information about the requested resource under this level will only show basic information i.e., number of apps that have access to this resource
Along with showing the privacy information to user, the proposed nudge will also show a “Review” button which will take user to AppOps where user can review the permissions. Figure 13 shows the three proposed nudges one for each level.
Nudge content & options LPL MPL HPL Permission approval options. 1. Always Allow 1. Always allow 1. Allow for now 2. Deny 2. Allow for now 2. Allow for 12 hrs 3. Deny 3. Allow for 36 hrs 4. Allow for 7 days 5. Deny Basic Ö Ö Ö (e.g., 5 other applications have access to Camera) Basic with Frequency Ö Ö (e.g., 5 other applications have accessed this camera for 168 times in last 7 days) Basic, frequency and background Ö usage. (e.g., 5 other applications have accessed this camera for 168 times in last 7 days, and 2 applications accessed it 78 times while not in use)
Table 5: Nudge options and privacy contents in different privacy levels
41
(a) (b) (c) High Privacy Level - HPL Medium Privacy - MPL Low Privacy Level - LPL
Figure 13: Privacy nudge view under three different levels
42
Chapter 4
Implementation
In this chapter we will present the high-level components that we defined based on the solution presented in PEF. We will also discuss at which level these components can be implemented and lastly, we will outline the technical detail of PEF.
4.1 PEF Components
We have defined six high level components for PEF. First four components are for the first phase of privacy enforcement which is privacy visualization and last two components are for privacy nudging and privacy review. We have only implemented the components related to first phase in this thesis while the other two phases are presented as conceptual work for future research.
4.1.1 Permissions policy generator
This component is responsible for creating permissions policy for functional group of applications. As soon as user hit search button, the top 25 applications from result set will be chosen to create the policy. The permissions requested by each will be compared against the privacy invasive permissions defined in section 3.2.2. As explained earlier, the permission policy will be set of permissions that can be allowed for an app. The set is formed by recording the frequency of occurrence of each permission in top 25 apps. If the permission frequency is 100% i.e., all 25 selected apps request the permission, then that permissions will be included in the permission policy. This policy will help in identifying the violation of PoLP in context. The algorithm for permission policy generator is as follows.
43
For all PrivacyInvasivePermissions For all Top25Apps If PrivacyInvasivePermission requested by app RequestedCount += 1
AppFrequency = RequestedCount * 100 / 25 If AppFrequency = 100 Include in permission policy for HighPrivayLevel
This policy can be cached and used for subsequent requests or can be generated with each request. The cached policy must be updated periodically to for the accurate risk assessment. The result of this component will be list of permissions for each level of privacy and permissions included in this list will be considered friendly permissions.
4.1.2 Privacy risk assessor
This component will be responsible for privacy risk assessment for the app. This component uses the permissions policy and permissions score defined in section 3.2.2, table 2. The privacy risk assessor compares requested permissions by the app against the permission policy and generate the privacy invasive score. The privacy score is sum of individual permission score which are not included in the policy.
For all RequestedPermissions by App If RequestedPermission is not in PermissionPolicy PrivacyInvasiveScore += RequestedPermissionScore
Since policy for each level can be different, the privacy score will also be different in each level for the same app. More the number of invasive permissions requested by app, higher the privacy invasive score it will get. The maximum score an app can have is 47 based on the sum of all 19 invasive permission, however every policy can have different maximum score. It will be hard to visualize the varying score for each app and functional group, so we will convert the privacy invasive score to a range of 0 – 5, where 0 will represent that app is not invasive at all, and 5 will represent that app is highly invasive.
4.1.3 Privacy visualizer
Permission visualizer is responsible for showing the score in a graphical representation. The visual representation that we have opted is bar with two colors i.e., Green and Red. The Green color in bar will represent the app privacy friendliness and red will represent the privacy invasiveness. For positive visualization, we will convert the privacy invasive score to privacy friendly score via reverse scoring27 within the same range of 0 - 5. i.e., instead of depicting how worse an application is, we will depict how friendly an app is
27 https://www.yorksj.ac.uk/media/content-assets/schools/psychological-social-sciences/documents/Reverse-Scoring.pdf
44 privacy vise. So, unlike privacy risk assessor component, 0 will represent that an app is not privacy friendly at all and 5 will represent that an app is highly privacy friendly.
PrivacyFriendlyScore = 5 – PrivacyInvasiveScore
Once the privacy friendly score is calculated, it will be converted into bar, see figure 14. Along with bar, the numeric score will also be displayed. The numeric score will be rounded off to 1 decimal position.
Figure 14: Visual representation of privacy friendliness score
4.1.4 Permissions Interpreter
Permissions interpreter will present the individual permissions requested by the app to user in intuitive way. Firstly, a per new permissions group explained in section 3.2.4, it will group the all the requested permissions, then as per permission policy, the permissions will be color coded i.e., friendly permissions will be displayed in green color while invasive permissions will be displayed in red color. Permissions interpreter will also extract the permissions context provided by the developer from AndroidManifest.xml file of the app. Together with new group, indication by color and context, user can get a good suggestion about the purpose of requested permission, and resources that can be accessed with the approval of this permission. The purpose or context of permission can only be shown if provided by the developer. Figure 15 shows an example of permissions interpreter.
45
Figure 15: A view of requested permissions presented to user
4.1.5 Permissions manager
This component will be a modified AppOps and will give user control to manager the permissions of individual app or for all apps globally. This component will have three different views where there will be different control options to manage the permission.
4.1.6 Privacy Nudges manager
Privacy nudges manager will present the privacy nudges to user where user can not only grant access to resource based on the chosen privacy level but will also present the privacy awareness information which can help users to take better privacy decisions and can motivate users to review the privacy related settings for apps.
46
4.2 Execution
4.2.1 Implementation level
The proposed solutions require changes at different level of android stack. Some components can only be implemented at operating system level and for that a custom android distribution needs to be developed. Some components can be built as web based or android native app market. The app market is used to search, review and install the apps and thus are very important starting level to show privacy related information about apps. Table 5 shows the various components and their ideal implementation level.
Component/implementation Web Native app Android interface store Operating for app system store Permissions policy generator Ö Ö Privacy risk assessor Ö Ö Privacy visualizer Ö Ö Ö Permissions interpreter Ö Ö Ö Permissions manager Ö Privacy nudges manager Ö Table 5: PEF components and corresponding implementation level
As you can see that some component can exist in all levels of implementation. For example, permissions interpreter and privacy visualizer, can show the privacy score of an app at application store or by installer application, or by operating system after installation.
In this thesis, we will implement the components of PEF in app store with web interface. The two components permissions manager and privacy nudges manager can only be implemented at operating system level and as mentioned earlier, the implementation of these two components is beyond the scope of this thesis.
4.2.2 Data Sourcing
In order to perform risk assessment, privacy visualization and permissions interpretation, we need to have app’s data. The source of our data will be the android’s official store, Google Play. In order to retrieve apps and related data from the android store, we need an API but there is no official API offered by android. In the absence of an official API, we chose an API from one of the third-party vendors. One such vendor is AppBrain28
28 AppBrain, https://www.appbrain.com
47 which provides a lot of information about apps and android ecosystem. API provided by AppBrain can be used to search apps and results can be sorted based various parameters such as relevancy, top rated, hot today, all time downloads etc. The API returns raw data based on the filters in JSON format that can be parsed and prepared for custom use.
Once data is successfully parsed, it will become the input of various components defined earlier for privacy processing. Based on this data, privacy policy will be generated, risk assessment will be performed, and permissions will be interpreted. Once all the information is ready, it will be presented to user in web interface.
4.2.3 Interface
In this thesis, we have also implemented the web interface for android store that lets user search the apps. Our web-based app store will present an interface where user can search for apps and can sort results either by relevancy, top rating and all-time downloads. This interface shown in figure 16 will also let user choose one of the privacy levels. Based on the privacy levels, the risk assessment and privacy visualization will be applied to apps.
This interface will show the search results similar to android app store but with privacy friendly score for each app, see figure 17. From the search result page, user can either proceed to android app store to install the app or can go to app details page where user can see more details about the app and its permissions. The search results will by default only show the privacy visualization. However, user can also see the permissions policy and permissions contextual information if provided in app’s detail page.
48
Figure 16: Search interface for PEF’s web-based app store
Figure 17: Search results page showing the privacy friendly score for each app
49
Chapter 5
Evaluation & Discussion
In this chapter we will evaluate our framework to see how well we have answered the posed research question. We will also highlight the limitations in our work.
5.1 PoLP compliance.
In order to see if an app is contextually complying to PoLP, we have to examine that app is not requesting access to resource that is beyond its functionality. We proposed to define functional groups for apps where each group will constitute comparable apps. After forming a functional group, the permission policy will be determined for each privacy level. This permission policy will specify which privacy permissions are legitimate and which are not in the context of function group. All the illegitimate permissions will be used further for risk assessment. To evaluate this proposed compliance method and verify the permissions policy, we have defined five functional groups, see table 6. These functional groups are basically few of the popular search terms in android’s official store [45]. Each functional group belongs to different android category. We will establish the expert opinion by defining the permission policy manually by evaluating the functionality offered by apps in each functional group. This subjective or expert opinion will then be compared with the permission policy generated by our framework.
PEF’s Functional group Android category Navigation Maps & Navigation Web browser Communication Photo editor Photography Flashlight Tools Weather Weather Table 6: Selected functional groups and their android category
50
Navigation The navigational apps are primarily used to find shortest route and have turn by turn directions for a route. These apps can also offer traffic updates e.g., congestion or blockade at the route etc. These apps can use either device’s GPS over online map or offline maps in a device to determine the route. So, if an app requires offline maps then it requires access to storage and if an app uses online map then it doesn’t require access to storage. Regardless of the source of map, navigation apps require access to devices precise location. Permission policy generated by our framework is also shown in table 7. We can see that PEF has only identified the GPS location permission as mandatory. User has to see if an app is using offline maps then the app requiring storage permission is not invasive otherwise it is. Some of the apps among top 25 apps also require other permissions. The frequency of those permissions is also highlighted as red in table 7. The top 25 most downloaded apps require as many as 11 invasive permissions however out tool has found 8 privacy friendly apps that requires only location permissions.
Permission Frequency% Expert opinion PEF’s Permission policy
ACCESS_FINE_LOCATION 100 Ö Ö READ_EXTERNAL_STORAGE 95 WRITE_EXTERNAL_STORAGE 95 ACCESS_COURSE_LOCATION 85 RECORD_AUDIO 45 READ_PHONE_STATE 65 READ_CONTACTS 65 GET_ACCOUNTS 70 RECEIVE_SMS 10 CAMERA 45 CALL_PHONE 20 Table 7: Permission Policy for functional group “Navigation” generated by PEF.
Web browser Web browsers are used to browse web via internet. User can upload or download files from the web as well using web browser. Although storage can be used to write the cookies as well which can be used to track user’s visits on particular websites, but we believe that a good privacy friendly browser either do not create cookies or deletes all cookies stored during a session when the app is closed. Keeping in mind the basic functionality of web browser apps, the expert opinion will constitute only storage permissions. Although some websites offer some audio or video related functionality, and, in that case, browsers also require access to camera and mic, but we don’t consider this as basic functionality of web browser. The permission policy generated by our framework is same as our expert opinion as mentioned in table 8. Our tool has identified 5 privacy friendly alternatives. Although 9 different permissions are requested by different apps, but our framework has marked 7 of those permissions invasive.
51
Permission Frequency% Expert opinion PEF’s Permission policy
READ_EXTERNAL_STORAGE 100 Ö Ö WRITE_EXTERNAL_STORAGE 100 Ö Ö ACCESS_FINE_LOCATION 80 ACCESS_COURSE_LOCATION 68 RECORD_AUDIO 20 READ_PHONE_STATE 32 CAMERA 32 READ_CONTACTS 4 GET_ACCOUNTS 8 Table 8: Permission Policy for functional group “web browser” generated by PEF.
Photo editor These apps are used for various photo editing actions such as cropping, balancing out color, styling, resizing, removing blemishes etc. Since the photos are stored in device storage, so in order to edit the photos the apps require access to storage. Some photo editor apps can capture photos on the fly which requires access to camera as well. Considering this functionality, we can take storage permission for granted for this functional group. The expert opinion and permission policy selected by PEF are shown in table 9. The frequency of other permissions requested by top 25 apps is also highlighted in table 9. PEF has marked 11 permissions as invasive and only storage permissions as friendly under this functional group. After comparing different apps with permission policy, PEF found 12 privacy friendly apps among the search results of first 50 apps.
Permission Frequency% Expert opinion PEF’s Permission policy
READ_EXTERNAL_STORAGE 100 Ö Ö WRITE_EXTERNAL_STORAGE 100 Ö Ö CAMERA 76 ACCESS_FINE_LOCATION 40 ACCESS_COARSE_LOCATION 32 RECORD_AUDIO 28 READ_PHONE_STATE 24 READ_CONTACTS 16 GET_ACCOUNTS 8 RECEIVE_SMS 8 PROCESS_OUTGOING_CALLS 4 READ_CALL_LOG 4 CALL_PHONE 4 Table 9: Permission Policy for functional group “Photo Editor” generated by PEF.
Flashlight Flashlight app is included in android and has a basic functionality of turning on device’s LED. Android has a built-in app for this functionality as well however many custom apps offer more functionality such as strobe, Morse, blinking mode etc. Since device’s
52
LED is part of camera, so flashlight apps require access to CAMERA. All permissions other than CAMERA are to be considered invasive. Our framework has identified that top 25 flashlight apps uses as many as 11 permissions listed in table 10. However only Camera permissions is identified as legitimate or friendly by PEF. PEF has found 30 flashlight apps that comply to the permission policy.
Permission Frequency% Expert opinion PEF’s Permission policy
CAMERA 100 Ö Ö READ_EXTERNAL_STORAGE 20 WRITE_EXTERNAL_STORAGE 20 READ_PHONE_STATE 16 ACCESS_FINE_LOCATION 8 ACCESS_COARSE_LOCATION 8 RECORD_AUDIO 4 RECEIVE_SMS 4 READ_CONTACTS 4 PROCESS_OUTGOING_CALLS 4 CALL_PHONE 4 Table 10: Permission policy for functional group “Flashlight” generated by PEF.
Weather The weather apps are used to get weather forecast of particular city or town. The forecast can be based on just name of city or town but for an accurate forecast, these apps require access to device’s location so the expert opinion will include only location permission in general and specifically approximate location as friendly. Other than location, all other permissions are objectionable for weather forecasting apps. We have found that top 25 apps under this functional group requires as many as 9 permissions however only LOCATION permission is identified as legitimate by PEF, see table 11. Although expert opinion comprises of approximate location but PEF has identified exact location as friendly but since both permissions belong to same group so we can still say its correct. Based on PEF’s permission policy, 5 friendly alternatives are available among top 50 apps.
Permission Frequency% Expert opinion PEF’s Permission policy
ACCESS_FINE_LOCATION 100 Ö ACCESS_COARSE_LOCATION 80 Ö READ_PHONE_STATE 48 READ_EXTERNAL_STORAGE 32 WRITE_EXTERNAL_STORAGE 32 GET_ACCOUNTS 8 READ_CALENDAR 8 CAMERA 4 PROCESS_OUTGOING_CALLS 4 Table 11: Permission Policy for functional group “weather” generated by PEF.
53
5.2 Privacy Visualization
As explained earlier privacy visualization is a process of analyzing and translating the app’s permissions into an easy to comprehend visual and textual representation that can help user in understanding the privacy risks attached with the permissions. To objectify the risk assessment, privacy invasive permissions needs to be identified for an app which we already have in the previous section. Based on the identified invasive permissions the privacy friendly score is calculated. The formula for this calculation is explained in section 3.2.2. In privacy visualization, the calculated score is displayed literally and with visual representation. The visual representation is bar with combination of two colors i.e., green and red as shown in figure 18 which is an actual screenshot of results displayed by our app store. This gives the user a robust indication of what an application looks like in terms of privacy, greener the bar, more privacy friendly the will be. Our search results can be viewed either using a grid or list view, see figure 18 and 19. The grid view shows only the privacy score for an app and option to download however, the list view, along with privacy score also shows the other parameters including the score rating, number of downloads, number of permissions requested etc.
54
Figure 18: Grid view of search results generated by PEF
55
List view of search results generated by PEF by generated results of search view List
: 19 Figure Figure
56
5.3 Permissions Grouping & Context
The privacy friendly score and its visualization is based on number of permissions and their severity and sometimes it is not enough to decide whether an application privacy friendly or invasive. User might have to review the permissions individually to examine the app further. Based on PEF’s permissions grouping, user can see the individual permissions that application requires on app’s detail page accessible from search results. Figure 20 shows the basic view of this dialog where respective permissions groups are listed without any duplication and vague descriptions. The groups are coded green if permissions of that particular group are included in permission policy and coded red if one or all permission is not included in the permissions policy. Figure 21 shows the extended view of the same dialog where users can see description of individual requested permissions under a group and the purpose of that permission if included.
This new dialog has firstly reduced the number of permission groups from 10 to 6 by grouping the related permissions together and removing the duplicate permissions. Secondly the group and individual permission description clearly warns about the data that will be accessible if permissions in particular group are approved. Thirdly with color coding, user gets an indication about the invasive permissions requested by the app. Fourthly, the permissions context will indicate why a permission is requested in context of said app and whether it is for benign functionality or for other purposes such as advertisement. With the help of these improvements, users are informed about the risk to assets they are posed to by certain permission and helps user in taking better privacy decision about an app.
57
Figure 20: Basic view of PEF’s permission dialog
58
Figure 21: Basic view of PEF’s permission dialog
59
5.4 General Statistics
Based on the permissions policy which we have defined in section 5.1, table 12 shows the number of apps (among top 50 by relevancy) that we find are privacy friendly alternatives under each functional group. We have installed top 3 apps from for each functional group and verified that the basic functionality works with the minimal set of permissions defined under permission policy.
Functional Group Number of privacy friendly alternative apps
Navigation 8 Web browser 5 Photo editor 12 Flashlight 30 Weather 5 Table 12: Number of privacy friendly alternative apps under each functional group
The privacy risk assessment method we have used is based on both qualitative and quantitative factor. Both these factors affect the final privacy risk assessment score for an application. The quantitative factor is the number of permissions and the qualitative factor is the severity of permissions derived from level of identification and prejudicial effects. It is very likely that the application with more permissions is less friendly but as we have seen in our data, it is possible that an app with many lower severity permissions is friendlier compared to an app with few but high severity permissions. Figure 22 shows such an example where each app has different score even though number of permissions are same but requested permissions are different.
To validate our framework even further, we compiled a list of top 8 popular privacy friendly browsers from LifeWire29, JoyofAndroid30, TechBeasts31 and ran these browsers through our framework to see how well they score. We found out that these browsers are indeed privacy friendly and five of them scored 5/5 with our framework. The remaining three also scored well but not as good as first five. We noticed the browsers with relatively low score requires more permissions and so are less friendly than others. Figure 23 shows the list of top 8 browsers and their corresponding scores in PEF.
29 https://www.lifewire.com/privacy-and-security-apps-for-android-4116583 30 https://joyofandroid.com/best-privacy-browsers-for-android/ 31 https://techbeasts.com/private-browsers-for-android/
60
Figure 22: Apps with same number of permissions but different scores
61
Figure 23: Privacy score for top 8 browsers
5.5 Limitations
Our framework can be used to find privacy friendly apps when there are lot of alternative apps are available. However, it can’t be used when user is only looking for specific app or when alternative can’t be chosen. For example, if user wants to use the app for his e- banking, then he will be limited to only app that is offered by user’s bank. Although user can find out how much friendly app his bank offers compare to the other banks but can’t use another bank’s app. Similarly, if user want to connect to his friends via Facebook, then there is no alternative to that, even if user finds an app that offers the same functionality as Facebook, then user’s friends will not be there. Same is the case with many popular apps such Snapchat, WhatsApp etc. In such cases it will hard to identify the legitimate permissions policy because there will not be many alternative apps which
62 offers same functionality and even if there are, user’s choice is still limited and dependent on choice of majority of other users who are already using that app.
Another limitation in our framework at this point of time is that the permission policy is deduced based on the permissions requested by top 25 apps of functional group. If all top 25 apps are over privileged, then majority of apps will be shown as privacy friendly. Although this is very unlikely that all top 25 apps are invasive, but it still is possible. We can however overcome this problem by defining the permission policy manually based on subjective analysis which is not easy task but with the help of crowd sourcing and metrics other than number of permissions and severity of permissions.
In this research, we have defined the functional groups based on assumption that user is searching for apps not by name but by general search term such as web browser. If user search for specific app such as Chrome, then it will be hard to define permissions policy based on only one app unless there is catalogue defined where each app is assigned to a specific functional group in which case permissions policy can be derived and specific app can be scored on privacy friendliness level. We have defined such catalogue, but it is very limited at the moment in which only few dozen functional groups and apps are mapped.
63
Chapter 6
Summary & Future work
6.1 Future work
We have learned that android permissions system is a complex access control model which on one hand empowers the users to take all security and privacy related decisions but on the other hand doesn’t help in an effective way to take better decisions. With latest android version, users can control access to their data via run time permissions approval but even that doesn’t satisfy the needs of privacy aware users.
With so many issues with android permission model, it was very hard to fix all of them in one solution. We chose few of them, especially the ones’ which an end user encounter right from the beginning where user try to find a privacy friendly application. After choosing the issues, the biggest challenge was to connect those with each other and come up with the one workable solution that helps users having different privacy requirements.
In, PEF, the proposed framework, we have attempted to help user to search, choose and control privacy friendly apps. PEF is multi-level solution i.e., a part of it can only be done at operating system level, another part can be implemented at store level or app level. Being a multi-level, the implementation of framework is limited.
With the limited implementation we can do risk assessment based on permissions requested by the app which in turn can be quantitatively visualized for users. Users can also be informed about the risks they are pose to with an improved presentation.
64
6.2 Future work
After all the phases we came to conclusion that an ideal solution requires all the entities of android echo system to take part which means there is a lot of room for improvement that can be made in future. Following are some of the suggested improvements as future work;
• Finish the part of implementation that is left out in this thesis that includes the implementation of privacy levels and permissions management at operating system level.
• In terms of implementation, the current web-based installer app can be converted to android native installer app that can be installed and used directly from the mobile device.
• Updating risk assessment method in which parameters other than privacy permissions can be taken in account. Those parameters can be subjective like the reputation of application developer, their overall privacy policy etc.
• Updating the permissions policy algorithm, where along with the requested permissions frequency, we should consider if permissions are only being assessed by 3rd party libraries. If so the severity of permissions can be set even higher.
65
66
Bibliography
[1] Statista, Smartphone shipment worldwide since 2009. [Online]. Available: https://www.statista.com/statistics/271491/worldwide-shipments-of-smartphones- since-2009/ [Accessed: 2018-03-30]
[2] eMarketer, “Android Dominates the Global Smartphone Market, but Falls Short in the US – eMarketer.” [Online]. Available: https://www.emarketer.com/content/android-dominates-the-smartphone-market- globally-but-not-in-the-us [Accessed: 2018-03-20]
[3] Master of code, “App Store vs Google Play: Stores in numbers.” [Online]. Available: https://masterofcode.com/blog/app-store-vs-google-play [Accessed: 2018-03-30]
[4] M. Alenezi and I. Almomani, “Abusing Android Permissions: A Security Perspective”, in IEEE Jordan Conference on Applied Electrical Engineering and Computing Technologies (AEECT). IEEE, 2017
[5] T. Vidas, N. Christin, and L. F. Cranor, “Curbing Android Permission Creep”, in Proceedings of W2SP. 2011.
[6] Federal Trade commission, “Android Flashlight App Developer Settles FTC Charges It Deceived Consumers.” [Online]. Available: https://www.ftc.gov/news- events/press-releases/2013/12/android-flashlight-app-developer-settles-ftc-charges- it-deceived [Accessed 2018-06-07]
[7] Uber newsroom, “An Update on Privacy At Uber.” [Online]. Available: http://newsroom.uber.com/2015/05/an-update-on-privacy-at-uber/ [Accessed: 2018-06-07]
[8] Path official blog, “We are sorry.” [Online]. Available: http://blog.path.com/post/17274932484/we-are-sorry [Accessed: 2018-06-08]
[9] W. Enck, P. Gilbert, S. Han, V. Tendulkar, B. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth, “Taintdroid: an information-flow tracking system for realtime privacy monitoring on smartphones”, in ACM Transactions on Computer Systems (TOCS), 2014.
[10] J. Lin, S. Amini, J. I. Hong, N. Sadeh, J. Lindqvist, and J. Zhang, “Expectation and purpose: understanding users’ mental models of mobile app privacy through crowdsourcing”, in Proceedings of UbiComp, 2012.
67
[11] “Your apps are watching you.” [Online]. Available: https://www.wsj.com/articles/SB10001424052748704368004576027751867039730 [Accessed: 2018-05-20]
[12] “Android M Dev Preview delivers permission controls, fingerprint API, and more.” [Online]. Available: https://arstechnica.com/gadgets/2015/05/android-m- dev-preview-launches-permission-controls-fingerprint-api-and-more/ [Accessed: 2018- 07-03]
[13] M. Schroeder and J. Saltzer. “The protection of information in computer systems.”, in Proceedings of the IEEE, 63(9): 1278-1308, 1975.
[14] P. G. Kelley, S. Consolvo, L. F. Cranor, J. Jung, N. Sadeh, and D. Wetherall, “A Conundrum of Permissions: Installing Applications on an Android Smartphone.”, in Financial Cryptography and Data Security, pp 68–79. Springer, 2012.
[15] K. Benton, L. J. Camp, and V. Garg, “Studying the Effectiveness of Android Application Permissions Requests.”, in IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops), pp 291–296. IEEE, 2013.
[16] A. P. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner, “Android Permissions Demystified.”, in Proceedings of the 18th ACM conference on Computer and communications security, pp 627–638. ACM, 2011.
[17] R. Stevens, C. Gibler, J. Crussel, J. Erickson and H. Chen, “Investigating User Privacy in Android Ad Libraries.”, in Proceedings of the 2012 Workshop on Mobile Security Technologies (MoST). 2012.
[18] G. L. Scoccia, I. Malavolta, M. Autili, A. Di Salle, and P. Inverardi, “User-centric Android Flexible Permission.”, in Proceedings of the 39th International Conference on Software Engineering Companion ICSE-C. ACM, 2017.
[19] A. R. Beresford, A. Rice, N. Skehin, and R. Sohan, “Mockdroid: trading privacy for application functionality on smartphones.”, in Proceedings of the 12th workshop on mobile computing systems and applications, pp 49-54. ACM, 2011.
[20] A. Håkansson, “Portal of Research Methods and Methodologies for Research Projects and Degree Projects,” in DIVA. CSREA Press U.S.A, 2013, pp. 67–73.
[21] A. Westin, “Privacy and Freedom”, in Washington and Lee Law Review, 25(1):166, 1968.
68
[22] D. J. Solove, “Conceptualizing Privacy.”, in California Law Review, pp 1087– 1155, 2002.
[23] J. Hoepman and M. V. Lieshout, “Privacy.”, in E.R. Leukfeldt and W. P. Stol, editors, Cyber Safety: An Introduction, pp 75–87. Eleven International Publishing, The Hague, 2012.
[24] EU GDPR.ORG, “Key Changes with the General Data Protection Regulation.” [Online]. Available: https://eugdpr.org/the-regulation/ [Accessed: 2018-07-12]
[25] S. D. Warren and L. D. Brandeis, “The Right to Privacy.”, in Harvard Law Review, Vol. 4, No. 5 (Dec. 15, 1890), pp. 193-220 (28 pages), 1890.
[26] CSO, “The 17 biggest data breaches of the 21st century | CSO Online.” [Online]. Available: https://www.csoonline.com/article/2130877/data-breach/the-biggest- data-breaches-of-the-21st-century.html [Accessed: 2018-07-14]
[27] The Guardian, “Revealed: 50 million Facebook profiles harvested for Cambridge Analytica in major data breach.” [Online]. Available: https://www.theguardian.com/news/2018/mar/17/cambridge-analytica-facebook- influence-us-election [Accessed: 2018-04-06]
[28] The Guardian, “Fitness tracking app Strava gives away location of secret US army bases.” [Online]. Available: https://www.theguardian.com/world/2018/jan/28/fitness-tracking-app-gives-away- location-of-secret-us-army-bases [Accessed 2018-04-07]
[29] OpenSignal, “Android Fragmentation (August 2015).” [Online]. Available: https://opensignal.com/reports/2015/08/android-fragmentation/ [Accessed: 2018- 04-04]
[30] Statista, “The Biggest App Stores.” [Online]. Available: https://www.statista.com/chart/12455/number-of-apps-available-in-leading-app- stores/ [Accessed: 2018-04-07]
[31] The Verge, “Google announces over 2 billion monthly active devices on Android.” [Online]. Available https://www.theverge.com/2017/5/17/15654454/android- reaches-2-billion-monthly-active-users [Accessed 2018-04-04]
[32] Android, “Platform Architecture.” [Online]. Available: https://developer.android.com/guide/platform/index.html [Accessed: 2018-04-04]
[33] A. Acquisti, “Nudging privacy: The behavioral economics of personal information.”, in IEEE Security & Privacy Magazine, pp 7(6):82-85, 2009.
69
[34] R. H. Thaler and C. R. Sunstein, “Nudge: Improving decisions about health, wealth, and happiness.”, in Yale University Press, 2008. 1, 2.3, 2.4, 6.1.2
[35] Q. Do, B. Martini, K. R. Choo, “Enhancing User Privacy on Android Mobile Devices via Permissions Removal.”, in 47th Hawaii International Conference on System Sciences (HICSS). IEEE, 2014.
[36] S. Biswas, W. Haipeng, and J. Rashid, “Android Permissions Management at App Installing.”, in International Journal of Security and its Applications (SCOPUS), Vol. 10, No. 3. 2016.
[37] H. Q. Vallee, P. Selby, and S. Krishnamurthi, “On a (Per)Mission: Building Privacy into the App Marketplace.”, in ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices. ACM, 2016.
[38] A. Hamed, H. K. Ayed, and D. Machfar, “Assessment for Android apps permissions a proactive approach toward privacy risk.”, in Proceedings of13th International Wireless Communications and Mobile Computing Conference (IWCMC). IEEE, 2017.
[39] P. G. Kelly, L. Cranor, and N. M. Sadeh, “Privacy as part of app decision making process.”, in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. 2013.
[40] G. Bal, K. Rannenberg, and J. Hong, “Styx: Design and evaluation of a new privacy risk communication method for smartphones.”, in ICT Systems Security and Privacy Protection, Springer, 2014.
[41] “Google, Privacy, Security and Deception.” [Online]. Available: https://play.google.com/about/privacy-security-deception/permissions/ [Accessed: 2018-03-30]
[42] CNIL, “Methodology for Privacy Risk Management.” [Online]. Available: https://www.cnil.fr/sites/default/files/typo/document/CNIL- ManagingPrivacyRisks-Methodology.pdf [Accessed: 2018-07-20]
[43] Android Forums, “Android permissions explained, security tips, and avoiding malware.” [Online], Available: https://androidforums.com/threads/android- permissions-explained-security-tips-and-avoiding-malware.36936/ [Accessed: 2018-07- 30]
[44] TechPP, “Use Permissions to Secure Your Private Data from Android Apps” [Online], Available: http://techpp.com/2010/07/30/android-apps-permissions- secure-private-data/ [Accessed: 2018-07-29]
70
[45] “Most Searched Keywords in Google Play Store: Infographic 2018.” [Online]. Available: https://www.blogkens.com/blog/most-searched-keywords-in-google-play- store/ [Accessed: 2018-08-23]
[46] A. Mylonas, M. Theoharidou and D. Gritzalis, “Assessing Privacy Risks in Android: A User-Centric Approach.”, in International Workshop on Risk Assessment and Risk-driven Testing, Springer, pp 21-37, 2013.
71
72
Appendix 1
Category Examples Art & Design Sketchbooks, painter tools, art & design tools, coloring books Auto & Vehicles Auto shopping, auto insurance, auto price comparison, road safety, auto reviews & news Beauty Makeup tutorials, makeover tools, hair styling, beauty shopping, makeup simulators Books & Reference Book readers, reference books, text books, dictionaries, thesaurus, wikis Business Document editor/reader, package tracking, remote desktop, email management, job search Comics Comic players, comic titles Communications Messaging, chat/IM, dialers, address books, browsers, call management Dating Matchmaking, courtship, relationship building, meeting new people, finding love Education Exam preparations, study-aids, vocabulary, educational games, language learning Entertainment Streaming video, Movies, TV, interactive entertainment Events Concert tickets, sporting event tickets, ticket resales, movie tickets Finance Banking, payment, ATM finders, financial news, insurance, taxes, portfolio/trading, tip calculators Food & Drink Recipes, restaurants, food guides, wine tasting & discovery, beverage recipes Health & Fitness Personal fitness, workout tracking, diet and nutritional tips, health & safety, etc. House & Home House & apartment search, home improvement, interior decoration, mortgages, real estate Libraries & Demo Software libraries, technical demos Lifestyle Style guides, wedding & party planning, how-to guides Maps & Navigation Navigation tools, GPS, mapping, transit tools, public transportation Medical Drug & clinical references, calculators, handbooks for health- care providers, medical journals & news Music & Audio Music services, radios, music players News & Magazines Newspapers, news aggregators, magazines, blogging
73
Parenting Pregnancy, infant care & monitoring, childcare Personalization Wallpapers, live wallpapers, home screen, lock screen, ringtones Photography Cameras, photo editing tools, photo management and sharing Productivity Notepad, to do list, keyboard, printing, calendar, backup, calculator, conversion Shopping Online shopping, auctions, coupons, price comparison, grocery lists, product reviews Social Social networking, check-in Sports Sports news & commentary, score tracking, fantasy team management, game coverage Tools Tools for Android devices Travel & Local Trip booking tools, ride sharing, taxis, city guides, local business information, trip management tools, tour booking Video Players & Video players, video editors, media storage Editors Weather Weather reports
74
Appendix 2
Permission Group Permissions
CALENDAR • READ_CALENDAR • WRITE_CALENDAR
CALL_LOG • READ_CALL_LOG • WRITE_CALL_LOG • PROCESS_OUTGOING_CALLS
CAMERA • CAMERA
CONTACTS • READ_CONTACTS • WRITE_CONTACTS • GET_ACCOUNTS
LOCATION • ACCESS_FINE_LOCATION • ACCESS_COARSE_LOCATION
MICROPHONE • RECORD_AUDIO
PHONE • READ_PHONE_STATE • READ_PHONE_NUMBERS • CALL_PHONE • ANSWER_PHONE_CALLS • ADD_VOICEMAIL • USE_SIP
SENSORS • BODY_SENSORS
SMS • SEND_SMS • RECEIVE_SMS • READ_SMS • RECEIVE_WAP_PUSH • RECEIVE_MMS
STORAGE • READ_EXTERNAL_STORAGE • WRITE_EXTERNAL_STORAGE
75
TRITA -EECS-EX-2019:785
www.kth.se