On Thursday, August 16, 2012 1:31:14 PM UTC-7, omoling wrote: > > Hi Nathan, thank you for your reply. > > On Thursday, August 16, 2012 8:56:31 PM UTC+2, Nathan wrote: >> >> >> At least you have listened to one suggestion. Take away the "Express >> doubt about this permission" feature, and your app will be even better. >> > > There is no purpose in making just another app which only lists the > permissions required by other apps. > I agree, since the Market already does that. So your strategy is to add more information even if it is useless? It must be hard to give up on code that you have already written. It is much more prudent to omit information that is not useful than to put it in to make your app *look* more useful.
You will be right in planning permission requirements upfront, but so am I > in questioning your permissions until you implement your plans. > Who says you will stop questioning them after I implement my plans? I'm more than happy to explain a permission and explain it is for an upcoming feature if necessary (this is hypothetical; doesn't apply to any app I have now). You can question a permission if you don't use a particular feature or plan to. You can question a permission if you just don't think any app should have that permission, if you don't understand the permission, etc. If a user has an objection to some permission I will be using in a feature next month, yes, I would prefer the user not install to begin with. > I never(!) said READ_LOG is unnecessary, read more carefully. > Yes you did. I read carefully. "not-really-needed permissions, as some SMS managing app requiring access to log files" - you said that. That was repeated in your app's description and comments by you posing as an end user. Access to log files is a "not-really-needed" permission. When others mentioned that they used it for debugging, you said: "There are lots of ways to do some good debugging without reading log files, just saying." It's okay to change your mind. Do you think READ_LOG is necessary? Please answer yes or no. > Sure. Just as a start, explaining clearly why an app requires some > permissions and what the app needs the data for... > > >> Here is a suggestion then. >> >> You can scrape the Market and determine which apps have a stated privacy >> policy url. If it is null, mark the app as NON TRANSPARENT. If it has one, >> mark it as TRANSPARENT, and allow the user to click through to the policy. >> Do this instead of the danger level and expressing doubt, and your app is >> done. Nothing to add. Nothing to take away. It delivers on its promise, and >> won't offend any developers. >> > > This might be your definition, not mine. Btw, such a policy does not imply > transparency. > If the privacy policy explains permissions (mine does) then it meets your definition of transparency as above. Sure, it might not mention permissions, it might not be very helpful, but the users can see it for themselves. Nathan On Thursday, August 16, 2012 1:31:14 PM UTC-7, omoling wrote: > > Hi Nathan, thank you for your reply. > > On Thursday, August 16, 2012 8:56:31 PM UTC+2, Nathan wrote: >> >> >> >> On Wednesday, August 15, 2012 2:36:16 PM UTC-7, omoling wrote: >>> >>> I didn't expect lots of positive feedback from developers, I rather >>> would have liked some feedback to make the app accepted also by devs. >>> Instead, I mostly read comments about how bad it is to show to users what >>> data an app has access to. >> >> >> With all due respect, you need to improve your listening skills. Despite >> all of our hostility, you have received five or six helpful suggestions in >> this thread. You are free to ignore them if they are not what you wanted >> to hear, but they are there. Some suggestions involve taking away a feature >> that you have already spent time on coding, but that is still a positive >> suggestion. Even Tim's suggestion of "Find another niche" was a positive >> suggestion with your best interests at heart. >> > > Thank you, I read carefully all of the comments in this thread, I wouldn't > have posted this topic here otherwise. > > >> >> >>> I'm still happy since I understood that it might not be that clear that >>> my app shows a potential! danger level, it does not show how dangerous an >>> app actually is. That is also not my purpose. I'll try to solve this issue. >>> >> At least you have listened to one suggestion. Take away the "Express >> doubt about this permission" feature, and your app will be even better. >> > > There is no purpose in making just another app which only lists the > permissions required by other apps. > > >> >> About strategies of requiring permissions that will be used in the >>> future, as a dev, you might require as many permissions as you like, but >>> you cannot expect users (like myself) to ignore all of them if I don't see >>> the point about requiring access to whatever private data. Deal with that. >>> >> Adversarial statements like "Deal with that" and you wonder why you are >> having trouble getting positive feedback. Several experienced developers >> have tried to explain this to you, but you insist that READ_LOG is >> unnecessary and evil nonetheless, and insist on saying so to your users. >> Why should we give you more feedback if you are not listening? >> >> Just try adding READ_PHONE_STATE after you have 50,000 daily users >> because some ad network requires it. I dare you. Let us know how it goes. >> > > Honestly, reading your comments, it seems strange to ask oneself why an > app requires a permission you don't see the purpose of. Is it Nathan? In my > opinion it is not. You will be right in planning permission requirements > upfront, but so am I in questioning your permissions until you implement > your plans. I never(!) said READ_LOG is unnecessary, read more carefully. > Also, nobody can deny that the log file might(!) contain private data. > > >> >> >>> I really appreciate transparency and I want my (even if few) users to >>> know why I'm reading their data. I would like all apps to be transparent >>> about privacy, but it is not the case! That's why Apprivacy was released. >>> >> Transparency, huh? Do you have a definition of transparency? >> > > Sure. Just as a start, explaining clearly why an app requires some > permissions and what the app needs the data for... One might argue that it > is no guarantee that the app is not evil. True. Still I regard is as the > better way to go. One might have to analyse deeply an app to evaluate if > the app actually is evil or not, and that is not the purpose of Apprivacy. > > >> Here is a suggestion then. >> >> You can scrape the Market and determine which apps have a stated privacy >> policy url. If it is null, mark the app as NON TRANSPARENT. If it has one, >> mark it as TRANSPARENT, and allow the user to click through to the policy. >> Do this instead of the danger level and expressing doubt, and your app is >> done. Nothing to add. Nothing to take away. It delivers on its promise, and >> won't offend any developers. >> > > This might be your definition, not mine. Btw, such a policy does not imply > transparency. > > >> >> Nathan >> >> > Cheers, > Omar > -- You received this message because you are subscribed to the Google Groups "Android Discuss" group. To view this discussion on the web visit https://groups.google.com/d/msg/android-discuss/-/5OWZ9Bts3VsJ. 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.
