An innocent fallback network
As regular readers may know my LED Flashlight HD app has had quite a tremendous success on the Android market. On this day it passed the 5 million download mark. Champagne. I am a proud leader in the glorious flashlight market.
Because Admob could only fill 98% of my ad requests, I decided to add mobclix as a fallback network using Adwhirl (via a custom command). My colleague Vadim spent some time integrating the Mobclix SDK, following their instructions, all that to fill the missing 2% requests.
I peacefully released an app update which included amongst other compatibility changes the addition of this new network.
So, as one does in this type of situations I went to the plunge pool with my girlfriend – yes, I am on 'holidays' in Portugal as I write this. When I came back to my machine... this Katastrophuck had happened:
I had about three pages of this. Despite not being very attentive to the German lessons in school, I quickly understood this was a serious problem.
Mobclix's SDK requires adding a permission whose name looks rather innocent: READ_PHONE_STATE. As innocent as it may seem to a programmer blindly following a tutorial, the description shown to the user upgrading the app is this:
READ PHONE STATE AND IDENTITY
Allows the application to access the phone features of the device. An application with this permission can determine the phone number and serial number of this phone, whether a call is active, the number that call is connected to and the like.
There is a disproportionate amount of german users reacting to this permission change. I have German users yet they are not the biggest market for this app. I assume that the number of scams related to SMS+ in Germany is just so huge that they are all terrified of being scammed. I must have some hidden german ancestry myself because when I read this description I thought I would never download an upgrade with such a warning.
So I quickly released an other update, disabling Mobclix calls and permissions and apologized to everyone who had e-mailed me in anger.
So who is to blame?
First of all, of course my own sorry ass. I should have read what this permission allowed. My only excuse is that I don't do my Android dev myself because... how do I put it... I don't really admire Android. I still should have reviewed this more carefully. On the other hand, there was a plunge pool nearby.
Mobclix: has a blog post explaining the need for a unique ID and the permissions.
I understand that Mobclix or its partner networks may not use this permission to its full extent and not be as nasty as they seem but whatever the reasons are developer's don't want to explain this shit over and over again in their app descriptions and to every user who e-mails angrily. If this is an issue with users using an OS older than 2.3 then don't serve ads to them if this permission isn't set.
The obvious solution is: do NOT use mobclix if you respect your user's privacy. If the people at Mobclix aim to chip some market share away from Admob they should definitely offer an option to use their SDK without these permissions, even if this means limiting the amount of partner networks. At this point in time they don't. Without this permission calls to the mobclix SDK fail and crash. I for one, chose my user's privacy and removed them. In the long run I prefer happy users, even if that means losing some revenue.
Short said: if Google (Admob) can be the leader without requiring this permission, others networks could survive without it too.
One should note that I still happily use Mobclix as my fallback network on iOS since this permission problem doesn't exist. Or at least it isn't shown in the face of the users big enough to deter them from downloading the app.
Google: There should definitely more granularity in permissions. If all you want is have access to some network information you shouldn't have to require a permission that allows accessing the user's phone number. When Google decided not to have a review process they put the users in a state of fragility. Reducing the span of permissions groups would help reassure them.