sent from a mobile device On Oct 31, 2011 12:45 PM, "Nathan" <[email protected]> wrote: > > Recently, I was doing an experiment with Pay per Install advertising, > mostly to report on the results to you guys at AnDevCon next week. > Everbadge, AppCircle, and Tapjoy all required me to add > READ_PHONE_STATE permission to verify installs, not to put ads in my > app ( which I don't), but to be able to advertise my app. My DEMO app > already had this permission, so I added the same permission. > > That was not the stupid thing that I did. The stupid thing that I did > was months ago. > > As recently as July, my app already had the READ_PHONE_STATE > permission. I did get a few questions a month about permissions, such > as: > Why do you want to record my phone calls? > Why do you want to erase my storage card? > Why do you want to read my personal, sensitive log data? > You can thank the Android Market for making the descriptions as scary > as possible.
Actually, that is a pretty scary permission even if most uses of it are benign. You can thank Google for not bothering to separate the ability to read imei from making calls to 1-900 numbers. Or at least that was my understanding of it when I looked into it earlier. At the very least, if you add a permission, any permission, make sure the first line of "what's new" states it and says why. That is your best chance at avoiding the mess, IMO. Fwiw, I think the bank of America app recently went through a similar snag when it added a permission about reading contacts. One of the sensational (pun int) tech news sites covered it in some detail in my RSS reader... > I determined that I wasn't using the READ_PHONE_STATE in the paid app, > so I dropped it. That was the stupid thing I did. No one noticed. > > But when you add it back, and they have to accept the permissions, > EVERYONE notices. (Except for those, of course, who can't figure out > how to update when they have to accept permissions. Those people ask > why you've made five updates in one day) > > In particular it brings out the passive agressive paranoid self > proclaimed privacy crusaders, who go straight to the Android Market to > comment. The comments build on each other. > > -Good app, but why the sudden need to read phone state and identity on > latest update? > -Uhhh... Why? I too wonder about the new phone id permissions. Will > not update until these permissions are either rescinded or explained > persuasively. > (these questions are rhetorical. It doesn't seem to matter if you've > explained it in your app description, latest changes, helpdesk, AND > weekly newsletter. Certainly noone has to update - I don't get any > money for updates) > -Not happy about permission change since buying app. > -Permissions Reduced to 1 star until they remove the newest > permissions ... paid version should have that crap > -Wish I hadn't paid PAID for this app and it is useful but feel DUPED > with the new permissions which are explicitely for ad networks which > track you. Boycot this app. > > Most people who have asked me or read my explanations have responded > positively. But because of this vocal minority, a permission change > has caused a PR nightmare that has distracted me from much more > important work. And because of how slow users are to update, > especially if they have to accept permissions, these comments will > probably trickle in. > > While I don't believe users are actually harmed by this, I could > decide that it is not worth the trouble to explain vs the advertising > exposure. But the damage is already done. No one will notice when you > take away a permission, so these comments are here for life. > > The lesson is this: If you think you will ever use a particular > permission, put it in your app from day one. If you don't think you > will ever use a particular permission, put it in your app from day > one. For example, I'm not currently using READ_LOG permission. I am > asking people to use SendLog to send me a log in case of failures; I > would like to have more integrated crash reporting. But I am certainly > not going to take that permission away in the meantime, knowing I > might put it back. > > Nathan > > -- > You received this message because you are subscribed to the Google Groups "Android Discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to [email protected]. > For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en. > -- You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en.
