Dear Tim, thank you for your reply. On Friday, August 17, 2012 12:00:31 AM UTC+2, Tim in Boulder wrote: > > On 8/16/2012 2:31 PM, omoling wrote: > > Honestly, reading your comments, it seems strange to ask oneself why > > an app requires a permission you don't see the purpose of. > > The problem is that you're asking yourself why an app requires a > permission, and YOU (or your users) are the ones trying to figure out why > it would need that permission, when neither you nor (and especially) your > users are qualified to judge in all cases (notably your comments about how > READ_LOG can, and by implication should, be accomplished via other means). >
Not really. Do you see any kind of users' answers/explanations in Apprivacy?.. > > > I never(!) said READ_LOG is unnecessary, read more carefully. > > You did imply that people who used it were being lazy or uncreative in > their programming practices. If it CAN be necessary, then why would you > insult people who use it? It's this attitude of "I know best" when you > clearly don't have the right expertise to judge that really angers people. > Tim, I did not imply that. I quote myself: "There are lots of ways to do some good debugging without reading log files", I don't see the lazy and uncreative parts... do you? And it does neither imply that it might be the best or worst way to do debugging. > > > Also, nobody can deny that the log file might(!) contain private data. > > From really badly written apps? Sure. But Google failed to give us the > permission that we really need -- read OUR log info only. > You got it. I don't think you assume all apps are well written, do you? > > And I hope you never, ever run applications on Windows, Mac OS X, or iOS, > since in all three cases the developers can "spy" on lots of personal data > without your knowledge. And what about root exploits in Android -- a real > bad player could simply include one of those (hidden, of course) in his > app, and use it to bypass permissions entirely. An app with no permissions > whatsoever could then be given the green light by your app! How is your app > "protecting" people, exactly? > I miss the part where I'm saying I'm "protecting" users. I try to inform users in a better way that it is done so far. It is up to the users to decide which apps they install and which apps they keep installed. Anyway, this also is a kind of protection, though information. > > I would like all apps to be transparent about privacy, but it is not the > case! That's why > > Apprivacy was released. > > But every single app in the store ALREADY has a list of permissions that > it requires, along with a (sometimes TOO scary, but never erring the other > way) description of what it does. This is the list you're evaluating, in > fact! So Apprivacy does exactly what the market/play store already does for > users, only more so on the "scary" and less on the "reasonable analysis" > side of the equation. > Exactly. The only difference is that Play does show it in a very short form, I like to have more information about the matter. > > >> 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. > > What IS the purpose, then, other than amplifying the already-too-scary > permission description Google makes people accept before they can install > any app already? Do you attempt to look at a privacy policy and see if they > make an effort to explain all the permissions the app uses? That would be > easy enough -- look at the privacy policy and the description for specific > permission names. > We obviously don't agree on this point Tim. I think they are not "scary" enough since I believe users do usually not open the details of the list of required permissions, and from the short description you don't understand much. > > You say that opening the apps' code and analyzing them isn't "the purpose > of Apprivacy." I thought the "purpose" was to help protect a user's > privacy? I submit that opening up the apps is the ONLY way to actually > accomplish that purpose to any degree beyond what Google already built into > Android. > Sure. I quote my first post here: "... I released Apprivacy recently with the aim of motivating users to be more aware of how installed apps deal with their privacy.". This is the aim of Apprivacy. > > In particular, the "users doubt" feature is a terrible idea where people > can crucify an app with ABSOLUTELY NO EVIDENCE -- your own screenshot shows > that you questioned EVERNOTE, of all things! It has a HUGE number of > features that tie into various corners of Android, so of COURSE it needs a > lot of permissions! This is like having people vote for who is likely to be > a criminal -- guess who will get the most votes? The one who already HAS > the most votes! And your app gives it a red banner just for HAVING > permissions, so many will already get a negative vote! Either an app is > safe or it isn't; a user's opinion isn't going to affect reality; it just > makes it MORE scary. > > You've invented app lynching/witch hunting, bringing mob mentality to app > rating, and you expect developers to "deal with it" and not complain? An > app is a black box. A user clicking "doubt this app" is them looking at the > box and taking a guess, and you're string some apps colored red even though > that doesn't mean anything. This isn't DATA, this is polling people to find > out how long the king's nose is instead of just MEASURING it. > > The Android permission system is probably a good thing overall, limiting > access to apps that actually need it, and making users aware of what apps > need what permissions. But its downside is that with transparency come > users like you who, now that they have that visibility into what an app > needs to do, are being freaked out by the sheer quantity of permissions > required by complex apps, and who therefore "doubt" apps from well-known > and high visibility companies like Evernote. FWIW I doubt Facebook's > integrity and privacy policies, but that is 100% orthogonal to what > permissions their app requires; if I trusted Facebook, the fact that it > required 20 permissions would be irrelevant. I don't trust Facebook, and > their app would have to require no more than Internet permission before I > would be happy using it. > In my opinion, these are some more +? on the Facebook app from your side. > On the other hand, I de facto trust Google with the information on my > phone (they developed the OS after all! If they were going to be evil, they > could do it without asking permission...), and so their apps asking for > more permissions seems completely harmless to me. You previously said you > wouldn't even install an update of a Google app when it required more > permissions. > Tim, I didn't say that, please read MY posts again. > In another breath said that asking for permissions an app doesn't need yet > was wrong, and that users should just accept it when you ask for more > permissions later. Which is it? You won't even upgrade a GOOGLE app when it > asks for more permissions, but you expect "users" to happily upgrade an app > from a developer they've never heard of because it's asking for more? > I don't see the point in not trusting unknown developers. I don't trust developers who ask to see private date I don't see the purpose for in their app. > > I still think you need to find a new niche. You're not increasing the > privacy of users at all, which is the stated purpose of your app, since all > you're doing is parroting the permissions the users already can see, and > allowing them to lynch apps randomly. Can you point to a SINGLE thing > you're doing that DOES actually increase a user's privacy over what the > Google permission system does now? > Tim, again, the purpose is stated in my first post here. > > Tim > 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/-/sKdvcHiFLOsJ. 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.
