Understanding Banking App Permissions

Understanding Banking App Permissions Image

As an application developer, there is one type of app review that I am always pained to see. Here are some real world examples of that type of review, taken from a mobile banking app for Android:

This app wants access to everything on your phone. Access to storage, access to make calls, access to your contacts… I use mobile banking to check balances and make payments. Not to make new friends, spam my contacts, or download stuff to my microSD card. Why does a banking app need to know who my contacts are? Get your priorities straight and clean up this bloated insecure POS. The older, less intrusive version was better.
[ 1 star ]

The permissions are scary… a 4 for now. Would be great if you could create a widget that constantly displays my balance so I can keep track of my spending :[ 4 stars, listed by Google as 11th “most helpful” review ]

 

There are many other similar reviews. So many, in fact, that the first line of the application description reads:

“Please note: We understand your concerns and assure you that your information is only used to make your ( . . . ) [mobile banking] experience an even better one.”

Pic 1
The long list of permissions requested.

Of course, they don’t intend to abuse their users’ data. Here is a list of some of the permissions they use and why they use them (as listed at the link they provide in their app description). I have provided my thoughts on the permissions and their related functionality, below.

System tools: Retrieve running applications

 “Since the app can be closed without signing out, it sits in the background until you open it again.”

My main concern here is that even their justification of why they use the permission is unclear. They very much need to clearly spell out the reason this permission is used. The reason they’ve listed simply describes functionality that almost every application has.

Services that cost you money: Directly call phone numbers

“This permission gives you the option to call the bank directly from the app even if you don’t have a voice plan.”

The functionality in question, making a phone call without a voice plan, is almost never going to be necessary. Most users with the application will not try to call from the app, the ones that do will very likely have a voice plan (they are using a smart device, after all).

It is a trivial task to cause tapping a phone number within your application to open up the Android phone application, presenting the dialer with the number filled in. This can be done without requesting any permissions. This would allow them to remove a scary sounding permission “Services that cost you money”, and the ‘loss’ of functionality would have a minimal impact on the user experience.

Hardware controls: Take pictures and videos

“With the save card feature you can add a thumbnail (or avatar) to the card. Take one using the camera on your device or choose from your photo gallery.”

As irrational as it may be, I think the first thought many people will have is that this could be used to spy on them. The problem compounds because without seeing the explanation of the purpose of the permission, it is hard to think of any reason a banking application should need to access your camera. On top of all this, I think the utility provided by allowing users to add an avatar to their cards is minimal. The user could just as simply nickname their card, requiring no permission.

This is the best candidate for removal of all the permissions listed. The fact that allowing camera access to an application is something users are likely to think twice about, coupled with the use of the permission being minimal, makes requesting this permission a bad idea.

Your personal information: Read contact data, write contact data

“You can add an e-Transfer recipient from your contact list, and add branch contact details to your address book from the locator.”

 Requesting this permission is a tough sell, at the best of times. You are requesting intimate details about a user, and giving yourself permission to add, modify, and delete that data. Again, this is a permission a user will not be able to immediately figure out. Why would a banking application need to read and write contact data?

 In this case, the provided functionality is useful to the application, but I think this is an example of an application overstepping its use cases.

 I think “write contact data” should be removed. There is little reason to add the branch contact details to your address book, and I think application analytics would quickly reveal the functionality is almost never used.

 

What to do

The unfortunate reality of the situation is that some users will almost always think you are overstepping your boundaries by requesting any permissions at all. Simply including analytics in your application requires the “Device Identifying Information” permission on BlackBerry 10. The  name and description of this permission could alienate users and lead them to believe you are tracking them, personally, in some way.

Every time you choose to include a feature that requires a permission to implement, you should very closely weigh the benefits of the feature vs. the potential user backlash. These days, with recent leaks outlining wide-reaching data collection policies of the NSA, many people are becoming more and more aware of who they are giving out their personal data to. This does not mean the user will take the time to research whether your intentions are good. They will make a snap decision on whether or not to trust you. Requesting a large list of permissions is not a good way to have this snap decision made in your favour.

This was just a brief overview of some potential permissions you may want to closely review before choosing to include related functionality within your application. There is an expansive list of potential permissions to consider and evaluate before choosing to use in your application. The functionality you have in mind may seem great, to you, but if it requires too many permissions you should very closely evaluate the benefit of the feature vs. the cost of requesting the permissions.

 Even before the user launches your application, they will see the permissions you are requesting. This is the true first impression of your brand, once the user has decided to give your app a chance. You want to make your first impression a good one, do not ruin your impression by requesting an ill-conceived list of permissions.