Ideally, as a user, I would like to:
1. Have app developers be able to note specifically what each
permission they are requesting is for.
2. On install, have the ability to 'uncheck' any permission that I
don't feel comfortable with (otherwise would install with default
requested permissions).
I think another feature would be fantastic is combine a domain white
list with Google's already existing site safety warning database.
That way user would feel more comfortable with trusting apps accessing
certain websites.
--
You received this message because you are subscribed to the Google
I don't think users would be confused by a developers extra text
explaining what they plan on using the permission for. It could even
be highlighted in a different color, or it could say reason from
developer:. I'm not convinced yet of your argument of why this is
more confusing or worse.
-niko
On Aug 30, 6:44 am, Dianne Hackborn hack...@android.com wrote:
Yes, this is another common request, and another one where I think the
solution is much worse than the problem. Putting application justification
about what it will do with a permission next to the OS's assurance about
what it
Separating some code into a separate .apk doesn't really improve
security, it's only a way for the user to adjust his/her comfort level.
There is nothing preventing two separate .apks, one with read contacts
and the other with internet permissions to do exactly the same as one
malicious app,
Interesting debate. And from a technical perspective I really like the
simplicity of delegating responsibility and permissions to separate
apks that have discretely defined scope. I'm just not sure how
practical it is.
If you look at the permissions that are most contentious in
combination :
On Mon, Aug 30, 2010 at 3:11 AM, Kostya Vasilyev kmans...@gmail.com wrote:
There is nothing preventing two separate .apks, one with read contacts and
the other with internet permissions to do exactly the same as one
malicious app, steal contact info. It might not be obvious to the user at
all
There is a fundamental problem that at the point you ask the
permission, the user is wanting to accomplish some task at hand, and all you
are doing is bugging them.
That's not always true.
My app requires around 30 permissions, which obviously is off-putting
to some/many people.
The average
On Aug 29, 9:11 pm, Dianne Hackborn hack...@android.com wrote:
This is a flaw in their design (and in the design of current ad servers as
well). By having you link their code into your app, you are required to
take responsibility for their permissions. Yet it is their code, you don't
have
I think its going to be very difficult to prevent applications without
network or sms permissions from leaking any data they can obtain to
the outside world by means of another application that does have those
permissions.
Its even possible for an application without network permissions to
Look there is a point where this was taken as an insult and I didn't
mean that. I simply meant Apple, a company who is notorious for a good
user experience all around, even has dialogs prompting users for extra
permissions. Yes I don't agree with their model of the wild west.
However if an app
Dianne,
Sorry but you are wrong. When my wife got her Droid and started installing
apps, she quickly came to me asking about a game she was installing that
said it would read her contact data. She knew what that meant, and wasn't
happy about it, and decided not to install the app.
If my
It turned out to be a big issue for our app too. We have several
comments from concerned customers why we need this and that
permission. Many permissions are needed only to execute specific and
often rare feature like we pre-fill customer's email address when
sending request to customer service.
On a somewhat related note, I decided I would try to integrate the
Bump functionality into my app -- some users asked for ways to
exchange transactions between phones in the family, and this seemed
pretty good.
But then I opened the docs and here it what it says:
Add
uses-permission
On Sat, Aug 28, 2010 at 4:00 PM, Dianne Hackborn hack...@android.com wrote:
My focus right now is on simplifying permissions, giving apps other ways to
do things that are safe without requiring permissions, etc. Making things
more complex for users is not desired.
Let's take the case of
I have not looked at Bump's API. I'll assume those permissions are
truly needed by the Bump API and not just for some sample app.
Off the cuff, the solution for Bump is to:
-- use PackageManager#checkPermission() to figure out if the app has
those permissions (probably requires you to supply the
I also agree that the permissions system is not as good as you are
claiming, Dianne.
First of all, even with a small number of permissions, users really
dont know what the permissions mean. For example, the Get Call State
and Identity permission is too large. It needs to be more granular. I
have
On 29 August 2010 15:05, Mark Murphy mmur...@commonsware.com wrote:
3. Move READ_CONTACTS into some sort of plug-in/add-on APK, so the
main Evernote app lacks the permission, but those who also install the
add-on get the additional feature. Now some percentage of the users
have 2x the
On 08/29/2010 03:05 PM, Mark Murphy wrote:
[ Problems with permissions using Evernote as an example ]
What I'd like to see is:
4. Evernote makes READ_CONTACTS optional. Users see that READ_CONTACTS
is optional, and those who are concerned about it can go toggle it
off. Evernote adds an if()
On 08/29/2010 03:23 PM, Mark Carter wrote:
On 29 August 2010 15:05, Mark Murphy mmur...@commonsware.com
mailto:mmur...@commonsware.com wrote:
3. Move READ_CONTACTS into some sort of plug-in/add-on APK,
[...]
Maybe have some generic READ_CONTACTS app (as opposed to each dev making
their
On Sun, Aug 29, 2010 at 5:31 AM, Zsolt Vasvari zvasv...@gmail.com wrote:
On a somewhat related note, I decided I would try to integrate the
Bump functionality into my app -- some users asked for ways to
exchange transactions between phones in the family, and this seemed
pretty good.
But
On Sun, Aug 29, 2010 at 6:46 AM, Jonas Petersson jonas.peters...@xms.sewrote:
I've been pondering this too for my apps, what I'd like to see is something
that just could call pick contact and the result would be JUST the data
related to that particular contact (for most cases, the DISPLAY_NAME
On Sun, Aug 29, 2010 at 6:25 AM, Jonas Petersson jonas.peters...@xms.sewrote:
On 08/29/2010 03:05 PM, Mark Murphy wrote:
[ Problems with permissions using Evernote as an example ]
What I'd like to see is:
4. Evernote makes READ_CONTACTS optional. Users see that READ_CONTACTS
is optional,
On Sun, Aug 29, 2010 at 12:14 PM, Dianne Hackborn hack...@android.comwrote:
I suspect it hasn't been changed in 2.2, but this is the kind of thing that
we should extend and if we aren't doing it fast enough would most likely
accept patches for.
Btw, for many of these things, solutions can be
On 08/29/2010 09:14 PM, Dianne Hackborn wrote:
On Sun, Aug 29, 2010 at 6:46 AM, Jonas Petersson jonas.peters...@xms.se
mailto:jonas.peters...@xms.se wrote:
I've been pondering this too for my apps, what I'd like to see is
something that just could call pick contact and the result would
On 08/29/2010 09:27 PM, Dianne Hackborn wrote:
On Sun, Aug 29, 2010 at 6:25 AM, Jonas Petersson jonas.peters...@xms.se
mailto:jonas.peters...@xms.se wrote:
On 08/29/2010 03:05 PM, Mark Murphy wrote:
[ Problems with permissions using Evernote as an example ]
In other words, it is your anecdotes against his. I thought I would
not need to remind you, but I guess I do: THE PLURAL OF 'ANECDOTES' IS
NOT DATA!
BTW: adducing the MIDP and Win7 experience is most unconvincing even
for its already unconvincing anecdotal class. This is because in both
those
This flaw in their design is caused by a flaw in Google's design for
distribution of apps.
There is no reasonable way, that does not impose an unacceptable
burden on users, to distribute an app that makes use of third party
functionality like this that should live in its own .apk.
And even if
You rightly say, should be taken down
from Market if it is discovered, but if that need exists, then what
will Google do to reassure users that somebody is watching for such
violations? A Service should not HAVE the ability of share that data
with other Applications unless they too have the same
I've been following this discussion with some interest. I have no
opinion at this point, but here's a data point that might be
interesting.
I'm developing an app with a particular set of POIs (points of
interest). Originally the manifest had uses-permission
I still think if developers at least had the ability to insert
comments into the permissions list thru the XML, it would help clarify
things for users. So for example if I had a reason attribute in the
permissions tag, and that string would be displayed if a user looked
at the permissions of the
On Sun, Aug 29, 2010 at 2:59 PM, Jonas Petersson jonas.peters...@xms.sewrote:
Oh, sorry - let me clarify with an example: In one of my apps (Inventory),
each item may have an owner. For 2.x, I obviously want to present the new
cool QuickContact badge, I have stashed the contact URI (and
On Sun, Aug 29, 2010 at 7:53 PM, niko20 nikolatesl...@yahoo.com wrote:
I still think if developers at least had the ability to insert
comments into the permissions list thru the XML, it would help clarify
things for users. So for example if I had a reason attribute in the
permissions tag, and
On Sun, Aug 29, 2010 at 5:17 PM, Bob Kerns r...@acm.org wrote:
There is no reasonable way, that does not impose an unacceptable
burden on users, to distribute an app that makes use of third party
functionality like this that should live in its own .apk.
How is bump's functionality as a
Let me try this from an end-user perspective. Obviously, the whole
permission feature was designed by a developer and, IMO, it's not a
very good system in a usuability sense.
As an end user, I only care one and ONLY one permission: INTERNET. I
only look for that one permission and the rest is
Yeah... I agree with that, and I'd like to add that what I would really
like to see is a(n easy) Monitor this App setting when you first
install it if it has internet access. How I think it should work is that
if the user wants to monitor the app, every outgoing packet (and maybe
incoming)
Yes.. we do... and I normally don't disagree with you :). But, in this
instance.. I REALLY do.
Let me expand on why I think it is a failing, and maybe you will see
where I am coming from.
I'll use the Window Firewall as an example as it is the closest example
I can think of. It deals with
So I am not saying use a dialog everywhere. I am saying on a per
application basis. The problem with Windows Vista was that it was
everywhere. I am saying in addition to a small wall of permissions
representing the what permissions are needed for the core
functionality of the application, you
On Sat, Aug 28, 2010 at 7:12 AM, Zsolt Vasvari zvasv...@gmail.com wrote:
Let me try this from an end-user perspective. Obviously, the whole
permission feature was designed by a developer and, IMO, it's not a
very good system in a usuability sense.
Oh my, I so very disagree with this.
The
On Sat, Aug 28, 2010 at 11:13 AM, Greg Giacovelli miyamo...@gmail.comwrote:
So I am not saying use a dialog everywhere. I am saying on a per
application basis. The problem with Windows Vista was that it was
everywhere. I am saying in addition to a small wall of permissions
representing the
On Aug 28, 4:00 pm, Dianne Hackborn hack...@android.com wrote:
Sorry but you are wrong. When my wife got her Droid and started installing
apps, she quickly came to me asking about a game she was installing that
said it would read her contact data. She knew what that meant, and wasn't
happy
I've just released an app that requires READ_CONTACTS for the sole
purpose of displaying names instead of phone numbers (of SMS
messages). Its really not necessary at all but just looks better.
Being able to specify that permission as optional would be much
better. If the user rejects it then the
I think I see where you are coming from to a point however honestly I
dislike the global statement. I mean a wall of permissions is going to
turn into white noise to users (in which case the permission could be
for Brick for all they care leading to spam) or paranoid users (in
which case your
On the otherhand, I'd probably want to know if an app was ever going
to ask for a particular permission. Then again, it might be reasonable
if an app, at some point after it's installed, said if you grant me
this permission, I can do this additional function or to fulfill
your request, I will need
I think there is enough evidence that asking permission at time of need
doesn't generally work -- see the MIDP experience, Windows Vista/7 security,
etc. There is a fundamental problem that at the point you ask the
permission, the user is wanting to accomplish some task at hand, and all you
are
I would argue the opposite :)
One of the handiest features of Windows Firewall is that you have the
option of Displaying a notification when it blocks a program, and when
the dialog shows up, you have the option of granting that program
access, and then it never bothers you again.
I do
Well, we disagree.
On Fri, Aug 27, 2010 at 10:27 PM, Brad Gies rbg...@gmail.com wrote:
I would argue the opposite :)
One of the handiest features of Windows Firewall is that you have the
option of Displaying a notification when it blocks a program, and when the
dialog shows up, you have
47 matches
Mail list logo
