On Fri, Oct 1, 2010 at 2:21 PM, Chris Palmer <[email protected]> wrote:
> 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.droidsecurity.com/ would disagree, although I agree they are spinning huge piles of bs and fearmongering. More to the point, "am i on the home screen" or "what is my battery level" (both reasonable interpretations of "PHONE_STATE") doesn't translate, to most users, into "send my phone number to a third party who's privacy policy may not even exist". ( http://groups.google.com/group/android-developers/browse_thread/thread/c97c3eb5dcef0519is an earlier push about this.) > 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. > > To continue along this line, I think "phone state" is a very misleading name anyway - "access your phone number, IMEI and other phone information". "Phone state" sounds like "awake, asleep, dim" "no data" etc.. > 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. > > OSX keychain is a great counter-example, and passes the grandmother test: an app can get account (or other secret) information by asking the user. The user can say "yes", "no", or "always yes"/"always no". (Since its a general purpose system, the user may be required to authenticate - not amazingly feasible on android, although an optional security PIN could work.) Windows popup-of-doom (going all the way back to ... blackice? or the other one? anyway, >10 years ago) handle it better. "This app is attempting to do this SPECIFIC thing, right now." Not "Please allow this app to do some or all of this large, vague list, at some point." > 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. > > A user who is confused by the addition of "remember these permissions" (or possibly just an "Advanced" button) is not going to get that far to begin with. For the more advanced users, there is no way to teach them differently right now. 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. > That sounds a lot more complex for the standard "click ok to make this work" case. > 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. > > Older API versions get 'no data', not a new, api-breaking SecurityException. (For example, no gps fix. No data network available. No contacts. No accounts. No sd inserted. No phone number, or a localized false number such as 555-555-0000. Etc. These are all events that could occur anyway in the device. Off the top of my head, I can't think of a permission that couldn't be spoofed in this way - if there is, it is worth evaluating whether it should be disablable in the first place..) > 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]<android-security-discuss%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/android-security-discuss?hl=en. > > -- 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.
