back

iconwrite Android permissions or the Mobclix Catastrophy

February 27, 2012, 22:25

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.

WTF !

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.

By Santiago Lema

16 responses to this post

Hello Santiago, Adam from Mobclix here. A couple of items on this post that should be shared to provide a complete picture: -First, some background: some of our ad network partners cannot deal with the error rate of ANDROID_ID (thanks to the pre-Gingerbread days) and require getDeviceId() in order to serve ads. And since most ad networks simply do not serve ads without a unique id, in order for us to continue connecting devs to multiple ad networks, certain compromises have to be made. The Mobclix SDK itself doesn’t use the Read Phone State permission, but without our ad partners, we wouldn’t have ads to serve at all. -Second, this is not a new development. We've had this permission for quite some time, at least 2 years. It's not popular because it creates mis-conceptions, but it is required by some of our publishers to serve advertisements. Not all use it but some do. As always, developer feedback is important to us so if you have specific feedback, please do let me know: adam(at)mobclix(dot)com -Adam

February 27, 2012, 23:23 | AdamL

Hi Adam, thanks for the clarifications (which is the same content as your blog post I already linked to). What Mobclix should do is handle gracefully the lack of this permission and just don't use any network that require it. Even if this means losing 50% of the ads it would still be useful to be able to fill something with the remaining networks. Honestly, It's all a matter of power. If there was no choice, all developers would accept any conditions. We do have choice and currently forcing this permission pushes conscious developers to use other networks.

February 28, 2012, 11:20 | Santiago

I feel for you dude. I put myself in the same position but persisted through. You only get these kind of comments when the change comes in the form of an update. There are a few parties to blame, but at the end of the day, if people get a free app, they need to get education on why the app needs X permission. One of the troubling things is that it's hard to explain to users this without polluting your details page. Ultimately, as I said it's only updates that are the problem. So for all of our new apps we always have all those permissions running so we don't get a case of the 1 stars when it comes time to make more money. I really feel for you, the way we made a come back was by putting in a feedback screen asking people to rate the app. Ultimately for every tin foil hat, there are a lot of happy users.

February 28, 2012, 11:56 | Pork

I noticed the lack of such comments on another (less successful) app which already had these permissions from the start. However we should take into account the fact that people who don't download the app never leave a review (they can't). how many German users (clearly the more informed about permissions) did you lose because of this? It's hard to find which percentage of the users this affects but considering in my case mobclix was just used for 2% of the requests I am probably compensating enough with the increased downloads.

February 28, 2012, 16:55 | Santiago

We definitely considered pushing out the networks and giving the users a choice, however, it would require the creation and maintenance of a completely new SDK, something we couldn't cost-justify. It's very expensive. One of the strengths of our platform is the SDK, which I'm told as aggregation goes, is one of the strongest, most stable out in the market. The market is definitely trending towards decreasing user permissions (not to mention UDIDs) it's something we're keeping a careful eye on. Also, it's worth noting, independent studies make use the 3rd most common ad SDK in the android market, so I'd say you're not alone and the users (by and large) aren't only seeing this with your application. I think because your application is relatively straight-forward, it's confusing to users why this permission is needed (why is read-phone state needed for a flashlight app, or internet for that matter?). I've recommended in the past (as Pork points out) that it minimizes this type of blow-back if the user is instructed on the reasons for the permissions, and the fact that the free app is powered by advertisements. If they don't like it, maybe they can buy it?

February 28, 2012, 18:09 | adamL

As always, an handy post by Santiago! @adamL Don't hurt our intelligence! If your SDK embeds SDKs of other Ad Networks, as they are known and numerable, a simple boolean flag in a configuration file will suffice. If it processes them server-side, well, it's simpler. No need to "require the creation and maintenance of a completely new SDK" or "If they don't like it, maybe they can buy it". A suggestion for the future: "we know about the issue and we are working on it" is what customers expect from their suppliers on "big issues" like that.

February 29, 2012, 12:42 | Daniele

Good

March 10, 2013, 11:00 | nikorn Jampartong

Good

March 10, 2013, 11:00 | nikorn Jampartong

konrad Kredlau

May 12, 2013, 16:49 | konrad

You might not include "spammy" japanese ads popping up with your flashlight app. I manually blocked the ads via the full break down of app functions and activity since installed.

September 20, 2013, 21:54 | LP700

You might not include "spammy" japanese ads popping up with your flashlight app. I manually blocked the ads via the full break down of app functions and activity since installed.

September 20, 2013, 22:10 | LP700

December 20, 2013, 18:50 | Daniel Schop

Hm.. there are no ad popups in my apps. There's only a banner at the bottom, nothing else. If you see something suspicious make sure you didn't get a modified chinese version. There are a lot out there and I can't do much about hem.

February 19, 2014, 08:28 | Santiago Lema

I want it

October 14, 2015, 07:02 | Rosalie

Dkrififeolrfigeukf

January 10, 2016, 19:31 | coulibaly

Dkrififeolrfigeukf

January 10, 2016, 19:31 | coulibaly

Name
E-mail (will not be published)
Comment
rss Blog RSS Feed

rss Comments RSS Feed