Technique to Avoid, #2: Directly Manipulating Settings

by schwiz » Mon, 27 Apr 2009 16:29:38 GMT


Sponsored Links
 Just read the android developers blog post stating that in the new
firmware programs wont be able to toggle things like GPS on and off,
and now developrs only choice will be to open the settings dialog box
so the user can manually change the setting.  Does anyone else think
this will be extremely annoying to the end user?  Apps like power
manager, that you open for a quick and easy interface too turn these
things on and off are no longer going to work?  It won't be able to
change settings depending on if your phone is plugged in or not?  This
has got to be the lamest thing I have ever heard.  Someone else has to
agree with me?

--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by madcoder » Mon, 27 Apr 2009 18:21:41 GMT


 Actually, I HIGHLY disagree.  User security should be of utmost
importance.  I don't mind clicking 'GPS' in useful switchers, then
having it open a dialog where I click one more time to prevent apps
from 'secretly' logging my position.

One of the things I like most about Android are the security
features.  Install an app that wants my location?  Nope.  It wants
access to my contacts?  Heaven forbid!

I can understand your point about not liking the extra step required,
but I feel it's well-worth the security implications.  A possible
compromise might be allowing the user to specify automatic access if
they don't care about security.

Thanks to all the Google engineers for this fix.






--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


Technique to Avoid, #2: Directly Manipulating Settings

by Mike Baroukh » Tue, 28 Apr 2009 00:30:25 GMT


 > One of the things I like most about Android are the security
There is no real security.
I bet I can add any permission I want on an apk and 90% users while 
install it without taking care.

I think it would have been more clever to be able to disable permission 
when installing or even later.
For example, If an application need internet acces and I don't know why, 
I disable only internet access for it.
If later I think there no security issue, I can re-enable this feature.

It would even be nice nice to be able to, eventually, allow permission 
when the application need it, for once or for the whole session.

finally, the choice should be to the user.
actually, it's the application that choose it wants some rights and it's 
android that said "nope, I won't allow you to turn on/off gps".
but finally, the user have no choice ...



Mike

madcoder a crit :


--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by KonstantinDK » Tue, 28 Apr 2009 01:48:04 GMT


 The apps are not reviewed  by google before the are put on the market
like apple does. So, security is a bigger issue here. (If I understand
it correctly)
--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by Mike Hearn » Tue, 28 Apr 2009 02:03:46 GMT


 Hm, if people are just going to accept the permissions without reading
then why make the screen more complicated?

I agree some people will, but the permissions are quite easy to
understand.

Anyway. A simple extension to this system is some kind of trusted
verifier organization who sign packages as well after checking that
they conform to some kind of privacy and security manifesto. Users
implicitly or explicitly trust that authority through some UI - kinda
like how you trust SSL root CAs today.

Now you don't have to think about it anymore.




--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by lbcoder » Tue, 28 Apr 2009 02:45:00 GMT


  think its a great idea to be able to force restrict application
permissions. By the very nature of the system, application permissions
are restricted -- for example, application A has system level
permission only for its own data as well as the data that the OS
explicitly makes available. This is by unix user permissions -- each
application is granted its own unique user id.

Now to just take that one more step, upon an application request for
one of those explicitly granted authorizations, the OS should check
the permissions table to check if that UID has authorization to access
that particular data. This would be on par with the function of
POLICYKIT, which is a Linux authorization control system...
http://en.wikipedia.org/wiki/PolicyKit



On Apr 27, 7:26am, Mike Baroukh <m...@baroukh.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by lbcoder » Tue, 28 Apr 2009 02:46:41 GMT


 h, and contrary to what others above have suggested, I DON'T CARE if
other people use it or just let it slide. Even if there is a button
that says "click here to modify advanced security authorizations", I
would be grateful for it and would *definitely* use it to restrict
applications that try to access things that I don't want them to.


On Apr 27, 2:44pm, lbcoder <lbco...@gmail.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by KonstantinDK » Tue, 28 Apr 2009 04:08:21 GMT


 > Hm, if people are just going to accept the permissions without reading

You are missing the point. NO one ever read the 20p long licences when
they install software, but why is it there? If smth goes wrong, the
developer says: I warned you, read the licence agrement.

So if you grant someone the permission and they screw you, google will
say:it's your fault. Our Android is secure, it's your problem if you
accepted permission without reading.
--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by Jon Colverson » Tue, 28 Apr 2009 12:27:57 GMT


 


You NEARLY made it to the end of a post without UNNECESSARILY
capitalizing any words. Better LUCK next time. ;-)

--
Jon

--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by Jesse McGrew » Tue, 28 Apr 2009 14:41:39 GMT


 


I do. I wouldn't mind if turning GPS or WiFi on and off weren't
something I had to do so often, but they do chew up the G1's battery.
So I have to turn them on when I want them, and for that I want as few
clicks as possible.


Android already has a permission system for such things, and IMO
that's all we need. If an app requests permission to turn your GPS on,
then you know it might do that; otherwise you know it won't.

Jesse
--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by Mike Hearn » Tue, 28 Apr 2009 19:03:25 GMT


 > So if you grant someone the permission and they screw you, google will

The difference between a typical EULA and the permissions screen is
enormous. I don't think they are comparable.

The problem with letting people selectively enable/disable permissions
is that now apps have to handle every possible combination of
permissions. Some of those they will actually need to do something
useful, so you don't win by letting people toggle them on/off, you
just force devs to add their own dialog box showing how to go toggle
the permission on.

I agree that Android needs a better way to handle optional
permissions, and I think prompting at runtime the first time they are
requested would provide a good user experience. But this has come up
many times and the Android core team don't like it, so, for now let's
drop it.
--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by Al Sutton » Tue, 28 Apr 2009 19:20:09 GMT


 To me selectable permissions is the only user empowering way to go.

Take a couple of current examples; 

1) If an accounts package wants the internet access permission you have the
choice of give it full internet access which it could use to send your
account details anywhere or not using it at all.

2) If a messaging program wants location facilities you have the choice of
not using the program, switching off location providers and screwing over
anything you did want to use location facilities, or handing over free reign
to it to publish your location whenever it wants.

Yes it would involve more work for developers, but imho we shouldn't
sacrifice user experience for ease of development, we should force
developers to step up their game to deliver apps that give the users control
over what their 'phone and the apps on it can do.

Personally I think the Internet permission is the worst offender and should
be a lot more fine grained so that developers can specify endpoints and
users see messages like ("This app wants the following permissions; Internet
access to www.paypal.com, s3.amazonaws.com, and www.andappstore.com"). The
current unlimited permission should be carried over if the app really needs
access to any server on the net (and to maintain backward compatibility),
but we should be looking to persuade developers to tell users exactly what
sites their data may go to.

Al.


---

* Written an Android App? - List it at  http://andappstore.com/  *

======
Funky Android Limited is registered in England & Wales with the 
company number  6741909. The registered head office is Kemp House, 
152-160 City Road, London,  EC1V 2NX, UK. 

The views expressed in this email are those of the author and not 
necessarily those of Funky Android Limited, it's associates, or it's 
subsidiaries. 


-----Original Message-----
From: android-discuss@googlegroups.com
[mailto:android-disc...@googlegroups.com] On Behalf Of Mike Hearn
Sent: 28 April 2009 12:03
To: Android Discuss
Subject: [android-discuss] Re: Technique to Avoid, #2: Directly Manipulating
Settings



The difference between a typical EULA and the permissions screen is
enormous. I don't think they are comparable.

The problem with letting people selectively enable/disable permissions is
that now apps have to handle every possible combination of permissions. Some
of those they will actually need to do something useful, so you don't win by
letting people toggle them on/off, you just force devs to add their own
dialog box showing how to go toggle the permission on.

I agree that Android needs a better way to handle optional permissions, and
I think prompting at runtime the first time they are requested would provide
a good user experience. But this has come up many times and the Android core
team don't like it, so, for now let's drop it.



--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by lbcoder » Tue, 28 Apr 2009 21:04:29 GMT


 Nothing better to do A$$HOLE?





--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by Peli » Tue, 28 Apr 2009 22:57:13 GMT


 gt; There is nothing which prevents the

Good point! This means one should be *either* very careful with
applications that require permissions to read contacts or similar,
*or* be very careful with applications that communicate to the outside
world.

For one of the two kinds of apps one should only rely on trusted
publishers or open source projects :-)

Peli
www.openintents.org

On Apr 28, 1:40pm, Tom Gibara <m...@tomgibara.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



Technique to Avoid, #2: Directly Manipulating Settings

by Neil » Wed, 29 Apr 2009 01:36:27 GMT


 




Actually you don't - the permission is "modify global system settings"
and you don't know which ones.

If the API was specific about which settings it was going to change,
and if you could choose not to accept some of the permissions it
needs, that would be my ideal situation.  It's no extra work to check
in the code whether the app has the required permission because you
should have already done that.

Neil

--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. Getting the already set alarm (AlarmManager)

Hello,

I want my app to be able to query the Alarm service to see if there is
a previous Alarm already set for this app, and if not to set one.


I could not find any api to get a list of set alarms or a specific
alarm for that matter.

Can anyone help?

I Appreciate any assistance.

-- 

2. Arabic Support in FROYO

hi all, i want to add arabic support in my froyo code.
Can anyone tell me how?
I have used eclair modded libs and they worked on that.

Can someone suggest code for arabic moded LIBWEBCORE AND LIBSKIA

-- 

3. Audio Capture Play Slowly

4. [SpicaUser - WTShare] Criminal's CM Alpha 8.1. ++

5. CallBack for the recorded block in MediaRecorder

6. How to get Icon of user defined default application

7. Data is not displaying in line