Permissions — “May I? May I? Pleaaaaase!”
When an app installation turns into a 5-year-old at the checkout
Recently the NY Times published an article promoting the Signal messenger. I’d tend to agree with the author from a security point of view, but there was one thing that amazed me when I checked out the application in the Android store: the set of permissions it demands
Apart from the two obviously required permissions “record audio” and “full network access” it also demands access to your phone identifier, your contacts, your location, your list of accounts, your text messages, your file storage, and a gazillion other items. Heck, it wants access to your wallpaper.
Even though, such a permission greed is particularly bad for an application with an emphasis on privacy and data safety we shouldn’t single out Signal on this. This crave for permissions is a general issue on platforms with dedicated service interfaces (messages, contacts, calendar, etc.).
I can’t seem to remember when Notepad tried to access my Outlook contacts the last time ....
However the fact that it is notoriously common on those platforms [1] [2] still does not make it any better. Why do applications demand access to all sorts of data, fundamentally irrelevant to their primary functionality?
So let’s have a quick look at a few of those permissions individually from a messenger perspective ....
- Read phone status and identity
That permission group is most likely used to determine the phone number. Signal — like many messengers these days — uses it as the internal user ID.
Why though? Why is it necessary to tie the phone number to an account for an unrelated Internet service? For decades and gazillion of services a screen name worked perfectly well and it was not a necessity to blurt out your private phone number all over the Internet, simply to talk to people and them not immediately having your phone details. - Read and modify your contacts
Signal requires the “read” part to match senders/recipients of messages to the contacts in your phone book. While this is a legitimate reason in the present architecture design, it would not be necessary if they had their own user directory. Regardless of any justification it does expose your entire list of contacts to the service. — As to the “write” part, that is possibly demanded to add new contacts via the service and opens yet another dimension of data access. - Approximate and precise location
Probably to include your location in your messages. Also necessary? - Read and edit your text messages
Why? To be a half baked replacement for your actual text message application, which messengers all actually try to replace? - Read and modify the contents of your USB storage
Most likely used for sharing pictures from your photo galleries — and a free pass for accessing everything in your common storage.
For users of Android up to version 5 that story ends here. You either agree to the application going bananas over your data or you can’t install it.
Runtime permissions
As of Android 6 — or Marshmallow in its slightly sweeter incarnation — there is actually a bit more light at the end of the tunnel with the introduction of runtime permissions. With those, users have finer control over what an application can access and can actually deny undesired requests.
But while this is undoubtedly an important improvement over the pre-Marshmallow permission concept it is still far from perfect. As it is category based it is most of the time an all-or-none decision and several areas are still left unmanaged.
How to fix that?
So glad you asked ;-). Here we go in order of priority and, incidentally, also most likely feasibility
#1 - More and more granular runtime permissions
The introduction of runtime permissions has been a step in the right direction, however Google should now step up that model to give users a larger and more granular set of permissions to manage.
Particularly the following areas should be revisited ....
- Hardware identifiers
For MAC addresses Marshmallow was privacy-wise — once more — a huge leap forward, as it prevents applications from accessing that data and randomises scanning packets (though there are claims neither is properly implemented).
What is still problematic though is the phone number, the IMEI, and the IMSI. Those are still only hidden between a very thin security layer and more control in this area (blocking access and/or randomisation) would be highly desirable. - Networking
Network access is currently entirely unmanaged, an application only needs to list the permission and will receive it (in the era of runtime permissions the user is not even notified anymore). Once the application is installed there is little the user can do to prevent network communication, short of disabling networking altogether.
Some sort of control (be it a basic firewall, a full-fledged one, or just another runtime permission) would be quite desirable as well — many alternative Android distributions do have that feature already. - Storage
Particularly starting with runtime permissions, storage access is pretty well managed in Android. Applications can only access their own data directory, for any external access it requires the explicit consent by the user. The problem is, it still is an all-or-none decision. Something more granular (e.g. folder-based) would be definitely a good choice.
Also, read and write access is currently tightly coupled in one category. That should be unbundled.
Update 03/17: With Nougat’s scoped directory access Google seems to be on the right track about this issue.
Generally, the whole category based permission concept should be reconsidered. There is little sense in offering different permission levels when many of them are cluttered together for no reason. Prime examples would be aforementioned read/write access (calendar, contacts, call log, text message and storage) and phone state. The latter intermingles access to privacy sensitive data (calls logs, identifiers, etc.) with generic phone status queries.
#2 - No all-you-can-eat permission mentality
Developers should finally learn to respect their user’s privacy. There is no need for a flashlight application to access your contacts or your text messages. Heck, it does not even need network access *). It is supposed to turn on and off the camera’s flash — that’s it.
And even if you firmly believe a permission is absolutely and utterly crucial to your application’s core function, that need could easily disappear with a change in architecture (e.g. screen name vs. phone number).
Permissions should be based on the minimum set required to execute the application’s purpose
That quote might come across as quite “puristic” and possibly somewhat exaggerated and that might be even true. Many times the need for a permission will depend on the context and even if that need might not be immediately obvious it might be still perfectly justified in the bigger picture. However the latter should — and can — still not serve as the perfect excuse to simply dump all available permissions into an application’s manifest and happily keep on requesting.
*) If ads are supposed to be the only reason to require network access, one solution could be to have Android offer an AdProvider service instead, which serves advertisements to applications barred from network access. — Make it configurable to different ad provider backends if you want.
#3 - Users need to acknowledge their own personal responsibility
Out of these three probably the least likely to change but still important.
Regardless of what measures the platform took to protect the user’s privacy and how invasive an application attempts to be, it always comes down to the user to make the decision to accept or reject applications’ permission requests.
In spite of smartphones being around for about a decade now, the majority of people still does not seem to care too much about privacy. At the beginning that could be explained with the technical illiteracy of the average user. By now however smartphones, their applications, and their permissions should have become a familiar concept to most people. Yet, many still exhibit the same indifference towards privacy as ever, but then of course complain when their data actually gets abused. This would need to change and people should be more careful and more critical as to what they install and accept.
Unfortunately however, this is unlikely to change but user awareness in this area would push the first two points tremendously more than any article of this kind could ever do.
On a different note, I found the article’s following statement somewhat disturbing
Probably the biggest thing missing from Signal will be many of your friends. The app isn’t as popular among consumers as other mainstream messaging apps, so hanging out on Signal can feel lonely. So if you care about your privacy, other than installing Signal today, you should nag everyone you know to join the service, too.
If all those messengers were actually a tad more interoperable you wouldn’t “have to” nag “everyone you know” to install yet another application, would you? But I assume this is for another rant ;-) ....
