Well, it would be nice to know, upon installation, the total set of permissions that this application *might* ask for. Maybe not requiring an override at install time, but, for example, if the application MIGHT ultimately ask for a combination of permissions that it can't possibly have any legitimate use for, then that would certainly be enough of a hint to figure "hey, this application may not be so nice..."
On Jun 29, 3:39 pm, Brad Gies <[email protected]> wrote: > Yeah.. exactly... except that I would like to see the "Prompt" type of > permissions with two options... "Grant this app forever" and "Grant this > time only and prompt again if needed". > > I also don't think the "Prompt" type of permissions need to be specified > in the manifest, or shown to the user at all, unless it is a separate > category of "Optional" or something like that, because they will be > informed when they are prompted. > > I do like your idea of a log for permission denials... it would be > helpful data to determine how much a feature is used. > > On 29/06/2010 12:15 PM, a genius wrote: > > > > > Sounds like what you need is a "prompt" option for permissions. > > Give permissions 3 states: allowed, denied, and prompt. > > > The way I would implement this is to continue specifying permissions > > in the manifest, but to add a DEFAULT PROMPT STATE option to the uses- > > permission tag. Upon install, the FULL list of permissions should be > > shown along with the DEFAULT states. A request for a "full" permission > > should give the user the option to set it to ALLOWED, DENIED, and > > PROMPT. A request for a "prompt" permission should give the user the > > option to set it to DENIED and PROMPT (but not ALLOWED). Permissions > > not requested should not be shown (as is already the case). Similarly, > > it should be possible to adjust these permissions when you go in to > > Settings --> Applications --> Manage Applications. > > > It would also be nice if there was a VISIBLE CLUE provided when the > > application attempts to use a permission that it does not have. Not a > > prompt for permission, but a LOG of permission denials. This log > > should go along with crash reports to the developer's market console > > -- this would take care of the application developer who failed to > > consider the possibility of permission denial -- so they can see > > crashes, associate them with permission denials, and update their code > > with a try/catch around code that may fail due to permission denial. > > > This was one of the big issues that freaked out GOOGLE regarding > > permission overrides -- that if an application crashed due to denied > > permission, it might be blamed on the platform when it is actually a > > defect in the application. Also, back to Tim's idea of providing fake > > data... that would definitely help reduce the possibility of crashes > > based on permission denial. Some other things it won't help with, like > > receiving invalid data from a web service, but that kind of thing > > really should be anticipated by the developer and should NOT crash the > > application since invalid data is always a possibility when dealing > > with the web. > > > On Jun 25, 3:15 pm, Brad Gies<[email protected]> wrote: > > >> Not to disagree too much with Mark, but here is one scenario (that I > >> have a need for) : > > >> My app uses user groups extensively, and when a user first installs my > >> app, I would have liked to be able to ask them is they want to check to > >> see if any of their friends are already registered on my site. To do > >> that, I would read their contacts (once only) and return a list of the > >> groups their friends are in to see if they also want to join that group. > > >> I decided to scrap doing that because I didn't want my app to have to > >> have the READ_CONTACTS permission whether the user uses it or not, and > >> when they only use it once if they do use it. > > >> AND I can think of many other times I've run into the same issue. I > >> really believe this should be added to all Android permissions... even > >> if it's just a Grant Once type of option, and then hope that developers > >> don't overuse it :). > > >> On 25/06/2010 12:03 PM, Mark Murphy wrote: > > >>> On Fri, Jun 25, 2010 at 2:47 PM, Peter Eastman<[email protected]> > >>> wrote: > > >>>> I'd like to see more permissions handled implicitly through user > >>>> actions at runtime. > > >>> For some fraction of permissions, this makes sense. The fraction is > >>> very very small. > > >>>> For > >>>> example, it's fine for a program to send an SMS message as long as > >>>> it's done through a standard UI that displays the message and requires > >>>> the user to click the "Send" button. That shouldn't require any > >>>> special permissions, and it also should be enough to meet the needs of > >>>> most programs. Permission would only be required to send SMS without > >>>> using the standard UI, and that would be an uncommon thing to ask > >>>> for. That way, it would actually get people's attention if a program > >>>> asked for that permission. > > >>> This is already implemented. It is also implemented for placing phone > >>> calls. > > >>> What the core Android team is trying to avoid is a Vista-like > >>> experience ("the CPU would like to execute an instruction -- allow or > >>> deny?"). > > >>>> No security model can stop all malware, and I think Android does a lot > >>>> better than most OS's, but there's room for improvement. Having a > >>>> program ask you for special permissions should be the exception, not > >>>> the rule. > > >>> Assuming the SMobile Systems survey is accurate, here are the top 5 > >>> permissions requested: > > >>> INTERNET > >>> ACCESS_COARSE_LOCATION > >>> WRITE_EXTERNAL_STORAGE > >>> ACCESS_FINE_LOCATION > >>> READ_CONTACTS > > >>> None of these have an obvious "user action" that fits your proposed > >>> model, IMHO. > > >>> There are certainly ways to improve the user's ability to grok and > >>> appreciate the permissions screen. However, it is unrealistic to > >>> expect that applications will just stop requesting permissions. > > >> -- > >> Sincerely, > > >> Brad Gies > >> ----------------------------------------------------------------------- > >> Bistro Bot - Bistro > >> Blurbhttp://www.bgies.comhttp://www.bistroblurb.comhttp://www.ihottonight.com > >> ----------------------------------------------------------------------- > > >> Never doubt that a small group of thoughtful, committed people can > >> change the world. Indeed. It is the only thing that ever has - Margaret > >> Mead > > -- > Sincerely, > > Brad Gies > ----------------------------------------------------------------------- > Bistro Bot - Bistro > Blurbhttp://www.bgies.comhttp://www.bistroblurb.comhttp://www.ihottonight.com > ----------------------------------------------------------------------- > > Never doubt that a small group of thoughtful, committed people can > change the world. Indeed. It is the only thing that ever has - Margaret Mead -- You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en.
