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/-/1zkpt72-R5cJ. 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.
