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 Blurb
http://www.bgies.com
http://www.bistroblurb.com
http://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.
