Here you are considering angry users bothered by newly added permissions (easy to track that), but how about angry users that have never installed your app in the first place just because it requested too much permissions? How do you estimate that? The point seems to be which situation is less harmful.
Diego M. Rosa On Mon, Oct 31, 2011 at 3:44 PM, Nathan <critter...@crittermap.com> 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. > > 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 android-discuss@googlegroups.com. > To unsubscribe from this group, send email to > android-discuss+unsubscr...@googlegroups.com. > 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 android-discuss@googlegroups.com. To unsubscribe from this group, send email to android-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en.
