Final report

Honours Project Final Report
Androids Permission System: Privacy VS Functionality
Fraser Hiddleston
Matric No: S1110109
BSc (Hons) Cyber Security and Networks
Module Leader: Dr. Richard Foley
Project Supervisor: Dr. Mike Just and Dr. Richard Foley
Second Marker: Katrin Hartmann
“Except where explicitly stated all work in this document is my own”
Signed: Date:

2 | P a g e
Table of Contents
Abstract.......................................................................................................................................4
Acknowledgements ...................................................................................................................... 5
1. Introduction.............................................................................................................................. 6
1.1 Project Background ............................................................................................................. 6
1.1.1 The quick rise in mobile apps popularity.........................................................................6
1.1.2 Issues caused by this sudden rise in popularity ................................................................ 7
1.1.3 App developers breaching the privacy of their customers................................................. 7
1.1.4 The Google Play store ...................................................................................................7
1.1.5 The State of privacy laws............................................................................................... 8
1.1.6 The effect of privacy concerns ....................................................................................... 8
1.1.7 How app developers are tackling privacy concerns.......................................................... 9
1.2 Project Outline & Research Questions ................................................................................ 10
1.2.1 Project overview ......................................................................................................... 10
1.2.2 Research Question....................................................................................................... 11
1.2.3 Aims and Objectives ................................................................................................... 11
1.2.4 Hypothesis.................................................................................................................. 12
1.3 Report Structure................................................................................................................ 13
2. Literature Review ................................................................................................................... 14
2.1 Google plays Android permission system............................................................................ 14
2.2 Researching app risk assessment services............................................................................ 14
2.3 Research carried out into app privacy ................................................................................. 15
Bring Your Own Device (BOYD) ........................................................................................ 16
The Flow of Sensitive Data.................................................................................................. 16
3. Research Methods................................................................................................................... 17
3.1 Methodology Justification.................................................................................................. 17
3.2 Methodology Objectives .................................................................................................... 18
3.2.1 Determining a sufficient set of free apps to be examined................................................ 18
3.2.2 Select an appropriate set of tools to enable a forensic investigation of the app permission
settings profile of the chosen apps ........................................................................................ 19
3.2.3 Setting up and executing the experiment ....................................................................... 19
3.2.4 Analyse the collected collection of app permission data from the experiment.................. 21

3 | P a g e
4. Results ................................................................................................................................... 23
Basic Permissions ................................................................................................................... 23
Comparing number of permission categories to number of permissions ...................................... 25
Average permissions per category vs. 3rd
party SDKs................................................................ 27
Most SDKs and Permissions for each category...................................................................... 27
Prevalence of high risk permissions.......................................................................................... 29
Data Collection....................................................................................................................... 30
5. Discussions and Conclusions ................................................................................................... 31
Project Summary .................................................................................................................... 31
Discussion of results ............................................................................................................... 31
Project Limitations.................................................................................................................. 33
Scale of the project.............................................................................................................. 33
Issues with chosen Services.................................................................................................. 33
Future Work........................................................................................................................... 34
Conclusions............................................................................................................................ 34
Appendices ................................................................................................................................ 36
A) The Chosen Free Android Apps .................................................................................... 36
Business apps...................................................................................................................... 36
Education apps .................................................................................................................... 36
Personalisation apps ............................................................................................................ 36
Lifestyle apps...................................................................................................................... 36
Entertainment apps .............................................................................................................. 37
B) Top 20 app list for each category according to App Annie .............................................. 38
Business apps...................................................................................................................... 38
Education apps .................................................................................................................... 39
Personalisation apps ............................................................................................................ 40
Lifestyle apps...................................................................................................................... 41
Entertainment Apps ............................................................................................................. 42
C) Googles Permission Categories..................................................................................... 43
D) Risk assessment Service Findings ................................................................................. 47
E) MyPermissons App Screenshot......................................................................................... 48
References ................................................................................................................................. 49
Bibliography .............................................................................................................................. 54

4 | P a g e
Abstract
With there being 1,166,411 free Android apps and 211,063 paid Android apps available on
the Google Play store and now an increase in concerns, with mobile app privacy since the
"Brightest Flashlight Free" app, which had over 10 million downloads on Android where they
were sharing user data without the users knowledge. This experiment will focus on free apps
on Android smart phones as they have an expected market share of 43.8% in 2015, which
means the results will be beneficial for more people. The aim of the experiment is to
investigate the extent in which functional app permissions are being used on the Google Play
store which has the potential to infringe on the privacy of the user. This experiment will be
conducted by using the top 5 app categories (Business, Education, Lifestyle, Personalisation
and Entertainment) on Android and download 10 from the top 20 apps for each app category.
Information on the apps will be gathered by using MyPermission app risk index,
PrivacyGrade and AppBrain. The information gained from this led to the discovery that all
50 of the free apps downloaded for the experiment had access to the user’s personal
information and the more 3rd party SDKs that an app uses the more permissions the app will
ask for. Overall the experiment found the there is a fine line between functionality and
privacy as the permissions being requested were being used for functional reasons and then
the same permission was being used for non-functional reasons as well.

5 | P a g e
Acknowledgements
I would like to take this opportunity to thank my supervisor Mike Just for providing guidance
throughout my honours project. I would also like to thank Richard Foley for taking over as
supervisor when Mike left and for the information which he provided during the various
honours talks.
Also I would like to thank all of those who marked my interim report and provided useful
feedback which I have taken on board.
Additionally I would also like to thank my Mum for helping me with the painstaking task of
referencing since this was the first time I have ever had to use the Harvard referencing
system.
Finally I would like to thank the rest of my family for staying out of the way and leaving me
to get on with my work, which was the best support they could have provided.

6 | P a g e
1. Introduction
This section will introduce the project area of mobile phone apps, the risk associated with
these apps, examples where mobile app developers have breached the laws governing app
behaviour and the massive increase in android mobile phones usage.
It will also introduce the research question, the projects objectives and the hypothesis which
will govern this project and the structure of the report.
1.1 Project Background
1.1.1 The quick rise in mobile apps popularity
Mobile apps have been popularised with the rise of the Iphone back in 2007 (Rakestraw et al.,
2013 ; Lescop & Lescop, 2014) and have become widely available due to android being
installed on some of the top mobile phone companies like Samsung, Sony, HTC and more.
With there being 1,166,411 free Android apps and 211,063 paid Android apps available on
the Google Play store (AppBrain, 2014(b)), there has been major concerns over user privacy.
This concern will keep growing since Google Play saw a massive growth in revenue during
October 2012 Google Play's revenue increased by 18%, for that month, whereas the IOS app
store only saw a 0.7% growth (Gold, 2012). The growth in app popularity on Android has
continued with the activity on the Google Play store up by 45% in Q2, 2014 from Q1
(Schick, 2014(b); App Annie, 2014(b)). However, this growth in apps from the Google Play
store has come from the popular business strategy called "freemium", which contributed to
about half of Google Plays downloads in May 2014 and also saw "freemium" revenue grow
to about 98% worldwide in May 2014 (Schick, 2014(a); App Annie, 2014(a)). The difference
in the amount of "freemium" (Red) and premium (Green) apps can be seen by looking at the
top 10 categories below (AppBrain, 2015):
(Figure 1)

7 | P a g e
1.1.2 Issues caused by this sudden rise in popularity
This large amount of growth, in "freemium" apps revenue has caused privacy concerns, due
to the permissions app, developers are asking for, and what they are doing with the data they
have collected from the user. The rise of revenue from "freemium" apps according to
Appthority's winter 2014 report (Appthority, 2014(a)), is due to the popularisation of app
developers generating income from sharing the user data collected from their apps with
advertising companies and analytic companies. This done via the use of third party software
development kits (SDKs), according to Anthony Bettini (Bettini, 2012):
"The greatest risks associated with mobile apps are not related to insecure programming
mistakes, but rather to the intentional misuse of supported features"
This statement carries a lot of truth behind it because in the United States of America the
Federal Trade Commission (FTC) has released a set of guidelines for app Developers to use
(Anon, 2013) to help protect the user's personal information.
1.1.3 App developers breaching the privacy oftheir customers
The FTC has also been clamping down on app developers who have breached the guidelines
and/or any privacy laws for example: the FTC charged Goldenshores Technologies for its app
"Brightest flashlight free" which had been downloaded over 10 million times by Android
users (Anon, 2014(a)). The "Brightest Flashlight Free" apps privacy policy deceived its users
by not telling them that it would track user geo-location, record their unique device identifier
(UDID) even before the user accepted the app permissions, would share it with advertising
networks and other third party companies (Anon, 2014(a)). The FTC has also charged W3
Innovations, for its Emily apps which were free on the IOS app store and aimed at children
(FTC, 2011). The apps were downloaded over 50,000 times (FTC, 2011) and were found to
have breached the FTC's Children's Online Privacy Protection Act (COPPA) because they
had been collecting and sharing the personal information of tens of thousands of children
under the age 13 without their parent's consent (FTC, 2011). They were fined $50,000 and
ordered to delete all of the information collected and made to change their privacy policy
(FTC, 2011).
1.1.4 The Google Play store
However it is not just the apps being downloaded whose privacy policies have been under
scrutiny, because the Android market place, Google Play, has come under fire for the way it
processes payments to app developers. When an app is purchased from the Google Play store,
Google sends the app developer the email address and certain billing information (Byrne,
2013), which is stated in their privacy policy. However, there have been calls for Google to
change it and do it the way Apple does it for its App store, where they just send the app
developer the money (Byrne, 2013) due to the privacy concerns of mobile apps.

8 | P a g e
1.1.5 The State ofprivacy laws
There are many problems with the privacy laws that affect mobile app developers, primarily
because there is no international consensus on how the privacy of the user should be
protected and there is no consensus on the protection of personal information. This
demonstrated by the fact that privacy is perceived as a human right in Europe, where
regulations are in place so personal information can be protected, whereas in Asia and the
United States, personal information is no more than a commercial commodity which is
subject to free market conditions (Kulesza, 2013). With this big difference in the perception
of privacy and the right for personal information to be protected, the choice of using the
Google Play store for downloading the apps for the Android mobile made sense since they
are registered within the United States of America but have operations across the globe and
therefore they should be complying with the laws in all of those jurisdictions.
The other failure in privacy laws is that there are many guidelines for app developers to
follow for example, ICO (ICO, 2013), FTC (Anon, 2013) and GSMA (Anon, 2012(a)) are
just a select few companies with voluntary guidelines out there on how to design an app
which puts the protection of the user's privacy as one of the top priorities, however none of
them are enforced by law. The fact the guidelines are not being enforced by law is not even
the worst part, as there are app developers out there who choose to ignore the laws because
the business has decided that it is more profitable to collect as much data as possible as the
financial loss from a fine and reputational damage are minimal if they are caught (Pearce et
al., 2013).
This therefore justifies why this project is looking into the permissions apps are asking for as
they are not following the laws and are collecting more data than they are allowed to, via the
permissions granted by the user.
1.1.6 The effect ofprivacy concerns
A survey carried out in the USA (2011) found that 56% of Android users have avoided
downloading an app due to privacy concerns and a further 32% of Android users have
uninstalled a app because of concerns over their privacy (Boyles et al., 2012). This is also
further backed up by the GSMA who did a survey in Singapore (2011), Malaysia (2013),
Spain (2011), Brazil (2012), Mexico (2012), Colombia (2013), UK (2011) and Indonesia
(2013) where they found that 83% of mobile internet users have concerns over their personal
Information being shared when they are using mobile apps or the internet (Anon, 2014(b)).
In the same survey the GSMA found that 60% of mobile users wanted a set of consistent
rules (Anon, 2014(b)), to be brought in and followed by any company that wants to access the
users geo-location no matter how they plan to use the information. However, GSMA also
found that 80% of mobile app users agree to privacy policies without reading them because
they are too long or use too much legal jargon (Anon, 2014(b)).

9 | P a g e
1.1.7 Howapp developers are tackling privacy concerns
GSMA like the FTC, have released a set of privacy design guidelines (Anon, 2012(a)).
Unlike the FTC they are not a government organisation, instead they are a company which
represents the industry in legal and policy decisions made by governments. Their Director of
Privacy, Pat Walshe, has been debating Privacy and Security Legislation at the European
parliament, to bring in new legislation which the EU government has been trying to agree
upon (Albrecht & Walshe, 2013).
Due to the fact that GSMA represent the industry and work closely with the industry leaders,
they have been able to construct a set of guidelines which protect the user and the developers.
Their Guidelines also are more user friendly because they provide definitions for key terms
e.g. Active consent, application, location, personal information, privacy and user (Anon,
2012(a)) which is important because privacy has many different legal definitions depending
on what it is relating to. They also provide a list of things personal information includes in
relation to mobiles:
 data collected directly from a user via an application’s user interface (name, address,
date of birth)
 data that is gathered indirectly such as mobile phone number, IMEI or UDID
 data gathered about a user’s behaviour, such as location data, web-browsing data or
the applications used which are linked to a unique profile
 User-generated data such as contact lists, videos and photos, messages, emails, notes,
and call logs.
(Anon, 2012(a))
This allows the user to better understand what personal information is being collected from
the different app permissions. It will also give the user an insight into what sort of
permissions they should expect to see for certain apps and give them the confidence to
question why they want all of those permissions e.g. read calendar events which is only
needed for task management apps (Hildenbrand, 2014) therefore if a game app were to ask
for it the user knows not to download the app.

10 | P a g e
1.2 Project Outline & Research Questions
1.2.1 Project overview
This project is an experimental project instead of a development and test since this project
will be using software and services which are complete and can be accessed by anyone to
use. The focus of this project will be on the permissions requested by free apps on Android
mobile phones, which can infringe on the user's privacy at risk. The reason for choosing
Android over other mobile operating systems is down to its popularity compared to other
mobile operating systems like Apples IOS whose expected market share for 2015 is only
16.9% compared to Androids 43.8% (Cortimiglia et al., 2011). The reason for focusing on
free apps is down to the 98% increase in revenue the Google Play store has seen from apps
using the "freemium" business strategy (Schick, 2014(a); App Annie, 2014(b)) which
demonstrates the popularity of free apps and also raises the question; what are the potential
risks to the users privacy? The reason for focusing on the permissions requested by the app
developers, rather than malware, which are not a big risk in comparison to the misuse of app
permissions and the handling of the user's personal information. According to a statement
made in Appthority's summer 2014 report (Appthority 2014(c)):
"The real concern should be over how popular mobile apps are handling personal info...
Appthority's deep analysis into app behaviours actually proves that mobile malware infects
only 0.4% of mobile apps"
This further demonstrates that the real threat to personal information on mobile devices is
mobile app permissions and not the misguided view that malware is the big threat.
The aim of this project is to demonstrate the effectiveness of the Google's permission system
which was recently changed (Hoffman, 2014), so that when apps which are already installed
on an Android device performed an update they are not required to inform the user of
permission changes. This will allow the app to automatically add dangerous permissions
(Hoffman, 2014), which could put the user's privacy at risk. The project also aims to compare
the permissions of similar apps e.g. wallpaper apps, to find out if one app requires more
permissions than another to perform a similar service. This project will also look at the
prevalence of 3rd part SDKs (software development kits) as this is how app developers can
make money from advertising and it also means that the app developers could be sharing the
user information with the owners of this 3rd party software.
To acquire the information on the apps for this project the use of three different services will
be used; Mypermissions, AppBrain, and PrivacyGrade. These services were chosen because
they provide different information about the 50 apps that will be examined within this project
and were chosen for their ease of use over other services. These services each have their own
database of app information which they have gathered and analysed which is available for
anyone to use. The Mypermissions service will be the main service used as it provides the
most information and Mypermissions has an app which allows the permissions to be
monitored on the smartphone which will alert the user to any changes in permissions of
installed apps. The other two services are only web based and do not offer an app like

11 | P a g e
Mypermissions, they are being used to supplement the information on each app. For an app to
qualify for use in this project there must be information on Mypermissions and at least one of
the other services, this means that there will be enough information on each app to provide
the results for each of the aims.
1.2.2 Research Question
The following research question has been obtained by the findings of the literature review:
“To what extent are free apps on Android using Google Plays permission system to aid
in the functionality of the app and how this has the potential to infringe on the privacy
of the user?”
1.2.3 Aims and Objectives
The aim of this experimental project is to perform an investigation into the transparency of
app developers, when it comes to disclosing their apps behaviour, through the use of app
permissions and their privacy policy. This will be performed by comparing the apps
permissions and privacy policy to the results of an app risk assessment service(s). For these
aims to be achieved certain objectives have been identified below:
The literature review objectives are:
S1. Research Google plays Android permission system.
o This will allow for an understanding of what the different permissions mean
and how effective Google's permission system is.
S2. Research App Risk Assessment Services, like Appthority's app risk assessment
service, Micro Trend Application Reputation Service, MyPermissions, PrivacyGrade
and AppBrain.
o This research will allow for the best app risk assessment service to be chosen
as they will have to meet the following criteria:
i. Not require the use of a Mobile device management service, as this
would cost too much.
ii. The service has to be affordable.
iii. Provide a list of what the apps are requesting access to.
iv. Provide a list of the third party software development kits (SDKs) used
with the app, since the companies supplying the SDKs are normally
getting access to personal information.
v. Provide a reputation score for each app.
vi. Have an easy to use user interface (UI); this will be achieved either by
using the service if it’s free/free trial or by looking at YouTube videos
to see the UI.
vii. Easy to install and setup.
S3. Potential application uses in terms of data collection and privacy related functional
behaviour when permissions are enabled for an app.

12 | P a g e
o This will allow for a better understanding into why certain apps need to use
permissions which permit data collection and privacy related functional
behaviour.
S4. Investigate Research previously carried out in app privacy.
o This will allow for a better understanding on mobile app privacy and will
show how different types of results have been displayed, allowing for different
options to be explored when presenting the findings in the final report.
The Primary research method objectives are:
P1. Determine a sufficient set of free apps which will be examined.
o This will be performed by using AppBrain to obtain a list of the top 5 app
categories by volume (Figure 1) and then using App Annie to obtain a list of
the top 20 apps for each category (Appendix B).
P2. Select an appropriate set of tools to enable a forensic investigation of the app
permission settings profile of the selected apps.
o This will be performed by examining the results of Appendix D
P3. Setting up and executing the experiment
o This objective relies upon the information gathered from the objective S4,
which allow for an informed decision to be made. An account will need to be
made so that all the features of the service can be utilised.
P4. Analyse the collected collection of app permission data from the experiment.
o Download all of the apps on the same day for the chosen app category, so that
the top 10 in the selected categories doesn't change.
1.2.4 Hypothesis
From the research question above the following hypothesises can be made:
H1.Google’s permission system has been simplified to the point where it no longer
protects the privacy of the user.
o Google has recently changed their permission systems (Hoffman, 2014), so that
when apps which are already installed on an Android device update, they are
not required to inform the user of permission changes, which will allow the app
to automatically add dangerous permissions (Hoffman, 2014), which could put
the users’ privacy at risk.
H2.Apps of a similar nature e.g. two wallpaper apps will utilise different permissions
to aid in the functionality of the app.
H3.Apps with a greater number of 3rd party SDKs will have a larger number of
permissions.

13 | P a g e
1.3 Report Structure
The first chapter of this report provides background information into the subject area mobile
app permissions versus the privacy of the user. The background section covers the rise in
popularity of mobile apps, the issues caused by this rise in popularity, examples of app
developers breaching the privacy of their users, the Google Play store, the state of privacy
laws, the effect of privacy concerns and how app developers are trying to deal with the issue.
The first chapter also provides an outline of the project by discussing what this project will
involve and provides the research question which is derived from the background
information.
The second chapter is the literature review which covers Google plays permission system
which explains the recent changes to the permission system and the various effects this could
have. It covers the research required to choose the app risk management services which will
be used in this project and will look into the work previously carried out into the permission
system and the privacy concerns associated with free apps on Android.
The third chapter of this report provides the methodology of the experiment and justification
for the whole of the methodology. This will cover the choosing of the set of apps, the
selecting of the various tools and services to be used within this project, the setting up and
execution of the experiment and how the results were collected and analysed.
The forth chapter shows the results of the experiment. The results are displayed using tables,
and different charts with a written explanation of each of the tables and charts.
The fifth chapter provides the conclusions drawn from the results of chapter four. This
section aims to answer the research question and the hypothesis drawn in chapter one. This
chapter will also draw conclusions from the experiment overall and recommendations on how
to improve the protection of the users privacy without damaging the functionality of the apps.

14 | P a g e
2. Literature Review
2.1 Google plays Android permissionsystem
Google has recently changed their permissions where an app, already installed on the
Android device can automatically add new permissions without the user's permission
(Hoffman, 2014). According to Google they have also “simplified” the way permissions are
displayed to the user, as they are now organised into permission groups (Google, 2015) which
is supposed to make it easier to identify what each app has access to.
This does make it easier for the user to quickly review what the app can access, however, it
now means that when an app which used to only require the “Read SMS messages”
permission now has access to every SMS related permission (Hoffman, 2014) because they
have all been grouped into the one category "SMS". So what Google has actual done is
manage, to put every single Android users privacy at risk because now the app developer just
needs to update their app in order to add a new permission under the “SMS” category and
from this they could send an SMS message, which the user could be charged for.
This update justifies the project because not only has Google made it easier for app
developers to exploit the permissions system they have now made it harder for the user to
find out what exactly each app is accessing, hence why this project will look into the
functional behaviour of apps and the potential for these permissions to put the users privacy
at risk.
Within Google's app developer site, Google defines a “Dangerous” or “Higher Risk”
permission for the developers as a permission “that would give a requesting application
access to private user data or control over the device that can negatively impact the user”
(Cilley & Sverdlove, 2012). This definition demonstrates that there are apps on Google Play
which will request these “dangerous” permissions, which is illustrated by the fact that Cilley
& Sverdlove, 2012 found that of the 400,000 apps they analysed they found that 290,000
(72%) used at least one of the potentially risky permissions. To get their results they
conducted an online survey of 139 IT security decision makers who are responsible for the
mobile security of over 400,000 employees. Their survey focused on the employee's use of
their mobile devices in the workplace and the organisation’s use of a mobile policy (Cilley &
Sverdlove, 2012).
Also when downloading from the Google Play store the user has two options either accept all
of the requested permissions or cancel the download, this limits the privacy control an
Android user has over their own information (Felt et al., 2012).
For a list of the 17 permission categories (Google, 2015) look at appendix C.
2.2 Researching app riskassessment services
The need for an app risk assessment service is essential because it will allow for the
permissions requested to be monitored and checked for any changes. This will now become
even more important since Google updated their permission system which lets apps add
permissions during an update (Hoffman, 2014).

15 | P a g e
When researching the app risk assessment services the following criteria had to be met for the
service to be viable:
 Did not require MDM software
 The service has to be affordable
 Has to provide a list of permissions
 Has to provide a list of SDKs
 Has to provide a reputation score
 Has to have an easy to use user interface (UI)
 Has to be easy to install and setup
The results of the above criteria can be seen in Appendix D, which shows that the Appthority
and the Micro Trend app risk assessment services were unable to be used since they required
access to mobile device management software (Appthority, 2014(b); Trend Micro, 2012)
which is not affordable and that is why the rest of table for those choices have been marked
as not applicable (N/A).
This, therefore, justifies the use of MyPermissions which only charges to use the upgraded
features and you are able to install the MyPermissions app directly onto the Android phone
(MyPermissions, 2014; Perez, 2013). MyPermissions will be used in combination with
PrivacyGrade and AppBrain which are free to use (AppBrain, 2012; PrivacyGrade, 2014).
The reason for using all three services, is in case an app is not analysed by one of the other
services, there is a fall back. Also information gained from each service is slightly different
which will provide a more in-depth analysis.
2.3 Research carriedout into app privacy
Within the mobile app privacy area there has been some studies carried out on it where IOS
and Android apps have been compared where they found that IOS apps had access to more
user data and that free apps had the riskier behaviour (Appthority, 2013). There has also been
a lot of research into developing software to help users analyse apps as they focused on the
malicious behaviour of apps (Enck, 2010).
However Google has recently changed their permission systems (Hoffman, 2014), so that
when apps that are already installed on an Android device update, they are not required to
inform the user of permission changes which will allow the app to automatically add
dangerous permissions (Hoffman, 2014), which could put the user's privacy at risk. For this
reason this report will focus solely on Android apps by monitoring the permissions and
therefore demonstrates that the users’ privacy can be easily compromised because of
Google's actions. This therefore justifies this project since the new permission system was
implemented in October 2014 (Hoffman, 2014) so there has been no research yet on the
effects of these changes. Therefore, this report will focus on the new permissions system
implemented by Google and will aim to offer further insight into the privacy of apps.

16 | P a g e
Bring Your Own Device (BOYD)
The work which has been carried out into app privacy has been focused on looking into to
BOYD (bring your own device). This section of mobile app privacy is aimed at businesses
who allow their employees to download and install apps on to their phones which contain
sensitive business information. This area has been the main focus of Appthority who have
released numerous app reputation reports. When carrying out their work into app privacy
concerns Appthority used their own cloud based platform to perform static and dynamic
analysis into the app. This has meant that Appthority has looked into the top 100 most
popular apps (Appthority, 2013) and have also compared IOS to Android by examining free
and paid apps (Appthority, 2014(C)).
This area differs from the work being carried out in this experiment as this experiment is not
looking into BOYD as several companies have and still are looking into BOYD for example
Bit9 (Cilley & Sverdlove, 2012) Appthority (Appthority, 2014(A)) and TrendMicro (Trend
micro, 2012). However, the information gained will be similar as this experiment is looking
at the privacy of the user rather than the privacy implications for businesses.
The Flowof Sensitive Data
The leaking of data is a big issue as Appthority has reported that they have analysed apps
which have over 15 Ad network SDKs in them (Musthalar L, 2013). This shocking revelation
has led to the development of TaintDroid. TaintDroid is an experimental piece of software
which could change the face of mobile privacy as it uses a method of data tainting where the
software tags sensitive information which can be tracked which allows it to monitor the flow
of the sensitive user data (Enck, et al., 2010). TaintDroid achieves this data flow monitoring
by using a network taint sink which allows TaintDroid to identify when tainted information is
transmitted out with the network interface. The problem TaintDroid faces is it is very
complex, however if TaintDroid was to prove to be operationally viable it could solve a lot of
the privacy issues which are associated with functional permissions as this would help tackle
the misuse of permissions on Android and other mobile operating systems.

17 | P a g e
3. ResearchMethods
3.1 Methodology Justification
The method in which this experimental project will be carried out is, by using the
MyPermissions app risk assessment service in combination with PrivacyGrade and
AppBrain. The reason for using the three of these services is to ensure a thorough assessment
of the apps and also means that if an app cannot be assessed by one of the services there will
be another service to fall back on. The reason these services have been selected for this
project over Appthority’s and TrendMicro’s service is down to the sole fact that they don't
require the use of a mobile device management (MDM) service (Appendix D), which would
require a substantial amount of money. MyPermissions basic service is free to use, but for the
purpose of this project will be upgraded so that more information can be obtained about each
of the apps. Also PrivacyGrade and AppBrain are being used to provide additional
information on the apps, since they are a free web service (Appendix D) for anyone to use
who wants find out about the apps that they have installed on their Android device.
For this project the 10 of the top 20 free apps will be downloaded from the top 5 app
categories on Android according to an updated version AppBrain. 2014(b), this will prevent
any bias when carrying out the app selection for this experiment. The reason this project will
focus on the top 5 categories is to demonstrate that even the most popular app categories and
apps have privacy concerns. This is demonstrated through the Trojan-horse wallpaper app
which appeared to offer nothing except for a nice background for the users phone, but was
also collecting the user's personal information and emailing it abroad. According to the
security company Lookout this a common practice as wallpaper apps are downloaded by
millions of android users (Hurlburt et al,. 2011). The reason for picking 10 apps from the top
20 is to ensure that the apps can be found the risk assessment services databases of apps, this
is important as PrivacyGrade and AppBrain cannot be contacted to ask for them to perform
analysis on certain apps.
The reason for choosing Android over Apples IOS is because of Androids 43.8% expected
market share in 2015 compared to Apples IOS expected market share of 16.9% (Cortimiglia
et al., 2011) This massive gap demonstrates Androids popularity over IOS; over the time
period of 2011 to 2015 Android's expected market share has increased by 4.9% compared to
Apples IOS expected market share which has decreased by 1.3% over the same time period.
Hence the reason for using Android is due to its popularity and it means the results of this
project will reach a larger audience.

18 | P a g e
3.2 Methodology Objectives
This section of the report will provide information on the different stages to physically
perform the experiment. This section has changed since the proposal as it has been refined
into fewer objectives as the previous objectives were at a very simplistic level.
3.2.1 Determining a sufficient setoffree apps to be examined
When selecting the apps for this experiment the main issue was making bias choices based on
the knowledge gained on from carrying out the research into mobile apps. To prevent this
from happening, the following stages were taken:
Stage 1 – Selecting the appscategories
When selecting the app categories for this experiment AppBrain was used as they provide a
chart with the top 10 app categories for Android based on the overall number of apps within
each category (Figure 1). Figure 1 illustrates that Business, Education, Personalisation,
Lifestyle and Entertainment app categories are the top 5, where each category has the
following number of apps (AppBrain, 2015):
Category Free Paid Total Number of
Apps
Education 97,152 23,290 120,442
Lifestyle 100,284 9,475 109,759
Entertainment 93,101 10,715 103,816
Business 99,020 3,344 102,364
Personalisation 65,030 31,694 96,724
(Figure 2)
The figures in figure 2 represent the information in figure 1. The choice to pick the most
popular app categories based on the overall number of apps rather than just the overall
number of free apps was made because it shows that app developers develop and design more
apps for certain app categories. The aim here was to remove as much bias as possible when
selecting the app categories and this was achieved by the use of AppBrain.
Stage 2 – Selecting the free apps
To obtain an app list in an unbiased manner App Annie was used which is a mobile analytical
company which monitors the app market place for all operating systems (IOS, Android, and
Windows etc.). The results from App Annie are contained within Appendix B, where
following search criteria were searched for on the 11th March 2015 within the store stats
section:
 Charts: Google Play
 Country: United Kingdom

19 | P a g e
 Category (Applications): selected one from the top 5 according to AppBrain (Figure
1).
 In-app purchases: All apps.
The above search criteria, was repeated for each app category. App Annie was used because
it provided a way of narrowing the search of the top charts for the apps to provide the option
for a very precise search criteria rather than combing app markets (Google play, IOS and
Windows etc.) and base the results on country specific figures rather figures based on just
worldwide or United States stats only.
This stage was an iterative process as it was revisited during the experiment as not all of the
apps initially selected were contained within the primary app risk assessment tool
MyPermissions, which meant they were replaced with another app from the app list in
Appendix B.
3.2.2 Select an appropriate set oftools to enable a forensic investigation ofthe app permission
settings profile ofthe chosen apps
When choosing the app risk assessment tools to perform the investigation into app
permissions. The following criteria had to be met for them to be a valid choice:
 Does not require mobile device management (MDM) software.
 Is either free to use or within a reasonable price (£50).
 It needs to provide a list of permissions.
 It needs to provide a list of 3rd party SDKs (software development kits).
 Provide a reputation/risk score.
 Must provide information on free apps.
These requirements can be seen in appendix D, where the information was obtained when
carrying out literature review 2.2. From the results of Appendix D you can see that only
MyPermissions and PrivacyGrade met the necessary requirements, stated above, however
when carrying out the experiment PrivacyGrade did not have all of the selected apps on their
database of app information and therefore AppBrain was introduced so that there were at
least 2 services being used to obtain information on each app. Even though AppBrain did not
provide a list of 3rd party SDKs it was chosen because it provided strong analysis on the
permissions of the selected apps which means that it helped to provide information on the
permissions of the chosen free apps. This actually worked out better since using 3 services
provided a more in-depth analysis of the selected apps, since each of them differ slightly in
the information they provide.
3.2.3 Setting up and executing the experiment
This section of the experiment was split up into 2 stages setup and execution. This made it
easier to track what had to be finished before starting the experiment, since any changes that
had to be made to the setup process would directly impact the execution of the experiment.

20 | P a g e
Setup
This stage describes what had to be carried out before the execution stage could start. The
first task was very basic as it involved creating a Google account as the project was utilising
an Android smart phone and the Google Play store, where both require a Google account.
The creation of the Google account had many benefits despite being necessary as it recorded
what apps had been installed on to the smart phone. The setup of the Google account takes
minutes and was carried out on a PC so that the smart phone could be setup with it straight
away.
After creating the Google account a Sony Xperia Z smart phone was obtained for use on the
experiment which had Android version 4.4.2 installed on it. The reason for using the Sony
Xperia Z was because it had all of the technology needed to use the apps and had the
necessary version of Android installed on the device. For this experiment an 8GB memory
card was used to store the apps, however with all 50 of the apps installed on the device they
only amounted to under 800MB.
During the setup stage the MyPermissions app was installed onto the smart phone as it tracks
the permissions of each app installed on the phone. The app also alerts the user when an app
does an update and has added new permissions. This was used to record any changes to the
permissions of the apps over the course of the experiment, so that the information obtained
was accurate.
The final task to be performed in the setup stage was to create an app list for each category
based on the information gained from Appendix B. This task is crucial as it provides a
focused search when starting the execution stage. For this it was important to select apps, if
possible which have the same app developer as it will allow for comparisons to be made.
Also, if possible ensure that some of the apps have the same main functionality for example,
provide a wallpaper for the phone, this allows for a comparison of the permissions requested.
This task is also iterative as the list did change throughout the experiment when during the
execution stage; certain apps were not on MyPermissions. The final list of chosen apps is
shown in Appendix A.
Execution
This stage will describe the process of tasks which were completed to obtain the result of the
experiment. The first task was to use MyPermissions App risk index to search for the each
app and record the information it had on each app. If it did not have the app within its
database the app was dropped and replaced with another app from Appendix B. This was
done for every app and therefore formed the finalised app list Appendix A. Once each app
had been found within MyPermissions database they were then searched for within
PrivacyGrade and then AppBrain. The information was recorded in word where each app
category had its own file with the names of each app and the information obtained about them
from each service. When carrying out this task each app category was done one at a time
which meant that none of the apps were missed and it meant that if any app had to be
replaced it was easier to keep track.
The next task involved downloading all 50 apps and recording the following information:

21 | P a g e
 App name
 App developer
 App Category
 Permissions requested
The information gathered was hand written as it sped up the process of downloading and
installing the 50 apps, where it was later inserted into an excel file for each app category.
This task required the phone to be kept on charge and a Wi-Fi connection as it took
considerable time to complete and some of the apps were over 100MB. During this stage the
apps were downloaded from the Google Play store via the Android smart phone, where all the
permissions the apps requested will be allowed, since on Android you either accept the
permissions or cancel the install (Felt et al., 2012). For this phase the apps will be
downloaded using the top app categories according to AppBrain 2015 and Appendix A.
Once the apps were on the smartphone they were left for a week to see if any of them added
new permissions via an update. Some the apps did perform updates however according to the
MyPermissions app they did not add any new permissions. When performing the updates if
an app had added a new permission, the MyPermissions app would have notified the smart
phone user straight away as the MyPermissions app has the option to notify the user once a
week, once a day, as it happens or never.
3.2.4 Analyse the collected collection ofapp permission data from the experiment
To analyse the apps a series of comparisons will be made to aid identifying functional
behaviour and the potential to infringe on the users privacy. The following comparison
criteria will be utilised to perform the analysis:
 Number of different basic permissions VS Average number of basic permissions.
 The number of app permission categories VS The number of permissions.
 Number of 3rd party SDKs VS The number of permissions.
 Functional data collection VS Non Functional data collection (potential to infringe
user privacy).
 The use of high risk permissions for Functionality VS The use of high risk
permissions to pass user information to 3rd party SDK owners.
The use of the comparison criteria above will aid in focusing the results and provide targets
when examining the information gathered from each of the different services. To analyse the
app information quickly and efficiently the app information will be printed out and examined
by app category. When examining the information it was beneficial to write the information
out and highlight key points rather than typing it as it sped up the process. After the
information was gathered it was then input to a spreadsheet using excel where the graphs and
tables were made. This was different from the interim report as SPSS was going to be used
however excel provided all features and tools needed to display the results of the experiment
and by having past experience using excel it was a faster process as there was no learning
curve.

22 | P a g e
When carrying out the analysis each comparison criteria was carried out individually rather
than doing multiple at the same time, which made it easier to keep track of the information
being correlated.

23 | P a g e
4. Results
This section of the report will look at evaluating the information gathered from the carrying
out the methods in the previous chapter. All of the information represented below comes
from using MyPermissions, PrivacyGrade and AppBrain. The results are represented using
tables and graphs which have been chosen as they make reading the information easier than
examining the raw data from experiment.
Basic Permissions
The information in figure 3 was obtained from the MyPermissions app risk index. The
information was then compared and correlated into the information shown below in figure 3.
(Figure 3)
Figure 3 above shows the average number of basic permissions and the number of different
basic permissions which exist within each app category examined in this experiment. A basic
permission is one in which the app does not need to get the users permission to use as they
are used for the sole purpose of aiding the functionality of the app. The examination of basic
permissions was performed to provide some context into how many different permissions the
user grants even when the Google Play store says “no special permissions required”, this is
because these permissions are needed for the app to function. However, if the app developer
was to start using them for other purposes they would then need to get the users permission.
The top 5 permissions over all 5 categories are shown below in figure 4.
0 2 4 6 8 10 12
Business
Education
Personalisation
Lifestyle
Entertainment
Business Education Personalisation Lifestyle Entertainment
Number of different basic
permissions
12 6 10 10 8
Averge Number of basic
permissions
4.1 2.9 3.7 4.2 3.5

24 | P a g e
Basic Permission Number of apps
% of overall
apps
Open network sockets 50 100%
Access information about networks 49 98%
Allow access to the device vibration 25 50%
Access information about Wi-Fi
networks 24 48%
Run at start up 10 20%
(Figure 4)
When carrying out the examination into the basic permissions, all apps were found to be able
to open network sockets (Figure 4), which mean that all apps can connect to the internet. This
does provide some potential risk to the user’s privacy depending on the other permissions the
app requests. However, the primary function of this permission is to allow the app developer
to monitor their app as they can get access to usage data, get feedback from the user, and
update their app and many other features which may not directly impact the user but is still
needed to help the app developer keep tabs on their app.

25 | P a g e
Comparing number of permissioncategories to number of permissions
Figure 5 below shows the average number of permissions compared to the average number of
permission categories for each app category. This information was obtained by using the data
obtained from MyPermissions and the data obtained when downloading and installing the
apps.
App category
Average number of
Permission
Categories
Average number of
Permissions
Business 5 13
Education 3 7
Personalisation 2 8
Lifestyle 5 10
Entertainment 3 8
(Figure 5)
Figure 5 demonstrates what was being said in the literature review in section 2.1 and helps in
proving hypothesis 1 (H1), by illustrating how very little information can be obtained from
the permission category as each category has many different permissions which fall under it.
From the information above (Figure 5) it is easy to see that on average there are more
permissions per permission category for personalisation apps which is interesting because 4
of the 10 apps tested for this experiment were just wallpaper app's (does not include Zedge).
This is interesting and worrying because a wallpaper apps main functionality is to provide a
background for the smart phone, the extent of the matter can be seen below in figure 6.
App name Number of permissions
Number of permission
categories
Backgrounds HD Wallpapers 9 3
Waterfall Live Wallpaper 8 1
Electric Screen Live
Wallpaper 2 0
Asteroids 3D Live Wallpaper 4 1
(Figure 6)
Figure 6 demonstrates the extent in which wallpaper apps use the permissions as they go
beyond the functional requirements for the app to work properly for the user. This is shown
by the fact that Backgrounds HD Wallpapers uses the permission for full network access for
functionality but it also uses it so that it can target ads at the user by using Google's SDK
Admob. This therefore shows that the app developer is using the permission for functional
use but then takes advantage to make money.
According to MyPermissions all four of these apps are low risk apps with the highest risk
being 14 out of 100 which is for Backgrounds HD Wallpapers and all of these apps score an
A on PrivacyGrade which is the highest privacy grade offered. This low score is based on the

26 | P a g e
fact that these types of apps do not use many 3rd party software development kits (SDKs) and
do not have many permissions. This therefore means that they don’t pose a threat to user
privacy as the only 3rd party SDKs which could potentially cause a threat is Google's Admob
which is an advertising piece of software used by Backgrounds HD Wallpapers and Waterfall
Live Wallpaper. This could potentially cause a threat to the user’s privacy as the app
developer does not have control over the software which could start using aggressive ad
targeting, which may require access to more of the smart phone.
There are other 3rd party SDKs used by these apps however they are being used to aid in the
functionality of the app, which benefits the user and the app developer. These SDKs are
amazons SDK and Nostra13 which are used to help the app developer to log errors and
provide an authentication framework.
The information in Figure 6 also helps prove hypothesis 2 as it clearly shows that 4 wallpaper
apps range from having 2 permissions to 9 permissions. This becomes a concern because of
the big jump the number of permissions as it clearly does not need them to operate at a basic
level. The problem arises when the complexity of each app get examined as the Background
HD Wallpapers with 9 permissions has got more complex features than Electric Screen Live
Wallpaper which has 2 permissions. The safer of the 2 is Electric Screen Live Wallpaper as
its 2 permissions are basic permissions which do not require the user to grant, this is shown
by the fact that it doesn’t have any permission categories associated with it.

27 | P a g e
Average permissions per category vs. 3rd party SDKs
Figure 7 below shows the relationship between permissions and 3rd party SDKs. The
information for this section was obtained from MyPermissions and PrivacyGrade.
(Figure 7)
Figure 7 above was obtained by using the information from the MyPermissions app risk
index. The information gained in figure 7 is used to illustrate that there is a trend in the way
the number of permissions is generally higher within app categories using large amounts of
3rd party SDKs. This information also helps to prove hypothesis 4 (H4) in section 1.2.4.
The use of 3rd party SDKs has always been one of the main concerns when carrying out this
project as the app developer cannot control the SDK even though it has been integrated into
the app. This lack of control is where this concern has arisen and the information from figure
7 justifies this concern as the app categories with the highest average number of 3rd party
SDKs are the ones with the highest average number of permissions. The problem arises when
the owners of the 3rd party SDKs need the app developer to add permissions to be requested
so that their software can work.
Most SDKs and Permissions for each category
App Category Number of SDKs App name
Business 15 Yammer
Education 15 Elevate – Brain Training
Entertainment 12 Talking Tom Cat 2 Free
Lifestyle 16 ShowBox
Personalisation 11 Zedge Ringtone Wallpapers
(Figure 7A)
0 2 4 6 8 10 12 14
Business
Education
Entertainment
Lifestyle
Personalisation
Business Education Entertainment Lifestyle Personalisation
Average number of 3rd party SDKs 6 6 5 8 2
Average number of Permissions 13 7 8 13 8
PermissionsVS 3rd Party SDKs

28 | P a g e
App Category
Number of
permissions
App name
Business 26 Lync 2013
Education 11
Elevate - Brain Training
Show my Homework
Peak – Brain Training
Entertainment 14 Talking Tom Cat 2 Free
Lifestyle 22 Hot or Not
Personalisation 13 Nova Launcher
(Figure 7B)
The relationship between a large number of 3rd party SDKs and permissions is demonstrated
by looking at Elevate – Brain Training from the education category and Talking Tom Cat 2
Free from the entertainment category (Figure 7A and 7B). This helps to enforce the concerns
over the use of 3rd party SDKs as this experiment shows that the more SDKs used the more
permissions used, which means that the potential to infringe on the users privacy is increased.
This result goes to prove hypothesis 3 (H3) in section 1.2.4.

29 | P a g e
Prevalence of high riskpermissions
The information below in figure 8 was obtained by installing the apps on the smart phone and
using the MyPermissions app which monitors the apps and forms a list of the apps which
have high permissions meaning they could infringe on the privacy of the user. Figure 8 shows
what the high risk permissions have access to and a screenshot of the MyPermissions app can
be seen in Appendix E where the information was obtained.
(Figure 8)
Figure 8 shows the prevalence of high risk permissions by using the information on what
sensitive information apps have access to. This does provide really worrying information as
100% of the apps tested according to the MyPermissions app have access to the personal
information. This demonstrates the very large potential of app infringing on the users privacy.
Also the fact that 74% (37) of the apps can access the user’s inbox and contacts is worrying
as contacts can include email contacts as well as phone book contacts. The permission to
access inbox and contacts does have functionality with social networking apps as they are
used to help connect the user with people they know.
However, this permission does have privacy infringing abilities since apps which have this
ability can use the users contact information to increase their marketing capabilities by
expanding their contact list so that they can target more people with emails or phone calls.
This permission can be beneficial to the user but it can very beneficial to the app developer as
it is a very easy way to make money from their user base.
0% 20% 40% 60% 80% 100%
Post in your name
Use your location
Access Inbox & Contacts
Use pictures & files
Access personal information
Post in your
name
Use your
location
Access Inbox &
Contacts
Use pictures &
files
Access personal
information
% of overall apps 82% 42% 74% 74% 100%
% of overall apps with high risk permissions

30 | P a g e
Data Collection
Figure 9 below shows the number of apps with high risk behaviour (permissions) according
to Appthority’s winter reputation report 2014. However for this experiment Identify User in
the Appthority report has been separated into Identify Device and Identify User, this was to
discover how apps associate the information with a specific user, whether it is by the users
email address (Identify user) or by the smart phones phone number or UDID (Identify
Device). This section is using the risky app permissions to illustrate data collection, as it is
the fact that the permissions collect user information is what makes them risky in the first
place.
(Figure 9)
The information above demonstrates how risky app permissions (behaviour) are being used in
a functional manner. This is shown very clearly by the fact that only 3 of the business apps
have access to the calendar and no other app does, this is a good example of where app
developers are respecting their user. However, a major concern is the fact that 7 of the
education apps use Ad networks, this means that the apps will share user information with the
Ad networks SDK owner. This becomes a bigger issue as Puffin Academy, which is one of
the education apps, is aimed specifically at children, which means that the app is sharing
personal information about children.
Location
tracking
Access to
address
book
Access to
calendar
Identify
Device
Identify
User
In app
purchasing
Ad
Networks
Business apps 5 4 3 5 8 1 2
Education apps 2 0 0 2 6 3 7
Personalisation apps 2 3 0 1 0 1 5
Lifestyle apps 8 1 0 7 9 4 4
Entertainment apps 3 0 0 7 3 1 2
0
1
2
3
4
5
6
7
8
9
10
Numberofapps
Data Collection

31 | P a g e
5. Discussions andConclusions
Project Summary
The purpose of this experimental based project was to investigate Androids Google Play
stores permission system, with the sole purpose of looking into how functional app
permissions can potentially infringe on the users privacy. The aim of the project was to
answer the three hypotheses in section 1.2.4 of the report using the comparison criteria in
section 3.2.4.
The implementation of the experiment involved selecting 10 apps from the top 20 app list for
each of the top 5 app categories for Android. Once selected, the app risk management service
were chosen by examining the results in Appendix D, which led to MyPermissions,
PrivacyGrade and AppBrain being chosen to retrieve information on each of the apps. For the
Apps to be viable they had to be on the primary service (MyPermissions) and also on one of
the other services. The information for each of the apps was recorded and examined by using
the comparison criteria in section 3.2.4 and the results aimed to answer the hypotheses in
section 1.2.4.
Discussionof results
The experiment was designed to examine how Androids permissions used for functional
behaviour can infringe on the users privacy. The results of this small scale experiment
suggest that there are privacy concerns associated with the use of permissions. It also
demonstrates that the apps may use high risk permissions to obtain user data but in most
cases the data collected is used within the app for functional purposes. The privacy concerns
arise when the use of 3rd party SDKs for targeted Ads is used as this means that the user’s
data has been shared to some extent.
The examination of basic permissions was used to provide some context to what the user
automatically gives access to the app. The average amount of basic permissions for all of the
five categories is very similar (Figure 3), this was not a big surprise as all apps tested required
the basic permission to open network sockets and all but one of the apps required access to
information about the network (Figure 4). This was not a surprise since all apps require some
way of providing usability data back to the app developer.
The comparison of the amount of permissions against the number of permission categories
was not surprising as it was expected that the number of permission categories would not
show the true extent of permissions granted. This was expected because as mentioned within
the literature review section 2.1 Google simplified their permission which led to the creation
of hypothesis 1 in section1.2.4. The information in figure 5 shows that the number of
permission categories an app has, can mislead the user into trusting the app, leading them to
think that their privacy will be safe. The information in figure 5 backs up what Hoffman,
2014 was saying as Google has made it easier for app developers to hide the amount of
permissions it will be requesting by only asking them to disclose the permission category.
This also has the knock on effect of preventing the user from knowing the true extent in

32 | P a g e
which app has access to their phone, which prevents them from making an informed decision
about what apps to install on their mobile phone.
The information gained from figure 6 proved a surprise, since it shows how wallpaper apps,
which all have the same basic functionality of providing a background for the smart phone,
vary when it comes to the amount of permissions each used. The information shows that the
wide range of 2 to 9 permissions for the apps, this is partly due to the fact that Background
HD Wallpapers with 9 permissions has some more complex features when compared to
Electric Screen Live Wallpaper with its 2 permissions. However, when you combine the
results of figure 6 with figure 9 it creates concerns that the apps could be passing on user
information with advertising companies since 50 % of the personalisation apps examined in
this experiment use 3rd party SKDs to target Ads to the users, which has the potential to
infringe on the users privacy.
The information in figure 9 illustrates that the collection of data does prove to contradict what
was discovered in Appthority, 2013; that entertainment apps shared more information with
Ad companies over Business and Education. By looking at the results from this experiment
Entertainment apps scored joint lowest with Business apps. The other surprise comes from
that fact that Appthority also found Education apps to use Ad networks the least whereas in
this experiment, education apps scored top (Appthority, 2013). The use of Ad network SDKs
was around about the same level as the Appthority winter report 2014 which found the use of
Ad networks to be at 57% whereas this experiment found it to be at 40%. This slight
difference can be easily explained as the information from the services which provided a list
of the SDKs (MyPermissions and PrivacyGrade) were not complete or was not able to access
them as they would not upgrade the user account (explained in project limitations).
The information gained in figure 7 goes in some way to prove hypothesis 3 as it shows that
the app categories with the largest amount of permissions (Lifestyle and Business) require on
average more permissions. However, Personalisation does have the lowest amount of SDKs
and has the 3rd highest average number of permissions, which in a way disprove the
hypothesis. This hypothesis is further proven by the information in figure 7A and 7B where it
illustrates that the top offender for the most permissions and 3rd party SDKs in Education and
Entertainment app categories are the same. In the Education category the offender is Elevate
– Brain Training and in the Entertainment category it is Talking Tom Cat 2 Free, this fact
does show a worrying trend in the way the number of SDKs used will cause the number of
permissions to increase. This means that these two apps will have a high potential to infringe
the privacy of the user since they have an extremely high amount of 3rd party SDKs being
used within the apps. Also a large majority of the apps permissions according to
PrivacyGrade are for functional behaviour. However, a lot of these functional permissions
also double up as a common permission like full network access which is used by most of the
apps examined in this experiment but it is also used by all of the Ad SDKs to target ads
specifically for that user.
Out of the 50 apps analysed in this experiment all of them had access to personal information
according to the MyPermissions app. This did prove surprising as it was expected that it

33 | P a g e
would be extremely high as it was in Appthority's summer 2014 poster (Appthority, 2014(C))
where they discovered that 91% of the free Android apps they tested in their report had
access to at least one risky behaviour (permission). However, it was not expected that all of
the apps tested in this experiment would have at least one, this goes to prove that there is
some serious potential for apps using permissions to infringe on the users privacy and
therefore relates directly to the research question.
Project Limitations
Scale ofthe project
The results were also hindered by the fact that the sample of 50 apps is very small as
companies like Appthority are analysing 400 apps for each of their reports which provides
them with a clearer understanding of the privacy area. Also due to the fact that it was a small
collection of apps it means that the results may not truly reflect the state of the potential
privacy threats from functional permissions.
Issues with chosen Services
The project was limited by the services used to gather information on the 50 apps due to
certain issues which arose with MyPermissions and PrivacyGrade.
MyPermissions
The issues faced when using MyPermissions had to upgrade the account to get access to a full
list of 3rd party SDKs and a reputation score. This became a big issue as to upgrade the
account, MyPermissions had to be contacted and then they would enquire to why the account
needed upgraded. Once they found out that the account was being upgraded for academic
purposes they offered to do it for free and asked for the app list. However, they never
upgraded the account and the app information was never sent through which meant that a
comparison of SDKs could not be made as only 2 SDKs were shown for each app and they
told you how many SDKs each app used. The other issue was that MyPermissions was first
emailed in 31st January 2015 where they enquired about why the account was needing
upgraded and then never answered anymore emails until yet another enquiry was made in
March 2015 when they said they would upgrade the account and provide the app information
but never did.
PrivacyGrade
The issues faced when using PrivacyGrade were that not all of the apps were on the service
which meant there were small gaps in the information obtained about each app. They also had
not analysed all of the permissions for all of the apps which limited the experiment as
PrivacyGrade gave a reason as to why each individual permission was being requested, which
made differentiating between functional permissions and non-functional permissions easier.

34 | P a g e
Future Work
This experiment shows that there needs to be more work into letting the user control the
permissions of apps, since currently it is very difficult for the user to find out what individual
permissions are being requested. This goes back to what Gates(Gates et al., 2012) was saying
as there is currently no effective way where the risks and benefits of permissions are being
portrayed to the user. This in some respect may be down to the fact that a large number of
users do not read the permissions of apps in the first place.
Also from the fact that this experiment found that all 50 apps have access to personal
information shows that there needs to be an international effort in controlling what apps, on
all platforms, not just apps from the Google Play store for Android, can access. This means
that companies like GSMA who provide guidelines for app developers need to continue
lobbying the EU to get their guidelines made into to law when developing apps as they
provide a set standards in the why apps can use high risk permissions in a safe manner, which
protects the privacy of the user. The reason for this to be focused on is due to the fact that all
of the guidelines are currently optional which means app developers do not need to adopt
them. By adopting them at an international level means governments can clamp down on bad
practices. This work relates back to section 1.1.5 of this report.
The work carried out on this experiment and work carried out by Appthority has highlighted
the privacy implications that SDKs cause and for this reason, there needs to be work carried
out in this area. This is required since this experiment discovered that 40% of the apps
analysed used Ad networks however it did not discover how many Ad networks were used
for each of the apps, whereas Appthority has analysed apps which have contained over 15 Ad
network SDKs (Musthalar L, 2013) which further highlights the issue of 3rd party SDKs.
Conclusions
To conclude, the surprise in there being 100% of the apps tested in this small scale
experiment, having access to personal information means that the privacy of the user is in
danger, as the user has now lost control of the their own information. The scale of the
problem will not be shown within the confines of this experiment as the data set was far too
small but the fact that 100% of the apps tested do have access to personal information does
mean that the potential for apps which are using the functional permissions to infringe on the
users privacy is very real.
The results of the experiment did prove that Google has simplified their permission system
too much, as it only provides the permission categories and not the actual permissions. This
problem puts the user’s privacy at risk as this experiment has demonstrated that the categories
do not portray the true extent in which permissions are used. Google does provide a
description of each category to help to explain to the user what each category may provide
the app with access to. However, after looking at the results of this experiment it would be
beneficial to the user to be able to access the individual permissions within each category.
This would provide the user with the ability see what type of permission is being asked for as
Read SMS and Send SMS (may cost the user money) are under the heading SMS. This
obscurity is what needs to change as simplifying it by just displaying heads works to an

35 | P a g e
extent as it provides a rough idea of what the app is going to need access to. There should be
an option which provides a list of the individual permissions within each app category, as this
combines the need for a simple way for users to take back some control over their privacy
without interfering with the functional permissions required for each app. The permission
system would also benefit with explaining why each app requires the permissions as it would
build trust between the user and the app developer as it lets users know why their personal
information is required and allows them to see if it will be shared with 3rd party SDK owners.
By doing this it would be easier to differentiate between the apps that use the user’s personal
information for functionality and which ones use it to make money from Ad networks as this
experiment uncovered that 100% of the apps examined had access to personal information.
The results also highlighted the difference with similar apps by looking at the wallpaper apps
in the Personalisation category which showed that apps which do the same basic function
vary widely in the amount of permissions used. This does cause some concern for the user’s
privacy but for the most part the increase in the number of permissions was required to
provide other features within the app. Also the fact that the Personalisation app category was
found to use the least number of 3rd party SDKs which does go in some way to prove that the
apps are using the permissions to aid the functionality of the apps and not to make money
from the users data.
The correlation of SDKs and permissions is worrying as it is shown that generally speaking
those with the largest amount of 3rd party SDKs have the most permissions. This does provide
the apps with the potential to infringe the user’s privacy as they may be requesting certain
permissions for the SDKs to operate, so that they can gather information about the user. This
however is speculation as more work into 3rd party SDKs is needed since currently there is a
large amount of SDKs out there and it is hard for the user to differentiate between a non-
functional SDK and a functional SDK which provides a useful function for, example provides
an authentication framework, provides the app developer with usability data etc.
Overall there is a fine line between functionality and privacy and this experiment shows it.
The need for apps to use high risk permissions for their app to function is always going to
come with the potential to infringe on the user privacy. For the issue of Functionality VS
Privacy, the Android permission system does have its failings as it does not provide the user
with enough information for them to question why an app is asking for a specific permission.
Until Google provides a permission system which combines the permission category with the
individual permissions, the user is always going to be in the dark about what apps are
accessing. By doing this and by incorporating the risk score method suggested in Chen (Chen
et al., 2014) where they found that it was more effective than just listing permissions, as a
normal user did not always understand what was being requested and why they required
access to that permission.

36 | P a g e
Appendices
A) The Chosen Free Android Apps
Business apps
App Name Developer
Job Search Indeed jobs
Facebook pages manager Facebook
Monster job search Monster worldwide
Microsoft remote desktop Microsoft corporation
Google my business Google Inc
Yammer Yammer Inc
LinkedIn Connected LinkedIn
Jobsite jobs Evenbase jobs
Lync 2013 Microsoft Corporation
Docs To Go™ Free Office Suite DataViz Inc
Education apps
App Name Developer
Duolingo: Learn Languages Free Duolingo
Driving Theory Test Deep River Development
Hazard Perception Test Free Focus Multimedia
Babbel - Learn Languages Babbel
Hazard Perception Test Deep River Development
Peak brain Training Peak Labs
Elevate Brain Training Elevate Labs
Puffin Academy Cloud Mosa Inc
Show my Homework Teacher Centric ltd
ABC PreschoolPlayground Free Sound House LLC
Personalisation apps
App Name Developer
Zedge Ringtones & Wallpapers Zedge
Smart Launcher 2 Ginlemon
Backgrounds HD wallpapers Stylem Media
Nova Launcher Tesla coil software
Waterfall Live Wallpaper Creative Factory
Rainbow Love emoji Keyboard Colorful Design
Super Funny Ringtones Crystal Clear
Electric Screen Live Wallpaper Iim mobile
Digital Clock Widget Xperia Lazar Dimitrov
Asteroids 3D Live Wallpaper Sky Drivers
Lifestyle apps
App Name Developer
Tinder Tinder
Gumtree Gumtree UK
Domino's Pizza Domino's Pizza group Ltd
Auto Trader Auto Trader

37 | P a g e
Slimming World Slimming World
App of the day -100% Free AppTurbo
Hot or Not Or Not Limited
Match.com Singles dating app Match.com LLC
Hungryhouse takeaway Online Hungryhouse
Showbox Showbox Group limited
Entertainment apps
App Name Developer
BBC Iplayer Media Applications Technologies for the BBC
Netflix Netflix Inc
Twitch Twitch Interactive
Viewster - movies, TV, Anime Viewster
IMDB movies TV IMDB
Demand 5 Channel five
Funny Jokes LOL! (English) Fortune Apps Dev
PlayStation®App Playstation mobile Inc.
Talking Tom Cat 2 Free Outfit7
TVcatchup GZero

38 | P a g e
B) Top 20 app list for each category according to App Annie
(For this project the free apps category is what will be used)
Business apps

40 | P a g e
Personalisation apps

42 | P a g e
Entertainment Apps

43 | P a g e
C) Googles PermissionCategories

47 | P a g e
D) Risk assessment Service Findings
Risk
Assessment
Service
Requires
MDM
software
Cost of
the
service
Provides a
permissions
list
Provides
a list of
3rd
party
SDKs
Provides a
reputation
Score
Easy to
use user
interface
Easy to
install
and setup
Types of
apps
examined
Appthority
(Appthority,
2014(b)).
Yes N/A N/A N/A N/A N/A N/A Paid and
Free
Trend Micro
(Trend micro,
2012)
Yes N/A N/A N/A N/A N/A N/A Paid and
Free
MyPermissions
(MyPermissions,
2014; Perez,
2013)
No Free
but
costs to
upgrade
to get
extra
features
Yes Yes Yes Yes Download
app from
Google
play store
and free
to use
website
Paid and
Free
PrivacyGrade
(PrivacyGrade,
2014)
No Free Yes Yes Yes Yes Free to
use
website
Free
AppBrain
(AppBrain,
2012)
No Free Yes No Yes Yes Free to
use
website
Paid and
Free
Note: If the risk assessment service requires mobile device management (MDM) software
then the service will not be valid since it would be too expensive to make it a viable option.

48 | P a g e
E) MyPermissons App Screenshot
Note: This is not a screenshot from the smart phone used for this experiment but is the
same interface.

49 | P a g e
References
Albrecht, J. P. & Walshe, P. 2013. Data Protection Debate [online]. Available from:
http://www.vieuws.eu/ict/data-protection-debate-with-jan-philipp-albrecht-mep-pat-walshe-
gsma/ [Accessed 10th November 2014]
Anonymous. 2014(a), “Android Flashlight App Settles FTC Charges”, Computer and
Internet Lawyer, Vol. 31, no. 3, pp. 23.
Anonymous. 2014(b). Mobile Privacy: Consumer research insights and considerations for
policymakers [online]. Available from: http://gsma.com/publicpolicy/wp-content/uploa
ds/2014/10/GSMA-Mobile-Privacy-Booklet_WEBv2.pdf [Accessed 10th November 2014]
Anonymous. 2013, “FTC Issues Mobile App Privacy Guidelines”, Computer and Internet
Lawyer, Vol. 30, no. 4, pp. 42-44.
Anonymous. 2012(a). Mobile and Privacy: Privacy Design Guidelines for Mobile
Application Development [online]. Available from: http://www.gsma.com/publicpolicy/wp-
content/uploads/2012/03/gsmaprivacydesignguidelinesformobileapplicationdevelopmentv1.p
df [Accessed 10th November 2014]
App Annie. 2014(a). The State of Play: A look at the growth of Google Play [online].
Available from:
https://s3.amazonaws.com/files.appannie.com/reports/App+Annie+Special+Report+Google+
Play+2014.pdf?utm_campaign=Google+I%2FO+Meetup+June+2014&utm_source=hs_auto
mation&utm_medium=email&utm_content=13253897&_hsenc=p2ANqtz--
cCeetyprS2GWuFyilsqGL36gJcVc2qzBoQkerf1SHPmTE0nDmPR7X7TnN6qgxhpcigFqkZ
bdZqg165VaHRLHoWeKrXg&_hsmi=13253897?mkt_tok=3RkMMJWWfF9wsRonuqzLZK
XonjHpfsX67%2BkqWaS0lMI%2F0ER3fOvrPUfGjI4ATMRkI%2BSLDwEYGJlv6SgFSrf
EMbFl3rgPUxU%3D [Accessed 8th November 2014]
App Annie. 2014(b). App Annie index – Market Q2 2014: Brazil, Thailand and India drive
Google Play’s Explosive Growth [online]. Available from:
https://s3.amazonaws.com/files.appannie.com/reports/App-Annie-Index-Market-Q2-
2014.pdf?mkt_tok=3RkMMJWWfF9wsRonu6vLZKXonjHpfsX67%2BkqWaS0lMI%2F0ER
3fOvrPUfGjI4ATMFqI%2BSLDwEYGJlv6SgFSrfEMbFl3rgPUxU%3D [Accessed 8th
November 2014]
AppBrain. 2015. Most popular google Play categories [online]. Available from:
http://www.appbrain.com/stats/android-market-app-categories [Accessed 10th March 2015]
AppBrain. 2014(a). Free vs paid android apps [online]. Available from:
http://www.appbrain.com/stats/free-and-paid-android-applications [Accessed 4th November
2014]

50 | P a g e
AppBrain. 2014(b). Most popular google Play categories [online]. Available from:
http://www.appbrain.com/stats/android-market-app-categories [Accessed 4th November
2014]
AppBrain. 2012. Apptimizer: AppBrain’s new tool to understand and improve your app
[online]. Available from: http://www.blog.appbrain.com/2012/11/apptimizer-appbrains-new-
tool-to.html [Accessed 2nd February 2015]
Appthority. 2014(a). App Reputation Report: An Appthority Publication – Winter 2014
[online]. Available from: https://www.appthority.com/resources/app-reputation-report
[Accessed 28th October 2014]
Appthority. 2014(b). How the Appthority Service Works. A Six-Step Introduction to the
Appthority Service Production Flow – Winter 2014 [online]. Available from:
http://www.appthority.com/learn/ [Accessed 8th January 2015]
Appthority. 2014(c). App Reputation Report: An Appthority Publication – Summer 2014
Appthority. 2013. App Reputation: Appthority Quarterly Publication – February 2013
Bettini, A. 2012, “The Greatest Risks in Mobile Apps”, IQT Quarterly, Vol.4, no. 1, pp. 14-
17.
Boyles, J. L., Smith, A. & Madden, M. 2012. Privacy and Data Management on Mobile
Devices: More than half of app users have uninstalled or avoided an app due to concerns
about personal information [online]. Available from:
http://www.pewinterest.org/Reports/2012/Mobile-Privacy.aspx [Accessed 23rd September
2014]
Byrne, A. 2013, “Google under fire for app store privacy policy”, Inside Councel. Breaking
News [online]. Available from: http://www.insidecounsel.com/2013/02/15/google-under-fire-
for-app-store-privacy-policy [Accessed 25th September 2014]
Chen, J., Gates, C & Li, N. 2014, “Effective Risk Communication for Android Apps” IEEE
Transactions on Dependable and Secure Computing, Vol.11, no. 3 [Accessed 3rd March
2015]
Cilley, J. & Sverdlove, H. 2012, Pausing Google Play: More Than 100,000 Android Apps
May Pose Security Risks [online]. Available from:
https://www.bit9.com/download/reports/Pausing-Google-Play-October2012.pdf
Cortimiglia, M. N., Ghezzi, A. & Renga, F. 2011, “Mobile Applications and Their Delivery
Platforms”, IT Professional Magazine, Vol.13, no. 5, pp. 51-56.

51 | P a g e
Federal Trade Commission (FTC). 2013(a). Mobile Privacy Disclosures. Building Trust
Through Transparency [online]. Available from:
http://www.ftc.gov/os/2013/02/130201mobileprivacyreport.pdf. [Accessed 6th January 2015]
Federal Trade Commission (FTC). 2013(b). COPPA – Children’s Online Privacy Protection
Act [online]. Available from: http://www.ftc.gov/ogc/coppa1.htm [Accessed 2nd February
2015]
Federal Trade Commission (FTC). 2011. Mobile Apps Developer Settles FTC Charges it
Violated Children’s Privacy Rules [online]. Available from: http://www.ftc.gov/news-
events/press-releases/2011/08/mobile-apps-developer-settles-ftc-charges-it-violated-childrens
Felt, A. P., Ha, E., Egelman, S., Haney, A., Chin, E. & Wagner, D. 2012. Android
Permissions: User Attention, Comprehension, and Behavior [online]. Available from:
http://www.eecs.berkeley.edu/Pubs/Tech/Rpts/2012/EECS-2012-26.html [Accessed 10th
November 2014]
Gates, C., Li, N., Nita-Rotaru, C., Portharaju, R. & Sarma, B. 2012. Android Permissions: A
Perspective Combining Risk and Benefits [Online]. Available from:
httpswww.cs.purdue.eduhomesgates2publicationssacmat2012.pdf [Accessed: 3rd March
2015]
Gold, J. 2012, “IOS app revenues still four times higher than Android, but Play store growing
fast”, Network World [online]. Available from:
http://www.networkworld.com/article/2161764/smartphones/ios-app-revenues-still-four-
times-higher-than-android--but-play-store-growing-fast.html [Accessed 3rd November 2014]
Google. 2015. Review App Permissions [online]. Available from:
http://www.support.google.com/googleplay/answer/6014972?hl=en [Accessed 2nd February
2015]
Hildenbrand, J. 2014. What some of those scary application permissions mean [online].
Available from: http://www.androidcentral.com/look-application-permissions [Accessed 4th
November 2014]
Hoffman, C. 2014. Android’s App Permissions were Just Simplified - Now They’re Much
Less Secure [online]. Available from: http://www.howtogeek.com/190863/androids-app-
permissions-were-just-simplified-now-theyre-much-less-secure/ [Accessed 2nd February
2015]
Hurlburt, G., Voas, J. & Miller, K. W. 2011, “Mobile-App Addiction: Threat to Security?”,
IT Professional Magazine, Vol. 13, no. 6, pp. 9-11.
Information Commissioner’s Office (ICO). 2013. Privacy in mobile apps – Guidance for app
developers [online]. Available from: http://www.ico.org.uk/media/for-

52 | P a g e
organisations/documents/1596/privacy-in-mobile-apps-dp-guidance.pdf [Accessed 4th
February 2015]
Information Commissioner’s Office (ICO). 2012(a). Data protection principles [online].
Available from: http://www.ico.org.uk/for-organisations/guide-to-data-protection/data-
protection-principles/ [Accessed 2nd February 2015]
Information Commissioner’s Office (ICO). 2012(b). Guidance on the rules on use of cookies
and similar technologies [online]. Available from: https://www.ico.org.uk/media/for-
organisations/documents/1545/cookies_guidance.pdf. [Accessed 6th January 2015]
Kulesza, J. 2013, “International law challenges to location privacy protection”, International
Data Privacy Law, Vol. 3, no. 3, pp. 158-169.
Lescop, D. & Lescop, E. 2014, “Exploring Mobile Gaming Revenues: the Price Tag of
Impatience, Stress and Release”, Communications & Strategies, Vol. n/a, no. 94, pp. 103-
122.
Musthalar, L. 2013, “How mobile apps can take whatever data they want from a smartphone”
[Online]. Available from: http://search.proquest.com/docview/1282095477?accountid=15977
[Accessed 10th April 2015]
MyPermissions, 2014. MyPermissions – Terms of Use [online] Available from:
http://www.mypermissions.com/terms [Accessed 2nd February 2015]
Pearce, S., McDonald, J. & Whitfield, K. 2014. “Is 2014 the Year UK Privacy Law Catches
up with Mobile App Developers?”, Society for Computers & Law [online]. Available from:
http://www.scl.org/site.aspx?i=ed36652 [Accessed 2nd February 2015]
Perez, S. 2013. Personal Security Startup MyPermissions Adds Real-Time Protection For
Twitter [online]. Available from: http://www.techcrunch.com/2013/08/19/personal-security-
startup-mypermissions-adds-real-time-protection-for-twitter [Accessed 2nd February 2015]
PrivacyGrade, 2014. What is PrivacyGrade.org? [online]. Available from:
http://www.privacygrade.org/faq [Accessed 2nd February 2015]
Rakestraw, T. L., Eunni, R. V. & Kasuganti, R. R. 2013, “The mobile apps industry: a case
study”, Journal of Business cases and Applications, Vol. 9, no. n/a, pp. 1-26.
Schick, S. 2014(a), “App Annie: freemium makes up 98% of Google Play revenue”,
FierceDeveloper [online]. Available from: http://www.fiercedeveloper.com/story/app-annie-
freemium-makes-98-google-play-revenue/2014-06-30 [Accessed on 25th september2014]
Schick, S. 2014(b), “App Annie: Emerging markets drive Google Play downloads past Apple
App Store”, FierceDeveloper [online]. Available from:
http://www.fiercedeveloper.com/story/app-annie-emerging-markets-drive-google-play-
downloads-past-apple-app-store/2014-08-
01?utm_medium=rss&utm_source=rss&utm_campaign=rss [Accessed 3rd November 2014]

53 | P a g e
Trend Micro. 2012. Mobile App Reputation Service – Innovative cloud-based security for
mobile app stores [online]. Available from: http://www.trendmicro.co.uk/media/ds/mobile-
app-reputation-service-datasheet-en.pdf [Accessed 23rd October 2014]
W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung,P. McDaniel, and A. N. Sheth 2010.
TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on
Smartphones. [online] Available from http://appanalysis.org/tdroid10.pdf [Accessed 18th
January 2015]

54 | P a g e
Bibliography
Anonymous. 2012(b), “Is it legal? Privacy”, Newsletter on International freedom, Vol.61, no.
3, pp. 126, 132-137 [online]. Available from:
http://www.search.proquest.com/docview/115392533?accountid=15977 [Accessed 3rd
November 2014]
Benisch, M., Kelly, P. G., Sadeh, N. & Cranor, L. F. 2011, “Capturing location-privacy
preferences: quantifying accuracy and user-burden tradeoffs”. Personal and Ubiquitous
Computing, Vol. 15, no. 7, pp. 679-694.
Franklin, M., Droutsas, D., Rodriguez, N., Walshe, P., Antokol, J. & Sherwood, C. 2013. The
4th Annual European Data Protection & Privacy Conference: Shaping the Future Privacy
Landscape – Agenda [online]. Available from: http://www.eu-
ems.com/agenda.asp?event_id=147&page_id=1232 [Accessed 10th November 2014]
Harris, M. & Patten, K. 2014, "Mobile device security considerations for small and medium-
sized enterprise business mobility", Information Management & Computer Security, Vol. 22,
no. 1, pp. 97-114.
Hoffman, C. 2013. Android’s Permissions System Is Broken and Google Just Made It Worse
[online]. Available from: http://www.howtogeek.com/177904/androids-permissions-system-
is-broken-and-google-just-made-it-worse/ [Accessed 2nd February 2015]
Rose, C. 2012, “Ubiquitous Smartphones, Zero Privacy”, Review of Business Information
Systems, Vol. 16, no. 4, pp. 187-191.
Quirolgico, S., Voas, J. & Kuhn, R. 2011, “Vetting Mobile Apps”, IT Professional Magazine,
Vol. 13, no. 4, pp. 9-11.

Final report

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (8)

Similar to Final report

Similar to Final report (20)

Final report