Download An Empirical Study of Android`s Permission Model

An Empirical Study of Android’s
Permission Model
A thesis submitted in partial fulfilment of the requirements for the
BSc (Hons) Computer Forensic Investigation
By
Finn Brassington-Edwards
Department of Computing and Mathematics
The University of Derby
April 2016
The University of Derby
Department of Computing and Mathematics
Abstract
Android provides a permission-based security model to third party application developers, which
controls access to system resources, including hardware, settings and user data. This project presents
an empirical study of Android’s permission model, to observe third party developers use of permission
sets in similar purpose applications and identify the levels of risk associated with different
combinations of permissions in Android applications. During the course of the project, 69 Android
applications were sampled from the Google Play Store. Using manual statistical analysis the sampled
applications were separated into similar designed sub-categories and high risk permissions were
identified. A total of 55 non-recurrent permissions were identified and discussed regarding overprivileged application design. 61 of the total 69 sampled applications were identified to be of high risk
based upon their permission combinations. These results were compared and discussed with recent
developments in the area of permission-based security models, to identify potential flaws and
improvements for Android’s permission model.
Page 1 of 137
The University of Derby
Department of Computing and Mathematics
Acknowledgements
I would like to thank my project supervisor Dr. Virginia Franqueira for her support and advice
throughout this project. I could not have achieved this level of work without her advice and guidance.
I would also like to thank my family, partner and friends for their support throughout my time at the
University of Derby, specifically my mother Vanda Brassington for her constant support and
guidance. Thank you for believing in me even when I didn’t believe in myself.
Page 2 of 137
The University of Derby
Department of Computing and Mathematics
Contents
Abstract .................................................................................................................................... 1
Acknowledgements .................................................................................................................. 2
List of Figures .......................................................................................................................... 5
1. Introduction ......................................................................................................................... 8
1.1 Project Rational ........................................................................................................................... 8
1.2 Project Aim .................................................................................................................................. 9
1.3 Project Objectives ....................................................................................................................... 9
1.4 Project Roadmap ....................................................................................................................... 10
2. Literature Review .............................................................................................................. 11
2.1 Android ...................................................................................................................................... 11
2.1.1 Android Operating System Architecture .............................................................................. 11
2.1.2 Android Operating System Timeline ................................................................................... 14
2.1.3 Android File-System ............................................................................................................ 15
2.1.4 Linux Kernel Security .......................................................................................................... 15
2.1.5 Application Sandbox Security .............................................................................................. 16
2.1.6 Android Root Exploits and Additional Attacks ................................................................... 16
2.2 Android Applications ................................................................................................................ 18
2.2.1 Android Application Fundamentals and Components ......................................................... 18
2.2.2 Application Signing.............................................................................................................. 24
2.2.3 Application Capability Leaking ........................................................................................... 24
2.2.4 Malicious Applications ........................................................................................................ 25
2.2.5 Third Party Security for Android Applications .................................................................... 25
2.3 Android Permission Model ....................................................................................................... 27
2.3.1 How Android Permissions Work ......................................................................................... 27
2.3.2 Android Authorised Permissions.......................................................................................... 31
2.3.3 Developer Custom Permissions............................................................................................ 31
2.3.4 Application Permissions prior to Android Update 6.0 Marshmallow .................................. 31
2.3.5 Android 6.0 Marshmallow: Changes to the Permission Model ........................................... 33
2.3.6 Risks with Android Permissions .......................................................................................... 37
2.4 Recent Developments in Android Application Security ........................................................ 37
2.4.1 Developments in Android Application Distribution and Malicious Application Detection 37
2.4.2 Developments in Inter-Application Communication ........................................................... 39
2.4.3 Developments in Android’s Permission Model Analysis .................................................... 40
2.5 Conclusion.................................................................................................................................. 44
Page 3 of 137
The University of Derby
Department of Computing and Mathematics
3. Methodology ....................................................................................................................... 45
3.1 Introduction ............................................................................................................................... 45
3.2 Research Methodology .............................................................................................................. 45
3.2.1 Empirical Research .............................................................................................................. 45
3.2.2 Experimental Research ......................................................................................................... 47
3.2.3 Project Methodology and Research Questions ..................................................................... 48
3.3 Stage 1 – Sampling .................................................................................................................... 48
3.4 Stage 2 – Data Collection .......................................................................................................... 51
3.5 Stage 3 – Data Filtering ............................................................................................................ 52
3.6 Stage 4 – Data Analysis ............................................................................................................. 53
4. Findings and Analysis ....................................................................................................... 54
4.1 Permission Overview and Statistics ......................................................................................... 54
4.2 Sub-category Application Permission Analysis ...................................................................... 58
4.3 Permission Risk Analysis .......................................................................................................... 78
4.3.1 Permissions that control device hardware ............................................................................ 78
4.3.2 Permissions that access user information ............................................................................. 80
4.4 Permission Combinations and Risk Analysis ......................................................................... 81
5. Discussion ........................................................................................................................... 94
5.1 Findings and Related Work ..................................................................................................... 94
5.2 Dataset Limitations ................................................................................................................... 98
5.3 Conclusion of Findings ............................................................................................................. 99
6. Conclusions and Recommendations .............................................................................. 100
6.1 Conclusion................................................................................................................................ 100
6.2 Recommendations and Future Work .................................................................................... 100
6.3 Personal Reflection.................................................................................................................. 102
References............................................................................................................................. 103
Appendix A. Android Authorised Permissions .......................................................................... 110
Appendix B. Google Play Store Application Categories ............................................................ 116
Appendix C. Methodology Screenshots ....................................................................................... 118
Appendix D. Unique Permission Frequency ............................................................................... 127
Appendix E. Unique Permissions Potential Dangers ................................................................. 130
Appendix F. Frequency of Low/High Permission Combinations ............................................. 135
Page 4 of 137
The University of Derby
Department of Computing and Mathematics
List of Figures
2.1: A high level overview of the Android system architecture (Android Architecture, 2016)……….12
2.2: Hardware Abstraction Layer (HAL) Components (Android Architecture, 2016)………………..13
2.3: Android Software Framework (Android Securtiy, 2016)…………………………………………13
2.4: Timeline of Android operating system updates…………………………………………………...15
2.5: Building and running an Android application (Android Tools, 2016)……………………………18
2.6: The Layout of AndroidManifest.xml file (Android Manifest, 2016)……………………………..20
2.7: Android manifest element descriptions (Android Manifest, 2016)……………………………….22
2.8: Example illustration of intent delivery (Android Intent, 2016)…………………………………...24
2.9: Example of <use-permission> XML tag (Android System Permissions, 2016)………………….28
2.10: Permission levels of protection (Android Permission, 2016)……………………………………29
2.11: Advantages and disadvantages of permissions and intent (Android Best Practices, 2016)……..30
2.12: Example subset of Android permissions (Android Manifest.permission, 2016)………………...31
2.13: Android permission syntax (Android Permission, 2016)………………………………………..31
2.14: Display of Android permission system for ‘Maps’ (Android Security, 2016)…………………..32
2.15: Application permission settings (Amadeo, 2015)……………………………………………….33
2.16: Permission Groups (Android System Permissions, 2016)………………………………………34
2.17: Function example (Android Run-Time Permissions, 2016)……………………………………..35
2.18: If-Else statement example (Android Run-Time Permissions, 2016)…………………………….36
3.1: Empirical Cycle (Explorable, 2016)………………………………………………………………46
3.2: Google Play Store application category sample selection………………………………………...49
3.3: Sub-category sample selection……………………………………………………………………50
4.1: Sampled application permission overview………………………………………………………..54
4.2: Unique permission frequency……………………………………………………………………..55
4.3: Top 5 requested unique permissions………………………………………………………………56
4.4: Dataset statistic overview…………………………………………………………………………57
4.5: Frequency of permissions between sub-category applications…………………………………...58
Page 5 of 137
The University of Derby
Department of Computing and Mathematics
4.6: Distribution of permissions between application sub-categories…………………………………60
4.7: ‘Comic’ permissions not shared…………………………………………………………………..61
4.8: ‘Communication’ permissions not shared………………………………………………………...62
4.9: ‘Education’ permissions not shared……………………………………………………………….63
4.10: ‘Entertainment’ permissions not shared…………………………………………………………63
4.11: ‘Family’ permissions not shared………………………………………………………………...64
4.12: ‘Finance’ permissions not shared………………………………………………………………..64
4.13: ‘Games’ permissions not shared…………………………………………………………………65
4.14: ‘Health & Fitness’ permissions not shared………………………………………………………65
4.15: ‘Lifestyle’ permissions not shared……………………………………………………………….66
4.16: ‘Media & Video’ permissions not shared………………………………………………………..67
4.17: ‘Medical’ permissions not shared………………………………………………………………..67
4.18: ‘Media & Audio’ permissions not shared……………………………………………………….68
4.19: ‘News & Magazines’ permissions not shared…………………………………………………...69
4.20: ‘Personalisation’ permissions not shared………………………………………………………..69
4.21: ‘Photography’ permissions not shared…………………………………………………………..70
4.22: ‘Productivity’ permissions not shared…………………………………………………………...71
4.23: ‘Shopping’ permissions not shared……………………………………………………………...71
4.24: ‘Social’ permissions not shared………………………………………………………………….72
4.25: ‘Sports’ permissions not shared………………………………………………………………….73
4.26: ‘Tools’ permissions not shared…………………………………………………………………..73
4.27: ‘Transport’ permissions not shared……………………………………………………………...74
4.28: ‘Travel & local’ permissions not shared………………………………………………………...75
4.29: ‘Weather’ permissions not shared……………………………………………………………….75
4.30: Frequency of unnecessary non-recurrent permissions…………………………………………..77
4.31: Highest risk permissions that control device hardware………………………………………….79
4.32: Highest risk permissions that access user information…………………………………………..81
4.33: High risk permissions……………………………………………………………………………82
Page 6 of 137
The University of Derby
Department of Computing and Mathematics
4.34: Permission risk analysis matrix………………………………………………………………….83
4.35: Sampled application risk analysis……………………………………………………………….92
4.36: Risk analysis summary…………………………………………………………………………..92
Page 7 of 137
The University of Derby
Department of Computing and Mathematics
Chapter 1
1. Introduction
1.1 Project Rational
According to predictions made by eMarketer an expected 4.77 billion people worldwide will
own or use a smartphone by the end of 2015; 65.8% of the total population (eMarketer, 2015). Gartner
predicts that by 2017 mobile applications will generate a massive $77 billion dollars with popular
applications being downloaded more than 268 billion times (Gartner, 2015). Mobile applications have
become one of the key channels for companies to drive content and services to consumers, however,
this rise in demand means application developers are keen to distribute innovative applications and
content at higher speeds without considering possible risks, threats and attacks on application security.
In a recent poll from Mintel, 96% of consumers had at least one security concern when using online
applications or entering online information (personal data, bank details, addresses etc.) and cybercrime
has been a rising issue with the National Fraud Intelligence Bureau (NFIB) reporting an accounted
loss of £670 million pounds from online fraud (Mintel, 2015). With growing fears of hacking, scams
and infections from malware, it is important that developers and manufacturers are increasing their
levels of security, whether it is built physically into the hardware (the mobile device) or coded into the
software (the mobile application).
One of the leaders of the smartphone revolution is Google’s Android Operating System, with
a share of 82.8% of the market. The closest competitor to Android is Apple, with 13.9% of the market
(IDC, 2015). Providing an open design and development system, Android is ahead of the curve, with
millions of applications being available online and thousands developed daily. Android devices and
applications are coming under more frequent threats of malware and hacking, due to the architectural
design of both the operating system and the applications designed for mobile devices (Pieterse &
Olivier, 2012).
A dangerous security breach became news headlines recently (Titcomb, 2015) when there was
a breach of security within Android applications, which allowed malicious applications to take control
of the mobile device with privileged access, putting millions of user’s personal information at risk
from smartphone hijacking. The security firm ‘Check Point’ investigated the possible risk and
identified a flawed system of certification across Android applications. The design of Android’s
operating system and applications are not durable enough to withstand the growing threats from cyberattacks.
Page 8 of 137
The University of Derby
Department of Computing and Mathematics
Felt et al. (2011) researched Android applications to determine what permissions were
requested on an Android device when an application was installed and accessed, identifying if
developers were creating their applications following the ‘least privilege’ (allowing applications
access to the necessary areas of a phone) or ‘over privilege’ (access to an unnecessary amount of the
phone’s hardware, settings and user data). The latter exposes the user to vulnerabilities to their privacy
and personal data. Other researchers including Barrera et al (2010), Enck (2011), Rosen et al. (2013),
Vidas et al. (2011) and Wain Yee Au et al. (2012) have all undertaken research and analysis in the
area of security-based permission models, specifically Android’s, over recent years and have found
contrasting and interesting findings. While they discuss considerable issues regarding over and underprivileged application designs, permission redundancy and potential flaws and improvements to the
Android permission model, there are areas of analysis which have not been considered. While the
majority of these researchers explore Android’s permission model from the developer’s point of view,
it is the user who needs to be educated to understand the potential risks and dangers when interacting
with an application and how Android’s permission model influences their mobile experience. This
project aims to analyse Android’s permission model, specifically the design traits of similar purpose
sub-categories of applications and determine a level of risk for each application dependant on the
different combinations of permissions present in an application.
1.2 Project Aim
The aim of the project is to analyse and evaluate Android’s permission model. Specifically, to evaluate
the relationship of permissions between similar purpose sub-categories of applications and the
potential levels of risk associated with different combinations of permissions.
1.3 Project Objectives
In order to achieve the project aim, the following project objectives must be met:
1.) Conduct an extensive literature review of related research regarding Android’s permission
model.
2.) Collect a sample of Android applications for analysis.
3.) Evaluate the permissions of the sampled Android applications.
4.) Compare and contrast findings with related research.
Page 9 of 137
The University of Derby
Department of Computing and Mathematics
1.4 Project Roadmap
The project comprises 6 chapters, which cover the implementation and analysis of the research that
was conducted. The chapter structure is as follows:

Chapter 2 Literature Review: presents an extensive literature review explaining the
background of Android, including the security and architecture of Android’s operating system,
application designs and Android’s security-based permission model.

Chapter 3 Methodology: presents the methodology used in this project, including the methods
used to sample, filter and analyse data.

Chapter 4 Findings and Analysis: presents the data collected during the project. It provides an
overview of the permissions analysed from the sampled applications, the applications sharing
similar design traits and the risk levels associated with different sets of permission
combinations.

Chapter 5 Discussion: presents a discussion and limitations of the findings and analysis in
chapter 4, including correlations with research discussed in chapter 2.

Chapter 6 Conclusions and Recommendations: presents a conclusion to the project, including
recommendations for future work and a personal reflection on how the project was managed.
Along with these chapters there is a reference section and an appendix, which provides evidence of
contributions to this project.
Page 10 of 137
The University of Derby
Department of Computing and Mathematics
Chapter 2
2. Literature Review
Chapter 2 provides an overview of the Android operating system and Android applications,
covering the historical and technical aspects, including the individual architectures and technical
background and specifically addressing the current state of Android application security, the threats to
mobile devices and the research to mitigate these vulnerabilities.
2.1 Android
Android was originally known as Android Inc. founded in October 2003 by Andy Rubin, a
veteran Apple engineer and designer of ‘Danger’ and early intentions were to produce the next
generation of smartphone software. Andy Rubin was driven to produce an evolutionary open-source
environment for any developer to build on. It wasn’t until 2005 that Android Inc. finally pitched their
designs to investors looking to buy into the smartphone experience. With growing competition from
Microsoft and Blackberry, Google took this opportunity to enter the mobile market. With a further
three years spent developing the design, Google finally released their first build of the Android
operating system in 2008, in the form of the ‘HTC Dream’ smartphone (Dobie et al., 2015).
In 2016, Android Inc., now known simply as Android, is still owned and developed by
Google, with a massive 82.8% of the worldwide smartphone operating system market. Apple is in
second place with a market share of 13.9% and Microsoft in third place with a market share of 2.6%
(IDC, 2015). The sheer dominance of the smartphone market shows that Android is extremely
popular.
2.1.1 Android Operating System Architecture
The Android operating system is an open-source; Linux based mobile operating system
designed for smartphones and tablets. With the core concept of an open-source community, Android
offers its tools, suites and source code for free. For developers this allows innovation in building
applications using the latest mobile technologies, including coding languages such as Java and Dalvik
bytecode (.dex), which is a bytecode format designed just for Android (Sufatrio et al. 2015). This
provides a product that can be tailored and customised, while receiving contributions from Android’s
community of partners, developers and users.
Page 11 of 137
The University of Derby
Department of Computing and Mathematics
Figure 2.1 outlines the five key components of the Android system architecture,
including the Application Framework, Binder IPC Proxies, Android System Services (including the
Media Server and System Server), Hardware Abstraction Layer (HAL) and the Linux Kernel.
Figure 2.1: A high level overview of the Android system architecture (Android Architecture, 2016)
Working from the top to the bottom of the architecture, it is important to understand
how Android works as a system (Android Architecture, 2016):

Application Framework – provides high level services to applications built on a device in the
form of Java classes, including the Activity Manager, Content Providers, Resource Manager
and Notification Manager

Binder IPC Proxies – provides the method of communication which allows the Application
Framework to interact with the Android System Service layer

Android System Services – interacts with the hardware and software, split into two individual
groups, System (Windows Manager etc.) and Media (Media Player, Camera etc.), to provide
further functionality to the device and applications
Page 12 of 137
The University of Derby

Department of Computing and Mathematics
Hardware Abstraction Layer (HAL) – responsible for discovering, enumerating and mediating
access to most of the hardware built into the device. It also responsible for hardware driver
installation and implementation. Figure 2.2 Lists examples of HAL components.
Figure 2.2: Hardware Abstraction Layer (HAL) Components (Android Architecture, 2016)

Linux Kernel – the base level operating system which provides a certain degree of
functionality and communication within the device, including the essential hardware drivers;
the camera, keyboard and display etc. The kernel will also take control of the networking
components of the device and any other methods of communication, in this case the Binder
IPC Proxies.
Figure 2.3 shows the Android software framework including three additional layers not
included in the Android system architecture shown in Figure 2.2:
Figure 2.3: Android Software Framework (Android Securtiy, 2016)
Page 13 of 137
The University of Derby

Department of Computing and Mathematics
Applications – this is the layer which stores and controls both pre-installed applications
(alarm, browser etc.) and user-installed applications (facebook, twitter etc.) on the mobile
device. These directly interact with the Android Framework layer

Native Libraries – built directly on top of the Linux kernel is a set of libraries used for
storage of native code and data including a repository of application data (SQLite) and the
open-source web browser engine WebKit

Android Runtime – the majority of Android applications are written in Java programming
language. This layer is the dedicated environment to run both Dalvik and native device
applications, including a Dalvik virtual machine. It is important to note that each
application is run in its own instance of a Dalvik virtual machine, creating a single process
for each application (Android Security, 2016)
2.1.2 Android Operating System Timeline
The architectures outlined in Figures 2.1 and 2.3 are the fundamental building blocks of
Android’s software stack. First released in 2008 these stacks have evolved and would have looked
slightly different from each other, but with an identical concept. Google rolls out new versions of
Android’s operating system nicknamed ‘Sweet Treats’ on a frequent basis to keep up with
technological advancements, functionality and security (Android History, 2016).
Mobile users are carrying more private and personal information around with them on their
mobile devices and this information ranges from the location of the device, to his or her personal
details. As the Android platform has grown to take one of the largest shares of the smartphone market,
it has become a prime target for criminal activity (Lookout, 2014). It is for this reason system updates
are a vital security measure to prevent malicious intent or unauthorised access.
Android offers a multi-layered security model which reinforces not only application builds but
the security of the operating system. Each Android update includes a number of enhancements in
security, usability and system features, designed to keep users protected. Due to the technological
advancement, it wasn’t until Android Jelly Bean version 4.2 was released in 2012, that Android saw
noticeable changes to their system security (Android Security, 2016). Since 2012 to date, changes
have included key Android security features such as Application Verification, Cryptography, Sandbox
reinforcements with SELinux, improved Disk Encryption, Smart Locks, Multi user profiles, Runtime
Permissions and Hardware-Isolated Security (fingerprint detection, lock screens, device encryption
etc.) (Android Security, 2016).
Page 14 of 137
The University of Derby
Department of Computing and Mathematics
Figure 2.4 outlines the timeline of Android’s operating system updates, from the release in
October 2008, entitled ‘Android 1.0’, to October 2015, entitled ‘Android Marshmallow 6.0’.
Figure 2.4: Timeline of Android operating system updates
2.1.3 Android File-System
The Android File-System or File-Hierarchy is closely related to that of the Linux File-System,
which is understandable as the Linux Kernel is the base level of the Android operating system. In
Android the file hierarchy is a single tree originating from the root “/”, all the devices files and
directories are under this. Android uses multiple drives and partitions to split up all of the devices
assets. A Virtual File System (VFS) within the kernel abstract layer is used to access files, directories
and application operations. The Android Kernel will only ever contain compiled file system modules
for relevant operations, this means that the file system can be tailored for a device and may not be the
same across all Android products. Android supports the following flash memory file systems exFAT
(Extended File Allocation Table), F2FS (Flash-Friendly File System), JFFS2 (Journal Flash File
System 2), YADDS2 (Yet Another Flash File System 2), EXT2/EXT3/EXT4 (EXTended File
System), MSDOS (Support FAT12 – 16 – 32) and VFAT (An extension to the MSDOS file system)
(Anderson, 2013).
2.1.4 Linux Kernel Security
At the operating system level, Android provides the security of the Linux Kernel. The Linux
Kernel developed in the early 1990s has stood the test of time against attacks and has become a stable
Page 15 of 137
The University of Derby
Department of Computing and Mathematics
and secure kernel trusted by many corporations and security professionals (Morris, 2013). Several key
security features are implemented via the kernel, including a user-based permissions model later
discussed in section 2.3, process isolation, extensible mechanisms for secure inter-process
communication (IPC) and the ability to remove insecure parts of the kernel with ease. The Linux
security philosophy has always been to protect user resources from one another (Android Kernel
Security, 2016).
2.1.5 Application Sandbox Security
The application sandbox is part of the Linux Kernel and takes full advantage of Linux’s userbased protection to isolate and identify application resources. Process isolation is an important aspect
of Android’s core security features and the application sandbox reflects this principle. In the Android
system each application is assigned a unique user ID (UID) and is run as a separate user in a separate
process (Dalvik virtual machine). Each application is run in its own private environment, unable to
access other applications. Developers can however, give applications the correct privileges and
permissions to access other applications. In this respect the application and sandbox is only as secure
as the interpreted code and permissions (Android Kernel Security, 2016). If a malicious application
wants to read other sources of data or take control of the system, it will require the correct user
permissions before leaving the isolated process it is confined in.
Additionally, the developer of an application can ask for a shared UID. With a shared UID
multiple applications signed by the same developer will share the same sandbox. Applications
employing this method would have access to each other’s permissions, files and information, and
effectively be a single application as far as the operating system is concerned.
2.1.6 Android Root Exploits and Additional Attacks
Root access of any technical device, mobile or stationary, is seen as having superior
administrator rights and complete control over a devices core settings and features. By default no user
of an Android device should have root access, this is ensured by developers to prevent users from
accessing areas of the operating system they don’t need, which could be accidentally damaged or
destroyed. Developers should only have access to a device’s root settings when required to take
control and to adapt or update certain aspects of the operating system, including the hardware and
software. For this reason most system applications will require some aspect of a devices root
privileges and will have permissions assigned accordingly (Won-Jun et al., 2011).
Root exploits have been designed to allow malicious applications to take control of these root
privileges, preventing the user having any control of their mobile device. Trojans misusing these root
exploits are among the most dangerous malicious applications in the Android market. An application
with root access can replace, modify, and install applications and updates. First discovered in the
Page 16 of 137
The University of Derby
Department of Computing and Mathematics
Chinese Android application market in 2011, a malicious malware was discovered called
DroidKungFu. Once installed DroidKungFu would attempt to root the phone using coded exploits and
proceed to install further malicious applications, in an attempt to compromise and steal any private
user details and system information (Xuxian Jiang, 2011).
Phishing is a malicious source impersonating a trustworthy source in an attempt to acquire
sensitive information such as usernames, passwords, and in most cases bank details. Phishing is
commonly associated with electronic communication via e-mail and computing, however, in recent
years it has expanded to mobile devices. Felt and Wagner (2011) suggested that Phishing was on the
rise in mobile devices due to the size of a mobile’s screen, making it harder to identify whether a
source is attempting to spoof a user or not and the large increase in legitimate and illegitimate
applications, making it hard to trust sources in general.
SMS Senders are malicious applications which ask the user permission to access and send
SMS messages upon installation of the application. The application then proceeds to send SMS
messages to premium rate numbers generating a large cost on the user’s behalf. The Rufraud Trojan
first identified in December 2011 mimicked a popular application to send SMS messages to high rate
numbers (Symantec, 2016). Unfortunately it is down to the user to read the permissions of an
application and install it upon security recommendations.
Drive-by-Download has been a threat associated with computer systems for many years and
has recently made its way onto the Android mobile platform due to technological advancements in
mobile web browser services. A Drive-by-Download is the process of a user receiving malicious code
or fake updates from a compromised commercial website. If the user interacts with compromised
aspects of this website or downloads any files they could infect their device with a malicious
application, such as a Trojan etc. (Microsoft, 2016).
With the growing number of vulnerabilities in the Android community it is critical that users
and developers alike are using every resource available to combat the continuity of these threats. The
majority of users in today’s society have a good understanding of how to use a mobile device, but are
completely oblivious to security threats and attacks. While anti-virus software and security patches are
released regularly, it is the user’s responsibility to update their system and ensure security measures
are in place on their device, to prevent any damage to their data or the system. The best practice for
any user of an Android device is to only install applications from a trusted source (Google Play Store
etc.) and make sure the correct permissions are in place for the type of application being installed
(Boutet, 2010).
It is also important that developers releasing Android applications have a comprehensive
understanding of how to prevent their applications becoming compromised by a malicious source.
Page 17 of 137
The University of Derby
Department of Computing and Mathematics
Developers need to make sure they know exactly what private user and device data the application is
collecting and transmitting and only collect data needed for the application to function correctly and
never transmit private data over an unencrypted communication channel (Boutet, 2010).
2.2 Android Applications
Android has a very clear Governance Philosophy, which states that “Anyone can (and
will!) use the Android source code for any purpose, and we welcome all legitimate uses” (Android
Source Code, 2016). A legitimate acceptance of customised source code requires developers to follow
the guidelines of the Android Compatibility Program. This includes Android’s Software Development
Kit (SDK) with built-in tools to regulate how an application is built and defining technical details of
the Android platform, to ensure developer’s applications are compatible to run on multiple platforms,
including smartphones and tablets (Android Compatibility, 2016).
They also state “uncontrolled customisation can, of course, lead to incompatible
implementations” (Android Source Code, 2016). Any illegitimate use of source code reflects badly on
open-source communities, so Android has created the Android Compatibility Program as a precaution
to prevent misuse.
For this reason the fundamentals and components of Android applications will be covered in
more detail, as well as a brief overview of Application Signing, Application Capability Leaking and
Third Party Security for Android Applications.
2.2.1 Android Application Fundamentals and Components
Android applications commonly abbreviated to ‘apps’ are written in the Java programming
language and compiled into a single archive file using the Android SDK toolkit. This takes the java
code and compiles it into an Android package file, referred to as an APK (.apk). APK files contain all
the relevant resources and data that are required to install and run an app on an Android device
(Android Developer, 2016). Figure 2.5 outlines the build process of an Android application.
Figure 2.5: Building and running an Android application (Android Tools, 2016)
The “AndroidManifest.xml” file seen at the root directory of the “Android Package (.apk)” in
figure 2.5 contains four key components and any critical information an application requires to run. In
Page 18 of 137
The University of Derby
Department of Computing and Mathematics
order for an application to initially be installed on a mobile device, the system must first know that the
application components exist by reading the AndroidManifest.xml file. The manifest will also declare
the Application Program Interface (API); hardware and software features and the API libraries that the
application requires connection to (Android Developer, 2016). It will also contain the more critical
user permissions of an application relating to its level of security, discussed in more depth in section
2.3.
The “AndroidManifest.xml” is the Java package for an application that describes each element
and process of an application. Figure 2.6 presents an empty layout of an Android Manifest file, while
Figure 2.7 explains the role of each element. Each element within this example, along with attributes
would be coded according to the developer’s application specifications (Android Manifest, 2016).
<?xml version=”1.0” encoding=”utf-8”?>
<manifest>
<uses-permission />
<permission />
<permission-tree />
<permission-group />
<instrumentation />
<uses-sdk />
<uses-configuration />
<uses-feature />
<supports-screens />
<compatible-screens />
<supports-gl-texture />
<application>
<activity>
<intent-filter>
<action />
<category />
<data />
</intent-filter>
<meta-data />
</activity>
<activity-alias>
<intent-filter> . . . </intent-filter>
<meta-data />
</activity-alias>
<service>
<intent-filter> . . . </intent-filter>
Page 19 of 137
The University of Derby
Department of Computing and Mathematics
<meta-data/>
</service>
<receiver>
<intent-filter> . . . </intent-filter>
<meta-data />
</receiver>
<provider>
<grant-uri-permission />
<meta-data />
<path-permission />
</provider>
<uses-library />
</application>
</manifest>
Figure 2.6: The Layout of AndroidManifest.xml file (Android Manifest, 2016)
Element
<action>
Description
Adds an action to an intent-filter. If an intentfilter does not contain one or more actions, than
no intent objects will get through the filter.
<activity>
Declares an activity that implements a part of the
application’s visual user interface.
<activity-alias>
An activity alias is a subset of the activity
element and can be used to define independent
entities and attributes.
<application>
Declares each application component and the
attributes that can affect these components.
<category>
<data>
Adds a category name to an intent filter.
Adds a data specification to an intent filter.
Page 20 of 137
The University of Derby
<grant-uri-permissions>
Department of Computing and Mathematics
Specifies which data subsets of a content provider
permission can be granted for. Granting
permissions are a way of enabling clients of the
provider access to data, which may be restricted.
<instrumentation>
Declares an Instrumentation class that enables
you to monitor an application’s interactions with
the system.
<intent-filter>
Specifies the types of intents that an activity,
service or broadcast receiver can respond to,
handle and filter.
<manifest>
Is the root element of the AndroidManifest.xml.
<meta-data>
Is an additional arbitrary data element, which can
be supplied to components to declare further
resources.
<permission>
Declares a permission that can be used to limit
access to specific components or features of this
or other applications.
<permission-group>
Declares a name for the logical grouping of
related permissions. Members of a group are
presented together in the user interface.
<permission-tree>
Declares the base name for a tree of permissions.
The application takes ownership of all names
within the tree.
<provider>
Declares a content provider component that
supplies structured access to data managed by the
application.
Page 21 of 137
The University of Derby
<receiver>
Department of Computing and Mathematics
Declares a broadcast receiver enabling an
application to receive intents that are broadcast
by the system or by other applications.
<service>
Declares a service as one of the applications
components. These are used to implement
background operations or communication APIs
that can be called by other applications.
<supports-screens>
Declares the specific screen size your application
supports.
<uses-configuration>
Indicates what hardware and software features
the application requires.
<uses-feature>
Declares a single hardware or software feature
that is used by the application.
<uses-library>
Specifies a shared system library that the
application must be linked against, preliminary
for application installation.
<uses-permission>
Requests a permission that the application must
be granted to operate correctly. Permissions are
granted by the user when the application is
installed (devices running Android 5.1) or while
the application is running (devices running
Android 6.0 or higher).
<uses-sdk>
Specifies application compatibility with one or
more versions of the Android Platform, by means
of an API level integer.
Figure 2.7: Android manifest element descriptions (Android Manifest, 2016)
Page 22 of 137
The University of Derby
Department of Computing and Mathematics
Application components are the initial building blocks of an Android application. Each
component has a different role associated with the system and eventually the user. The four core
components of Android Applications are Activities, Services, Content Providers and Broadcast
Receivers.
All Android applications are composed of Activities, which are self-contained tasks designed
to provide information to the user. Activities usually represent a single screen of information such as
composing an instant message or e-mail. Activities are pro-active and start and cancel one another,
creating a clear flow of information to the user interface, including calling Activities from other
applications installed on the device (Android Developer, 2016).
The Service component of Android applications has no user interface and is responsible for
running all of the applications background processes, including fetching data remotely over a network
while a user is interacting with other applications on their device. Services are commonly called via an
Activity to provide further functionally to an application (Android Developer, 2016).
The Content Providers manage data associated with an application, shared or private. This
data can be stored within a file system, SQLite database, on the web or any other persistent storage
location. Applications will call upon the Contents Providers to query or even modify stored data (only
with permission from the applications Content Provider). For example contact information like names
and numbers can be used dynamically across a broad variety of Android applications, a Content
Provider will be implemented to distribute and control modification and flow of this data (Android
Developer, 2016).
The Broadcast Receivers are responsible for announcing system-wide notifications. Broadcast
Receivers are not commonly associated with a user interface; however, they can still announce
notifications such as low battery and other system messages to the user. In regards to Android
applications the Broadcast Receiver will allow an application to broadcast notifications to other
applications including new initiations of data, Activities or Services. Referred to as a “gateway” to
other components the Broadcast Receiver is intended to do the least amount of work out of the four
application components (Android Developer, 2016).
Android uses an asynchronous messaging object called Intent to activate these individual
components and to allow them to send messages and commands to one another. You can think of
Intent as a messenger that requests an action from another component. The Intent will be written to
describe what task has been requested (an Activity, Service, Provider or Broadcast) and the necessary
data required to complete the task (Android Intent, 2016). These messages will be passed backwards
and forwards amongst the four components repeatedly, to build the bigger picture of a functionally
running application.
Page 23 of 137
The University of Derby
Department of Computing and Mathematics
Figure 2.8: Example illustration of intent delivery (Android Intent, 2016)
Figure 2.8 outlines a simple Intent process. Activity A has requested the start of another
activity, in this case Activity B. The Intent is passed to the Android System, where it searches for the
application that matches the Intent request sent from A. Once found the Intent is sent to Activity B
creating a new process. The details of these processes will be controlled via the four application
components.
2.2.2 Application Signing
Android has a very simple yet effective procedure to increase levels of security amongst the
open-source community; a firm requirement is for all developers to sign their applications before
distribution. Android applications often use self-signed certificates which identify the author of an
application, where the developer holds the certificate’s private key. This ensures an author or
developer cannot be impersonated or duplicated via a malicious developer. The certificate also
provides a level of trust between the developer and the operating system, in that the signing process
alerts the system if the application has been modified after the developer signed it (Android
Application Signing, 2016).
2.2.3 Application Capability Leaking
Application Capability Leaking is the process of an application leaking access to a device or
system feature, providing other applications permissions to areas of the mobile device without actually
requesting access. This may not be done intentionally, but by allowing leaks to go unnoticed this
breaches Android’s permission based security model outlined in section 2.3. Grace et al. (2012)
created the Woodpecker project to develop a tool to identify leaked permissions or capabilities. In
their study they examined eight phone images and among 13 privileged permissions examined, 11
were leaked, with individual phones leaking up to 8 permissions. Malicious sources can exploit these
permission loopholes and wipe out user data, send SMS messages or record user activity without ever
asking for application permissions.
Page 24 of 137
The University of Derby
Department of Computing and Mathematics
2.2.4 Malicious Applications
The modern mobile platform, such as Android, increasingly resembles that of a traditional
computer’s operating system. This presents similar challenges and threats associated with the common
home personal computer. Malicious applications such as Trojans, Worms, Spyware and Botnets,
commonly associated with computing have found their way onto mobile devices. Due to Android’s
open source community, applications can originate from third party providers, external to trusted
sources such as the Google Play Store and present very modern malicious exploits. Malicious
applications have the simple goal of infecting a mobile device to compromise the user’s security and
privacy or even gaining complete control of the device. They are made even more dangerous on a
mobile device because they can be hidden in trusted applications in unsupervised application stores
and spread easily via a constant internet connection from Wi-Fi or 3G/4G (Delac et al., 2011).
Trojans, also referred to as Trojan Horses are deployed within a malicious application to gain
control of a targets device. Always in disguise the Trojan pretends to be a useful application with
malicious intent in the background, finding ways to access private information and install further
malicious code such as Worms or Botnets. They can also be used to perform phishing attacks by
gathering information, provided through the fake application interface, such as personal information,
bank details etc. (Delac et al., 2011).
Worms are self-replicating malicious applications designed to spread automatically to
uninfected systems, with the common method of infection through Bluetooth links. Similar to its
counterparts its main objective is to acquire sensitive information (Delac et al., 2011).
Spyware can come in two different forms, commercial and malicious. Commercial spyware is
applications installed on a user’s handset manually to specifically spy on that user with the mobile
devices system resources (camera etc.), while malicious spyware operates similar to its computer
counterpart, covertly stealing data and transmitting it to a third party (Te-En, Wei et al., 2012).
Botnets are a network of compromised devices which can be controlled and coordinated
remotely. Owners may never be aware they are part of this compromised network of devices;
however, their devices will be used to conduct Denial of service attacks or the process of stealing
sensitive user information for the purpose of illegally gaining money (Delac et al., 2011).
2.2.5 Third Party Security for Android Applications
Mobile applications have become one of the key channels for companies to drive content and
services to consumers, however, this rise in demand means application developers are keen to
distribute innovative apps and content at higher speeds without considering possible risks, threats and
attacks on application security. In a recent poll from Mintel, 96% of consumers had at least one
Page 25 of 137
The University of Derby
Department of Computing and Mathematics
security concern when using online applications or entering online information (personal data, bank
details, addresses etc.) and cybercrime has been rising, with the National Fraud Intelligence Bureau
(NFIB) reporting an accounted loss of £670 million pounds from online fraud (Mintel, 2015).
In the official Google Android Security Report 2014, Google stated that, “their in house
security teams provided patches for 41 moderate, 30 high, and 8 low severity vulnerabilities.” In
addition to providing fixes in the platform level of Android, these teams are designed to monitor and
capture any vulnerability, which could compromise device or user information (Google Security
Report, 2014).The Common Vulnerabilities and Exposures (CVE) security vulnerability database
recorded a massive 130 vulnerabilities in 2015 including 56 Denial of Service attacks, 73 Code
Executions, 65 Overflows, 47 Memory Corruptions, 22 System Bypasses, 38 Information and
Privilege leaks. This is a massive increase of 119 documented vulnerabilities since 2014, with a
further increase of 13 vulnerabilities identified in 2016 already (CVE, 2016). It is clear from these
reports that the growth in Android’s popularity over recent years has brought an increased variety of
security threats and risks to their operating system and applications.
Anti-virus giants such as AVG, Norton and many other market professionals have developed
mobile applications for Android and iOS (Apple’s operating system) with the intent of providing users
with a further layer of security, external of a devices hardware or software pre-sets. Anti-virus
applications are created to prevent malicious applications from being installed on a device. Pre-built
features include the ability to scan applications for malicious behaviour before installation, locate
stolen or misplaced devices and remotely wipe the information off a missing device, with the power of
restoration and backups (AVG, 2016).
The ‘Google Play Store’, previously known as the ‘Android Market’, is Google’s official store
and portal for Android applications. Android have implemented levels of security at this level to
monitor and prevent malicious applications affecting any Android mobile device (Android Central,
2015). A simple security precaution of the Google Play Store is the ability to remotely kill and remove
any application from users’ handsets and the marketplace, if and when an application is violating the
Developer Distribution Agreement (Google Developer Distribution Agreement, 2016) or the
Developer Program Policies (Google Developer Content Policy, 2016). In most cases, applications
that violate these agreements are malicious in one way or another and this capability has been utilized
to remove malicious applications on more than one occasion. On January 13th 2016, thirteen Android
applications were banished from the Google Play marketplace after the application attempted to gain
root privileges of user handsets (Goodin, 2016). The remote kill switch is however, only useful
against applications installed through the Google Play market. If the application in question has been
directly installed via its .apk file then it will not be captured by this feature (Cannings, 2011).
Page 26 of 137
The University of Derby
Department of Computing and Mathematics
In an attempt to reduce malicious software and applications ever reaching the Google Play
Store, a new layer of security was introduced in 2012, nicknamed ‘Bouncer’. The aim of this software
was to analyse applications and developer accounts for malware, spyware and trojans. It also goes as
far as flag applications, which show abnormal behaviour and in extreme cases will simulate an
application running on an Android device to identify any hidden behaviours. This is however an
automated process that uses the characteristics of known malware to analyse the applications with no
human interaction, which means that not all malicious activity can be captured, only that of previous
malicious applications (Lockheimer, 2012).
2.3 Android Permission Model
Android is a privilege-separated operating system, in which each application runs with a
distinct system identity and is isolated by the Linux kernel into a virtual sandbox, separating them
from other applications and to protect the system’s integrity and user privacy. If an application wants
to use resources or information outside of its sandbox, then the application has to explicitly request
permission. Depending on the type of permission the application requests, the system may grant it
automatically or the system may ask the user to grant the permission. Android defines this process as a
finer-grained security feature used to enforce restrictions of specific operations with the use of
permissions and so the Android Permission Model was created (Android System Permissions, 2016).
The following sections will outline the fundamental parts of Android’s Permission Model
including section 2.3.1 covering how Android permissions work, section 2.3.2 Android authorised
permissions, section 2.3.3 developer custom permissions, section 2.3.4 Application permissions prior
to Android update 6.0. Section 2.3.5 will outline the changes Android’s Permission Model has seen in
the most recent update 6.0 Marshmallow and section 2.3.6 will outline the risks associated with
Android permissions.
2.3.1 How Android Permissions Work
The Android security architecture states that no application, by default, has permission to
perform any operations that would impact other applications, the operating system, or the user. As
previously stated Android applications operate in individual sandbox environments with no access to
resources or data outside of their sandbox. Android created their permission model as a means for
these applications to call functions, to allow them permission to additional capabilities not provided by
the basic sandbox (Android System Permissions, 2016).
Previously discussed in section 2.2.2, applications are signed by developers to assign a
specific certification to their applications. This certification identifies the author of the application and
allows the system to grant or deny applications basic access to what is known as SignatureOrSystem
Page 27 of 137
The University of Derby
Department of Computing and Mathematics
Permissions, which allows the application to interact with the operating system of the device (Android
System Permissions, 2016). The levels of permissions will be discussed in more detail in section 2.3.4.
A basic Android application has no permissions associated with it by default; developers are
responsible for populating an application with permissions, appropriate to its functionality.
Application permissions are stored in a file called the “AndroidManifest.xml” found inside the
“Android Package (.apk)” file of the application. Once installed onto a device these permissions can
only be changed during system or application updates, however, these changes will require user
approval for installation (Android Developer, 2016).
The <uses-permission> tag is an element within the AndroidManifest.xml file which allows
the developers to declare what permissions must be granted for the application to function correctly.
Permissions are granted by the user when the application is installed on devices running Android 5.1
or while the application is running on devices running Android 6.0 or higher (Android Manifest,
2016). Figure 2.9 outlines an example of the <uses-permission> tag requesting permission to use the
RECEIVE_SMS function.
Figure 2.9: Example of <use-permission> XML tag (Android System Permissions, 2016)
The system’s behaviour, after a permission is declared, depends on how sensitive the
permission is. If the permission does not affect user privacy then it will be granted automatically, if the
permission might access sensitive data the system will ask the user to approve the request (Android
System Permissions, 2016). This depends on whether the permission is classed as Normal or
Dangerous.
All application permissions come with four levels of protection: Normal, Dangerous,
Signature and SignatureOrSystem. These levels are based on their capacity for damage to the target
system or user data. The Android packager installer will not ask the user approval for permissions with
the protection level of Normal, however, a level of protection Dangerous will cause warnings to be
displayed to users before installation, requiring further user approval (Android Permission, 2016).
Figure 2.10 outlines the Android defined meanings behind each permission level of protection.
Protection Level
Description
Normal
A low risk permission that gives requesting
Page 28 of 137
The University of Derby
Department of Computing and Mathematics
applications access to isolated application – level
features, with minimal risk to other applications,
the system, or the user.
Dangerous
A high risk permission that would give a
requesting application access to private user data
or control over a device that can negatively
impact the user.
Signature
A permission that the system grants only if the
requesting application is signed with the same
certificate as the application that declared the
permission.
SignatureOrSystem
A permission that the system grants only to
applications that are in the Android system image
or signed with the same certificate as the
application that declared the permission. This
permission is used in certain special situations to
allow multiple vendors to share specific features
explicitly because they are built together.
Figure 2.10: Permission levels of protection (Android Permission, 2016)
Android outlines a very clear set of best practices for developers trying to get the most out of
their applications while using the permission model responsibly. It is very easy for a developer to put
more permission into an application than it actually needs and very quickly the user can be
overwhelmed by the amount of requests they need to approve, just to use an application. The
developer should only ask for permissions that are vital for the applications functionality, explain why
the application requires the permission and then to code the application accordingly, so the user is not
faced with frequent dialog boxes for permission approval (Android Best Practices, 2016).
In most cases Android gives developers more than one way to perform an action and
permissions are no exception. Developers can have an application, ask for a permission to perform an
operation itself, or define an Intent, to have another part of the system perform that operation for the
application. Previously discussed in section 2.2.1, Intent is an asynchronous messaging object used to
communicate with other attributes and components in an Android device. Intent therefore can be used
to send messages to other elements of a device to access and retrieve data unavailable by the
application (Android Best Practices, 2016).
Page 29 of 137
The University of Derby
Department of Computing and Mathematics
For example if an application requires access to a user’s camera they can either ask for the
permission CAMERA, for access to the camera directly, or create an Intent to request an image to be
taken. This will allow the devices camera application to capture an image and return it to the
application without giving it access to the camera applications overall functionality. There are
obviously advantages and disadvantages to both features available to developers, Figure 2.11 outlines
these advantages and disadvantages.
Method
Advantage
Disadvantage
Using a Permission
The user has the power to grant the The application has full control over
application access to the required the user experience when an operation
permission, after that the application is
performed.
can perform the operation without complexity
to
This
a
may
task
add
since
an
additional interaction. Regardless the appropriate user interface will need to
user has the power to accept or decline be designed accordingly.
permissions, keeping control over how
their applications function.
Using an Intent
A specific user interface does not need The application has no control over the
to be created for the operation. The users experience and the user could be
application that handles the intent interacting with an application the
provides the user interface.
developer has never encountered.
The user does not have a default
application for an intents operation and
will have to define one every time the
user performs this operation.
Figure 2.11: Advantages and disadvantages of permissions and intent (Android Best Practices, 2016)
Android theoretically provides developers with everything they need to create functional
applications, but it is their responsibility to use these features and tools responsibly to provide users
with a meaningful service, without jeopardising their sensitive data or abusing their trust.
The
following sections expand on the fundamentals of Android’s permission model to understand how it
works from a user’s point of view and the changes it has undergone in recent years.
Page 30 of 137
The University of Derby
Department of Computing and Mathematics
2.3.2 Android Authorised Permissions
Figure 2.12 outlines four example permissions authorised by Android for developers to use
when developing applications. Please refer to Appendix A to see the complete list of Android’s
Authorised Permissions.
Permission Name
ACCESS_CHECKIN_PROPERTIES
Permission Description
Allows read/write access to the "properties" table in
the checkin database, to change values that get
uploaded.
ACCESS_COARSE_LOCATION
Allows an app to access approximate location.
ACCESS_FINE_LOCATION
Allows an app to access precise location.
ACCESS_LOCATION_EXTRA_COMMA
NDS
Allows an application to access extra location
provider commands.
Figure 2.12: Example subset of Android permissions (Android Manifest.permission, 2016)
2.3.3 Developer Custom Permissions
Developers can also create and use ‘Custom Permissions’ external to the authorised google
permissions to restrict access to various application services or components. When an application
interacts with other application components the required permission would be called to approve access
based on a set of parameters outlined by the developer. These custom permissions are freely available
to other developers and Intent can be used to access these permissions by other applications or areas of
the system. Figure 2.13 outlines the basic shell syntax a developer would populate to create a ‘Custom
Permission’ (Android Permission, 2016).
<permission android:description="string resource"
android:icon="drawable resource"
android:label="string resource"
android:name="string"
android:permissionGroup="string"
android:protectionLevel=["normal" | "dangerous" |
"signature" | "signatureOrSystem"] />
Figure 2.13: Android permission syntax (Android Permission, 2016)
2.3.4 Application Permissions prior to Android Update 6.0 Marshmallow
Application permissions are an aspect of Android’s security model, which allows users to
have power over what they can and cannot accept on their mobile devices. As previously mentioned,
Page 31 of 137
The University of Derby
Department of Computing and Mathematics
Android applications run in an individual application sandbox with a limited range of system
resources. When an application is requested to be installed on a device running Android 5.1 or lower,
Android automatically restricts the application’s capability until the user explicitly accepts the
installation and access to the operating system or features that the application requires to function
correctly. This provides a brief technical description to a user of what that application will be
accessing within the device once installed (Android Security, 2016). Figure 2.14 outlines the usual
display of application permissions presented to a user at the time of installation.
Figure 2.14: Display of Android permission system for ‘Maps’ (Android Security, 2016)
On devices running Android 5.1 or lower, application permissions are all or nothing; users
must accept all the permissions of an application or decline the application completely. This concept
prevents legitimate developers from being concerned whether or not users can refuse single
permissions that would cause their application to crash or behave incorrectly. It also allows users to
deny suspicious applications, depending on certain permissions, even if the application itself provides
an interesting service (Android Security, 2016). Developers can also create hidden permissions which
are used to function with other applications on a user’s device; however, this counteracts parts of the
security of the application sandbox. These permissions are not stated during the installation process
and remain unseen from the user; it is only by examining the “AndroidManifest.xml” file that these
hidden permissions can be determined (Android Security Tips, 2016).
Page 32 of 137
The University of Derby
Department of Computing and Mathematics
2.3.5 Android 6.0 Marshmallow: Changes to the Permission Model
Android 6.0 Marshmallow was released in October 2015 and is currently the newest version
of Android’s mobile operating system. Every update Android has released has been designed to give
the user a more interactive, friendly and safer mobile environment. Update 6.0 boasted about
providing users with more contextual assistance, better battery life, and higher levels of productivity,
connectivity and internationalisation, however, its greatest improvements were its dynamic changes to
Android’s most talked about privacy and security feature, their permission model (Android
Marshmallow, 2016).
Beginning with Android 6.0 users can now grant permissions while applications are running,
no longer asking for permissions to be granted upon an applications initial installation, previously
discussed in section 2.3.4. This approach is designed to streamline the application installation process,
since the user no longer has to grant any permission to install or update an application. Update 6.0 also
provides users with advanced functionality and control over their applications, by giving them the
power to revoke individual permissions from an application via the application settings interface
(Amadeo, 2015). For example a user could choose to give a transport application access to their device
location but reject access to view their contact list or SMS services. Figure 2.15 shows the new user
interface for this advanced control.
Figure 2.15: Application permission settings (Amadeo, 2015)
A device running Android 6.0 or higher now defines dangerous permissions into what
Android refers to as ‘Permission Groups’. These groups are what is displayed to a user when accepting
permissions and how the user interacts with permissions when turning them on and off. Compared to
Page 33 of 137
The University of Derby
Department of Computing and Mathematics
figure 2.13 in section 2.3.4, the user will no longer see a small brief technical description about what
the permission does, but the ‘Permission Group’ they are associated with (Android System
Permissions, 2016). Figure 2.16 outlines the 9 ‘Permission Groups’ and their associated Dangerous
permissions.
Permission Group
Dangerous Permissions
Calendar
READ_CALENDAR
WRITE_CALENDAR
Camera
CAMERA
Contacts
READ_CONTACTS
WRITE_CONTACTS
GET_ACCOUNTS
Location
ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION
Microphone
RECORD_AUDIO
Phone
READ_PHONE_STATE
CALL_PHONE
READ_CALL_LOG
WRITE_CALL_LOG
ADD_VOICEMAIL
USE_SIP
PROCESS_OUTGOING_CALLS
Sensors
BODY_SENSORS
SMS
SEND_SMS
RECEIVE_SMS
READ_SMS
RECEIVE_WAP_PUSH
RECEIVE_MMS
Storage
READ_EXTERNAL_STORAGE
WRITE_EXTERNAL_STORAGE
Figure 2.16: Permission Groups (Android System Permissions, 2016)
These changes make the system behave completely different when an application requests a
dangerous permission. Any permission can belong to a permission group, including Normal
permissions; however, the permission’s group only affects the users experience if the permission is
classed as Dangerous. If an application requests a Dangerous permission that has not got a listed
permission group then the user will be presented with a dialog box describing the permission the
Page 34 of 137
The University of Derby
Department of Computing and Mathematics
application wants access to; once the user has accepted or declined the requested permission a group
will be created accordingly. If another Dangerous permission is requested, that falls into the same
permission group as a permission previously accepted, the system will automatically grant that
permission access without further user interaction (Android System Permissions, 2016). For example
if the READ_CALL_LOG has been previously granted from the Phone group and then the
WRITE_CALL_LOG permission is requested by the same application, the system will immediately
grant the application access.
All of these new changes have affected the way developers now write and create applications.
Developers creating applications for devices running 5.1 or lower understand that their applications
will either be accepted or declined upon installation, barely affecting the way the permissions need to
be defined. However, now that users have the power to turn permissions on and off developers have
had to implement new procedures to check if permissions are on or off. Checking for permissions is
defined by the function ‘Context.Compat.checkSelfPermission()’ and called every time an application
requests a Dangerous permission, to determine whether the user has previously accepted that
permission, declined it or turned it off. (Android Run-Time Permissions, 2016). Figure 2.17 outlines
an example of an application checking for the WRITE_CALENDAR permission.
Figure: 2.17: Function example (Android Run-Time Permissions, 2016)
If the permission check returns false and defines a permission has never been requested
before, the developer will use the function ‘requestPermissions()’ to request the new permission. This
makes a very simple If-Else statement outlined in Figure 2.18. If the permission check comes back
false and the user hasn’t already declined or accepted the requested permission, then the user will be
presented with a dialog box during run-time to accept or decline the newly requested permission
(Android Run-Time Permissions, 2016).
Page 35 of 137
The University of Derby
Department of Computing and Mathematics
Figure 2.18: If-Else statement example (Android Run-Time Permissions, 2016)
Applications in the marketplace built before the release of Android 6.0 will still behave in the same
way as before, however, they may cause a few errors on the users device. Upon installation of these
older applications the user will still be shown the permissions and accept or decline them accordingly
to install the application onto their device. The user is still able to enter the applications system
settings and disable permissions of their choice, however, they will not have any run-time dialog
boxes informing them of any changes to the applications permissions and most permissions declined
on older builds will return empty data space to the user and break the functionality of the application.
If the user turns off the Location permission group and the application tries to get the location it will
simply return the value “Location not available”; this may affect or completely halt the functionality
of the application and users are advised to leave older application permissions on (Birch, 2015).
Android 6.0 has improved their permission model to provide users with more power to control
how their applications interact with their device and the environment around them; however, the
fundamental risks regarding permissions are still unresolved. Users still don’t understand how these
permissions actually interact with their device and why they are requested, while developers still
Page 36 of 137
The University of Derby
Department of Computing and Mathematics
create applications with more permissions than they actually need. The development of Android’s
permission model analysis will be touched upon in greater detail in section 2.4.3.
2.3.6 Risks with Android Permissions
To ensure security and privacy, Android uses a permission-based security model to mediate
access to sensitive data. Regardless of using this model to secure Android applications, these
permissions can also be assigned incorrectly by developers making an application, Over-Privileged or
Least-Privileged, producing an unnecessary threat to privilege escalation attacks from malicious
sources (Xuetao et al., 2012).
Over-Privileged Applications are applications, which operate using more permissions than
they require to function correctly, giving additional access to other applications or areas of an Android
device it does not require. If a malicious source took control of an Over-Privileged Application the
scope of damage is increased, as the application can access more of a device’s sensitive information
(Felt et al., 2011). Least-Privileged Applications are applications which operate using the least set of
permissions required to function correctly. The Least-Privilege principle states that minimum access
should be maintained to limit damage from accidents, errors or unauthorised use (Langford, 2003).
2.4 Recent Developments in Android Application Security
Due to the large quantity of research undertaken relating to the security and analysis of
Android and Android’s applications, the following research reflects on some of the most critical
problems associated with Android application security in relation to the risks and attacks discussed in
section 2.4.
2.4.1 Developments in Android Application Distribution and Malicious
Application Detection
Gartner (2015) predicts that by 2017 mobile applications will generate a massive $77 billion
dollars, with popular applications being downloaded more than 268 billion times. Mobile applications
have become one of the key channels for companies to drive content and services to consumers’,
however, application marketplaces create a false sense of security for users, with studies revealing that
security is not the main tenet for these marketplaces, which can harbour malicious or vulnerable
applications (Gartner, 2015). Mahmood et al. (2012) researched the security measures taken by
Android application stores to prevent malicious applications compromising user devices. By
identifying the lack of practical methods for analysing application security in the marketplace, they
developed an Android – specific technique based upon ‘fuzz testing or fuzzing’ (feeding malicious
data into an application to reveal vulnerabilities) to test the robustness of security before an application
was submitted to the Android marketplace. Specifically producing a framework for automated security
Page 37 of 137
The University of Derby
Department of Computing and Mathematics
testing of Android applications on the cloud, Mahmood et al.’s (2012) scope failed to identify key
short falls in the security of the Android marketplace; however, they provided a method to single out
malicious applications before reaching the marketplace.
Grace et al. (2012) designed and produced ‘RiskRanker’, a scalable and accurate Zero-day
Android malware detection tool. With the large amount of malicious applications infiltrating
smartphone application marketplaces, existing anti-virus systems have become obsolete in identifying
new techniques and designs of malicious applications. ‘RiskRanker’ was designed to identify
malicious applications within Android’s marketplaces without relying on previously known malware
samples and signatures. 118,318 applications were collected and analysed revealing 3,281 risky
applications. Compared with the research undertaken by Mahmood et al. (2012), Grace et al. (2012)
have attempted to monitor and remove malicious applications already existing in Android’s
marketplaces, rather than trying to produce a system to identify malicious applications before
distribution.
Zhou et al.’s (2012) ‘DroidRanger’, similar to Grace et al.’s (2012) ‘RiskRanker’, proposed a
permission based behavioural scheme to detect new samples of known Android malware families in
official and alternative Android marketplaces. In a collection of 204,040 applications from five
different marketplaces, 211 malicious applications were identified. 32 found on the official Android
marketplace, including 2 zero-day malicious applications and 179 from alternative marketplaces. It is
clear from these results that third-party marketplaces pose a great threat, due to their disregard for
security and by still finding malicious applications in official marketplaces, shows a clear need for
improved security processing of applications before distribution. The difference between the two tools
‘RiskRanker’ and ‘DroidRanger’ is their methods of detecting zero-day malicious applications, but
their results are comparable.
Viennot et al. (2014) built a tool called ‘PLAYDRONE’, the first scalable Google Play
crawler tool, designed to filter and explore the content of applications distributed by Android’s most
well-known marketplace. An average of 1,100,000 applications were indexed and analysed, with a
further 880,000 free applications being decompiled for analysis. ‘PLAYDRONE’ was designed to
perform large scale characterizations of Android applications in the Google Play Store, to demonstrate
how content has evolved over time and to identify any malicious intent in applications. It was
identified in Viennot et al.’s (2014) research that the Google Play Store has only ever had access to an
applications compressed binary package, with application source code only accessible by third-party
developers, greatly reducing the scope of Android’s application testing before distribution. In
comparison to the other studies ‘PLAYDRONE’ was designed to explore the entirety of an
applications design and content, while identifying malicious intent as a benefit of the tools design.
Page 38 of 137
The University of Derby
Department of Computing and Mathematics
Due to the large amount of research undertaken in the area of Android application security in
the Android marketplace, these four studies are just indicative of the amount of methodologies, tools,
and models being produced to identify malicious applications. The lack of security in Android’s
application distribution and the rise in malicious application injections, makes it clear that there is a
need for improved security policies and methods of malware detection before an application is
distributed to a user’s device.
2.4.2 Developments in Inter-Application Communication
Research has been undertaken into the open design of Android’s application program interface
(API) to understand the vulnerabilities of Android applications and inter-application messaging. Interapplication communication allows applications to communicate with third party services and other
applications, to create one seamless user interface. Unfortunately the design of these applications can
allow malicious applications or external factors to intercept, steal, or manipulate these messages to
breach user privacy and sensitive data. Refer to section 2.2.1 Android Application Fundementals and
Components for an in depth understanding of Android’s communication model (Android Developer,
2016).
Chin et al. (2011) created a tool called ‘ComDroid’ to detect vulnerabilities in application
communication systems. ‘ComDroid’ was designed for developers to analyse application
communication vulnerabilities before release. The initial research study analysed 20 applications
finding 34 exploitable vulnerabilities in their design. ‘ComDroid’ is also available to the Android
marketplace and end users to analyse applications already released on the market. Designed for static
analysis ‘ComDroid’ identifies and issues warnings, but does not verify the existence of attacks or
available fixes for the vulnerabilities found in the application’s design. Not providing dynamic
analysis means that ‘ComDroid’ cannot identify vulnerabilities while an application is running,
reducing the scope for vulnerability detection.
With a similar scope to Chin et al.’s (2011) ‘ComDroid’, Octeau et al. (2013) developed a tool
called ‘Epicc’ (Efficient and Precise ICC). ‘Epicc’ was designed to identify inter-component
communication (ICC) (otherwise known as inter-application communication) vulnerabilities, with far
less false results than the next best tool at the time, which in their opinion was ‘ComDroid’. ‘Epicc’
like ‘ComDroid’ was a static analysis tool, however, it was designed with a superior analysis model,
allowing the tool to branch further into Android’s application communication structure, not only
revealing any vulnerability in an application, but storing the data for future application analysis. This
meant existing applications on the market could be analysed and compared with vulnerabilities found
on previous applications. 1200 applications were analysed in their initial study, with an average
analysis taking 113 seconds per application, demonstrating the tools capability to scale higher than any
previous tool on the market. As it does not provide dynamic analysis it also shares the same
Page 39 of 137
The University of Derby
Department of Computing and Mathematics
weaknesses as ‘ComDroid’, which are not being able to identify vulnerabilities while an application is
running, reducing the scope for vulnerability detection.
The growing variety of static analysis tools on the market gives a very one-sided approach to
application security analysis. However dynamic analysis tools have been designed to capture
vulnerabilities whilst interacting with live applications. Enck et al. (2010) designed ‘TaintDroid’,
which provided a real-time, dynamic, system wide tracking and analysis tool, capable of
simultaneously tracking multiple sources of sensitive data. Their initial study monitored the behaviour
of 30 popular third-party Android applications, with 68 instances of potential misuse of user
information across 20 of the 30 applications. The short fall of ‘TaintDroid’ was its ability to track
control flows of an application, which weren’t implemented in the design of the tool to minimize
performance overheads and to focus on the ability to track the data flow of an application. In order to
track the control flow of an application correctly a tool requires static analysis components similar to
that of ‘ComDroid’ and ‘Epicc’.
Both static and dynamic analysis tools are available on the market for developers and
distributers to evaluate their application security. Research has been undertaken to combine the two
principles of static and dynamic analysis to create a hybrid tool capable of analysing an application in
its entirety. Influenced by Chin et al.’s (2011) ‘ComDroid’ and Enck et al.’s (2010) ‘TaintDroid’,
Zheng et al. (2012) developed ‘SmartDroid’ capable of both static and dynamic application security
analysis. The principle of ‘SmartDroid’ was to analyse user interface (UI) interactions of running
applications to detect sensitive application behaviour in areas not captured by previous tools. The
static analysis side of the tool was designed to analyse both activity and function calls of an
application, while the dynamic analysis explored the UI interactions. A prototype was produced in
2012 to investigate the behaviour of potentially malicious applications, which otherwise could not be
detected with existing techniques. The short fall of ‘SmartDroid’ is its lack of complex algorithms and
processes to capture live data outside of the UI interactions, including complex events or logic based
triggers, which can affect sensitive application behaviours.
2.4.3 Developments in Android’s Permission Model Analysis
Research has been undertaken regarding Android application permissions to determine what
permissions were requested on an Android device when an application was installed and accessed;
identifying whether developers were creating their applications following the ‘least privileged’ or
‘over privileged’ guidelines. The latter exposing user’s to vulnerabilities to their privacy and personal
data. Vidas et al. (2011) developed a tool to assist developers in utilizing least privileged permissions
in Android applications. This tool, ‘Permission Check’ was an Eclipse integrated development
environment (IDE) plugin, that could be used alongside the Android specific development
environment provided in the SDK. This tool provided a method of assigning an application the least
Page 40 of 137
The University of Derby
Department of Computing and Mathematics
privileges by highlighting code that required certain permissions and highlighting pre-written
permissions, which wouldn’t be required in the application design. The tool was primarily designed
for source code analysis and ran into problems when it wasn’t mandatory for developers to release
their code, as well as most of the application packages being compiled into a XML and JAVA class
format before release, making the ‘Permission Check’ plugin virtually useless at any stage other than
application development.
Felt et al. (2011) used Vidas et al.’s (2011) findings and further researched Android
application permissions to create a tool called ‘Stowaway’. ‘Stowaway’ was designed to detect ‘over
privileged’ applications in compiled application packages, where Vidas et al.’s (2011) ‘Permission
Check’ tool could not, specifically aimed at determining API calls from an application to build a
permission map. The tool was primarily used to investigate the causes of ‘over privilege’ and find
evidence to substantiate whether developers were trying to follow ‘least privilege’; but it failed to do
so due to insufficient documentation during development. The short fall of ‘Stowaway’ was its lack of
ability to handle complex reflective calls and Java reflection (used to make API calls) in Android static
analysis tools.
‘Stowaway’ is considered out of date now and does not produce accurate results on modern
Android applications. Wain Yee Au et al. (2012) produced the tool, ‘PScout’ designed to extract the
permission specification from the Android’s OS source code using static analysis. ‘PScout’ is seen as
‘Stowaway’s’ improved replacement in regards to Android permission analysis is still relevant today.
‘PScout’ was used in its initial study to analyse 4 versions of Android, spanning from version 2.2 to
4.0, to understand the permission model of the Android OS and therefore relate it to how Android
applications were being developed. Wain Yee Au et al.’s (2012) analysis identified that Android had
over 75 permissions with little redundancy, however, if the applications developed could be
constrained to only documented APIs then only 22% of non-system permissions were actually
necessary for an application to perform correctly. Not specifically designed to evaluate the ‘least
privilege’ and ‘over privilege’ model of Android applications, ‘PScout’ attempted to find the root
problems of the Android OS permission model, whereas ‘Permissions Check’ and ‘Stowaway’
analysed the applications directly.
Research from these three studies identified some key developments in analysis of Android’s
permission model, specifically in ‘over privilege’ applications. A consistent factor found in these
studies is the overwhelming amount of Android permissions and the underwhelming amount of
permission documentation, making it very easy for developers to make common errors when
developing Android applications and in most cases producing ‘over privileged’ applications.
Page 41 of 137
The University of Derby
Department of Computing and Mathematics
Barrera et al. (2010) took a different approach to analysing Android’s permission model. They
created a methodology designed to empirically analyse the permissions of Android applications.
Empirical research is the method of gaining knowledge by direct or indirect observation or experience
of a subject, in this case to investigate how the permission-based system worked in practice and to
identify strengths and limitations of the current implementation. Barrera et al. (2010) took a sample of
1,100 Android applications consisting of the top 50 free applications downloaded in 2009 from each of
the 22 categories in the Android Market and with the help of the Self-Organizing Map (SOM)
algorithm, identified a trend in how developers of these applications used the Android permission
model. The dataset was designed to be diverse and representative; however, by choosing top-ranked
applications, they missed out on analysing possible malicious or poorly written applications.
Regardless they visually displayed the usage trends of Android permissions, revealing a small number
of permissions being used very frequently and a large number of permissions being used only
occasionally and correlating the results between several of the infrequently used permissions. They
identified that Android had far too many permissions that impacted on both developers and end users.
It is important for developers to understand what is needed to perform certain actions, while it is
important for users to understand exactly how permissions will impact on application usage.
Permissions are described in a friendly language when being installed, however, they are technically
brief and do not disclose what is intended by having access to a certain resource.
Although Android’s permission model is intended to allow users to make informed decisions
about their privacy, it is often ineffective at conveying meaningful, useful information on how an
application may impact a user’s privacy and security. Rosen et al.
(2013) analysed 80,000
applications using API mappings and static analysis to produce a high-level behaviour profiler called
‘AppProfiler’.
The behaviour profiles of these analysed applications were consolidated into an
Android application, to allow users to review their findings and provide feedback on whether this
research had provided better knowledge and understanding on the impact of these applications on user
privacy. Rosen et al. (2013) found five clear limitations to Android’s permission model before
analysing these applications, which is still significant in today’s research of Android’s permission
model. Most permissions are so prevalent that users ignore them, permissions generally cover a broad
category of functionality with insufficient detail on how they are being used, applications often request
permissions they don’t use, certain behaviours of applications, which should be protected by
permissions aren’t, allowing applications to bypass the permissions model and the permission model is
so tightly integrated within Android’s operating system, making it very difficult to fix these problems,
resulting in a trade-off between operating system stability and fine-grained permissions. Regardless of
analysing these limitations, Rosen et al. (2013) demonstrated that users craved a source of knowledge
at a greater technical depth than what was currently being provided and could use the extracted data
from AppProfiler to find trends in the application market place. They expressed that for the permission
Page 42 of 137
The University of Derby
Department of Computing and Mathematics
model to be improved it needed to be fine-grained enough to meet the needs of users, where they
could make their own distinctions between permissions and understand how these permissions work,
whether they were performing actions caused by the user or actions taking place in the background.
William Enck (2011), a leading researcher in smartphone security, recently published a paper
on the techniques and future direction of defending users against smartphone applications. Enck
(2011) covered platform protection, protection mechanisms and application analysis from many
different angles, including views from other researchers. However, Android’s permission model was a
focus point for the majority of his discussions. Enck (2011) described Android permissions in two
ways, install-time (permissions approved at the time of installation) and time-of-use (permissions
approved while the application is running). While the Android permission model allows users to
consent to what their applications can access, the maximum privilege level an application can reach
and a method of security review triaging, Android’s permission-based protection system is rule driven,
therefore, one must understand the semantics of individual permissions to understand the global
policy.
It was recommended that an application had multiple stages of analysis deeper than their
initial permissions, to understand the applications true intent and whether they had any provable
malicious intents or relationships. Enck (2011) observed that permission analysis was valuable for
performance efficient security analysis but was very limited compared to dynamic or static analysis,
which could be used to indicate application behaviour and functionality. Dynamic analysis identifies
what actually happens when an application is running, however, is limited by scalability and most
methods designed to statically analyse an application require custom tools to overcome hurdles created
by Android’s middleware. Enck (2011) concluded that Android’s permission model had granularity
issues, with developers making clear trade-offs between security and usability when defining
permissions. Android defined permissions cannot be compared and are not intended to be transitive.
This makes it very difficult to implement a high-level policy based purely on Android’s permissions
without generating a lot of exceptions, therefore it requires the knowledge of developers and
researchers to analyse and recommend improvements to the permission model to protect users and
application security.
Page 43 of 137
The University of Derby
Department of Computing and Mathematics
2.5 Conclusion
A literature review of Android and the fundamental components of Android applications,
including its security and architectural design was undertaken. The recent developments outlined in
section 2.4 cover specific studies relating to Android application security and the environments these
applications are distributed in. These studies outline very specific tools and methodologies to evaluate
technical areas of Android applications, including Android’s permission model, source code
developments, static and dynamic analysis and the tools developed to detect malicious threats to user
devices.
It is clear from recent developments that Android’s permission model has been greatly
discussed regarding application security and improvements that can be made to make a more refined,
fine-grained and secure permission-based security system. The nature of Android’s permission model
means that application developers must understand how Android permissions work to produce least
privilege applications, however, the complexity of permissions and lack of documentation can
sometimes get misconstrued and confuse developers as to what an application requires to function
correctly and safely. Malicious applications purposely designed with permissions to access sensitive
areas of a user’s device are available on the marketplace, making it very difficult for a user to trust an
application, whether it is from an official source or not. Most users don’t understand how application
permissions interact with the rest of their device and personal data, making them afraid of accepting
every application and permission they come in contact with.
Recent developments in Android 6.0 Marshmallow, discussed in section 2.3.6, have also
identified unexplored changes to Android’s permission model which have greatly affected the methods
in which developers assign permissions to an application, how users interact with application
permissions and how an application interacts with the system.
An empirical study of Android’s permission model by categories of android applications has
been proposed. This project will identify permission trends and the security impact of combinations of
permissions. The research will be conducted to give users a more realistic idea of what an application
says it needs and what it actually has. Compared with similar applications in a set category, trends can
be identified to understand how different applications are designed and the threats they could present
to a user. Developments in Android update 6.0 will also affect the analysis, not previously mentioned
or researched, giving new data on how these changes affect the performance of applications in regards
to their permissions.
Page 44 of 137
The University of Derby
Department of Computing and Mathematics
Chapter 3
3. Methodology
3.1 Introduction
Previously discussed in Chapter 2 section 2.5, the proposed project is designed to analyse
Android’s permission model to identify trends in Android permissions, including levels of risk of
combinations of permissions in Android applications. Results provide an insight into how developers
are designing applications and whether these designs impact on the user’s mobile experience. A
selection of applications were chosen and arranged into sub-categories, designed to compare and
contrast the range of permissions in similar purpose applications. In order to achieve these goals, a
research methodology was chosen to sample, collect, filter and analyse the data. The following chapter
includes, section 3.2 covering the research methodology, section 3.3 sampling, section 3.4 data
collection, section 3.5 data filtering and section 3.6 data analysis.
3.2 Research Methodology
While various research methodologies provide a clear set of guidelines, including various
manual analysis and data mining techniques, this project required a different approach. Instead of
following a strict set of guidelines, this project followed the outline of a research methodology to
generate a set of research questions to be answered by different techniques of sampling, collection and
analysis, creating a new methodology designed purely for the scope of this project. For this reason
Empirical research is discussed in section 3.2.1, Experimental research is discussed in section 3.2.2
and the chosen methodology and the set of research questions is discussed and finalised in section
3.2.3.
3.2.1 Empirical Research
Empirical research is defined as the process of gaining knowledge by means of direct or
indirect observation from actual experiences rather than from theory or belief. Empirical evidence or
data is designed to record these direct observations or experiences which can then be analysed
quantitatively or qualitatively to draw conclusions based upon a set of research questions. Empirical
research is designed to help integrate research and practice, to understand and respond more
appropriately to the dynamics of a situation, as well as discuss contextual differences, which help
build upon research which is already known (Dönmez, 2015).
Page 45 of 137
The University of Derby
Department of Computing and Mathematics
The following steps are taken to produce an empirical research study:
1. Define specific research questions or hypotheses to be studied
2. Determine design study
3. Decide approach
4. Consider quality criteria (sampling)
5. Collect data
6. Analyse data
7. Interpret and conclude results regarding research questions (Dönmez, 2015)
Figure 3.1: Empirical Cycle (Explorable, 2016)
Figure 3.1 outlines the structure of empirical research, known as the Empirical Cycle including:
1. Observation – receiving knowledge of the outside world through senses or recording
information using scientific tools and instruments. Any data recorded during an experiment
can be called an observation
2. Induction – initial observation leads to the discovery of a pattern, in which predictions can be
made and a theory developed
3. Deduction – generates a testable hypothesis or research question and designs experiments to
observe the results to prove or disprove the theory developed
4. Testing – experiments designed to generate new empirical evidence in regards to the theory
5. Evaluation – Interpret and conclude the results to prove or disprove the theory
(Wieringa, 2014)
Observational studies which use empirical research are very beneficial in generating data sets
that cannot be produced in laboratory settings. Many researchers combine this form of research with
qualitative and quantitative forms of data analysis to compare data with existing theories and
assumptions, to answer questions in areas less affiliated with scientific disciplines (Dönmez, 2015).
Page 46 of 137
The University of Derby
Department of Computing and Mathematics
3.2.2 Experimental Research
Experimental research is defined as a planned interference in the natural order of events.
Rather than just observing a stream of events, experimental research relies on experiments to
manipulate or interfere with the conditions of an event, to generate new data capable of building upon
existing research derived from initial observations and theories. Compared to empirical research,
experimental research uses initial observations to go deeper into a theory with a more practical
approach, in the hope that direct manipulation can show trends and patterns simple observation cannot.
Researchers are not satisfied with simple descriptions of an observed event, by changing a selected
condition further observations and measurements can record the effects this change has on the stream
of events (Campbell et al, 1963).
The following steps are taken to produce an experimental research study:
1. Define specific research questions or hypotheses to be studied
2. Select or assign subjects to experimental units
3. Select or assign units for specific treatment or conditions (experimental manipulation)
4. Specify the order or arrangements of the treatments or conditions
5. Specify the sequence of observations or measurements to be taken (Campbell et al, 1963)
Experimental research uses a large amount of scientific factors and terminology to design and
implement experiments and one of the more critical factors of an experiment are called variables. A
variable refers to any factor considered in an experiment which can be changed or kept constant to
influence the results of a set of tests (Campbell et al, 1963). The following types of variables need
careful consideration when preparing an experimental research study:

Independent Variables – are variables manipulated by the researcher that may cause or
influence the outcome of a test or measurement to change

Dependent Variables – are variables which are not manipulated by the researcher but may be
influenced or modified by the changes of the independent variables when tested

Controlled Variables – are variables that the researcher wants to remain constant because they
are not being measured during the testing

Extraneous Variables – are variables external to the experiment which may influence or affect
the results of testing (Fisher, 1935)
Compared to empirical research studies, which acquire data through observation and analysis,
experimental research studies always involve some form of action, imposed control or intervention to
obtain data for subsequent analysis. Experimental research is consider scientific compared to most
research methodologies and will provide an in depth analysis on cause and reaction of set events.
Page 47 of 137
The University of Derby
Department of Computing and Mathematics
3.2.3 Project Methodology and Research Questions
Android’s permission model is a dynamic security feature of Android’s system architecture,
making it open to different methods of examination and analysis. A variation of methodologies could
be used to analyse Android’s permission model, however, due to the scope of this research an
empirical design was chosen over any other research methodology. An empirical research approach
allowed the observation of Android’s permission model, specifically how it was built into applications
and denoted by the marketplace and to generate a data set designed to build patterns and trends
between sub-categories of Android applications. While an experimental research approach can be
designed to analyse Android’s permission model, this is normally implemented in tests designed with
a hypothesis to investigate the cause and reaction of a specific experiment, commonly associated with
static and dynamic analysis tools. Due to the size of Android’s permission model and the components
involved, a simple hypothesis cannot be created, but a set of research questions have been designed, to
investigate:
1. Do similar designed sample applications (i.e. sub-category sets) share similar permission
design traits, based upon their features and purpose?
2. Is there any combination of dangerous permissions in the sampled applications that could
possibly make the user vulnerable to security and privacy risks?
3.3 Stage 1 – Sampling
A sample was taken from the Google Play Store, Android’s legitimate application
marketplace. The Google Play Store offers 29 unique categories of applications, however, the ‘Game’
category has a further 17 sub-categories and the ‘Family’ category has a further 10 categories (see
Appendix B). A census of Android applications is in the millions and completely out of the scope of
this research. It was important to take a sample of applications large enough to represent the scope of
the research, without being biased, based on a set of specific parameters.
The initial set of application categories in the Google Play Store were combined and reduced
to fit the research design. A sample was taken from every category. However, one of the research
questions was to understand if similar sub-category applications correlate, in regards to their
permission design and not all of the original categories would fit in to this specification. Figure 3.2
outlines the Google Play Store application categories which were sampled.
Page 48 of 137
The University of Derby
Department of Computing and Mathematics
Google Play Store Application Category
Comics
Communication
Education
Entertainment
Finance
Health & Fitness
Lifestyle
Media &Video
Medical
Music & Audio
News & Magazines
Personalisation
Photography
Productivity
Shopping
Social
Sports
Tools
Transport
Travel & Local
Weather
Games
(specifically the sub-category ‘Card’)
Family
(specifically the sub-category ‘Education’)
Figure 3.2: Google Play Store application category sample selection
A total of 23 categories of the Google Play Stores 29 were chosen for sampling. The 6
categories not included on the list were ‘Android Wear’, ‘Books & Reference’, ‘Business’, ‘Libraries
& Demos’, ‘Live Wallpaper’, and ‘Widgets’. These categories were removed because they were too
broad to cover a unique set of free applications, sharing similar design intentions. The ‘Game’ and
‘Family’ categories were also condensed down to 2 categories of ‘Card’ games and ‘Education’. These
categories were chosen as they shared very similar application designs. It would be very difficult to
Page 49 of 137
The University of Derby
Department of Computing and Mathematics
compare permission models of game applications, which provide very different services from one
application to another.
A sub-category was designed to compare and contrast the differences of permissions and
designs of similar roles of applications, for example the ‘Travel’ category was sampled by ‘Train line’
applications. This allowed a different form of analysis where applications designed to do the same role
are critically analysed against one another in a sub-set.
Google Play Store Application Category
Sub-category
Comics
Drawing
Communication
Instant Messaging
Education
Homework Planners
Entertainment
Streaming TV
Finance
Banking
Health & Fitness
Calorie Counters
Lifestyle
Cooking
Media &Video
Screen Recording
Medical
Pregnancy
Music & Audio
Music Players
News & Magazines
Newspapers
Personalisation
Keyboard Additions
Photography
Cameras
Productivity
Calendars
Shopping
Online Retailers
Social
Social Media
Sports
Betting
Tools
Alarms
Transport
Train lines
Travel & Local
GPS Navigation
Weather
Forecast
Games
Solitaire
(specifically the sub-category ‘Card’)
Family
Word Puzzles
(specifically the sub-category ‘Education’)
Figure 3.3: Sub-category sample selection
Page 50 of 137
The University of Derby
Department of Computing and Mathematics
To generate the data set required for analysis, 3 applications were chosen from the subcategory, specific to the areas outlined in figure 3.3. All of the sampled applications were free and
sampled depending on the sub-categories parameters i.e. ‘Travels’ Train line applications. The
applications chosen demonstrated a broad scope of the marketplace. Therefore, one application was
chosen because of its quality and popularity, while the second and third applications were randomly
chosen because of their lower levels of quality and popularity. This generated a range of quality
amongst the three chosen applications, providing a larger scope of analysis and comparison of similar
designed application permission datasets. A total of 69 applications were sampled from the Google
Play Store using the described set of parameters. The Google Play Store also provided the applications
details, including name, operating system version and permissions. This information was collected via
the Google Play Stores website and stored in a Microsoft Excel spreadsheet for analysis.
3.4 Stage 2 – Data Collection
A Samsung GT-I9100 Android 4.1.2 mobile device was used for the data collection. It was
reset to factory default settings to avoid interface from any other previous data present on the mobile
device. Once connected to a Wi-Fi internet connection the mobile was connected to the official
Google Play Store, using an official Google Play account to download Android applications. The
chosen sampled applications were downloaded directly on to the mobile device. The most important
element at this stage was the application’s APK file. Using an Android application called ‘Apk
Extractor’ the APK file was extracted directly from the application and stored in the mobile devices
SD media storage (Prasad, 2016).
To maintain data integrity across the course of this research every Android application APK
file required an MD5 hash value to be generated. Using an Android application called ‘MD5Checker’
a MD5 hash value was generated for each extracted APK file on the mobile device and stored
(Thalgott, 2014). Once transferred onto the computer hard-drive they were checked again using
‘WinMD5Free’ and compared with the original hash values (WinMD5Free, 2016). If any of the hash
values had changed then the data integrity had not been kept constant and the data was invalid. This
process was repeated with every sampled application when any APK file was prone to change,
whether on the mobile device or on the computer’s hard-drive.
Once all 69 applications had been installed, extracted and hashed, the mobile device was
connected to a computer to transfer all of the application APK files for analysis. Once stored on the
computer the APK files were decompiled in order to view the AndroidManifest.xml file and read the
permissions detailed within. Using the Windows command line interface and a tool called ‘ApkTool’
the APK file was decompiled into a readable file (Apktool, 2016). This provided an unzipped APK file
including the applications assets, Meta information, resources, classes and manifest file.
Page 51 of 137
The University of Derby
Department of Computing and Mathematics
Using the official Android Software Development Toolkit (SDK) the individual application
manifest files were opened and parsed using the ‘Android Asset Packaging Tool (Aapt)’. The
AndroidManifest.xml file was read and parsed to view the permissions detailed in the file, including
any third party permissions (Android SDK, 2016). This process was repeated for all 69 sampled
applications, while the permissions were categorized and stored in a Microsoft Excel spreadsheet for
analysis.
3.5 Stage 3 – Data Filtering
Once the 69 applications had been sampled, installed, extracted, and decompiled, the
information and data acquired in Stages 1 and 2 was stored and Microsoft Excel 2010 was used to
produce a spreadsheet of the preliminary findings. The spreadsheet contained three tabs for each
aspect of the data collection.
The first tab entitled ‘Initial Acquisition’ contained nine headings, including Application
Category, Application Sub-category, Application Name, Developer, Permission Count (Including
Third Party Permissions), Operating System Version, MD5 Hash Value Generated on Mobile Device,
MD5 Hash Value Generated on Computer, and MD5 Match. This tab summarised the overall sampled
applications including individual application details acquired from the Google Play Store and MD5
Hash values generated during data collection.
The second tab entitled ‘Application Permissions’ contained
six headings, including
Application Category, Application Sub-category, Application Name, Permissions outlined on Google
Play Store, Permissions from AndroidManifest.xml file and Permission Abbreviations. This tab
allowed the permissions outlined by the Google Play Store to be directly compared to the permissions
parsed and extracted from the sampled applications AndroidManifest.xml file. The parsed permissions
were then abbreviated for analysis discussion. The Android permission ‘uses-permission:
name='android.permission.INTERNET'’ was abbreviated to ‘INTERNET’. This was only done for
permissions native to Android. Any third-party applications discussed still had their complete
designation; ‘com.education.DooFree.permission.C2D_MESSAGE’ was not shortened to avoid
confusion when permissions from different third parties had the same identifier.
The final tab entitled ‘Permission Summary’ included two tables with three headings
including ‘Permission Number’, ‘Permission Abbreviation’ and ‘Permission Count’. This tab was used
to order the complete set of permissions acquired from the sample into alphabetical order and assigned
a numerical value. The sampled applications permissions were counted and stored accordingly, to give
an overview of the permissions statistics. The second table in this tab had the same headings, however,
it only included permissions, which had been called more than once across the complete dataset and
this was used when comparing sub-categories of applications.
Page 52 of 137
The University of Derby
Department of Computing and Mathematics
All recorded sampled permissions in the dataset were checked against Android’s official
permission list outlined in Appendix A. This identified any potential developer errors, including
spelling mistakes, as well as providing an overview of how permissions worked in a sampled
application,
regarding application features and purpose. Third party permissions were noted and
numerically counted, however, they were not included in any further analysis, other than permission
discussions, as third party permissions could not be compared to one another or Android’s official
permissions and would require more in depth analysis outside of this research.
The permissions were converted into a Common Separated Value (CSV) format, where data
was stored in plain text with each new line of the file referring to a data record, each data record
consisted of one or more fields separated by a field separator, commonly associated with a comma.
The CSV file was created using a pre-set save setting in Microsoft Excel 2010, converting a
spreadsheet populated with data into CSV format. The CSV format was used during analysis to make
the dataset easier to read and perform statistical analysis. To condense the dataset into a more
readable amount of data the sampled applications were referred to as ‘x’ where {x1, x2…….x?} was
denoted as application permissions. If the sampled applications called for a specific permission then it
was denoted with a ‘1’ and if it did not it was denoted with a ‘0’, similar to the method Barrera et al
(2010) used during their empirical analysis of Android’s permission model. More than one CSV file
was created so that the complete dataset could be analysed alongside the sub-category of application
permissions. The CSV file was written accordingly to include any information necessary for analysis,
including application category, application sub-category or application name.
3.6 Stage 4 – Data Analysis
IBM SPSS Statistics suite was used to analyse the specific statistics of the collected dataset
and the Microsoft Excel 2010 spreadsheets were used to observe the data collected, to compare and
contrast the dataset with previous work detailed in Chapter 2 Section 2.4.3. Assumptions were made
about Android’s permission model and whether the sampled applications satisfied the hypotheses and
research questions outlined in section 3.2.3. See Appendix C. Methodology Screenshots, regarding the
process by which the dataset was created, excluding photos of the mobile device and application
installations.
Page 53 of 137
The University of Derby
Department of Computing and Mathematics
Chapter 4
4. Findings and Analysis
4.1 Permission Overview and Statistics
Figure 4.1 provides an overview of the 23 sampled categories from the Google Play Store.
This includes the total number of permissions requested by the 3 sampled applications in a category,
the total number of unique permissions (including third party permissions) and the average amount of
permissions per application. Figure 4.2 continues to expand upon these results by outlining the total
permission count of all 78 unique permissions in the sampled application dataset.
Category
Total Permissions
Comic
Communication
Education
Entertainment
Family
Finance
Games
Health & Fitness
Lifestyle
Media & Video
Medical
Music & Audio
News & Magazines
Personalisation
Photography
Productivity
Shopping
Social
Sports
Tools
Transport
Travel & Local
Weather
29
144
28
29
13
40
13
53
38
32
46
42
56
58
49
54
46
91
31
37
41
73
35
Unique Permissions
(Including Third Party
Permissions)
18
86
20
20
6
24
6
37
24
17
32
29
33
30
34
33
30
67
23
18
30
45
27
Total Permissions
Total Unique Permission (Excluding Third Party Permissions)
Total Third Party Permissions
Total Requested Unique Permissions (Excluding Duplicates)
Figure 4.1: Sampled application permission overview
Page 54 of 137
Average
Permissions
9.6
48
9.3
9.6
4.3
1.6
4.3
17.6
12.6
10.6
15.3
14
18.6
19.3
16.3
18
15.3
30.3
10.3
12.33
13.6
24.3
11.6
1079
78
215
840
The University of Derby
Department of Computing and Mathematics
Figure
4.2:
Unique
permission
frequency
Page 55 of 137
The University of Derby
Department of Computing and Mathematics
A total of 1079 permissions were requested and recorded from the 69 sampled applications.
The total amount of permissions requested were condensed to 78 unique permissions (i.e. if 5 different
applications requested access to the permission ‘INTERNET’, it is only counted once). 215 third party
permissions were also derived from the 1079 requested permissions. The average number of
permissions requested by applications in each category was calculated for comparison. The
‘Communication’ category is by far the most diverse, with 144 permissions requested and an average
of 48 permissions per application. The least diverse categories were ‘Family’ and ‘Games’ with a
total of 13 permissions requested in each category and with the lowest average of 4.3 permissions per
application.
Permission
Permission Frequency
ACCESS_NETWORK_STATE
71 (102.8%)
INTERNET
69 (100%)
WRITE_EXTERNAL_STORAGE
55 (79.7%)
WAKE_LOCK
47 (68.1%)
GET_ACCOUNTS
42 (60.8%)
Figure 4.3: Top 5 requested unique permissions
Figure 4.3 outlines the top 5 most requested unique permissions (See Appendix D for a
breakdown of the complete dataset). The ACCESS_NETWORK_STATE permission was requested
by 71 applications (102.8% of all applications), however, the initial dataset only contained 69
applications, meaning the ACCESS_NETWORK_STATE was called more than once per application.
The applications ‘WeChat’, ‘ABC News Breaking Latest News’, ‘Lollipop Emoji Keyboard’ and
‘Train time, travel & tickets’ called this permission twice. This is a developer error, since adding the
permission more than once does not have any added benefit to the application and is likely due to
limitations of the IDE or the different ways in which Android maps system calls to permissions. In this
case the permission ACCESS_NETWORK_STATE should have only been called in 67 of the
applications (97.1% of all applications) and is misrepresented in the initial permission count. The
permissions
ACCESS_COARSE_LOCATION
(called
twice
in
one
application),
ACCESS_WIFI_STATE (called twice in one application), CAMERA (called three times in one
application), GET_ACCOUNTS (called three times in one application and twice in another
application), INTERNET (called twice in two applications), NFC (called three times in one
application),
RECEIVE_BOOT_COMPLETED
(called
twice
in
one
application)
and
WRITE_EXTERNAL_STORAGE (called twice in two applications) were also called more than once
in the sampled applications and misrepresent the initial permission count, however, they show a clear
representation of developer error and misuse of permissions.
Page 56 of 137
The University of Derby
Department of Computing and Mathematics
A further six of the unique 78 permissions were found to be obsolete or written incorrectly.
The
permissions
ACCESS_SUPERUSER,
GET_TASKS,
RESTART_PACKAGES
and
RAISED_THREAD_PRIORITY (both called once) are permissions no longer used in Android’s
current version. ACCESS_SUPERUSER was previously used to root and gain control of a device,
while the RAISED_THREAD_PRIORITY was used in audio playbacks. The permission STORAGE
(called once) was assumed to be written incorrectly, as it is not an official Android permission and was
not written as a third party permission. It can be assumed the developer confused this with either
READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE; the two Android permissions
related to storage control of an Android device. The fourth permission, WRITE_APP_BADGE, is also
not an official Android permission and only appears in one application. Further research into this
permission indicated no clear description of how it functions within an application.
The lowest frequencies of permissions were permissions only called once or twice. A total of
20 unique permissions were only called once and 12 were called twice across the sampled
applications, almost half of the unique permissions (40.5% of all unique permissions).
Out of the initial 1079 permissions called, 215 were third party permissions. Third party
permissions were noted and numerically counted, however, they were not included in any further
analysis, as third party permissions cannot be directly compared to one another or Android’s official
permissions and would require more in depth analysis outside of this projects scope. A total of 42
applications (60.8% of total applications) in the sampled dataset had third party permissions. Figure
4.4 provides a complete overview of the datasets statistics, between the total permissions called, total
third party permissions and the total unique permissions called.
100%
90%
80%
70%
60%
50%
100%
40%
80.08%
30%
20%
10%
19.92%
0%
Total Permissions
Third Party Permissions
Unique Permissions
Figure 4.4: Dataset statistic overview
Page 57 of 137
The University of Derby
Department of Computing and Mathematics
4.2 Sub-category Application Permission Analysis
Figure 4.5 analyses the sampled application permissions further than the previously outlined
permission overview in section 4.1. Rather than analysing the frequency of each unique permission,
each sub-category, consisting of three applications, was analysed against one another to outline which
permissions were shared between all three applications, which were shared between two of the three
applications and which were only present in one of the three applications. This was repeated with all
three applications in each of the 23 sub-categories.
Category
Sub-category
Permissions
not shared
Comic
Communication
Education
Entertainment
Family
Finance
Games
Health & Fitness
Lifestyle
Media & Video
Medical
Music & Audio
News & Magazines
Personalisation
Photography
Productivity
Shopping
Social
Sports
Tools
Transport
Travel & Local
Weather
Drawing
Instant Messaging
Homework Planner
Streaming TV
Word Puzzles
Banking
Solitaire
Calorie Counters
Cooking
Screen Recording
Pregnancy
Music Players
Newspapers
Keyboard Additions
Cameras
Calendars
Online Retailers
Social Media
Betting
Alarms
Train lines
GPS Navigation
Forecast
8
15
9
8
2
7
1
15
11
4
13
11
8
11
19
5
5
18
9
6
9
17
14
Permissions
shared between
2 applications
3
12
7
5
1
2
3
8
3
6
7
5
5
10
9
9
6
10
4
7
3
10
2
Permissions
shared between
3 applications
4
19
0
2
3
7
2
4
5
4
3
4
7
7
3
6
5
7
2
5
4
9
3
Figure 4.5: Frequency of permissions between sub-category applications
47.8% of the 23 sub-categories show clear differences in permissions not shared between the
three applications and the permissions that are shared. These categories are ‘Education’ (difference of
9), ‘Entertainment’ (difference of 6), ‘Health & Fitness’ (difference of 11), ‘Lifestyle’ (difference of
6), ‘Medical’ (difference of 10), ‘Music & Audio’ (difference of 7), ‘Photography’ (difference of 16),
‘Social’ (difference of 11), ‘Sports’ (difference of 7), ‘Travel & Local’ (difference of 8) and ‘Weather’
(difference of 11). While the permissions that are shared between only two of the three applications
are still relevant, the analysis of the permissions not shared between the three applications can reveal
more about similarly designed sub-categories of applications, identifying potential flaws in application
development and permission management.
Page 58 of 137
The University of Derby
Department of Computing and Mathematics
Page 59 of 137
The University of Derby
Department of Computing and Mathematics
Figure 4.6: Distribution of permissions between application sub-categories
Page 60 of 137
The University of Derby
Department of Computing and Mathematics
Figure 4.6 expands upon the overview provided in figure 4.5 by outlining the frequency of
each of the 74 unique permissions, per sub-category, by the amount they are shared between
individual applications; whether the permissions are not shared between all three applications, shared
between two of the three applications or shared between all three applications. This graphical display
identifies the high frequency permissions not shared with all three applications. The five not shared
permissions are BILLING (not shared in 11 sub-categories), READ_EXTERNAL_STORAGE (not
shared in 11 sub-categories), READ_PHONE_STATE (not shared in 7 sub-categories),
READ_SYNC_SETTINGS (not shared in 8 sub-categories) and USE_CREDENTIALS (not shared in
9 sub-categories).
The most frequently shared permissions amongst all three sub-category
applications are ACCESS_NETWORK STATE (shared in 21 sub-categories), INTERNET (shared in
21 sub-categories) and WRITE_EXTERNAL STORAGE (shared in 12 sub-categories), which are the
top three most frequent permissions in the sampled applications. While the graph shows a high trend
in permissions not shared between three applications, only a total of 223 permissions were requested
(26.5% of the 840 unique permission calls), 272 permissions were requested which were shared
between two of the three applications (32.3% of the 840 unique permission calls) and 345 permissions
were requested which were shared between all three applications of a sub-category (41.2% of the 840
unique permission calls). This shows that while there are singular application permissions the majority
of sub-categories are designed with shared permissions.
Thousands of applications are being developed daily and released into the Google Play
marketplace in an attempt to provide the user with a unique service, which competes with other similar
designed applications. It is extremely challenging to judge exactly what permissions an application
should have and what it should not, without understanding how the sampled applications work on a
user’s device. The permissions not shared between the three sub-category applications have been
divided and detailed against the appropriate sub-category application. These permissions were
analysed against one another based upon the overall sub-categories purpose. Figures 4.7 through to
4.29 details the differences in each sub-category.
Category
Comic
Sub-Category
Drawing
Application
Permissions Not Shared
Draw Cartoons 2
BILLING
RECORD_AUDIO
USE_CREDENTIALS
Learn to Draw Anime Manga
GET_TASKS
RECEIVE_BOOT_COMPLETED
SYSTEM_ALERT_WINDOW
How to Draw 3D and Illusions
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
Figure 4.7: ‘Comic’ permissions not shared
Page 61 of 137
The University of Derby
Department of Computing and Mathematics
Figure 4.7 outlines the permissions not shared within the ‘Drawing’ sub-category. The
purpose of the ‘Drawing’ sub-category applications is to teach users how to draw. The permission
GET_TASKS was recently deprecated in Android’s API level 21 and is no longer enforced as a
known permission and is deemed irrelevant in this analysis. The permissions USE_CREDENTIALS
and BILLING are justified functionality to this sub-category, which allows an application to use
known user details to sign in and provide a method of buying additional functionality for an
application
(free/premium
RECORD_AUDIO,
accounts).
The
permissions
SYSTEM_ALERT_WINDOW,
RECEIVE_BOOT_COMPLETED,
ACCESS_COARSE_LOCATION
and
ACCESS_FINE_LOCATION, provide additional application functionality; such as finding the users
location, recording their audio and automatically loading the application upon the devices boot
sequence. These permissions are deemed unnecessary to this sub-categories purpose.
Category
Communication
Sub-Category
Application
Permissions Not Shared
Skype
CALL_PHONE
DISABLE_KEYGUARD
GET_TASKS
READ_SYNC_STATS
WeChat
BILLING
BLUETOOTH_ADMIN
BODY_SENSORS
DOWNLOAD_WITHOUT_NOTIFICATION
GET_PACKAGE_SIZE
INSTALL_SHORTCUT
NFC
READ_SETTINGS
SET_ALARM
UNINSTALL_SHORTCUT
WRITE_APP_BADGE
Instant Messaging
Telegram
Figure 4.8: ‘Communication’ permissions not shared
Figure 4.8 outlines the permissions not shared within the ‘Instant Messaging’ sub-category.
The purpose of the ‘Instant Messaging’ sub-category applications is to allow a method of instant
communication via a messaging system. The permission GET_TASKS was recently deprecated in
Android’s API level 21 and is no longer enforced as a known permission and WRITE_APP_BADGE
is an unknown erroneous permission and can be deemed irrelevant in this analysis. The permissions
BILLING, CALL_PHONE, DISABLE_KEYGUARD, and NFC have justified functionality to this
sub-category, which can allow an application to buy additional functionality (free/premium accounts),
call phone numbers from the user’s device and function beyond a user’s locked device unless a
passcode has been assigned. READ_SYNC_STATS, BLUETOOTH_ADMIN, BODY_SENSORS,
DOWNLOAD_WITHOUT_NOTIFICATION,
GET_PACKAGE_SIZE,
INSTALL_SHORTCUT,
READ_SETTINGS, SET_ALARM, and UNINSTALL_SHORTCUT provide additional application
functionality, such as finding and connecting to Bluetooth devices without user consent, download
Page 62 of 137
The University of Derby
Department of Computing and Mathematics
updates or applications without user consent and read potentially private user information. These
permissions are deemed unnecessary to this sub-categories purpose.
Category
Sub-Category
Application
Permissions Not Shared
Homework Planner
Show My Homework
Education
Homework Planner
myHomework Student Planner
AUTHENTICATE_ACCOUNTS
MANAGE_ACCOUNTS
READ_SYNC_SETTINGS
WRITE_SYNC_SETTINGS
ACCESS_COARSE_LOCATION
ACCESS_WIFI_STATE
BILLING
READ_EXTERNAL_STORAGE
READ_PHONE_STATE
Figure 4.9: ‘Education’ permissions not shared
Figure 4.9 outlines the permissions not shared within the ‘Homework Planner’ sub-category.
The purpose of the ‘Homework Planner’ sub-category applications is to provide a method of
organising homework, including a homework calendar, class schedules and timetables. The
permissions
AUTHENTICATE_ACCOUNTS,
MANAGE_ACCOUNTS,
BILLING
and
READ_EXTERNAL_STORAGE are justified functionality to this sub-category, which can allow an
application to manage and authenticate different application accounts and settings, while providing a
method of buying additional functionality for an application (free/premium accounts). The permissions
READ_SYNC_SETTINGS,
WRITE_SYNC_SETTINGS,
ACCESS_COARSE_LOCATION,
ACCESS_WIFI_STATE and READ_PHONE_STATE provide additional functionality, such as
finding a user’s approximate location and access to areas of sensitive user and application information.
These permissions are deemed unnecessary to this sub-categories purpose.
Category
Sub-Category
Application
Permissions Not Shared
BBC iPlayer
Entertainment
Streaming TV
DISH Anywhere
BROADCAST_STICKY
CHANGE_WIFI_MULTICAST_STATE
CLEAR_APP_CACHE
GET_TASKS
READ_LOGS
RAISED_THREAD_PRIORITY
RESTART_PACKAGES
My5
USE_CREDENTIALS
Figure 4.10: ‘Entertainment’ permissions not shared
Figure 4.10 outlines the permissions not shared within the ‘Streaming TV’ sub-category. The
purpose of the ‘Streaming TV’ sub-category applications is to provide a method of streaming TV
shows on a user’s mobile device. The permissions GET_TASKS, RAISED_THREAD_PRIORITY
and RESTART_PACKAGES were recently deprecated in Android’s API level 21 and are no longer
Page 63 of 137
The University of Derby
Department of Computing and Mathematics
enforced as known permissions and can be deemed irrelevant in this analysis. The permissions
BROADCAST_STICKY, CHANGE_WIFI_MULTICAST_STATE and USE_CREDENTIALS are
justified functionality to this sub-category, which can allow an application to broadcast gathered data
and information as an intent, along with using known stored user details to sign in to an application.
The permissions CLEAR_APP_CACHE and READ_LOGS provide additional functionality, such as
clearing the caches of all stored applications and being able to read the devices system log files. These
permissions are deemed unnecessary to this sub-categories purpose.
Category
Sub-Category
Application
Permissions Not Shared
LetterSchool Free – Write ABC
Family
MODIFY_AUDIO_SETTINGS
READ_EXTERNAL_STORAGE
Word Puzzles
ABC Learning Letters for Toddlers
ABC Flash Cars for Kids Game
Figure 4.11: ‘Family’ permissions not shared
Figure 4.11 outlines the permissions not shared within the ‘Word Puzzles’ sub-category. The
purpose of the ‘Word Puzzles’ sub-category applications is to provide a method of learning letters for
children. ‘LetterSchool Free – Write ABC’ is the only application in this category which has
additional permissions compared to its counterparts. MODIFY_AUDIO_SETTINGS allows the
application to change audio settings while the application is running. This permission can be justified
in this sub-category as the applications may have music or sounds alternating in volume, which may
need adjusting according to the user preference. The permission READ_EXTERNAL_STORAGE,
however, allows the application to view the contents of the user’s USB and can provide unnecessary
functionality for this application sub-category, unless the application needs to save a user’s progress.
Category
Sub-Category
Application
PayPal
Finance
Banking
Permissions Not Shared
AUTHENTICATE_ACCOUNTS
CAMERA
CHANGE_CONFIGURATION
READ_PROFILE
RECEIVE_BOOT_COMPLETED
VIBRATE
WAKE_LOCK
NatWest
Yorkshire Bank Mobile Banking
Figure 4.12: ‘Finance’ permissions not shared
Figure 4.12 outlines the permissions not shared within the ‘Banking’ sub-category. The
purpose of the ‘Banking’ sub-category applications is to provide a method of banking, including
Page 64 of 137
The University of Derby
Department of Computing and Mathematics
money management, transfers and accounts. ‘PayPal’ is the only application with additional
permissions. The permissions AUTHENTICATE_ACCOUNTS and READ_PROFILE are justified
functionality to this sub-category which can allow an application to authenticate the accounts used
when accessing ‘PayPal’ and is useful when multiple accounts access the application. The permissions
CAMERA, CHANGE_CONFIGURATION, RECEIVE_BOOT_COMPLETED, VIBRATE and
WAKE_LOCK provide additional functionality, such as gaining access to the devices camera, change
device configurations, vibrate the device and prevent the screen from going to sleep or dimming.
These permissions are deemed unnecessary to this sub-categories purpose.
Category
Sub-Category
Application
Permissions Not Shared
Solitaire
Games
Solitaire
Solitaire Classic
Spider Solitaire
VIBRATE
Figure 4.13: ‘Games’ permissions not shared
Figure 4.13 outlines the permissions not shared within the ‘Solitaire’ sub-category. The
purpose of the ‘Solitaire’ sub-category applications is to provide users with a card game. ‘Spider
Solitaire’ is the only application with one additional permission, VIBRATE. This permission provides
the functionality of vibrating a user’s device. This permission provides unnecessary functionality for a
user playing a card game, unless the application wants to use the vibrate function to indicate certain
features to the user during gameplay.
Category
Sub-Category
Application
Permissions Not Shared
FatSecret
ACCESS_WIFI_STATE
MyFitnessPal
Health & Fitness
Calorie Counters
Google Fit
ACCESS_COARSE_LOCATION
BILLING
MANAGE_DOCUMENTS
READ_EXTERNAL_STORAGE
AUTHENTICATE_ACCOUNTS
MANAGE_ACCOUNTS
MODIFY_AUDIO_SETTINGS
READ_SYNC_SETTINGS
READ_SYNC_STATS
WRITE_SYNC_SETTINGS
Figure 4.14: ‘Health & Fitness’ permissions not shared
Figure 4.14 outlines the permissions not shared within the ‘Calorie Counters’ sub-category.
The purpose of the ‘Calorie Counters’ sub-category applications is to provide a method for users to
monitor
their
calorie
intake.
AUTHENTICATE_ACCOUNTS,
The
permissions
ACCESS_WIFI_STATE,
MANAGE_ACCOUNTS,
BILLING,
MODIFY_AUDIO_SETTINGS,
READ_SYNC_SETTINGS, READ_SYNC_STATS and WRITE_SYNC_SETTINGS are justified
Page 65 of 137
The University of Derby
Department of Computing and Mathematics
functionality in this sub-category, which can allow an application to connect to a Wi-Fi connection,
provide a method of buying additional functionality for an application (free/premium accounts),
authenticate and manage the accounts used with an application, have the capability to change audio
settings and manage how application data is stored, written and synced to a user’s device. The
permissions
ACCESS_COARSE_LOCATION,
MANAGE_DOCUMENTS,
and
READ_EXTERNAL_STORAGE provide additional functionality, such as approximating a user’s
location and reading, moving and deleting user documents. These permissions are deemed
unnecessary to this application sub-categories purpose.
Category
Sub-Category
Application
Permissions Not Shared
All Recipes Free
ACCESS_WIFI_STATE
CookPad
ACCESS_COARSE_LOCATION
BILLING
MANAGE_DOCUMENTS
READ_EXTERNAL_STORAGE
Food Network In the Kitchen
AUTHENTICATE_ACCOUNTS
MANAGE_ACCOUNTS
MODIFY_AUDIO_SETTINGS
READ_SYNC_SETTINGS
READ_SYNC_STATS
WRITE_SYNC_STATS
Cooking
Lifestyle
Figure 4.15: ‘Lifestyle’ permissions not shared
Figure 4.15 outlines the permissions not shared within the ‘Cooking’ sub-category. The
purpose of the ‘Cooking’ sub-category applications is to provide of cooking aids, including recipes
and
culinary
guides.
The
permissions
ACCESS_WIFI_STATE,
BILLING,
AUTHENTICATE_ACCOUNTS, MANAGE_ACCOUNTS and MODIFY_AUDIO_SETTINGS are
justified functionality to this sub-category, which can allow an application to connect to a Wi-Fi
connection, provide a method of buying additional functionality for an application (free/premium
accounts), authenticate and manage the accounts used with an application and modify audio settings.
The
permissions
ACCESS_COARSE_LOCATION,
READ_EXTERNAL_STORAGE,
READ_SYNC_SETTINGS,
MANAGE_DOCUMENTS,
READ_SYNC_STATS
and
WRITE_SYNC_STATS provide additional functionality such as approximating a user’s location,
reading, moving and deleting user documents and affecting the way data is written and synced with an
application. These permissions are deemed unnecessary to this applications sub-categories purpose.
Page 66 of 137
The University of Derby
Category
Department of Computing and Mathematics
Sub-Category
Application
Permissions Not Shared
GET_ACCOUNTS
Screen Recorder
Media & Video
Screen Recording
STORAGE
Spy Video Recorder
INSTALL_SHORTCUT
VIBRATE
SCR Free
Figure 4.16: ‘Media & Video’ permissions not shared
Figure 4.16 outlines the permissions not shared within the ‘Screen Recording’ sub-category.
The purpose of the ‘Screen Recording’ sub-category applications is to provide a method of capturing
and recording a user’s device screen activity. The STORAGE permission was identified as an
erroneous permission and will not be considered in this analysis. The remaining permissions
GET_ACCOUNTS, INSTALL_SHORTCUT and VIBRATE provide additional functionality, such as
accessing the list of device accounts, installing an application shortcut and vibrating the user’s device,
however, these are deemed unnecessary to this application sub-categories purpose.
Category
Sub-Category
Application
Permissions Not Shared
ACCESS_COARSE_LOCATION
BILLING
CALL_PHONE
CAMERA
CHECK_LICENSE
CLEAR_APP_CACHE
READ_CALENDAR
READ_CONTACTS
SEND_SMS
SET_DEBUG_APP
WRITE_CALENDAR
Pregnancy +
Medical
Pregnancy
Pregnancy Calculator
Ovia Pregnancy Tracker
ACCESS_FINE_LOCATION
AUTHENTICATE_ACCOUNTS
Figure 4.17: ‘Medical’ permissions not shared
Figure 4.17 outlines the permissions not shared within the ‘Pregnancy’ sub-category. The
purpose of the ‘Pregnancy’ sub-category applications is to provide a method of monitoring the course
of a user’s pregnancy. The permissions BILLING, CHECK_LICENSE, READ_CALENDAR,
READ_CONTACTS, WRITE_CALENDAR and AUTHENTICATE_ACCOUNTS are justified
functionality to this sub-category, which can allow an application to provide a method of buying
additional functionality for an application (free/premium accounts), check that the application is
licensed, read and write the devices calendar and read a user’s contacts list. The permissions
ACCESS_COARSE_LOCATION,
CALL_PHONE,
Page 67 of 137
CAMERA,
CLEAR_APP_CACHE,
The University of Derby
Department of Computing and Mathematics
SEND_SMS, SET_DEBUG_APP and ACCESS_FINE_LOCATION provide additional functionality,
such as finding the user’s location, calling any phone number, accessing the devices camera, sending
SMS and clearing all application cache data. These permissions are deemed unnecessary to this
application sub-categories purpose.
Category
Sub-Category
Application
Spotify
Media & Audio
Music Players
Permissions Not Shared
BILLING
BLUETOOTH
BLUETOOTH_ADMIN
BROADCAST_STICKY
MODIFY_AUDIO
NFC
READ_PHONE_STATE
Music Free
SoundCloud
AUTHENTICATE_ACCOUNTS
READ_SYNC_SETTINGS
RECORD_AUDIO
WRITE_SYNC_SETTINGS
Figure 4.18: ‘Media & Audio’ permissions not shared
Figure 4.18 outlines the permissions not shared within the ‘Music Players’ sub-category. The
purpose of the ‘Music Players’ sub-category applications is to provide a method for users to stream
and listen to music. The majority of permissions in this sub-category are ideal for the applications
purpose and are probably not shared due to different application designs. The permissions BILLING,
BROAD_STICKY,
MODIFY_AUDIO,
AUTHENTICATE_ACCOUNTS,
NFC,
READ_SYNC_SETTINGS,
READ_PHONE_STATE,
RECORD_AUDIO
and
WRITE_SYNC_SETTINGS provide functionality, including a method of buying additional
functionality for an application (free/premium accounts), broadcast gathered data and information as
an intent, authenticate the accounts used with an application, record audio and modify audio settings.
The permissions BLUETOOTH and BLUETOOTH_ADMIN provide additional functionality, such as
being able to find and connect to Bluetooth devices without user consent, however, these permissions
are deemed unnecessary to this sub-categories purpose.
Page 68 of 137
The University of Derby
Category
Department of Computing and Mathematics
Sub-Category
Application
Permissions Not Shared
BBC News
News & Magazines
Newspapers
ACCESS_WIFI_STATE
BROADCAST_STICKY
GET_TASKS
MANAGE_ACCOUNTS
READ_EXTERNAL_STORAGE
READ_PHONE_STATE
RECEIVE_BOOT_COMPLETED
WRITE_EXTERNAL_STORAGE
ABC News
Google News & Weather
Figure 4.19: ‘News & Magazines’ permissions not shared
Figure 4.19 outlines the permissions not shared within the ‘Newspapers’ sub-category. The
purpose of the ‘Newspapers’ sub-category applications is to provide a method for user’s to receive
daily information whether locally or globally. ‘ABC News’ is the only application in this sub-category
which has additional permissions compared to its counterparts. The permission GET_TASKS was
recently deprecated in Android’s API level 21 and is no longer enforced as a known permission and
can be deemed irrelevant in this analysis. The permissions ACESS_WIFI_STATE and
BROADCAST_STICKY provide justified functionality that allows the application to connect to a WiFi connection and broadcast gathered data and information as an intent. The permissions
MANAGE_ACCOUNTS,
READ_EXTERNAL_STORAGE,
RECEIVE_BOOT_COMPLETED
and
READ_PHONE_STATE,
WRITE_EXTERNAL_STORAGE
provide
additional
functionality such as managing the accounts on a user’s device, being able to read and write external
storage and automatically load the application upon the devices boot sequence. These permissions are
deemed unnecessary to this sub-categories purpose.
Category
Personalisation
Sub-Category
Application
Permissions Not Shared
Emoji Keyboard Lite Kika Free
MOUNT_UNMOUNT_FILESYSTEMS
PACKAGE_USAGE_STATS
SYSTEM_ALERT_WINDOW
Lollipop Emoji Keyboard
BILLING
GLOBAL_SEARCH
READ_HISTORY_BOOKMARKS
READ_LOGS
READ_SMS
RECORD_AUDIO
WRITE_SETTINGS
Keyboard Additions
Emoji Keyboard 6
Figure 4.20: ‘Personalisation’ permissions not shared
Page 69 of 137
The University of Derby
Department of Computing and Mathematics
Figure 4.20 outlines the permissions not shared within the ‘Keyboard Additions’ sub-category.
The purpose of the ‘Keyboard Additions’ sub-category applications is to provide additional
functionality to a user’s device keyboard. The permission BILLING provides justified functionality
that provides a method of buying additional functionality for an application (free/premium accounts).
The
permissions
MOUNT_UNMOUNT_FILESYSTEMS,
SYSTEM_ALERT_WINDOW,
GLOBAL_SEARCH,
PACKAGE_USAGE_STATS,
READ_HISTORY_BOOKMARKS,
READ_LOGS, READ_SMS, RECORD_AUDIO and WRITE_SETTINGS provide additional
functionality, such as being able to mount and unmount device file systems, monitor package
statistics, read a user’s history, read SMS messages, record audio and change device settings. These
permissions are deemed unnecessary to this sub-categories purpose.
Category
Sub-Category
Application
Camera for Android
Cameras
Photography
Permissions Not Shared
BIND_WALLPAPER
CHANGE_WIFI_STATE
MANAGE_ACCOUNTS
NFC
READ_SYNC_SETTINGS
SET_WALLPAPER
SUBSCRIBED_FEEDS_READ
SUBSCRIBED_FEEDS_WRITE
USE_CREDENTIALS
VIBRATE
WRITE_SETTINGS
WRITE_SYNC_SETTINGS
BLUETOOTH
BLUETOOTH_ADMIN
BLUETOOTH_PRIVILEGED
READ_EXTERNAL_STORAGE
READ_PHONE_STATE
READ_PROFILE
SYSTEM_ALERT_WINDOW
Retrica
Open Camera
Figure 4.21: ‘Photography’ permissions not shared
Figure 4.21 outlines the permissions not shared within the ‘Cameras’ sub-category. The
purpose of the ‘Cameras’ sub-category applications is to provide additional functionalities to a user’s
device
camera.
The
permissions
BIND_WALLPAPER,
SET_WALLPAPER
and
READ_EXTERNAL_STORAGE provides justified functionality that can allow an application to read
the devices external storage and be able to bind and set a wallpaper to the devices home screen. The
permissions CHANGE_WIFI_STATE, MANAGE_ACCOUNTS, NFC, READ_SYNC_SETTINGS,
SUBCRIBED_FEEDS_READ, SUBSCRIBED_FEEDS_WRITE, USE_CREDENTIALS, VIBRATE,
WRITE_SETTINGS,
WRITE_SYNC_SETTINGS,
BLUETOOTH_PRIVILEGED,
BLUETOOTH,
READ_PHONE_STATE,
BLUETOOTH_ADMIN,
READ_PROFILE
and
SYSTEM_ALERT_WINDOW are a large range of permissions which give far too much unnecessary
Page 70 of 137
The University of Derby
Department of Computing and Mathematics
access to device and user information and functionality outside of the confines of a pure ‘Camera’
based application. These permissions are deemed unnecessary to this sub-categories purpose.
Category
Sub-Category
Calendars
Productivity
Application
Permissions Not Shared
Sunrise Calendar
ACCESS_FINE_LOCATION
AUTHENTICATE_ACCOUNTS
Google Calendar
ACCESS_COARSE_LOCATION
SUBSCRIBED_FEEDS_READ
SUBSCRIBED_FEEDS_WRITE
Calendar
Figure 4.22: ‘Productivity’ permissions not shared
Figure 4.22 outlines the permissions not shared within the ‘Calendars’ sub-category. The
purpose of the ‘Calendars’ sub-category applications are to provide a user’s device with calendar
functionalities, including storing appointments against times and dates. The permission
AUTHENTICATE_ACCOUNTS is a justified functionality that will allow each account to be
authenticated
against
the
accounts
individual
calendar.
The
permissions
ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, SUBCRIBED_FEEDS_READ and
SUBSCRIBED_FEEDS_WRITE provide additional functionality, such as finding the user’s location
and allowing the application to read and write to the subscribed feed contents provider. These
permissions are deemed unnecessary to this sub-categories purpose.
Category
Sub-Category
Application
Permissions Not Shared
eBay
TopShop
ACCESS_WIFI_STATE
READ_LOGS
Etsy
GET_TASKS
READ_EXTERNAL_STORAGE
USE_CREDENTIALS
Online Retailers
Shopping
Figure 4.23: ‘Shopping’ permissions not shared
Figure 4.23 outlines the permissions not shared within the ‘Online Retailers’ sub-category.
The purpose of the ‘Online Retailers’ sub-category applications is to provide users with a method of
purchasing items online. The permission GET_TASKS was recently deprecated in Android’s API
level 21 and is no longer enforced as a known permission and can be deemed irrelevant in this
analysis. The permissions ACCESS_WIFI_STATE and USE_CREDENTIALS are justified
permissions that can allow an application to connect to a Wi-Fi connection and use known stored user
details
to
sign
in
to
an
application.
The
permissions
READ_LOGS
and
READ_EXTERNAL_STORAGE provide additional functionality that can allow an application to
Page 71 of 137
The University of Derby
Department of Computing and Mathematics
read system log files and the user’s external storage. However, these permissions are deemed
unnecessary to this sub-categories purpose.
Category
Social
Sub-Category
Social Media
Application
Permissions Not Shared
Pinterest
USE_CREDENTIALS
Facebook
ACCESS_COARSE_LOCATION
ACCESS_WIFI_STATE
BATTERY_STATS
BROADCAST_STICKY
CHANGE_NETWORK_STATE
CHANGE_WIFI_STATE
DOWNLOAD_WITHOUT_NOTIFICATION
GET_TASKS
INSTALL_SHORTCUT
READ_EXTERNAL_STORAGE
READ_PHONE_STATE
READ_SMS
RECORD_AUDIO
SYSTEM_ALERT_WINDOW
WRITE_CALENDAR
LinkedIn
READ_SYNC_STATS
Figure 4.24: ‘Social’ permissions not shared
Figure 4.24 outlines the permissions not shared within the ‘Social Media’ sub-category. The
purpose of the ‘Social Media’ sub-category applications is to provide a method for users to have a hub
for virtual socialising with friends, family and acquaintances. The permission GET_TASKS was
recently deprecated in Android’s API level 21 and is no longer enforced as a known permission and
can
be
deemed
irrelevant
ACCESS_WIFI_STATE,
in
this
analysis.
The
BROADCAST_STICKY,
permissions
USE_CREDENTIALS,
READ_EXTERNAL_STORAGE
and
WRITE_CALENDAR are justified permissions that can allow an application to use known stored user
details to sign in to an application, connect to a Wi-Fi connection and broadcast gathered data and
information as an intent. The permissions ACCESS_COARSE_LOCATION, BATTERY_STATS,
CHANGE_NETWORK_STATE,
INSTALL_SHORTCUT,
DOWNLOAD_WITHOUT_NOTIFICATION,
CHANGE_WIFI_STATE,
READ_PHONE_STATE,
READ_SMS,
RECORD_AUDIO, SYSTEM_ALERT_WINDOW and READ_SYNC_STATS are a large range of
permissions which give far too much unnecessary access to device and user information and
functionality outside of the confines of a pure ‘Social Media’ based application. These permissions are
deemed unnecessary to this sub-categories purpose.
Page 72 of 137
The University of Derby
Department of Computing and Mathematics
Category
Sub-Category
Application
Permissions Not Shared
Bet365 News
Tipster 365
Betting
Sports
Betting Tips
ACCESS_FINE_LOCATION
INSTALL_SHORTCUT
READ_EXTERNAL_STORAGE
READ_HISTORY_BOOKMARKS
SYSTEM_ALERT_WINDOW
UNINSTALL_SHORTCUT
USE_CREDENTIALS
WRITE_EXTERNAL_STORAGE
WRITE_HISTORY_BOOKMARKS
Figure 4.25: ‘Sports’ permissions not shared
Figure 4.25 outlines the permissions not shared within the ‘Betting’ sub-category. The purpose
of the ‘Betting’ sub-category applications are to provide a method of betting and tips for sport, directly
from the user’s device. ‘Betting Tips’ is the only application in this category, which has additional
permissions,
compared
to
ACCESS_FINE_LOCATION,
its
counterparts.
INSTALL_SHORTCUT,
READ_HISTORY_BOOKMARKS,
Additional
permissions
include
READ_EXTERNAL_STORAGE,
SYSTEM_ALERT_WINDOW,
UNINSTALL_SHORTCUT,
USE_CREDENTIALS, WRITE_EXTERNAL_STORAGE and WRITE_HISTORY_BOOKMARKS
which give far too much unnecessary access to device and user information and functionality outside
of the confines of a pure ‘Betting’ based application. These permissions are deemed unnecessary to
this sub-categories purpose.
Category
Sub-Category
Application
Wave Alarm
Tools
Alarms
Permissions Not Shared
ACCESS_WIFI_STATE
BILLING
My Talking Alarm Clock
GET_ACCOUNTS
RECORD_AUDIO
WRITE_SETTINGS
My Alarm Clock Free
PREVENT_POWER_KEY
Figure 4.26: ‘Tools’ permissions not shared
Figure 4.26 outlines the permissions not shared within the ‘Alarms’ sub-category. The purpose
of the ‘Alarms’ sub-category applications is to provide the user with additional functionality regarding
alarm clocks and time management. The permissions BILLING, GET_ACCOUNTS and
RECORD_AUDIO are justified permissions that can allow an application to buy additional
functionality for an application (free/premium accounts), get different accounts from the user’s device
and record the user’s audio input. The permissions ACCESS_WIFI_STATE, WRITE_SETTINGS and
PREVENT_POWER_KEY provide additional functionality that can allow an application to gather the
Page 73 of 137
The University of Derby
Department of Computing and Mathematics
devices Wi-Fi information, write the devices settings and prevent the users from using the devices
power button. These permissions are deemed unnecessary to this sub-categories purpose.
Category
Sub-Category
Application
Permissions Not Shared
BROADCAST_STICKY
READ_EXTERNAL_STORAGE
READ_PHONE_STATE
Trainline – times & tickets
Transport
Train Lines
ACCESS_LOCATION_EXTRA_COMMANDS
BILLING
DISABLE_KEYGUARD
SET_ALARM
VIBRATE
WRITE_CALENDAR
National Rail Enquires
Train times, travel & tickets
Figure 4.27: ‘Transport’ permissions not shared
Figure 4.27 outlines the permissions not shared within the ‘Train Lines’ sub-category. The
purpose of the ‘Train Lines’ sub-category applications is to provide a method of monitoring, viewing
and booking train tickets. The permissions BROADCAST_STICKY, BILLING, SET_ALARM and
WRITE_CALENDAR are justified permissions that can allow a broadcast of gathered data and
information as an intent, write to a user’s calendar and provide a method of buying additional
functionality
for
an
application
READ_EXTERNAL_STORAGE,
(free/premium
accounts).
READ_PHONE_STATE,
The
permissions
VIBRATE
ACCESS_LOCATION_EXTRA_COMMANDS and DISABLE_KEYGUARD provide additional
functionality that can allow an application to read a devices external storage, phone state, additional
locational services and to make a user’s device vibrate. These permissions are deemed unnecessary to
this sub-categories purpose.
Category
Travel & Local
Sub-Category
Application
GPS Navigation
Waze – GPS, Maps & Traffic
Page 74 of 137
Permissions Not Shared
AUTHENTICATE_ACCOUNTS
MANAGE_ACCOUNTS
READ_CALENDAR
READ_PROFILE
READ_SMS
READ_SYNC_SETTINGS
READ_SYNC_STATS
RECEIVE_SMS
USE_CREDENTIALS
WRITE_CONTACTS
WRITE_SETTINGS
WRITE_SYNC_SETTINGS
The University of Derby
Department of Computing and Mathematics
GPS Navigation & Maps Sygic
ACCESS_WIFI_STATE
CHANGE_WIFI_STATE
CHECK_LICENSE
INSTALL_SHORTCUT
READ_LOGS
MapFactor GPS Navigation Maps
Figure 4.28: ‘Travel & local’ permissions not shared
Figure 4.28 outlines the permissions not shared within the ‘GPS Navigation’ sub-category.
The purpose of the ‘GPS Navigation’ sub-category applications is to provide a user’s device with
additional GPS navigational functionality, including direction prompts and global road maps. The
permissions AUTHENTICATE_ACCOUNTS, MANAGE_ACCOUNTS, READ_SYNC_SETTINGS,
READ_SYNC_STATS,
WRITE_SYNC_SETTINGS,
and
CHECK_LICENSE
are
justified
permissions that can allow an application to authenticate and manage the accounts used with an
application, check the license of the application and read, write and change the way application data is
managed. The permissions READ_CALENDAR, READ_PROFILE, READ_SMS, RECEIVE_SMS,
USE_CREDENTIALS,
WRITE_CONTACTS,
WRITE_SETTINGS,
ACCESS_WIFI_STATE,
CHANGE_WIFI_STATE, INSTALL_SHORTCUT and READ_LOGS are permissions which give far
too much unnecessary access to device and user information and functionality outside of the confines
of a pure ‘GPS Navigation’ based application. These permissions are deemed unnecessary to this subcategories purpose.
Category
Weather
Sub-Category
Forecast
Application
Permissions Not Shared
BBC Weather
NFC
Yahoo Weather
ACCESS_WIFI_STATE
AUTHENTICATE_ACCOUNTS
GET_ACCOUNTS
MANAGE_ACCOUNTS
READ_EXTERNAL_STORAGE
READ_SYNC_SETTINGS
READ_SYNC_STATS
USE_CREDENTIALS
VIBRATE
WRITE_EXTERNAL_STORAGE
WRITE_SYNC_SETTINGS
Weather
BILLING
Figure 4.29: ‘Weather’ permissions not shared
Figure 4.29 outlines the permissions not shared within the ‘Forecast’ sub-category. The
purpose of the ‘Forecast’ sub-category applications is to provide the user with a method of monitoring
local
or
global
weather.
ACCESS_WIFI_STATE,
AUTHENTICATE_ACCOUNTS,
GET_ACCOUNTS, MANAGE_ACCOUNTS, USE_CREDENTIALS and BILLING are justified
permissions that allow an application to connect to a Wi-Fi connection, authenticate and manage
Page 75 of 137
The University of Derby
Department of Computing and Mathematics
accounts used with an application and use previously stored credentials to sign into an application, and
to provide a method of buying additional functionality for an application (free/premium accounts). The
permissions
NFC,
READ_SYNC_STATS,
READ_EXTERNAL_STORAGE,
WRITE_EXTERNAL_STORAGE,
READ_SYNC_SETTINGS,
WRITE_SYNC_SETTINGS
and
VIBRATE, are permissions which give far too much unnecessary access to device and user
information and functionality outside of the confines of a pure ‘Forecast’ based application. These
permissions are deemed unnecessary to this sub-categories purpose.
Page 76 of 137
The University of Derby
Department of Computing and Mathematics
Figure 4.30: Frequency of unnecessary non-recurrent permissions
Page 77 of 137
The University of Derby
Department of Computing and Mathematics
All 23 sub-categories have permissions, which are not shared (non-recurrent) between the
three sub-category applications; the majority of these non-recurrent permissions were deemed
unnecessary to the sub-categories purpose. Figure 4.30 outlines the frequency of all of the unnecessary
non-recurrent permissions found in the 69 sampled applications. 55 of the 74 unique permissions were
identified
as
non-recurrent
permissions.
The
top
three
non-recurrent
permissions
were
READ_EXTERNAL_STORAGE (requested 8 times), ACCESS_COARSE_LOCATION (requested 7
times) and VIBRATE (requested 6 times), with a total of 22 unique non-recurrent permissions only
requested once. Each application with non-recurrent, unnecessary permissions is assumed to be overprivileged because they exceed the permissions required for the basic sub-categories primary purpose,
however, further static and dynamic analysis (further to this project) is required to understand how
each application uses its requested permissions during run time.
4.3 Permission Risk Analysis
In the Android operating system, there is a three-way relationship between the user, Google
(the designer and provider of the Android operating system) and the third party application developer.
Google moderates the relationship between user and developer using sets of permissions for each
application a user downloads. Permissions are Android’s method of requiring the developer to disclose
how the application interacts with the user’s device and what information the application will have
access to (discussed in more detail in section 2.3). The user understands, by accepting these
permissions, that the application will have access to different areas of their device, however, they may
not understand the potential danger associated with each permission and how combinations of
permissions can leave the user vulnerable to a variety of risks. The following section discusses the 78
unique permissions acquired from the sampled applications and divides them into two levels of risk;
section 4.3.1 permissions that control device hardware and section 4.3.2 permissions that access user
information. These are then analysed against the 69 sampled applications to identify the potential
dangers of combinations of permissions.
4.3.1 Permissions that control device hardware
36 of the 74 unique permissions (excluding the four erroneous permissions outlined in section
4.1) collected from the sampled applications (48.6% of all unique permissions), allow an application
to interact with the hardware components of an Android device and do not have direct access to any
user information.
The two most common permissions that take control of device hardware are permissions
which help the user connect to the internet and maintain a constant connection with the devices
network properties. The ACCESS_NETWORK_STATE (used by 97.1% of all sampled applications)
and INTERNET (used by 100% of all sampled applications) allow an application to connect to the
Page 78 of 137
The University of Derby
Department of Computing and Mathematics
Internet and identify networks that the device has access to. Any application, which requires Internet
access, requires both of these permissions to function correctly. Independently these permissions have
no direct access to any user information. Figure 4.31 outlines 12 of the 36 unique permissions, which
have the highest risk of controlling device hardware. See Appendix E for a complete overview of the
35 permissions that control device hardware and their statements of risk.
Permission
Purpose/Potential Risk
Can turn bluetooth on and off and discover
connectable devices.
BLUETOOTH
BLUETOOTH_ADMIN
Can discover and pair bluetooth devices without
user knowledge.
BLUETOOTH_PRIVILEGED
Can discover and pair bluetooth devices without
user interaction and allow or disallow access to
phonebook access or message access
Could take pictures and videos without user
knowledge.
CAMERA
Can modify, change or turn off network
connectivity.
CHANGE_NETWORK_STATE
DOWNLOAD_WITHOUT_NOTIFICATION
Allows the application to download files through
the download manager without the users consent or
notification.
INTERNET
Allows an application to connect to the Internet.
MOUNT_UNMOUNT_FILESYSTEMS
Can mount or unmount removable file systems.
RECEIVE_BOOT_COMPLETED
Allows an application to run itself every time the
user opens their device.
WRITE_EXTERNAL_LOCK
WRITE_SETTINGS
WRITE_SYNC_SETTINGS
Allows the application to override the phones lock
configurations.
Allows an application to modify or corrupt user
system configurations and settings.
Allows an application to change how user account
data is synced and backed up.
Figure 4.31: Highest risk permissions that control device hardware
The other 24 unique permissions that control device hardware include VIBRATE,
FLASHLIGHT and SET_ALARM, which were not included in figure 4.30’s list of high risk
permissions as their potential impact to device security was not as severe as the other 12 unique
permissions. The VIBRATE permission allows an application to vibrate the user’s device and when
correlated with other combinations of permissions, VIBRATE could not cause high levels of risk to
the users device hardware. This principle was adhered to when completing the selection of high risk
permissions that control device hardware.
Page 79 of 137
The University of Derby
Department of Computing and Mathematics
All of these permissions are not completely safe when interacting with a user’s device. If used
incorrectly or maliciously an application could potentially damage a user’s hardware, but ultimately
these permissions cannot access user information. Section 4.3.2 will cover the permissions that do not
directly access hardware components but can access user and device information.
4.3.2 Permissions that access user information
38 of the 74 unique permissions (excluding the four erroneous permissions outlined in section
4.1) collected from the sampled applications (51.2% of all unique permissions) have the potential to
allow an application to access and interact with user information on an Android device.
The two most common permissions that can access user information are permissions which
determine the user location, whether it’s approximate location or a precise location. The
ACCESS_COARSE_LOCATION
(used
by
47.8%
of
all
sampled
applications)
and
ACCESS_FINE_LOCATION (used by 52.2% of all sampled applications) allow an application to
determine the exact location of a user’s device and information that includes GPS, Coordinates etc.
Figure 4.32 outlines 23 of the 74 unique permissions that have the highest risk when accessing user
information. See Appendix E for a complete overview of the 39 permissions that can access user
information and their associated description and risk.
Permission
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
ACCESS_WIFI_STATE
AUTHENTICATE_ACCOUNTS
CALL_PHONE
CHANGE_WIFI_MULTICAST_STATE
CHANGE_WIFI_STATE
DISABLE_KEYGUARD
GET_ACCOUNTS
Purpose/Potential Risk
Allows an application to determine a user’s approximate
location.
Allows an application to determine a user’s precise
location.
Allows an application to view a user’s Wi-Fi status and
information.
Allows an application to authenticate credentials and
reveal user passwords.
Allows an application to call any phone number (except
emergency phone numbers).
Allows an application to discover and connect to a
multicast network (one-to-many or many-to-many
connections), sharing information with multiple
networks.
Allows an application to connect or disconnect to Wi-Fi
connections.
Allows an application to disable a user’s
Password/PIN/Slide lock screen.
Allows an application access to the list of device
accounts.
MANAGE_ACCOUNTS
Stores, reads and enters account details (i.e. e-mails,
passwords, and usernames) for repetitive entry.
MANAGE_DOCUMENTS
Allows an application to access, move and read user
documents.
READ_CALENDAR
Allows an application to read calendar events.
Page 80 of 137
The University of Derby
Department of Computing and Mathematics
READ_CONTACTS
Allows an application to read all contacts stored on a
user’s device.
READ_EXTERNAL_STORAGE
Allows an application to read from a devices external
storage (SD card, USB etc.).
READ_SETTINGS
Allows an application to read a user’s device settings.
Allows an application access to read all user SMS
messages.
Allows an application the capability to eavesdrop on
phone calls and other voice based communication, as
well as record sound from any source fed into the user’s
device (Microphone etc.).
READ_SMS
RECORD_AUDIO
RECEIVE_SMS
Allows an application to receive user SMS messages
SEND_SMS
Allows an application to send SMS messages.
Allows an application to request authentication tokens
and use stored user authentication credentials.
Allows an application to add or change events on a
user’s calendar.
USE_CREDENTIALS
WRITE_CALENDAR
WRITE_CONTACTS
Allows an application to modify a user’s contact list.
Allows an application to write directly to a user’s
external storage (SD card, USB etc.).
WRITE_EXTERNAL_STORAGE
Figure 4.32: Highest risk permissions that access user information
The 15 unique permissions that can access user information include USE_FINGERPRINT,
WRITE_USER_DICTIONARY and SUBSCRIBED_FEEDS_READ. These were not included in
figure 4.31’s list of high risk permissions because of their potential impact on user security, which was
not as severe as the other 23 unique permissions. The WRITE_USER_DICTIONARY permission
allows an application to write words into a user’s default device dictionary. If used maliciously it
causes a problem for users, however, when correlated with other combinations of permissions,
WRITE_USER_DICTIONARY does not cause high levels of risk to user information. This principle
was adhered to when completing the selection of high risk permissions that access user information.
It is extremely challenging to judge the potential risk that a permission has on a user’s device,
without understanding how the information from a user’s device is used. User information is treated as
sensitive information, while the judgement of potential risk is highly contextual; users should not view
these permissions as inherently dangerous or detrimental to their privacy, but understand that this
analysis provides an overview of the potential vulnerabilities created by certain combinations of
permissions if used incorrectly or maliciously.
4.4 Permission Combinations and Risk Analysis
In sections 4.3.1 and 4.3.2 the 74 unique permissions sampled from the 69 applications were
split into two different categories; permissions that control device hardware and permissions that
access user information. These categories of permissions were analysed to find permissions which
have a high risk to a user’s device security, whether it affects a user’s private information, device
Page 81 of 137
The University of Derby
Department of Computing and Mathematics
hardware or a combination of both. Figure 4.33 outlines the combination of the two sets of high risk
permissions which generates a set of 35 unique high risk permissions based upon impact to device and
user security. The 35 unique permissions have been ordered alphabetically and given a permission
number to identify individual permissions during analysis.
Permission Number
P1
Permission Name
ACCESS_COARSE_LOCATION
P2
ACCESS_FINE_LOCATION
P3
ACCESS_WIFI_STATE
P4
AUTHENTICATE_ACCOUNTS
P5
BLUETOOTH
P6
BLUETOOTH_ADMIN
P7
BLUETOOTH_PRIVILEGED
P8
CALL_PHONE
P9
CAMERA
P10
CHANGE_NETWORK_STATE
P11
CHANGE_WIFI_MULTICAST_STATE
P12
CHANGE_WIFI_STATE
P13
DISABLE_KEYGUARD
P14
DOWNLOAD_WITHOUT_NOTIFICATION
P15
GET_ACCOUNTS
P16
INTERNET
P17
MANAGE_ACCOUNTS
P18
MANAGE_DOCUMENTS
P19
MOUNT_UNMOUNT_FILESYSTEMS
P20
READ_CALENDAR
P21
READ_CONTACTS
P22
READ_EXTERNAL_STORAGE
P23
READ_SETTINGS
P24
READ_SMS
P25
RECEIVE_BOOT_COMPLETED
P26
RECEIVE_SMS
P27
P28
RECORD_AUDIO
SEND_SMS
P29
USE_CREDENTIALS
P30
WRITE_CALENDAR
P31
WRITE_CONTACTS
P32
WRITE_EXTERNAL_LOCK
P33
WRITE_EXTERNAL_STORAGE
P34
WRITE_SETTINGS
P35
WRITE_SYNC_SETTINGS
Figure 4.33: High risk permissions
Page 82 of 137
The University of Derby
Department of Computing and Mathematics
The 35 high risk permissions were used to generate a 35 x 35 matrix outlined in figure 4.34,
capable of comparing and analysing the potential levels of risk of permission combinations based upon
their combined impact to user and device security. A 12 x 23 matrix would have only had the
capability to analyse permissions that control device hardware by permissions that access user
information. The 35 x 35 matrix allows the comparison of two permissions that control device
hardware and two permissions that have access to user information, as well as the combination of a
permission that can control device hardware with a permission that can access user information.
Colour Code
Risk Level
High
Low
Duplicate Permissions
Figure 4.34: Permission Risk Analysis Matrix
The matrix was colour coded according to two individual risk levels: high and low. The level
of risk associated with a combination of two permissions was determined by their combined impact on
the security of a user’s device or personal information, based upon the permissions statement of risk,
Page 83 of 137
The University of Derby
Department of Computing and Mathematics
outlined in sections 4.3.1 and 4.3.2. For example P1 ACCESS_COARSE_LOACTION and P8
CALL_PHONE is considered low risk because it can only allow an application to approximate a
user’s location and allow the application to call phone numbers (excluding emergency numbers).
While that still presents a risk to user security, the high risk combination of P14
DOWNLOAD_WITHOUT_NOTIFICATION and P33 WRITE_EXTERNAL_STORAGE, which
allows an application to download and save a potentially harmful application, or update to a user’s
external storage, presents a higher level of risk to user and device security. This was repeated with
every possible combination of the 35 unique permissions and colour coded according to their potential
levels of risk. Permissions cannot be compared with themselves (i.e. P1 by P1) and this was indicated
with the colour yellow in the matrix.
Figure 4.35 is a complete list of all 23 sampled Google categories including a list of all 69
sampled applications. Each applications set of permissions were compared against the high risk
permissions (section 4.3.1 and 4.3.2) and organised accordingly. The matrix was used to measure the
level of risk associated with every possible combination of permissions in each application. See
Appendix F for the frequency of low and high risk permission combinations in each of the 69
applications. Each application was given an overall level of risk (high, low or equal) based upon the
frequency of high risk permission combinations and low risk permission combinations. For example
the application ‘Draw Cartoons 2’ was given an overall high risk level because only 3 permission
combinations were deemed low risk and 7 permission combinations were deemed high risk, therefore
the majority of permission combinations in this application impacted on a user’s device security and
personal information. This process was repeated for each of the 69 applications.
Category
Comic
Permissions that access device hardware
Permissions that access user
information
Risk
Level
Draw
Cartoons 2
INTERNET (P16)
GET_ACCOUNTS (P15)
RECORD_AUDIO (P27)
USE_CREDENTIALS (P29)
WRITE_EXTERNAL_STORAGE (P33)
High
Learn to
Draw Anime
Manga
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
ACCESS_WIFI_STATE (P3)
GET_ACCOUNTS (P15)
WRITE_EXTERNAL_STORAGE (P33)
High
How to Draw
3D and
Illusions
INTERNET (P16)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
WRITE_EXTERNAL_STORAGE (P33)
High
Application
Page 84 of 137
The University of Derby
Department of Computing and Mathematics
BLUETOOTH (P5)
CAMERA (P9)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE_SETTINGS (P34)
WRITE__SYNC_SETTINGS (P35)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
AUTHENTICATE_ACCOUNTS (P4)
CALL_PHONE (P8)
CHANGE_WIFI_STATE (P12)
DISABLE_KEYGUARD (P13)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_CONTACTS (P21)
READ_EXTERNAL_STORAGE (P22)
READ_SMS (P24)
RECEIVE_SMS (P26)
RECORD_AUDIO (P27)
USE_CREDENTIALS (P29)
WRITE_CONTACTS (P31)
WRITE_EXTERNAL_STORAGE (P33)
BLUETOOTH (P5)
BLUETOOTH_ADMIN (P6)
CAMERA (P9)
DOWNLOAD_WITHOUT_NOTIFICATION
(P14)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE_SETTINGS (P34)
WRITE__SYNC_SETTINGS (P35)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
AUTHENTICATE_ACCOUNTS (P4)
CHANGE_WIFI_STATE (P12)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_CONTACTS (P21)
READ_SETTINGS (P23)
READ_SMS (P24)
RECORD_AUDIO (P27)
USE_CREDENTIALS (P29)
WRITE_CONTACTS (P31)
WRITE_EXTERNAL_STORAGE (P33)
Telegram
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE__SYNC_SETTINGS (P35)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
AUTHENTICATE_ACCOUNTS (P4)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_CONTACTS (P21)
READ_EXTERNAL_STORAGE (P22)
RECEIVE_SMS (P26)
RECORD_AUDIO (P27)
WRITE_CONTACTS (P31)
WRITE_EXTERNAL_STORAGE (P33)
High
Homework
Planner
RECEIVE_BOOT_COMPLETED (P25)
N/A
Low
INTERNET (P16)
WRITE__SYNC_SETTINGS (P35)
AUTHENTICATE_ACCOUNTS (P4)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
USE_CREDENTIALS (P29)
WRITE_EXTERNAL_STORAGE (P33)
High
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
ACCESS_COARSE_LOCATION (P1)
ACCESS_WIFI_STATE (P3)
GET_ACCOUNTS (P15)
READ_EXTERNAL_STORAGE (P22)
USE_CREDENTIALS (P29)
WRITE_EXTERNAL_STORAGE (P33)
High
Skype
Communication
WeChat
Show My
Homework
High
High
Education
myHomework
Student
Planner
Page 85 of 137
The University of Derby
BBC iPlayer
Entertainment
Family
Department of Computing and Mathematics
INTERNET (P16)
WRITE_EXTERNAL_STORAGE (P33)
High
DISH
Anywhere
INTERNET (P16)
ACCESS_WIFI_STATE (P3)
CHANGE_WIFI_MULTICAST_STATE
(P11)
GET_ACCOUNTS (P15)
WRITE_EXTERNAL_STORAGE (P33)
High
My5
INTERNET (P16)
ACCESS_WIFI_STATE (P3)
GET_ACCOUNTS (P15)
USE_CREDENTIALS (P29)
High
INTERNET (P16)
READ_EXTERNAL_STORAGE (P22)
WRITE_EXTERNAL_STORAGE (P33)
High
INTERNET (P16)
WRITE_EXTERNAL_STORAGE (P33)
High
INTERNET (P16)
WRITE_EXTERNAL_STORAGE (P33)
High
CAMERA (P9)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
AUTHENTICATE_ACCOUNTS (P4)
READ_CONTACTS (P21)
READ_EXTERNAL_STORAGE (P22)
WRITE_EXTERNAL_STORAGE (P33)
Low
INTERNET (P16)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
READ_CONTACTS (P21)
READ_EXTERNAL_STORAGE (P22)
WRITE_EXTERNAL_STORAGE (P33)
High
Yorkshire
Bank Mobile
Banking
INTERNET (P16)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
READ_CONTACTS (P21)
WRITE_EXTERNAL_STORAGE (P33)
High
Solitaire
INTERNET (P16)
ACCESS_WIFI_STATE (P3)
Solitaire
Classic
INTERNET (P16)
ACCESS_WIFI_STATE (P3)
WRITE_EXTERNAL_STORAGE (P33)
High
Spider
Solitaire
INTERNET (P16)
WRITE_EXTERNAL_STORAGE (P33)
High
FatSecret
CAMERA (P9)
INTERNET (P16)
ACCESS_COARSE_LOCATION (P1)
WRITE_EXTERNAL_STORAGE (P33)
High
LetterSchool
Free – Write
ABC
ABC
Learning
Letters for
Toddlers
ABC Flash
Cars for Kids
Game
PayPal
Finance
NatWest
Games
Health &
Fitness
Page 86 of 137
High
The University of Derby
Department of Computing and Mathematics
MyFitnessPal
BLUETOOTH (P5)
BLUETOOTH_ADMIN (P6)
CAMERA (P9)
CHANGE_WIFI_STATE (P12)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
CHANGE_WIFI_STATE (P12)
GET_ACCOUNTS (P15)
MANAGE_DOCUMENTS (P18)
READ_CONTACTS (P21)
USE_CREDENTIALS (P29)
WRITE_EXTERNAL_STORAGE (P33)
Low
Google Fit
BLUETOOTH (P5)
BLUETOOTH_ADMIN (P6)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE__SYNC_SETTINGS (P35)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
GET_ACCOUNTS (P15)
WRITE_EXTERNAL_STORAGE (P33)
Equal
All Recipes
Free
INTERNET (P16)
ACCESS_WIFI_STATE (P3)
GET_ACCOUNTS (P15)
WRITE_EXTERNAL_STORAGE (P33)
High
CookPad
INTERNET (P16)
ACCESS_COARSE_LOCATION (P1)
GET_ACCOUNTS (P15)
MANAGE_DOCUMENTS (P18)
READ_EXTERNAL_STORAGE (P22)
USE_CREDENTIALS (P29)
WRITE_EXTERNAL_STORAGE (P33)
High
Food
Network In
the Kitchen
INTERNET (P16)
WRITE__SYNC_SETTINGS (P35)
AUTHENTICATE_ACCOUNTS (P4)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
USE_CREDENTIALS (P29)
High
Screen
Recorder
INTERNET (P16)
WRITE_SETTINGS (P34)
GET_ACCOUNTS (P15)
READ_EXTERNAL_STORAGE (P22)
RECORD_AUDIO (P27)
WRITE_EXTERNAL_STORAGE (P33)
High
Spy Video
Recorder
CAMERA (P9)
INTERNET (P16)
RECORD_AUDIO (P27)
WRITE_EXTERNAL_STORAGE (P33)
High
SCR Free
CAMERA (P9)
INTERNET (P16)
WRITE_SETTINGS (P34)
READ_EXTERNAL_STORAGE (P22)
RECORD_AUDIO (P27)
WRITE_EXTERNAL_STORAGE (P33)
High
Pregnancy +
CAMERA (P9)
INTERNET (P16)
ACCESS_COARSE_LOCATION (P1)
ACCESS_WIFI_STATE (P3)
CALL_PHONE (P8)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_CALENDAR (P20)
READ_CONTACTS (P21)
READ_EXTERNAL_STORAGE (P22)
SEND_SMS (P28)
USE_CREDENTIALS (P29)
WRITE_CALENDAR (P30)
WRITE_EXTERNAL_STORAGE (P33)
High
Pregnancy
Calculator
INTERNET (P16)
N/A
Low
Lifestyle
Media & Video
Medical
Page 87 of 137
The University of Derby
ACCESS_COARSE_LOCATION (P1)
ACCESS_WIFI_STATE (P3)
AUTHENTICATE_ACCOUNTS (P4)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_EXTERNAL_STORAGE (P22)
USE_CREDENTIALS (P29)
WRITE_EXTERNAL_STORAGE (P33)
High
ACCESS_WIFI_STATE (P3)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_EXTERNAL_STORAGE (P22)
USE_CREDENTIALS (P29)
WRITE_EXTERNAL_STORAGE (P33)
High
INTERNET (P16)
ACCESS_WIFI_STATE (P3)
READ_EXTERNAL_STORAGE (P22)
WRITE_EXTERNAL_STORAGE (P33)
High
SoundCloud
INTERNET (P16)
WRITE__SYNC_SETTINGS (P35)
ACCESS_WIFI_STATE (P3)
AUTHENTICATE_ACCOUNTS (P4)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
RECORD_AUDIO (P27)
USE_CREDENTIALS (P29)
WRITE_EXTERNAL_STORAGE (P33)
High
BBC News
INTERNET (P16)
WRITE__SYNC_SETTINGS (P35)
ACCESS_COARSE_LOCATION (P1)
AUTHENTICATE_ACCOUNTS (P4)
GET_ACCOUNTS (P15)
High
ABC News
INTERNET (P16)
RECEIVED_BOOT_COMPLETED
WRITE__SYNC_SETTINGS (P35)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
AUTHENTICATE_ACCOUNTS (P4)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_EXTERNAL_STORAGE (P22)
USE_CREDENTIALS (P29)
WIRTE_EXTERNAL_STORAGE
Google News
& Weather
INTERNET (P16)
WRITE__SYNC_SETTINGS (P35)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
GET_ACCOUNTS (P15)
USE_CREDENTIALS (P29)
High
Emoji
Keyboard
Lite Kika
Free
DOWNLOAD_WITHOUT_NOTIFICATION
(P14)
INTERNET (P16)
MOUNT_UNMOUNT_FILESYSTEMS
(P19)
RECEIVE_BOOT_COMPLETED (P25)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
CHANGE_WIFI_STATE (P12)
GET_ACCOUNTS (P15)
READ_CONTACTS (P21)
READ_EXTERNAL_STORAGE (P22)
WRITE_EXTERNAL_STORAGE (P33)
High
Ovia
Pregnancy
Tracker
Spotify
Media & Audio
News &
Magazines
Personalisation
Department of Computing and Mathematics
Music Free
INTERNET (P16)
BLUETOOTH (P5)
BLUETOOTH_ADMIN (P6)
INTERNET (P16)
Page 88 of 137
High
The University of Derby
Department of Computing and Mathematics
Lollipop
Emoji
Keyboard
DOWNLOAD_WITHOUT_NOTIFICATION
(P14)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE_SETTINGS (P34)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
CHANGE_WIFI_STATE (P12)
GET_ACCOUNTS (P15)
READ_CONTACTS (P21)
READ_SMS (P24)
RECORD_AUDIO (P27)
WRITE_EXTERNAL_STORAGE (P33)
Emoji
Keyboard 6
INTERNET (P16)
ACCESS_WIFI_STATE (P3)
READ_CONTACTS (P21)
WRITE_EXTERNAL_STORAGE (P33)
High
Camera for
Android
CAMERA (P9)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE_EXTERNAL_LOCK (P32)
WRITE_SETTINGS (P34)
WRITE__SYNC_SETTINGS (P35)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_CONTACTS (P21)
RECORD_AUDIO (P27)
USE_CREDENTIALS (P29)
High
Retrica
BLUETOOTH (P5)
BLUETOOTH_ADMIN (P6)
BLUETOOTH_PRIVILEGED (P7)
CAMERA (P9)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE_EXTERNAL_LOCK (P32)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
GET_ACCOUNTS (P15)
READ_CONTACTS (P21)
READ_EXTERNAL_STORAGE (P22)
Open Camera
CAMERA (P9)
WRITE_EXTERNAL_LOCK (P32)
ACCESS_FINE_LOCATION (P2)
RECORD_AUDIO (P27)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE__SYNC_SETTINGS (P35)
ACCESS_FINE_LOCATION (P2)
AUTHENTICATE_ACCOUNTS (P4)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_CALENDAR (P20)
READ_CONTACTS (P21)
USE_CREDENTIALS (P29)
WRITE_CALENDAR (P30)
WRITE_EXTERNAL_STORAGE (P33)
Google
Calendar
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE__SYNC_SETTINGS (P35)
ACCESS_COARSE_LOCATION (P1)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_CALENDAR (P20)
READ_CONTACTS (P21)
USE_CREDENTIALS (P29)
WRITE_CALENDAR (P30)
High
Calendar
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
READ_CALENDAR (P20)
WRITE_EXTERNAL_STORAGE (P33)
High
eBay
CAMERA (P9)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
ACCESS_FINE_LOCATION (P2)
GET_ACCOUNTS (P15)
WRITE_EXTERNAL_STORAGE (P33)
High
Photography
Sunrise
Calendar
Productivity
Shopping
Page 89 of 137
High
Low
Low
High
The University of Derby
Department of Computing and Mathematics
CAMERA (P9)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
WRITE_EXTERNAL_STORAGE (P33)
High
Etsy
INTERNET (P16)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
GET_ACCOUNTS (P15)
READ_EXTERNAL_STORAGE (P22)
USE_CREDENTIALS (P29)
WRITE_EXTERNAL_STORAGE (P33)
High
Pinterest
CAMERA (P9)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
ACCESS_FINE_LOCATION (P2)
GET_ACCOUNTS (P15)
READ_CONTACTS (P21)
USE_CREDENTIALS (P29)
WRITE_EXTERNAL_STORAGE (P33)
High
CAMERA (P9)
CHANGE_NETWORK_STATE (P10)
DOWNLOAD_WITHOUT_NOTIFICATION
(P14)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE__SYNC_SETTINGS (P35)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
AUTHENTICATE_ACCOUNTS (P4)
CHANGE_WIFI_STATE (P12)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_CALENDAR (P20)
READ_CONTACTS (P21)
READ_EXTERNAL_STORAGE (P22)
READ_SMS (P24)
RECORD_AUDIO (P27)
WRITE_CALENDAR (P30)
WRITE_CONTACTS (P31)
WRITE_EXTERNAL_STORAGE (P33)
High
LinkedIn
INTERNET (P16)
WRITE__SYNC_SETTINGS (P35)
ACCESS_FINE_LOCATION (P2)
AUTHENTICATE_ACCOUNTS (P4)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_CALENDAR (P20)
READ_CONTACTS (P21)
WRITE_CONTACTS (P31)
WRITE_EXTERNAL_STORAGE (P33)
High
Bet365 News
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
N/A
High
Tipster 365
INTERNET (P16)
GET_ACCOUNTS (P15)
High
ACCESS_FINE_LOCATION (P2)
GET_ACCOUNTS (P15)
READ_EXTERNAL_STORAGE (P22)
USE_CREDENTIALS (P29)
WRITE_EXTERNAL_STORAGE (P33)
High
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
DISABLE_KEYGUARD (P13)
READ_EXTERNAL_STORAGE (P22)
WRITE_EXTERNAL_STORAGE (P33)
High
TopShop
Facebook
Social
Sports
Betting Tips
Tools
Wave Alarm
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
CAMERA (P9)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
Page 90 of 137
The University of Derby
My Talking
Alarm Clock
My Alarm
Clock Free
Trainline –
times &
tickets
Transport
National Rail
Enquires
Train times,
travel &
tickets
Department of Computing and Mathematics
DISABLE_KEYGUARD (P13)
GET_ACCOUNTS (P15)
RECORD_AUDIO (P27)
WRITE_EXTERNAL_STORAGE (P33)
High
CAMERA (P9)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
DISABLE_KEYGUARD (P13)
READ_EXTERNAL_STORAGE (P22)
WRITE_EXTERNAL_STORAGE (P33)
High
INTERNET (P16)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
READ_EXTERNAL_STORAGE (P22)
High
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
DISABLE_KEYGUARD (P13)
WRITE_CALENDAR (P30)
High
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
High
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE_SETTINGS (P34)
INTERNET (P16)
INTERNET (P16)
BLUETOOTH (P5)
CAMERA (P9)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE_SETTINGS (P34)
WRITE__SYNC_SETTINGS (P35)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
AUTHENTICATE_ACCOUNTS (P4)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_CALENDAR (P20)
READ_CONTACTS (P21)
READ_EXTERNAL_STORAGE (P22)
READ_SMS (P24)
RECEIVE_SMS (P26)
RECORD_AUDIO (P27)
USE_CREDENTIALS (P29)
WRITE_CONTACTS (P31)
WRITE_EXTERNAL_STORAGE (P33)
GPS
Navigation &
Maps Sygic
BLUETOOTH (P5)
CAMERA (P9)
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
CHANGE_WIFI_STATE (P12)
GET_ACCOUNTS (P15)
READ_CONTACTS (P21)
READ_EXTERNAL_STORAGE (P22)
RECORD_AUDIO (P27)
WRITE_EXTERNAL_STORAGE (P33)
Low
MapFactor
GPS
Navigation
Maps
INTERNET (P16)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
READ_EXTERNAL_STORAGE (P22)
WRITE_EXTERNAL_STORAGE (P33)
High
BBC Weather
INTERNET (P16)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
High
Waze – GPS,
Maps &
Traffic
Travel & Local
Weather
Page 91 of 137
High
The University of Derby
Department of Computing and Mathematics
Yahoo
Weather
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
WRITE__SYNC_SETTINGS (P35)
ACCESS_COARSE_LOCATION (P1)
ACCESS_FINE_LOCATION (P2)
ACCESS_WIFI_STATE (P3)
AUTHENTICATE_ACCOUNTS (P4)
GET_ACCOUNTS (P15)
MANAGE_ACCOUNTS (P17)
READ_EXTERNAL_STORAGE (P22)
USE_CREDENTIALS (P29)
WIRTE_EXTERNAL_STORAGE
Weather
INTERNET (P16)
RECEIVE_BOOT_COMPLETED (P25)
ACCESS_FINE_LOCATION (P2)
Figure 4.35: Sampled Application Risk Analysis
61 of the 69 (88%) applications were given an overall risk level of high, 7 of the 69 (10%)
were given an overall risk level of low, while 1 of the 69 (2%) applications had a equal risk level with
18 high risk permission combinations and 18 low risk combinations. Figure 4.36 presents the risk
analysis summary of the 69 sampled applications.
High Risk Applications
Low Risk Applications
Equal Risk Applications
1, 2%
7, 10%
61, 88%
Figure 4.36: Risk Analysis Summary
The risk analysis of the 69 sampled applications identified that there was a larger number of
combinations of permissions that impacted on the security of a user’s device and personal information
than the low risk permission combinations. On the matrix 19 of the 35 high risk permissions
including DISABLE_KEYGUARD (P13), DOWNLOAD_WITHOUT_NOTIFICATION (P14),
GET_ACCOUNTS
(P15),
MANAGE_DOCUMENTS
INTERNET
(P18),
(P16),
MANAGE_ACCOUNTS
MOUNT_UNMOUNT_FILESYSTEMS
Page 92 of 137
(P17),
(P19),
High
High
The University of Derby
Department of Computing and Mathematics
READ_CALENDAR (P20), READ_CONTACTS (P21), READ_EXTERNAL_STORAGE (P22),
READ_SETTINGS
(P23),
RECEIVE_SMS
(P26),
READ_SMS
(P24),
RECEIVE_BOOT_COMPLETED
RECORD_AUDIO
(P27),
SEND_SMS
(P25),
(P28),
WRITE_EXTERNAL_STORAGE (P33) WRITE_SETTINGS (P34) and WRITE_SYNC_SETTINGS
(P35) demonstrated a clear trend when combined with one another and other permissions. The high
risk permission combinations, which were identified, accumulated in the centre of the matrix and
proceeded down to the right hand corner. The 19 high risk permissions identified by the coloured trend
in the matrix were confirmed when analysing the sampled 69 applications, with the majority of the 19
identified permissions appearing more frequently in permission combinations than lower level risk
permission combinations and justified the 61 (88%) of high risk applications.
This chapter has presented the complete dataset of Android applications and permission
analysis in line with the projects aims and objectives. The data presented is a complete overview of the
permissions collected, including statistical analysis. Further analysis of similar sub-categories of
applications was undertaken and the findings recorded. A risk analysis matrix was created based upon
statements of risks associated with different combinations of high risk Android permissions. These
findings will be discussed in chapter 5, including a comparison with related research identified in
chapter 2.
Page 93 of 137
The University of Derby
Department of Computing and Mathematics
Chapter 5
5. Discussion
Chapter 5 presents a discussion of the findings and analysis from chapter 4 and includes a
comparison with related work discussed in chapter 2. Section 5.1’s findings and related work
compares and contrasts the projects findings with other research of Android’s permissions model,
section 5.2 dataset limitations covers the potential limitations of the project’s dataset and section 5.3
concludes the overall findings.
5.1 Findings and Related Work
69 sampled applications were collected from Android’s official application marketplace
(Google Play Store). From these sampled applications 78 unique permissions were identified, 4 of
which were deprecated in previous Android operating system versions and 2 were written incorrectly.
11.5% of the total 69 sampled applications contained deprecated permissions from older versions of
Android’s operating system. Felt at al. (2011) sampled a total of 940 applications and found that 8%
contained deprecated permissions or permissions written incorrectly, and found that this was a
common mistake amongst Android application developers. They stated that while there is sufficient
amount of Android documentation regarding application architecture and security, the documentation
for official Android permissions is very limited and causes confusion amongst developers.
The errors found in this project increased, with a total of 9 (13% of total unique permissions)
duplicate permissions being called more than once in multiple applications (5.7% of the 69 sampled
applications). Vidas et al. (2011) sampled a total of 34,000 applications across the course of their
research and found a total of 4% of applications had duplicate permissions, which correlated with the
top shared duplicate permissions found in this project.
ACCESS_NETWORK_STATE,
Vidas et al. (2011) found
WRITE_EXTERNAL_STORAGE
and
INTERNET,
RECEIVE_BOOT_COMPLETED. Duplicate permissions provide no additional functionality to an
application if previously called and can be considered an error by a developer during development,
which reflects on the limited and erroneous documentation and information provided. Felt et al (2011)
confirmed these findings as they identified 78 documented methods of calling Android official
applications, however, their developed tool ‘Stowaway’ identified a total of 1,259 methods of calling
permissions in API functions.
23 categories of the Google Play Store were sampled for application acquisition. From these
sampled applications 1079 permissions were requested, 215 of which were third party permissions,
Page 94 of 137
The University of Derby
Department of Computing and Mathematics
external to the official Android permission documentation and created for custom use by developers.
The categories ‘Communication’, ‘Social, and ‘Travel’ had the largest amount of permission requests
and were considered the most diverse categories, while the categories ‘Game’ and ‘Family’ had the
least permission requests and were considered the least diverse categories. While 32 of the 78 unique
permissions identified were only called once or twice in the sampled applications. The top 5 most
frequent application permission requests were ACCESS_NETWORK_STATE, INTERNET,
WRITE_EXTERNAL_STORAGE, WAKE_LOCK, and GET_ACCOUNTS. Barrera et al. (2010)
undertook an empirical analysis of Android’s permission model, sampling a total of 1100 applications
and they found that the most diverse categories were ‘Communication’ and ‘Productivity’ and some of
the
most
frequently
requested
permissions
of
their
research
also
included
ACCESS_NETWORK_STATE and INTERNET.
The distribution and frequency of permissions demonstrated in both of these studies identified
a clear divide in permission use, with a small amount of permissions being used frequently and a large
amount of permissions being used infrequently. This divide indicates that Android need a finer level of
granularity amongst permission groups. The permission READ_SMS, RECEIVE_SMS and
WRITE_SMS could simply be converted to ‘SMS’ and provide the functionality of the three original
permissions. This would make it easier for developers to assign permissions and for Android to update
permission documentation and discard infrequent permission usage. Android permission model,
however, is tightly integrated into Android’s operating system and would require all applications to be
rewritten for significant changes to take place.
The 69 sampled applications were categorised into groups of three, dependent on their
individual sub-category. Further sub-category application analysis (designed to compare and contrast
similar designed applications, based upon a sub-categories purpose) found potential methods to
identify over-privileged application sets. All 23 sub-categories contained non-recurrent permissions
(permissions not shared amongst the three sub-category applications), with 47.8% of sub-categories
showing clear differences in non-recurrent permissions and permissions shared between all three
applications. The categories ‘Health & Fitness’, ‘Photography’, ‘Medical’, ‘Social’ and ‘Weather’ had
the largest differences between non-recurrent permissions and the permissions shared between all
three
sub-category
applications.
The
top
5
most
frequently
requested
permissions;
ACCESS_NETWORK_STATE, INTERNET, WRITE_EXTERNAL_STORAGE, WAKE_LOCK,
and GET_ACCOUNTS, were also the most commonly shared permissions between sub-categories
(shared between all three sub-category applications). 223 non-recurrent permissions were requested
(26.5% of the 840 unique permission calls), 272 permissions shared between two applications were
requested (32.3% of the 840 unique permission calls) and 345 permissions shared between all three
sub-category applications were requested (41.2% of the 840 unique permission calls). 55 of the 78
unique permissions were deemed unnecessary, non-recurrent permissions and not vital to an
Page 95 of 137
The University of Derby
Department of Computing and Mathematics
applications purpose. The non-recurrent permissions BILLING, READ_EXTERNAL_STORAGE,
READ_PHONE_STATE, READ_SYNC_SETTINGS and USE_CREDENTIALS had a higher
frequency than any other non-recurrent permission, with the majority of these permissions allowing an
application access to user information or device settings. The non-recurrent permissions
READ_EXTERNAL_STORAGE, ACCESS_COARSE_LOCATION and VIBRATE were the top 3
unnecessary permissions based upon sub-category purpose, while a total of 22 non-recurrent
permissions were only requested once in sub-category applications. Applications with unnecessary
non-recurrent permissions were deemed over-privileged, as they had more permissions than required
for their sub-category purpose and further static and dynamic analysis would be required to confirm
these findings.
Vidas et al. (2011) found that more applications request more permissions than needed, and
could be considered ‘questionable’ or ‘malicious’. Adding additional permissions suggests that
developers do not necessarily understand what the application should have or that they are assigning
permissions for future implementation, while the majority of unnecessary, non-recurrent permissions
could be used maliciously, allowing an application access to a user’s device, which puts their sensitive
information at risk. 50% of applications send information about a user’s device to third parties. Felt et
al. (2011) found a third of their 940 sampled applications dataset were considered over-privileged
based on API requests. They found that an over-privileged application requests additional permissions,
with more than half of their dataset containing the addition of one permission and 6% requesting more
than four unnecessary permissions. Contrary to the findings in this project they revealed that the most
frequent unnecessary permissions were ACCESS_COARSE_LOCATION, ACCESS_WIFI_STATE,
WRITE_EXTERNAL_STORAGE, CAMERA, and WRITE_SETTINGS. Wain Yee Au et al. (2012)
also found 543 of 1260 applications declared one additional permission, with the remaining overprivileged applications requesting two or three extra permissions. It is clear from this projects findings
and previous related research that there are multiple methods of finding over-privileged applications.
However, rather than completely analysing the marketplaces applications for over-privileged designs,
use of sub-categories and sub-category designs can be refined to analyse individual groups of
applications and build a least-privilege profile, based upon an applications sub-category purpose.
Regardless of the errors in Android’s documentation or developers’ lack of knowledge when
creating applications, the users of Android applications are the priority and how they interpret the
technology they use is important. Recently there has been a growing interest from users in
understanding security risks of applications and permission-based security models, with a focus on
location services, messaging and social networking (Rosen et al 2013). Rosen et al (2013) provided a
method to create behaviour profiles for individual applications, based upon their permission requests
and API calls, with over 80,000 applications analysed. While their work was successful, they could
Page 96 of 137
The University of Derby
Department of Computing and Mathematics
only interpret the permissions of singular applications based upon the applications API calls made
during static analysis.
This project proposed a risk analysis matrix for high risk permission combinations, based
upon an individual permissions ‘statement of risk’. 12 high risk permissions that control device
hardware and 23 high risk permissions that access user information were identified, based upon their
impact on user and device security. The risk analysis matrix was created using a combination of these
permissions and identified a total of 294 unique high risk permission combinations, based upon their
impact on user and device security (unique because they weren’t counted twice for permission
combinations reversed e.g. P1 with P2 = high risk, P2 with P1 is also high risk). A total of 301 unique
low risk permission combinations were identified. Using the matrix the sampled applications were
analysed and 61 of the 69 sampled applications were identified to be high risk and 7 were considered
low risk with 1 application having equal amounts of high and low risk permission combinations. 19 of
the 35 high risk permissions included INTERNET, GET_ACCOUNTS, MANAGE_ACCOUNTS,
MANAGE_DOCUMENTS,
MOUNT_UNMOUNT_FILESYSTEMS,
SEND_SMS,
RECORD_AUDIO and WIRTE_EXTERNAL_STORAGE showing a trend in the matrix and analysis
of the applications. While this analysis is completely contextual, the user does not receive enough
information about the permissions they are installing during installation, enabling them to understand
the implications of the permissions in an application. Android need to increase all permission
documentation for developers, to enable them to understand the minimum amount of permissions
required to build a safe functional application. While users need a more technical description, which
describes how the application uses these permissions to interact with their device and their
information. While Android 6.0 Marshmallow, discussed in section 2.3.5, has seen Android’s
permission model progress, it still requires a finer granulation of permissions, with clear direction of
use for developers and users alike. Enck (2011) proposed a tool called ‘Kirin’ which could break down
an application’s manifest file into combinations of dangerous functionality, including the permissions
used to perform it. 311 free Android applications were analysed across different Android market
categories and their derived rule identified 10 applications for further analysis. Enck (2011) stated,
“Android’s install-time permissions inform the user what an application can access, they do not
abstract the risk associated with specific combinations of permissions. Kirin uses both permissions and
action strings listed in the application’s package manifest to infer an upper bound on its functionality.
Kirin modifies Android’s application installer and can be used to prevent application installation or to
display statements of risk (rather than permissions at install-time).” It is clear from this that Android
needs to provide users with more technical descriptions of how an application can affect their devices
security, rather than simply detailing what an application can do. The risk analysis matrix produced for
this project could be expanded to include all official Android permissions and used to generate
Page 97 of 137
The University of Derby
Department of Computing and Mathematics
statements of risks for all available Android applications, providing users with the worst case scenario
of risk for all known Android applications.
5.2 Dataset Limitations
This section identifies and discusses the limitations of the projects findings, including
discussion of analysis techniques and data validity.
One of the main limitations of this projects design is its overall sample size. Previous
discussion of related work has provided samples of complete application marketplaces, with thousands
of analysed applications. This project collected a very small sample of 69 applications, from 23 of
Google Play Store categories. To obtain complete and comprehensive findings of the Google Play
Store a larger sample of applications could have been collected from all 29 of Google Play Stores
categories. While 69 applications show a very concise selection of applications, further applications
could have been sampled from third party marketplaces or even malicious marketplaces to compare
and contrast application datasets and designs.
Another limitation of this project was its lack of automation. Automation would have provided
methods of sampling and analysing, with capabilities of generating a large application dataset with
recognised and proven methods of analysis. The manual sampling, installation, parsing and analysis
were very time consuming and open to human error. The potential extra time gained by using
automated analysis tools could have allowed for further and more in depth analysis of Android’s
permission model and also provide methods for easier duplication. This is an aspect of the project,
which could have made collection and data analysis easier, but it does not affect the quality of the
projects findings. While this stage is completely contextual, it provides a different approach to
previous methods of analysis of Android’s permission model. Further static and dynamic analysis
techniques could have been used to further validate the results of this project, to understand how the
sampled applications used defined permissions during run-time. Additionally no methods of third
party permission analysis was researched and potentially this could have been used to collaborate with
data collected from the other sources of analysis, potentially identifying areas for further research.
Finally, the high risk permission combinations discussed in section 4.3 were sampled from the
initial 78 unique Android permissions. A statement of risk could have been generated for all known
documented Android permissions, so that the risk analysis matrix reflected a level of risk for all
combinations of permissions. Further analysis of how third party permissions impact on the user and
device security and risk levels associated with user confidentiality, data integrity and availability,
could be consider for future areas of research.
Page 98 of 137
The University of Derby
Department of Computing and Mathematics
5.3 Conclusion of Findings
In recent years extensive research has been undertaken relating to Android’s permission model
and while Android have made progress in the way users and developers design and interact with
applications, as discussed in section 2.3.5, there are still ongoing issues which need addressing. One
reoccurring issue identified by all of the research relating to Android is Google’s lack of official
documentation. There is a sufficient amount of documentation regarding application architecture and
security, but the documentation for official Android permissions is very limited and causes confusion
amongst many developers. The repetition of requested permissions, spelling errors or a general
misconception of Android permissions is leaving developers creating functionally incorrect or overprivileged applications, increasing the risk on user devices. While Android deprecates permissions
with almost every operating system update, documentation does not reflect these changes, allowing
developers to use old irrelevant permissions. Android have attempted to minimise permission groups
in their recent 6.0 Marshmallow update, however, the request from developers and researchers to
produce a finer granularity of permissions is still a pertinent topic and was replicated in this projects
findings. The differences in similar purpose permissions (e.g. ACCESS_COARSE_LOCATION and
ACCESS_FINE_LOCATION) are so small it is confusing to understand why Android has not
attempted to condense the permissions into more manageable groups. The permission model is tightly
integrated into the Android operating system and would require a rollback of millions of applications
to implement the correct changes and functionality, which Android may not be prepared to do. The
users of Android applications are the priority of Android and it is clear that user’s level of technical
understanding is minimal in the mobile community and the permission descriptions currently provided
by Android reflect this. However, in recent years users have started to become more aware of what
their mobile device can access and they are taking more control and requesting more technical
information and security. The findings of this project clearly identified different levels of risk in
Android permission combinations that users may not be aware of and other researchers have backed
up these findings by identifying different behaviours of applications based upon their permissions.
Going forward it is important that Android develop a more technical description of how an
application’s permissions will interact with a user’s device, rather than providing a simple description
of what a permission does. The users of Android devices are slowly becoming more aware and taking
more responsibility of the access an application can have over their device, however, it is a long road
ahead until a user can feel completely safe about the applications they download and interact with and
the procedures and designs developers use to create them.
Page 99 of 137
The University of Derby
Department of Computing and Mathematics
Chapter 6
6. Conclusions and Recommendations
This chapter discusses the overall conclusion of the project, section 6.1 discusses whether the
project met its aims and objectives, section 6.2 discusses the recommendations of further research
presented from the projects findings and section 6.3 provides a personal reflection on how the project
was managed and completed.
6.1 Conclusion
This project sampled 69 applications from the Google Play Store which were analysed. Subcategories of applications were identified and analysed revealing not only potential over-privileged
applications, but the differences in application designs, including duplicate, deprecated or erroneous
permissions. 35 high risk permissions were identified based upon their abilities to access device
hardware and user information. From this a risk analysis matrix was created to analyse the risk levels
associated with combinations of Android permissions. These methods of analysis identified clear
trends in developer’s usage of Android’s permissions model.
The aim of the project was to analyse and evaluate Android’s permission model, specifically
to evaluate the relationship of permissions between similar purpose sub-categories of applications and
the potential levels of risk associated with different combinations of permissions. The objectives of
this project were to conduct a literature review of related work, collect a sample of Android
applications, evaluate their permissions and compare the findings to other research. A broad literature
review of the Android operating system and permission model was conducted, identifying different
methods of analysis and areas for improvement. While the sample size of this project may have been
considered small and the methods of analysis and collection completely manual, the findings have
presented new methods of analysis for Android permissions and can be considered as a further
extension to existing research. The limitations of this project have been critically analysed and have
identified clear areas for further research.
6.2 Recommendations and Future Work
This project has identified a different approach of analysis for Android’s permission model,
and outlines clear findings, discussed in chapter 5. However, there are clearly areas that need further
research and discussion and the following section explores the potential direction this project could
take and formulates a proposal for future research.
Page 100 of 137
The University of Derby
Department of Computing and Mathematics
One of the noticeable limitations identified in chapter 5 was this project’s sampled application
dataset. With a sample size of 69 this project presented a very limited view of the Google Play Store.
It is recommended that future work would take a much larger sample selection, and preferably the
entirety of an application marketplace. This would provide a larger dataset to compare and analyse,
and would also provide more accurate results to provide trends of use and permission usage.
Extending the sample selection to other third party marketplaces, including potentially malicious
application marketplaces, would provide a wider selection of applications, which could be sampled
and analysed based upon different application designs. The same Analysis methods used in this project
could be used for these datasets of applications, to compare and contrast findings of official Google
applications, third party applications and malicious applications.
As covered in section 4.1, third party permissions were not analysed in this project’s analysis
but as third party permissions were collected in this dataset, further possible analysis using the same
methods of analysis could be used to investigate how third party permissions effect application designs
in sub-categories of applications, as well as investigating the potential risk levels of combinations of
Android’s official permissions and third party permissions. However, it should be noted that Android
do not provide any documentation on third party permissions, other than how they are designed, which
could be detrimental for any further analysis.
The project’s data collection and analysis was completely manual. Future recommendations
would include the use of automation techniques to enhance the projects analysis. While there are tools
on the market to automatically install and parse an applications .apk file, it could be beneficial to
design a tool which could record the parameters discussed in sections 4.2 and 4.3, which could
automatically categorize applications based upon their design traits and permission risk combinations.
Further static and dynamic testing techniques would need to be developed to reinforce the findings of
this project. While an application is running, the correct API calls could be monitored to determine
exactly how an application uses the permissions the developer has requested.
Finally the risk analysis matrix designed in section 4.3, created a new method of analysing
Android permission combinations, while only 35 specific Android permissions were compared, the
majority of documented permissions were not included. This provides further potential investigations
for this project’s findings, by creating a matrix for all documented Android permissions and to
incorporate third party permissions. Previously discussed in section 4.3.1 and 4.3.2, different
permissions access different parts of a user’s device for different reasons. While this project presented
a risk matrix for high risk permission combinations, which control device hardware and have access to
user information, further matrices could be created based upon the impact to user confidentiality,
integrity and availability, realistically providing a more definite way of providing an application with
Page 101 of 137
The University of Derby
Department of Computing and Mathematics
an overall risk level. This would help in educating both users and developers as to what exactly the
applications are requesting access to and the associated levels of risk.
6.3 Personal Reflection
This project was originally designed to explore and analyse the security implications of
different mobile device operating systems. Initial research into this area revealed a very time
consuming and broad topic, completely outside of the scope of this undergraduate dissertation and
further refinement of this idea led to the comprehensive research undertaken in the area of Android.
With a completion date of just under eight months, it was vital that this project produced a clear
structure to follow and relevant research that provided the means to critique findings from previous
research. With a few months of research undertaken it was decided that Android’s permission model
would be the focal point of this project. Unfortunately this took longer than expected and left less time
to focus on methodologies, tools and techniques to analyse Android permissions. Further implications
were the availability and access of tools to analyse the data, with the majority of third party tools
having little to no user documentation and requiring a great technical understanding. These were
quickly overcome and the project found clear methods of sampling and analysing Android
applications.
Overall the project was concisely managed with clear timed objectives and milestones.
Regular e-mail communication and meetings were organised with the project’s supervisor and advice
was taken regularly. This project was a challenging learning experience, which tested the ability to
research a specific area of development and produce findings which could be compared, contrasted
and critiqued with previous research. While this project could have taken a different direction and
produced a larger set of results, the work undertaken has been produced with integrity and the findings
can be used for further research.
Page 102 of 137
The University of Derby
Department of Computing and Mathematics
References
Amadeo, R. (2015) Android 6.0 Marshmallow, thoroughly reviewed. [Online]. Ars Technica.
Available at: http://arstechnica.com/gadgets/2015/10/android-6-0-marshmallow-thoroughlyreviewed/5/ (Accessed: 22 February 2016).
Anderson, B. (2013) Understanding the Android File Hierarchy [Online]. Available at:
http://www.all-things-android.com/content/understanding-android-file-hierarchy (Accessed: 16
February 2016).
Android Architecture. (2016). Android Interfaces and Architecture | Android Open Source Project.
[Online]. Source.android.com. Available at: https://source.android.com/devices/index.html (Accessed:
6 January 2016).
Android Application Signing. (2016) Signing Your Applications | Android Developers. [Online].
Developer.android.com. Available at: http://developer.android.com/tools/publishing/app-signing.html
(Accessed: 8 January 2016).
Android Central, (2015) Google Play Store. [Online]. Available at:
http://www.androidcentral.com/google-play-store (Accessed: 11 January 2016).
Android Compatibility, (2016) Android Compatibility | Android Open Source Project. [Online].
Source.android.com. Available at: https://source.android.com/compatibility/index.html (Accessed: 11
January 2016).
Android Declaring Permissions, (2016) Declaring Permissions | Android Developers. [Online].
Available at: http://developer.android.com/training/permissions/declaring.html (Accessed: 23
February 2016).
Android Best Practices, (2016) Permissions Best Practices | Android Developers. [Online]. Available
at: http://developer.android.com/training/permissions/best-practices.html (Accessed: 23 February
2016).
Android Developer (2016) Application Fundamentals | Android Developers. [Online].
Developer.android.com. Available at:
http://developer.android.com/guide/components/fundamentals.html (Accessed: 8 January 2016).
Android History (2016) Android - History. [Online]. Available at: https://www.android.com/history/
(Accessed: 6 January 2016).
Android Intent. (2016) Intents and Intent Filters | Android Developers. [Online].
Developer.android.com. Available at: http://developer.android.com/guide/components/intentsfilters.html (Accessed: 8 January 2016).
Android Kernel Security. (2016) System and kernel security | Android Open Source Project. [Online].
Source.android.com. Available at: https://source.android.com/security/overview/kernel-security.html
(Accessed: 8 January 2016).
Page 103 of 137
The University of Derby
Department of Computing and Mathematics
Android Manifest. (2016) App Manifest | Android Developers.[Online]. Developer.android.com.
Available at: http://developer.android.com/guide/topics/manifest/manifest-intro.html (Accessed: 15
February 2016).
Android Manifest.Permission, (2016) Manifest.permission | Android Developers.[Online]. Available
at: http://developer.android.com/reference/android/Manifest.permission.html (Accessed: 16 February
2016).
Android Marshmallow, (2016) Android – Marshmallow.[Online]. Available at:
https://www.android.com/versions/marshmallow-6-0/?gclid=CjwKEAiAgKu2BRDu1OGw3KXokwSJAB_Yy2QVhdelA0Y2awKEncwMwxQp8_wTKfH8FlO_KG2N9pWWBoCp_Pw_wcB
(Accessed: 22 February 2016).
Android Permission, (2016) <permission> | Android Developers.[Online]. Available at:
http://developer.android.com/guide/topics/manifest/permission-element.html (Accessed: 8 January
2016).
Android Run-Time Permissions, (2016) Requesting Permissions at Run Time | Android Developers.
[Online]. Available at: http://developer.android.com/training/permissions/requesting.html (Accessed:
23 February 2016).
Android SDK. (2016) Download Android Studio and SDK Tools | Android Developers. [Online].
Available at: http://developer.android.com/sdk/index.html (Accessed: 23 March 2016).
Android Security, (2016) Security | Android Open Source Project. [Online]. Available at:
https://source.android.com/security/index.html (Accessed: 6 January 2016).
Android Security Tips, (2016) Security Tips | Android Developers. [Online]. Available at:
http://developer.android.com/training/articles/security-tips.html (Accessed: 8 January 2016).
Android Source Code. (2016) The Android Source Code | Android Open Source Project. [Online].
Source.android.com. Available at: https://source.android.com/source/index.html (Accessed: 6 January
2016).
Android System Permissions. (2016) System Permissions | Android Developers. [Online].
Developer.android.com. Available at:
http://developer.android.com/guide/topics/security/permissions.html (Accessed: 22 February 2016).
Android Tools. (2016) Building and Running Overview | Android Developers. [Online].
Developer.android.com. Available at: http://developer.android.com/tools/building/index.html
(Accessed: 8 January 2016).
Apktool. (2016) Apktool - A tool for reverse engineering Android apk files. [Online]. Available at:
http://ibotpeaches.github.io/Apktool/ (Accessed 23 Mar. 2016).
AVG, (2016). AVG Antivirus for Android | Free Mobile Antivirus App. [Online]. Available at:
http://www.avg.com/gb-en/antivirus-for-android (Accessed: 8 January 2016).
Barrera, D., Kayacik, H., Oorschot van, P. and Somayaji, A. (2010) A Methodology for Empirical
Analysis of Permission-based Security Models and its Application to Android. Proceedings of the 17th
ACM conference on Computer and Communications Security, pp.73-84, ACM Publish, doi:
10.1145/1866307.1866317 (Accessed: 16 February 2016).
Page 104 of 137
The University of Derby
Department of Computing and Mathematics
Boutet, J., (2010) SANS Institute InfoSec Reading Room – Malicious Android Applications: Risks and
Exploitation. [Online]. Available at: https://www.sans.org/readingroom/whitepapers/threats/malicious-android-applications-risks-exploitation-33578 (Accessed: 12
January 2016).
Birch, J. (2015) Exploring the new Android Permissions Model — ribot labs. [Online]. Available at:
https://labs.ribot.co.uk/exploring-the-new-android-permissions-model-ba1d5d6c0610#.je2hrl1iv
(Accessed: 23 February 2016).
Campbell, D. and Stanley, J. (1963) Experimental and quasi-experimental designs for research and
teaching. In Gage (Ed.), Handbook on research on teaching. Chicago: Rand McNally & Co., 1963.
Cannings, R., (2011) Exercising our remote application removal feature. [Online]. Available:
http://android-developers.blogspot.com/2010/06/ exercising-our-remote-application.html (Accessed: 8
January 2016).
Cannings, R., (2011) An update on android market security. [Online]. Available:
http://googlemobile.blogspot.com/2011/03/ update-on-android-market-security.html (Accessed: 8
January 2016).
Chin, E., Felt, A., Greenwood, K. and Wagner, D. (2011) Analyzing inter-application communication
in Android. Proceedings of the 9th international conference on Mobile systems, applications, and
services - MobiSys '11, pp. 239-252, ACM Publish, doi:10.1145/1999995.2000018 (Accessed: 28
October 2015).
CVE, (2016) Google Android : CVE security vulnerabilities, versions and detailed reports. [Online].
Available at: http://www.cvedetails.com/product/19997/Google-Android.html?vendor_id=1224
(Accessed: 12 January 2016).
Delac, G., Silic, M., and Krolo, J., (2011) Emerging security threats for mobile platforms ,in MIPRO,
2011 Proceedings of the 34th International Convention , pp.1468-1473, 23-27 May 2011 (Accessed:
12 January. 2016).
Dönmez, D. (2015) Social science methods for empirical data collection and analysis. [Online].
Available at: C:/Users/Finn%20B-E/Downloads/handout_MethodsSession_DDonmez.pdf (Accessed:
7 March 2016).
Dobie, A., Holly, R., Hildenbrand, J., and Martonik, A. (2015) Android Pre-History. [Online].
Available at: http://www.androidcentral.com/android-pre-history (Accessed: 6 January 2016).
eMarketer, (2015) Smartphone Users Worldwide Will Total 1.75 Billion in 2014 - eMarketer. [Online]
Available at: http://www.emarketer.com/Article/Smartphone-Users-Worldwide-Will-Total-175Billion-2014/1010536 (Accessed: 24 October 2015).
Enck, W. (2011) Defending user against smartphone apps: techniques and future directions. In
Proceedings of the 7th international conference on Information Systems Security, pp. 49-70, SpringerVerlag Berlin, doi:10.1007/978-3-642-25560-1 3 (Accessed: 26 February 2016).
Enck, W., Gilbert, P., Chun, B., Cox, P., Jung, J., McDaniel, P., and Seth, A. N. (2010) TaintDroid:
An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones. In Proc. of
Page 105 of 137
The University of Derby
Department of Computing and Mathematics
the 9th USENIX Symp. on Operating Systems Design and Implementation (OSDI) (2010) (Accessed:
14 January 2016).
Explorable. (2016) Empirical Research - Based on the Scientific Method. [Online]. Available at:
https://explorable.com/empirical-research (Accessed: 7 March 2016).
Felt, A., Chin, E., Hanna, S., Song, D. and Wagner, D. (2011) Android permissions demystified.
Proceedings of the 18th ACM conference on Computer and communications security - CCS '11, pp.
627-638, ACM Publish, doi:10.1145/2046707.2046779 (Accessed: 28 October 2015).
Felt, A and Wagner. D., (2011) Phishing on mobile devices. In Web 2.0 Security and Privacy, 2011.
[Online]. Available: http://w2spconf.com/ 2011/papers/felt-mobilephishing.pdf (Accessed: 12 January
2016).
Fisher, R.A (1935) The design of experiments (1st ed.) London: Oliver & Boyd, 1935.
Gartner, (2015) Gartner Says by 2017, Mobile Users Will Provide Personalized Data Streams to More
Than 100 Apps and Services Every Day. [Online]. Available at:
http://www.gartner.com/newsroom/id/2654115 (Accessed: 24 October 2015).
Goodin, D. (2016) Malicious apps in Google Play made unauthorized downloads, sought root.
[Online]. Ars Technica. Available at: http://arstechnica.com/security/2016/01/malicious-apps-ingoogle-play-made-unauthorized-downloads-sought-root/ (Accessed: 8 January 2016).
Google Developer Content Policy, (2016) Google Play – Developer Content Policy. [Online].
Available at: https://play.google.com/about/developer-content-policy.html (Accessed: 8 January
2016).
Google Developer Distribution Agreement, (2016) Google Play - Developer distribution agreement.
[Online]. Available: http: //www.android.com/us/developer-distribution-agreement.html (Accessed: 8
January 2016).
Google Security Report, (2014) Google Security Report [Online]. Available at:
https://static.googleusercontent.com/media/source.android.com/en//security/reports/Google_Android_
Security_2014_Report_Final.pdf (Accessed: 12 January 2016).
Grace. M., Zhou. Y., Zhang. Q., Zhou. S., and Jiang. X., (2012) RiskRanker: Scalable and Accurate
Zero-day Android Malware Detection. In Proceedings of the 10th international conference on Mobile
systems, applications and services, pp. 281-294, ACM Publish, doi>10.1145/2307636.2307663
(Accessed: 15 January 2016).
Grace, M., Zhou, Y., Wang, Z., and Jiang, ., (2012) Systematic Detection of Capability Leaks in Stock
Android Smartphones [Online]. Available at:
http://www.cs.fsu.edu/~zwang/files/NDSS12_Woodpecker.pdf (Accessed: 12 January 2016).
IDC, (2015) IDC: Smartphone OS Market Share. [Online]. Available at:
http://www.idc.com/prodserv/smartphone-os-market-share.jsp (Accessed: 25 October 2015).
Jang, W., Cho, S., Lee, H., Ju, H., and Kim, J. (2011) Rooting attack detection method on the Androidbased smart phone, in Computer Science and Network Technology (ICCSNT), 2011 International
Conference on , vol.1, pp.477-481, 24-26 Dec. 2011
doi: 10.1109/ICCSNT.2011.6182000 (Accessed: 14 January 2016).
Page 106 of 137
The University of Derby
Department of Computing and Mathematics
Jiang, X. (2011) New DroidKungFu Variants -- Again!. [Online]. Available at:
https://www.csc.ncsu.edu/faculty/jiang/DroidKungFu3/ (Accessed: 12 January 2016).
Langford, J., (2003) Implementing Least Privilege at your Enterprise [Online]. Available at:
https://www.sans.org/reading-room/whitepapers/bestprac/implementing-privilege-enterprise-1188
(Accessed: 13 January 2016).
Lineberry, A., Richardson, D., and Wyatt, T., (2010) These aren’t the permissions you are looking for.
[Online]. Available: http: //dtors.files.wordpress.com/2010/09/blackhat-2010-final.pdf (Accessed: 8
January 2016).
Lockheimer, H., (2012) Android and security. [Online]. Available: http:
//googlemobile.blogspot.com/2012/02/android-and-security.html (Accessed: 8 January 2016).
Lookout, (2014) 2014 Mobile Threat Report [Online]. Available at:
https://www.lookout.com/img/images/Consumer_Threat_Report_Final_ENGLISH_1.14.pdf
(Accessed: 7 January 2016).
Mahmood, R., Esfahani, N., Kacem, T., Mirzaei, N., Malek, S., Stavrou, A., (2012) A whitebox
approach for automated security testing of Android applications on the cloud, in Automation of
Software Test (AST), 2012 7th International Workshop on , pp.22-28, IEEE Publish, doi:
10.1109/IWAST.2012.6228986 (Accessed: 28 October 2015).
Mintel, (2015) Digital Trends Spring – UK – March 2015 *Online Security. [Online]. Available at:
http://academic.mintel.com.ezproxy.derby.ac.uk/display/732276/?highlight (Accessed: 25 October
2015).
Microsoft, (2016) SIR: Glossary. [Online]. Available at:
https://www.microsoft.com/security/sir/glossary/drive-by-download-sites.aspx (Accessed: 12 January
2016).
Morris, J. (2013) Overview of Linux Kernel Security Features | Linux.com. [Online]. Linux.com | The
source for Linux Information. Available at: https://www.linux.com/learn/docs/727873-overview-oflinux-kernel-security-features/ (Accessed: 8 January 2016).
Octeau. D, McDaniel .P, Jha . S, Bartel. A, Bodden. E, Klein. J, and Y. L. Traon., (2013) Effective
inter-component communication mapping in android with epicc: An essential step towards holistic
security analysis. In Proceedings of the 22Nd USENIX Conference on Security, pp. 543–558, 2013
(Accessed: 12 January 2016).
Pieterse, H.; Olivier, M.S (2012) Android botnets on the rise: Trends and characteristics, Information
Security for South Africa (ISSA), pp.1-5, IEEE Publish, doi: 10.1109/ISSA.2012.6320432.
(Accessed: 28 October 2015).
Prasad, C. (2016) Apk Extractor [Online]. Available at
https://play.google.com/store/apps/details?id=com.ext.ui&hl=en_GB (Accessed: 23 March 2016).
Rosen, S., Qian, Z. and Mao, Z. (2013) AppProfiler: a flexible method of exposing privacy-related
behavior in android applications to end users. In Proceedings of the third ACM conference on Data
and application security and privacy, pp. 221-232, ACM Publish, doi:10.1145/2435349.2435380
(Accessed: 26 February 2016).
Page 107 of 137
The University of Derby
Department of Computing and Mathematics
RStudio. (2016) RStudio. [Online]. Available at: https://www.rstudio.com/products/rstudio/
(Accessed: 23 March 2016).
Sufatrio,. Tan, D., Chua, T., and Thing. V., (2015) Securing Android: A Survey, Taxonomy, and
Challenges. ACM Comput. Surv. 47, 4, Article 58 (May 2015), 45 pages.
DOI=http://dx.doi.org/10.1145/2733306 (Accessed: 12 January 2016).
Symantec, (2016) Android.Rufraud Technical Details | Symantec. [Online]. Available at:
http://www.symantec.com/security_response/writeup.jsp?docid=2011-121306-2304-99&tabid=2
(Accessed: 12 January 2016).
Thalgott, F. (2014) MD5 Checker [Online]. Available at:
https://play.google.com/store/apps/details?id=com.fab.md5&hl=en_GB (Accessed: 23 March 2016).
Titcomb, J. (2015) Android security breach puts millions at risk of smartphone hijacking. [Online].
Telegraph.co.uk. Available at: http://www.telegraph.co.uk/technology/internetsecurity/11788184/Android-security-breach-puts-millions-at-risk-of-smartphone-hijacking.html
(Accessed: 25 October 2015).
Vidas, T., Christin, N., and Cranor, L., (2011) Curbing Android Permission Creep. [Online]. Available
at: https://www.andrew.cmu.edu/user/nicolasc/publications/VCC-W2SP11.pdf (Accessed: 14 January
2016).
Viennot, N. Garcia, E., and Nieh, J. (2014) A Measurement Study of Google Play. In Proceedings of
the 2014 ACM international conference on Measurements and modelling of computer systems (2014),
ACM, pp. 221-233 (Accessed: 14 January 2016).
Wain Yee Au, K., Zhou, Y., Huang, Z., and Lee, D., (2012) PScout: Analyzing the Android
Permission Specification. In Proceedings of the 19th ACM Conference on Computer and
Communications Security – CCS ’12, pp. 217-228, ACM Publish, doi:10.1145/2382196.2382222
(Accessed: 13 January 2016).
Wei, X., Gomez, L., Neamtiu, L., and Faloutsos, M. (2012) Permission Evolution in the Android
Ecosystem [Online] Available at: http://www.cs.ucr.edu/~neamtiu/pubs/acsac12wei.pdf (Accessed: 13
January 2016).
Wei, T., Jeng, A.B., Lee, H., Chih-How, C., and Tien, C., (2012) Android privacy, in Machine
Learning and Cybernetics (ICMLC), 2012 International Conference on , vol.5, pp.1830-1837, 15-17
July 2012, doi: 10.1109/ICMLC.2012.6359654 (Accessed: 12 January 2016).
Wieringa, R. (2014) Design Science Methodology for Information Systems and Software Engineering
– The Empirical Cycle. Part IV, pp 109-120, Springer Berlin Heidelberg, doi: 10.1007/978-3-66243839-8_10 (Accessed: 25 October 2015).
WinMD5Free. (2016) WinMD5 Free - Windows MD5 Utility Freeware. [Online]. Available at:
http://www.winmd5.com/ (Accessed: 23 March 2016).
Zheng, C., Zhu, S., Daj, S., Gu, G., Gong, X., Han, X., and Zou, W. (2012) Smartdroid: an automatic
system for revealing uibased trigger conditions in android applications. In Proceedings of the second
ACM workshop on Security and privacy in smartphones and mobile devices (2012), ACM, pp. 93–
104 (Accessed: 14 January 2016).
Page 108 of 137
The University of Derby
Department of Computing and Mathematics
Zhou. Y, Wang. Z, Zhou. W, and Jiang. X. (2012) Hey, You, Get Off of My Market: Detecting
Malicious Apps in Official and Alternative Android Markets [Online]. Available at:
https://www.internetsociety.org/sites/default/files/07_5.pdf (Accessed: 15 January 2016).
Page 109 of 137
The University of Derby
Department of Computing and Mathematics
Appendices
Appendix A. Android Authorised Permissions
Permission Name
ACCESS_CHECKIN_PROPERTIES
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
ACCESS_LOCATION_EXTRA_COMMANDS
ACCESS_NETWORK_STATE
ACCESS_NOTIFICATION_POLICY
ACCESS_WIFI_STATE
ACCOUNT_MANAGER
ADD_VOICEMAIL
BATTERY_STATS
BIND_ACCESSIBILITY_SERVICE
BIND_APPWIDGET
BIND_CARRIER_MESSAGING_SERVICE
BIND_CARRIER_SERVICES
BIND_CHOOSER_TARGET_SERVICE
BIND_DEVICE_ADMIN
BIND_DREAM_SERVICE
BIND_INCALL_SERVICE
BIND_INPUT_METHOD
BIND_MIDI_DEVICE_SERVICE
Permission Description
Allows read/write access to the "properties" table in the checkin
database, to change values that get uploaded.
Allows an app to access approximate location.
Allows an app to access precise location.
Allows an application to access extra location provider
commands.
Allows applications to access information about networks.
Marker permission for applications that wish to access
notification policy.
Allows applications to access information about Wi-Fi networks.
Allows applications to call into AccountAuthenticators.
Allows an application to add voicemails into the system.
Allows an application to collect battery statistics.
Must be required by an AccessibilityService, to ensure that only
the system can bind to it.
Allows an application to tell the AppWidget service which
application can access AppWidget's data.
This constant was deprecated in API level 23. Use
BIND_CARRIER_SERVICES instead
The system process that is allowed to bind to services in carrier
apps will have this permission.
Must be required by a ChooserTargetService, to ensure that only
the system can bind to it.
Must be required by device administration receiver, to ensure that
only the system can interact with it.
Must be required by an DreamService, to ensure that only the
system can bind to it.
Must be required by a InCallService, to ensure that only the
system can bind to it.
Must be required by an InputMethodService, to ensure that only
the system can bind to it.
Must be required by an MidiDeviceService, to ensure that only
the system can bind to it.
Page 110 of 137
The University of Derby
BIND_NFC_SERVICE
BIND_NOTIFICATION_LISTENER_SERVICE
BIND_PRINT_SERVICE
BIND_REMOTEVIEWS
BIND_TELECOM_CONNECTION_SERVICE
BIND_TEXT_SERVICE
BIND_TV_INPUT
BIND_VOICE_INTERACTION
BIND_VPN_SERVICE
BIND_WALLPAPER
BLUETOOTH
BLUETOOTH_ADMIN
BLUETOOTH_PRIVILEGED
BODY_SENSORS
BROADCAST_PACKAGE_REMOVED
BROADCAST_SMS
BROADCAST_STICKY
BROADCAST_WAP_PUSH
CALL_PHONE
CALL_PRIVILEGED
CAMERA
Department of Computing and Mathematics
Must be required by a HostApduService or OffHostApduService
to ensure that only the system can bind to it.
Must be required by an NotificationListenerService, to ensure
that only the system can bind to it.
Must be required by a PrintService, to ensure that only the system
can bind to it.
Must be required by a RemoteViewsService, to ensure that only
the system can bind to it.
Must be required by a ConnectionService, to ensure that only the
system can bind to it.
Must be required by a TextService (eg SpellCheckerService) to
ensure that only the system can bind to it.
Must be required by a TvInputService to ensure that only the
system can bind to it.
Must be required by a VoiceInteractionService, to ensure that
only the system can bind to it.
Must be required by a VpnService, to ensure that only the system
can bind to it.
Must be required by a WallpaperService, to ensure that only the
system can bind to it.
Allows applications to connect to paired bluetooth devices.
Allows applications to discover and pair bluetooth devices.
Allows applications to pair bluetooth devices without user
interaction, and to allow or disallow phonebook access or
message access.
Allows an application to access data from sensors that the user
uses to measure what is happening inside his/her body, such as
heart rate.
Allows an application to broadcast a notification that an
application package has been removed.
Allows an application to broadcast an SMS receipt notification.
Allows an application to broadcast sticky intents.
Allows an application to broadcast a WAP PUSH receipt
notification.
Allows an application to initiate a phone call without going
through the Dialer user interface for the user to confirm the call.
Allows an application to call any phone number, including
emergency numbers, without going through the Dialer user
interface for the user to confirm the call being placed.
Required to be able to access the camera device.
Page 111 of 137
The University of Derby
CAPTURE_AUDIO_OUTPUT
CAPTURE_SECURE_VIDEO_OUTPUT
CAPTURE_VIDEO_OUTPUT
CHANGE_COMPONENT_ENABLED_STATE
CHANGE_CONFIGURATION
CHANGE_NETWORK_STATE
CHANGE_WIFI_MULTICAST_STATE
CHANGE_WIFI_STATE
CLEAR_APP_CACHE
CONTROL_LOCATION_UPDATES
DELETE_CACHE_FILES
DELETE_PACKAGES
DIAGNOSTIC
DISABLE_KEYGUARD
DUMP
EXPAND_STATUS_BAR
FACTORY_TEST
FLASHLIGHT
GET_ACCOUNTS
GET_ACCOUNTS_PRIVILEGED
GET_PACKAGE_SIZE
GET_TASKS
GLOBAL_SEARCH
INSTALL_LOCATION_PROVIDER
INSTALL_PACKAGES
INSTALL_SHORTCUT
INTERNET
Department of Computing and Mathematics
Allows an application to capture audio output.
Allows an application to capture secure video output.
Allows an application to capture video output.
Allows an application to change whether an application
component (other than its own) is enabled or not.
Allows an application to modify the current configuration, such
as locale.
Allows applications to change network connectivity state.
Allows applications to enter Wi-Fi Multicast mode.
Allows applications to change Wi-Fi connectivity state.
Allows an application to clear the caches of all installed
applications on the device.
Allows enabling/disabling location update notifications from the
radio.
Allows an application to delete cache files.
Allows an application to delete packages.
Allows applications to RW to diagnostic resources.
Allows applications to disable the keyguard if it is not secure.
Allows an application to retrieve state dump information from
system services.
Allows an application to expand or collapse the status bar.
Run as a manufacturer test application, running as the root user.
Allows access to the flashlight.
Allows access to the list of accounts in the Accounts Service.
Allows access to the list of accounts in the Accounts Service.
Allows an application to find out the space used by any package.
This constant was deprecated in API level 21. No longer
enforced.
This permission can be used on content providers to allow the
global search system to access their data.
Allows an application to install a location provider into the
Location Manager.
Allows an application to install packages.
Allows an application to install a shortcut in Launcher.
Allows applications to open network sockets.
Allows an application to call killBackgroundProcesses(String).
KILL_BACKGROUND_PROCESSES
Page 112 of 137
The University of Derby
Department of Computing and Mathematics
LOCATION_HARDWARE
Allows an application to use location features in hardware, such
as the geofencing api.
MANAGE_DOCUMENTS
Allows an application to manage access to documents, usually as
part of a document picker.
MASTER_CLEAR
MEDIA_CONTENT_CONTROL
MODIFY_AUDIO_SETTINGS
MODIFY_PHONE_STATE
MOUNT_FORMAT_FILESYSTEMS
MOUNT_UNMOUNT_FILESYSTEMS
NFC
PACKAGE_USAGE_STATS
PERSISTENT_ACTIVITY
PROCESS_OUTGOING_CALLS
READ_CALENDAR
READ_CALL_LOG
READ_CONTACTS
READ_EXTERNAL_STORAGE
Not for use by third-party applications.
Allows an application to know what content is playing and
control its playback.
Allows an application to modify global audio settings.
Allows modification of the telephony state - power on, mmi, etc.
Allows formatting file systems for removable storage.
Allows mounting and unmounting file systems for removable
storage.
Allows applications to perform I/O operations over NFC.
Allows an application to collect component usage statistics.
Declaring the permission implies intention to use the API and the
user of the device can grant permission through the Settings
application.
This constant was deprecated in API level 9. This functionality
will be removed in the future; please do not use. Allow an
application to make its activities persistent.
Allows an application to see the number being dialed during an
outgoing call with the option to redirect the call to a different
number or abort the call altogether.
Allows an application to read the user's calendar data.
Allows an application to read the user's call log.
Allows an application to read the user's contacts data.
Allows an application to read from external storage.
READ_FRAME_BUFFER
Allows an application to take screen shots and more generally get
access to the frame buffer data.
READ_INPUT_STATE
This constant was deprecated in API level 16. The API that used
this permission has been removed.
READ_LOGS
READ_PHONE_STATE
READ_SMS
READ_SYNC_SETTINGS
READ_SYNC_STATS
READ_VOICEMAIL
REBOOT
RECEIVE_BOOT_COMPLETED
Allows an application to read the low-level system log files.
Allows read only access to phone state.
Allows an application to read SMS messages.
Allows applications to read the sync settings.
Allows applications to read the sync stats.
Allows an application to read voicemails in the system.
Required to be able to reboot the device.
Allows an application to receive the
ACTION_BOOT_COMPLETED that is broadcast after the
system finishes booting.
Page 113 of 137
The University of Derby
Department of Computing and Mathematics
Allows an application to monitor incoming MMS messages.
RECEIVE_MMS
Allows an application to receive SMS messages.
RECEIVE_SMS
Allows an application to receive WAP push messages.
RECEIVE_WAP_PUSH
RECORD_AUDIO
REORDER_TASKS
REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
REQUEST_INSTALL_PACKAGES
RESTART_PACKAGES
SEND_RESPOND_VIA_MESSAGE
SEND_SMS
SET_ALARM
SET_ALWAYS_FINISH
SET_ANIMATION_SCALE
SET_DEBUG_APP
SET_PREFERRED_APPLICATIONS
SET_PROCESS_LIMIT
SET_TIME
SET_TIME_ZONE
SET_WALLPAPER
SET_WALLPAPER_HINTS
SIGNAL_PERSISTENT_PROCESSES
STATUS_BAR
SYSTEM_ALERT_WINDOW
TRANSMIT_IR
UNINSTALL_SHORTCUT
UPDATE_DEVICE_STATS
Allows an application to record audio.
Allows an application to change the Z-order of tasks.
Permission an application must hold in order to use
ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
.
Allows an application to request installing packages.
This constant was deprecated in API level 8. The
restartPackage(String) API is no longer supported.
Allows an application (Phone) to send a request to other
applications to handle the respond-via-message action during
incoming calls.
Allows an application to send SMS messages.
Allows an application to broadcast an Intent to set an alarm for
the user.
Allows an application to control whether activities are
immediately finished when put in the background.
Modify the global animation scaling factor.
Configure an application for debugging.
This constant was deprecated in API level 7. No longer useful,
see addPackageToPreferred(String) for details.
Allows an application to set the maximum number of (not
needed) application processes that can be running.
Allows applications to set the system time.
Allows applications to set the system time zone.
Allows applications to set the wallpaper.
Allows applications to set the wallpaper hints.
Allow an application to request that a signal be sent to all
persistent processes.
Allows an application to open, close, or disable the status bar and
its icons.
Allows an app to create windows using the type
TYPE_SYSTEM_ALERT, shown on top of all other apps.
Allows using the device's IR transmitter, if available.
Allows an application to uninstall a shortcut in Launcher.
Allows an application to update device statistics.
Page 114 of 137
The University of Derby
USE_FINGERPRINT
USE_SIP
VIBRATE
WAKE_LOCK
WRITE_APN_SETTINGS
WRITE_CALENDAR
WRITE_CALL_LOG
WRITE_CONTACTS
WRITE_EXTERNAL_STORAGE
WRITE_GSERVICES
WRITE_SECURE_SETTINGS
WRITE_SETTINGS
WRITE_SYNC_SETTINGS
WRITE_VOICEMAIL
Department of Computing and Mathematics
Allows an app to use fingerprint hardware.
Allows an application to use SIP service.
Allows access to the vibrator.
Allows using PowerManager WakeLocks to keep processor from
sleeping or screen from dimming.
Allows applications to write the apn settings.
Allows an application to write the user's calendar data.
Allows an application to write (but not read) the user's contacts
data.
Allows an application to write the user's contacts data.
Allows an application to write to external storage.
Allows an application to modify the Google service map.
Allows an application to read or write the secure system settings.
Allows an application to read or write the system settings.
Allows applications to write the sync settings.
Allows an application to modify and remove existing voicemails
in the system.
Page 115 of 137
The University of Derby
Department of Computing and Mathematics
Appendix B. Google Play Store Application Categories
Google Play Store
Sub-category of
Application Categories
Applications
Android Wear
Books & Reference
Business
Comics
Communication
Education
Entertainment
Finance
Health & Fitness
Libraries& Demo
Lifestyle
Live Wallpaper
Media & Video
Medical
Music & Audio
News & Magazines
Personalisation
Photography
Productivity
Shopping
Social
Sports
Tools
Transport
Travel & Local
Weather
Widgets
Games
Action
Adventure
Arcade
Board
Page 116 of 137
The University of Derby
Department of Computing and Mathematics
Card
Casino
Casual
Educational
Music
Puzzle
Racing
Role Playing
Simulation
Sports
Strategy
Trivia
Word
Family
Ages 5 & Under
Ages 6-8
Ages 9 & Over
Popular
Characters
Action &
Adventures
Brain Games
Creativity
Education
Music and Video
Pretend Play
Page 117 of 137
The University of Derby
Department of Computing and Mathematics
Appendix C. Methodology Screenshots
Stage 1 – Sampling
The Google Play Store was accessed via a Google Chrome browser and the application categories
were identified.
Applications were chosen and sampled based on the parameters detailed in the methodology.
Page 118 of 137
The University of Derby
Department of Computing and Mathematics
The applications details including permissions stated by the Google Play Store were taken at this
point.
Stage 2 – Data Collection
Applications were sourced via the Google Chrome browser and installed directly from the Google
Play Store on the Samsung GT-I9100 Android 4.1.2 mobile device. A photo of the phone and
installation process is unavailable as the dataset was generated prior to this Appendices creation.
Once installed the ‘Apk Extractor’ application was used to extract the apk file onto the SD card.
Page 119 of 137
The University of Derby
Department of Computing and Mathematics
Once extracted the ‘MD5Checker’ was used on the apk files to generate a MD5 Hash Value.
The application apk files were then transferred and stored on my home computer via USB connection.
Page 120 of 137
The University of Derby
Department of Computing and Mathematics
The apk files were then ran on WinMD5Free to compare and contrast MD5 Hash Values. This process
was repeated with all 69 applications and the data was stored in a Microsoft Excel 2010 spreadsheet.
Using the ‘ApkTool’ and windows command line interface the apks were decompiled.
Page 121 of 137
The University of Derby
Department of Computing and Mathematics
This process was repeated with all 69 applications to acquire their AndroidManifest.xml files.
Page 122 of 137
The University of Derby
Department of Computing and Mathematics
Page 123 of 137
The University of Derby
Department of Computing and Mathematics
The AndroidManifest.xml files for each application were loaded into the Android SDK studio and the
permissions were parsed using the ‘Android Asset Packaging Tool (Aapt)’ dump function.
Page 124 of 137
The University of Derby
Department of Computing and Mathematics
Stage 3 – Data Filtering
The data from the previous stages was stored appropriately in a Microsoft Excel 2010 Spreadsheet
outlined in the methodology.
Tab 1
Tab 2
Page 125 of 137
The University of Derby
Department of Computing and Mathematics
Tab 3
Page 126 of 137
The University of Derby
Department of Computing and Mathematics
Appendix D. Unique Permission Frequency
ACCESS_NETWORK_STATE
INTERNET
WRITE_EXTERNAL_STORAGE
WAKE_LOCK
GET_ACCOUNTS
71 (102.8%)
69 (100%)
55 (79.7%)
47 (68.1%)
42 (60.8%)
38 (55.0%)
VIBRATE
ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION
ACCESS_WIFI_STATE
RECEIVE_BOOT_COMPLETED
READ_PHONE_STATE
READ_EXTERNAL_STORAGE
USE_CREDENTIALS
36 (52.1%)
33 (47.8%)
33 (47.8%)
31 (44.9%)
29 (42.0%)
26 (37.6%)
23 (33.3%)
21 (30.4%)
CAMERA
READ_CONTACTS
MANAGE_ACCOUNTS
READ_SYNC_SETTINGS
WRITE_SYNC_SETTINGS
AUTHENTICATE_ACCOUNTS
RECORD_AUDIO
20 (28.9%)
17 (24.6%)
17 (24.6%)
17 (24.6%)
15 (21.7%)
15 (21.7%)
13 (18.8%)
BILLING
SYSTEM_ALERT_WINDOW
READ_PROFILE
READ_SYNC_STATS
BROADCAST_STICKY
BLUETOOTH
CHANGE_WIFI_STATE
11 (15.9%)
10 (14.4%)
10 (14.4%)
9 (13.0%)
8 (11.5%)
8 (11.5%)
8 (11.5%)
NFC
WRITE_SETTINGS
MODIFY_AUDIO_SETTINGS
Page 127 of 137
8 (11.5%)
7 (10.1%)
The University of Derby
Department of Computing and Mathematics
READ_CALENDAR
GET_TASKS
WRITE_CONTACTS
BLUETOOTH_ADMIN
DISABLE_KEYGUARD
INSTALL_SHORTCUT
READ_SMS
WRITE_CALENDAR
ACCESS_LOCATION_EXTRA_COMMANDS
DOWNLOAD_WITHOUT_NOTIFICATION
READ_LOGS
READ_USER_DICTIONARY
RECEIVE_SMS
SUBSCRIBED_FEEDS_READ
SUBSCRIBED_FEEDS_WRITE
WRITE_EXTERNAL_LOCK
ACCESS_SUPERUSER
BODY_SENSORS
CALL_PHONE
CHANGE_NETWORK_STATE
CHECK_LICENSE
CLEAR_APP_CACHE
MANAGE_DOCUMENTS
READ_HISTORY_BOOKMARKS
SET_ALARM
UNINSTALL_SHORTCUT
USE_FINGERPRINT
WRITE_USER_DICTIONARY
BATTERY_STATS
BIND_WALLPAPER
BLUETOOTH_PRIVILEGED
Page 128 of 137
7 (10.1%)
6 (8.69%)
6 (8.69%)
5 (7.24%)
5 (7.24%)
5 (7.24%)
5 (7.24%)
5 (7.24%)
4 (5.79%)
4 (5.79%)
4 (5.79%)
3 (4.34%)
3 (4.34%)
3 (4.34%)
3 (4.34%)
3 (4.34%)
2 (2.89%)
2 (2.89%)
2 (2.89%)
2 (2.89%)
2 (2.89%)
2 (2.89%)
2 (2.89%)
2 (2.89%)
2 (2.89%)
2 (2.89%)
2 (2.89%)
2 (2.89%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
The University of Derby
Department of Computing and Mathematics
CHANGE_CONFIGURATION
CHANGE_WIFI_MULTICAST_STATE
FLASHLIGHT
GET_PACKAGE_SIZE
GLOBAL_SEARCH
MOUNT_UNMOUNT_FILESYSTEMS
PACKAGE_USAGE_STATS
PREVENT_POWER_KEY
RAISED_THREAD_PRIORITY
READ_SETTINGS
RESTART_PACKAGES
SEND_SMS
SET_DEBUG_APP
SET_WALLPAPER
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
1 (1.44%)
STORAGE
WRITE_APP_BADGE
WRITE_HISTORY_BOOKMARKS
Page 129 of 137
1 (1.44%)
1 (1.44%)
The University of Derby
Department of Computing and Mathematics
Appendix E. Unique Permissions Potential Dangers
Permissions that control device hardware:
Potential Danger
Permission
ACCESS_NETWORK_STATE
Can view the status of device networks.
BATTERY_STATS
Can modify collected battery statistics.
BIND_WALLPAPER
Can allow access to the system which binds
wallpapers to a device.
BLUETOOTH
Can turn bluetooth on and off and discover
connectable devices.
Can discover and pair bluetooth devices
without user knowledge.
BLUETOOTH_ADMIN
Can discover and pair bluetooth devices
without user interaction and allow or disallow
access to phonebook access or message access
BLUETOOTH_PRIVILEGED
Can make your device running slow or be
unstable by introducing memory leaks.
BROADCAST_STICKY
Could take pictures and videos without your
knowledge.
CAMERA
CHANGE_CONFIGURATION
Allows an application to modify your current
configurations.
CHANGE_NETWORK_STATE
Can modify, change or turn off network
connectivity.
Can check, read and confirm the license
information of an application from the license
verification library.
CHECK_LICENSE
DOWNLOAD_WITHOUT_NOTIFICATION
FLASHLIGHT
GET_PACKAGE_SIZE
GET_TASKS
GLOBAL_SEARCH
INSTALL_SHORTCUT
Allows the application to download files
through the download manager without the
users consent or notification.
Can control your camera flashlight.
Allows an application to find out the space
used by other installed apps.
Allows an app to find out what other
applications are running on the device.
Allows content providers to view and read data
on the global search system of the device (any
internet based browser)
Allow an app to put an icon or shortcut on
home screen.
Page 130 of 137
The University of Derby
Department of Computing and Mathematics
INTERNET
Allows an app to connect to Internet.
MODIFY_AUDIO_SETTINGS
MOUNT_UNMOUNT_FILESYSTEMS
Can modify device audio settings (volume,
routing, etc.).
Can mount or unmount removable file
systems!
NFC
Gives full access to Near-Field communication
options.
PACKAGE_USAGE_STATS
Allows an app to collect and read component
usage statistics.
PREVENT_POWER_KEY
Prevents the user turning off their device.
READ_LOGS
Allows an app to read system low files.
RECEIVE_BOOT_COMPLETED
Allows an app to run itself every time you start
your device.
Could allow closing of processes of other
applications.
RESTART_PACKAGES
SET_ALARM
Allows the opening of the alarm app on the
phone.
SET_DEBUG_APP
Allows an application to configure itself into
debugging mode (liable to changes and
adjustments).
SET_WALLPAPER
Could change your wallpaper.
SYSTEM_ALERT_WINDOW
Allows an app to show a popup window on top
of other apps.
Allows an app to uninstall a shortcut or icon
from the home screen.
UNINSTALL_SHORTCUT
VIBRATE
Allows control of the vibrate function on your
device.
WAKE_LOCK
It can prevent your device from going to sleep
mode (drain battery).
WRITE_EXTERNAL_LOCK
Allows the app to override the phones lock and
open.
Could modify or corrupt your system
configuration.
WRITE_SETTINGS
WRITE_SYNC_SETTINGS
Could change how your account data are
synced and backed up.
ACCESS_NETWORK_STATE
Can view the status of device networks.
Page 131 of 137
The University of Derby
Department of Computing and Mathematics
BATTERY_STATS
Can modify collected battery statistics.
BIND_WALLPAPER
Can allow access to the system which binds
wallpapers to a device.
BLUETOOTH
Can turn bluetooth on and off and discover
connectable devices.
Can discover and pair bluetooth devices
without user knowledge.
BLUETOOTH_ADMIN
Can discover and pair bluetooth devices
without user interaction and allow or disallow
access to phonebook access or message access
BLUETOOTH_PRIVILEGED
Can make your device running slow or be
unstable by introducing memory leaks.
BROADCAST_STICKY
Could take pictures and videos without your
knowledge.
CAMERA
CHANGE_CONFIGURATION
Allows an application to modify your current
configurations.
CHANGE_NETWORK_STATE
Can modify, change or turn off network
connectivity.
Can check, read and confirm the license
information of an application from the license
verification library.
CHECK_LICENSE
DOWNLOAD_WITHOUT_NOTIFICATION
FLASHLIGHT
GET_PACKAGE_SIZE
GET_TASKS
GLOBAL_SEARCH
INSTALL_SHORTCUT
INTERNET
Allows the application to download files
through the download manager without the
users consent or notification.
Can control your camera flashlight.
Allows an application to find out the space
used by other installed apps.
Allows an app to find out what other
applications are running on the device.
Allows content providers to view and read data
on the global search system of the device (any
internet based browser)
Allow an app to put an icon or shortcut on
home screen.
Allows an app to connect to Internet.
Page 132 of 137
The University of Derby
Department of Computing and Mathematics
Permissions that access user information:
Permission
Potential Danger
ACCESS_COARSE_LOCATION
Allows an app to determine your approximate
location.
Allows an app to determine your precise
location.
ACCESS_FINE_LOCATION
ACCESS_LOCATION_EXTRA_COMMANDS
Gives access to location connected provider
commands.
Allows an app to view Wi-Fi status and
information.
ACCESS_WIFI_STATE
Allows an app to authenticate credentials and
could trick you into revealing your password.
AUTHENTICATE_ACCOUNTS
Allows an application to directly bill you for
services through Google Play.
BILLING
Can read and change data gathered from body
sensors, including sensitive user data including
heart rates etc.
BODY_SENSORS
CALL_PHONE
Allows an app to call all phone numbers
(except emergency phone numbers).
CHANGE_WIFI_MULTICAST_STATE
Can discover and connect to a multicast
network (one-to-many or many-to-many
connections), sharing information with
multiple networks.
CHANGE_WIFI_STATE
Can connect or disconnect Wi-Fi connections.
CLEAR_APP_CACHE
Can clear the cache of other installed apps.
DISABLE_KEYGUARD
Allows an app to disable your
Password/PIN/Slide lock screen.
GET_ACCOUNTS
MANAGE_ACCOUNTS
MANAGE_DOCUMENTS
Allows access the list of device accounts.
Stores, reads and enters account details (i.e. emails, passwords, usernames) for repititive
entry.
Can access, move and read user documents.
READ_CALENDAR
Can read calendar events or in combination
with other permissions send it to other people.
READ_CONTACTS
Can read all contacts stored on your device.
READ_EXTERNAL_STORAGE
Allows an application to read from external
storage.
READ_HISTORY_BOOKMARKS
Can see what website you visit and read your
Page 133 of 137
The University of Derby
Department of Computing and Mathematics
bookmarks.
Access to unique identification numbers of
your device (IMEI, IMSI & Google 64bit ID).
READ_PHONE_STATE
READ_PROFILE
Allows read only access to phone state.
READ_SETTINGS
Allows an application to read from external
storage.
READ_SMS
Allows an application the capability to read all
your text messages.
READ_SYNC_SETTINGS
Allows an app to know if you have turned on
or off background data syncs (Facebook,
Gmail, etc.).
READ_SYNC_STATS
Allows an app to read synchronization stats of
your device.
Can read words added to your custom
dictionary.
READ_USER_DICTIONARY
Eavesdropping on phone calls and other voice
based communication!
RECORD_AUDIO
RECEIVE_SMS
Could read your SMS messages
SEND_SMS
Allows an app to send an SMS message.
SUBSCRIBED_FEEDS_READ
Allows an app to access RSS feeds you have
subscribed to.
SUBSCRIBED_FEEDS_WRITE
Allows an app to access RSS feeds you have
subscribed to.
USE_CREDENTIALS
Could request authentication tokens and use
the authentication credentials.
USE_FINGERPRINT
Allows an app to read and use the data
acquired from a fingertip.
WRITE_CALENDAR
Can add or change the events on your
calendar.
WRITE_CONTACTS
Can modify your contacts.
WRITE_EXTERNAL_STORAGE
Can write to SD card.
WRITE_HISTORY_BOOKMARKS
WRITE_USER_DICTIONARY
Can modify your browser history.
Can write words to your custom dictionary.
Page 134 of 137
The University of Derby
Department of Computing and Mathematics
Appendix F. Frequency of Low/High Permission Combinations
Category
Comic
Communication
Education
Entertainment
Family
Finance
Games
Health & Fitness
Lifestyle
Media & Video
Application
Frequency of Low Risk
Permission Combinations
Frequency of High Risk
Permission Combinations
Draw Cartoons 2
3
7
Learn to Draw Anime Manga
3
3
How to Draw 3D and Illusions
2
4
Skype
100
132
WeChat
111
118
Telegram
41
64
Homework Planner
0
0
Show My Homework
2
19
myHomework Student Planner
9
17
BBC iPlayer
0
1
DISH Anywhere
4
6
My5
1
5
LetterSchool Free – Write ABC
0
3
ABC Learning Letters for
Toddlers
0
1
ABC Flash Cars for Kids Game
0
1
PayPal
24
20
NatWest
9
12
Yorkshire Bank Mobile Banking
6
9
Solitaire
0
1
Solitaire Classic
0
2
Spider Solitaire
0
1
FatSecret
2
4
MyFitnessPal
57
48
Google Fit
18
18
All Recipes Free
2
4
CookPad
6
15
Food Network In the Kitchen
0
15
Screen Recorder
3
11
Spy Video Recorder
0
6
Page 135 of 137
The University of Derby
Medical
Media & Audio
News & Magazines
Personalisation
Photography
Productivity
Shopping
Social
Sports
Tools
Transport
Department of Computing and Mathematics
SCR Free
3
11
Pregnancy +
39
52
Pregnancy Calculator
0
0
Ovia Pregnancy Tracker
14
22
Spotify
17
19
Music Free
2
4
SoundCloud
12
24
BBC News
2
9
ABC News
22
44
Google News & Weather
2
13
Emoji Keyboard Lite Kika Free
32
34
Lollipop Emoji Keyboard
31
45
Emoji Keyboard 6
2
4
Camera for Android
36
54
Retrica
45
33
Open Camera
5
1
Sunrise Calendar
17
49
Google Calendar
9
36
Calendar
0
6
eBay
5
10
TopShop
9
12
Etsy
8
13
Pinterest
10
18
Facebook
104
105
LinkedIn
12
33
Bet365 News
0
1
Tipster 365
0
1
Betting Tips
6
15
Wave Alarm
17
19
My Talking Alarm Clock
3
18
My Alarm Clock Free
12
16
Trainline – times & tickets
4
7
Page 136 of 137
The University of Derby
Travel & Local
Weather
Department of Computing and Mathematics
National Rail Enquires
3
7
Train times, travel & tickets
0
6
Waze – GPS, Maps & Traffic
73
115
GPS Navigation & Maps Sygic
36
28
MapFactor GPS Navigation
Maps
4
5
BBC Weather
0
3
Yahoo Weather
22
44
Weather
1
2
Page 137 of 137