On Fri, Oct 1, 2010 at 7:03 AM, Disconnect <[email protected]> wrote:
> As Android privacy becomes increasingly under attack, The term "attack" is a little strong, given that nobody is claiming these dubious apps bypass the permission system or otherwise break the Android security model. Note that the TaintDroid video, http://www.networkworld.com/news/2010/092910-android-privacy.html?page=2 doesn't show the install screen. Presumably, the wallpaper app asks for the various permissions it uses, just like all apps. For privacy-conscious users, the combination of INTERNET and (say) READ_PHONE_STATE for a wallpaper app should be a big warning sign. If an app uses the permissions you give it in a way you don't like, why not uninstall it and give it a bad review on Market? TaintDroid seems like a good tool for detecting bad behavior in apps that don't try to bypass TaintDroid. And there's always Wireshark and smali/baksmali. Also, the problem is not specific to Android --- Android just surfaces these pre-existing concerns and deals with them better. Not perfectly, but better. Other platforms give all apps all the goods all the time, no permission screen required. > maybe it is time to > revisit an old idea - allow a user to (temporarily or permanently) remove > permissions from an app. In an earlier message you said users are not going to wise up and will click OK on anything. I don't think you're right about that, but if you are, increasing the complexity of the UX is surely counterproductive. Personally, I'm not against the idea of having the permission screen be (for example) a list of checkboxes rather than a yes/no for all. But we'd have to have some way to cope with all the existing apps that are not prepared to catch the (unchecked) SecurityExceptions they will get when permissions they thought they had are gone. > The UI doesn't have to be a mess, and the API > interface is easily backward-compatible. (Add an API call to find out if a > permission is revoked, and older API apps receive a reasonable, valid "no > data" return on reads and either "temporary error" or "ok" on writes.) You're underestimating the complexity and scope of that project. But it could be a good project. It'd be cool to try out this idea out in Cyanogen or another distribution. If it flies, you could contribute it back to AOSP? -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" 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-security-discuss?hl=en.
