What are you looking for?

Are app permissions putting users off?

Last year, the UK’s Information Commissioner’s Office put out a survey suggesting that 49% of smartphone users don’t download apps because of privacy concerns. Given that in 2013, more apps were downloaded than ever before and users spent over $10b in Apple’s App Store, we took a look at the study and have provided our own guidelines to app privacy.

While we welcome the guidelines from the UK Information Commissioner’s Office (ICO) about keeping personal information secure in apps, it won’t stop the lazy or malicious developers from ignoring them.
A survey carried out for the ICO highlights that 49% of participants decided not to download an app due to privacy concerns, however, it doesn’t state which operating system the participants are using.
With iOS, app users are only asked for access to device functions such as the calendar, contacts, camera or location after they have downloaded the app. It will be relatively clear in the case of iOS why the app is trying to access specific functions, as it will relate to the task being carried out.
When downloading apps from Google Play, Android users are told upfront about which of the device features the app would like permission to access.
There are typically three main reasons developers will ask for permission to use features:
  • Firstly, for the app to function the way it was designed, developers will request access to the camera, storage and network communication (for example to take, save and upload a picture to an online service).
  • Secondly, some developers are just a bit lazy and request access to as much as possible.
  • The third is that they are just trying to be malicious.
The results of the survey suggest that participants who chose not to download an app are Android users. When there aren’t clear explanations as to why apps need to access personal information, users could understandably be put off from downloading an app (see picture below for Facebook’s permissions on Android).
Apps on iOS and Android are sandboxed, meaning that data cannot be harvested by other apps anyway, so the apps themselves have to deliberately harvest the data.
There have been some instances, such as Path, where the app was accessing contacts and uploading them to its servers. As the app was about sharing messages and photos with contacts, it would have needed to access the contacts but failed to state that the contacts would be uploaded to its servers.
This led to Path being fined by the FTC for storing information on underage users. Some reports claim that Path had used the stored information on contacts to send marketing messages without the express permission of the user.
At Mubaloo, we would only ever require access to data that we require for the app itself. If that data is coming from a web service we would insist on an SSL connection to protect the data while in transit.
Working with large organisations means we always have to be very careful about what data we store and where we store it. For example, where possible we do not save login credentials on the device and if we do, it is stored in the secure keychain, rather than in plain text.
We have a set of our own internal guidelines and policies that we thought might be a good idea to share in light of the ICO guidelines:
  1. Encrypt data at rest on the device: Any data on the app needs to be encrypted to protect the user in the case of theft or attempts at infiltration
  2. Only access features necessary for the application: If device features need to be accessed, make it clear how it will be used. For example, if it is accessing contacts state that it is so that the user can access them easily in the app or that the information will not be sent to any 3rd parties or stored in the cloud. There is a balance to be struck in that too much information will put the user off reading it and too little and they may not trust the app.
  3. Only send the data that the app requires via any web services and nothing more: Only send the information the app actually needs, there is no point in sending every field just in case. This slows the transfer, makes the API less efficient and puts data at risk. Only sending what is required leads to a far better experience, and a secure experience
  4. Do not store sensitive information for any longer than it needs to be stored: If data, such as contacts is being stored for analysis, only store it whilst algorithms run the analysis. Afterwards, ensure the data is deleted. Users want to know that their data is secure and not being stored remotely without their permission
  5. Encrypt data in transit (i.e. data being sent via a network connection) via SSL connections: Data may pass through various different servers before it gets to its final destination, by using an SSL connection, the data is secured and can’t be easily intercepted
For the enterprise market, we always recommend using an MDM / MAM provider to ensure the device is secured when producing enterprise applications. At the very least with this approach you can ensure a device is passcode protected and dictate the criteria that the passcode has to meet.
By Brett Wickenden, Technical Operations Director, Mubaloo

If you would like more information please get in touch alternatively:

Contact Mubaloo by phone +44 (0)203 327 8333 or email

  • Deloitte Tech Fast 50 winner 2014
  • Appsters winner for best use of API 2014
  • Ranked as the top app developer outside of the US by research firm Clutch
  • UXUK Winner 2014
  • footer-TRW
  • Mubaloo innovation lab
  • footer-Mubaloo

Company registration number: 0‌6770774.

Registered address: Mubaloo, 3 Grosvenor Gardens, London, SW1W 0BD