Technique to Avoid, #2: Directly Manipulating Settings

by Tom Gibara » Tue, 28 Apr 2009 19:18:34 GMT


Sponsored Links
 I'm going to repeat a suggestion I mooted a while ago.
In the manifest apps could mark some requested permissions as optional. For
backward compatibility permissions not marked out in this way would be
required. This way developers can either choose for simplicity (or because
its appropriate for their application) to leave all requested permissions
required, or they can weaken their application's requirements.

This could be extended by marking some permissions as recommended, so there
would be three states: required, recommended, optional. Any permissions
which not required could be toggled by the user. By default recommended
permissions would be granted and optional permissions ungranted.

It does increases the number of choices that the installer demands of a user
which is a bad thing, but it provides the best balance of
control/intelligibility/simplicity that I can think of for all parties --
developers and users-- neither of whom need to concern themselves with the
extra options if they want a simpler life.

Tom.

2009/4/28 Mike Hearn <mh.in.engl...@gmail.com>


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



Technique to Avoid, #2: Directly Manipulating Settings

by Al Sutton » Tue, 28 Apr 2009 19:21:45 GMT


 Now that sounds like an immensely sensible (and workable) idea.
 
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.



 

  _____  

From: android-discuss@googlegroups.com
[mailto:android-disc...@googlegroups.com] On Behalf Of Tom Gibara
Sent: 28 April 2009 12:18
To: android-discuss@googlegroups.com
Subject: [android-discuss] Re: Technique to Avoid, #2: Directly Manipulating
Settings


I'm going to repeat a suggestion I mooted a while ago. 

In the manifest apps could mark some requested permissions as optional. For
backward compatibility permissions not marked out in this way would be
required. This way developers can either choose for simplicity (or because
its appropriate for their application) to leave all requested permissions
required, or they can weaken their application's requirements.

This could be extended by marking some permissions as recommended, so there
would be three states: required, recommended, optional. Any permissions
which not required could be toggled by the user. By default recommended
permissions would be granted and optional permissions ungranted.

It does increases the number of choices that the installer demands of a user
which is a bad thing, but it provides the best balance of
control/intelligibility/simplicity that I can think of for all parties --
developers and users-- neither of whom need to concern themselves with the
extra options if they want a simpler life.


Tom.

2009/4/28 Mike Hearn <mh.in.engl...@gmail.com>





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.








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


Sponsored Links


Technique to Avoid, #2: Directly Manipulating Settings

by Tom Gibara » Tue, 28 Apr 2009 19:40:32 GMT


 wo examples among many, but they do highlight two of the most common
dilemmas for users.
I'm not convinced that the general usefulness of a 'domain constrained'
internet permission outweighs the complexity it is certain to entail (eg.
wildcarding subdomains is usually necessary to make it practical, and
implementing it would probably be very awkward, there might be performance
issues too).

Anyhow, I have strong reservations about the security model in general. It's
much better than nothing, and has the virtue of simplicity but my biggest
issue with it is that it does nothing to protect you from collusion between
applications.

To go with your example, one publisher might have an accounts app (which has
requires no internet permission) and another which is say a "tax guide" that
pulls webpages down from their servers. There is nothing which prevents the
publisher either using a sharedAppId, content provider, or even using the SD
Card, to transfer data from one app to the other for the purpose of
maliciously snooping on user data.

In the latter two cases (transfer via content provider or SD card) the apps
could even come from separate publishers who are colluding. I've not seen
anyone else raise these concerns, but it's something that has troubled me
for quite a while.

Tom.

2009/4/28 Al Sutton <a...@funkyandroid.com>


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



Technique to Avoid, #2: Directly Manipulating Settings

by Al Sutton » Tue, 28 Apr 2009 19:58:39 GMT


 y vision of the the domain based internet security is a simple one; string
pattern matching with full subdomain access.

So if an app says it wants access to paypal.com it would get access to any
subdomain (or subdomain of subdomain, etc) of paypal.com. The system
libraries could then throw an exception if that app tried to do a DNS lookup
on any DNS name other than those domains specified in the list specified in
the permissions by doing a simple loop over the list of permission allowed
domains and endsWith check on the DNS lookup request. The DNS lookup result
is then cached as an approved entry and traffic to that address allowed. The
only really tricky part would be dealing with protocol level redirects which
went outside the domain (e.g. HTTP 3xx return codes), but that isn't overly
complex if it can all be handled in the system libraries.

Enhancing it further could add rules for checking for overly wide
permissions (e.g. a request for just .com, .net, or .co.uk).

To me this would give Android users similar features to those many PC users
buy firewalls and anti-virus software for, which I'm sure the Market person
(who I think sits next to a unicorn and the easter bunny) could get a lot of
mileage from.

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.





_____

From: android-discuss@googlegroups.com
[mailto:android-disc...@googlegroups.com] On Behalf Of Tom Gibara
Sent: 28 April 2009 12:40
To: android-discuss@googlegroups.com
Subject: [android-discuss] Re: Technique to Avoid, #2: Directly Manipulating
Settings


Two examples among many, but they do highlight two of the most common
dilemmas for users.

I'm not convinced that the general usefulness of a 'domain constrained'
internet permission outweighs the complexity it is certain to entail (eg.
wildcarding subdomains is usually necessary to make it practical, and
implementing it would probably be very awkward, there might be performance
issues too).

Anyhow, I have strong reservations about the security model in general. It's
much better than nothing, and has the virtue of simplicity but my biggest
issue with it is that it does nothing to protect you from collusion between
applications.

To go with your example, one publisher might have an accounts app (which has
requires no internet permission) and another which is say a "tax guide" that
pulls webpages down from their servers. There is nothing which prevents the
publisher either using a sharedAppId, content provider, or even using the SD
Card, to transfer data from one app to the other for the purpose of
maliciously snooping on user data.

In the latter two cases (transfer via content provider or SD card) the apps
could even come from separate publishers who are colluding. I've not seen
anyone else raise these concerns, but it's something that has troubled me
for quite a while.

Tom.

2009/4/28 Al Sutton <a...@funkyandroid.com>



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

Take a couple of current examples;

1) If an accounts package wa



Technique to Avoid, #2: Directly Manipulating Settings

by Paper Coder » Tue, 28 Apr 2009 20:04:24 GMT


 xcellent point Tom!

It would also be nice to see information about what shared access is
required when installing. Yes, more work for both the coder and end user,
but much more secure.

As is stands now, I don't install hardly any apps that want internet access
unless I feel I really need that app. This limits the number of apps I'm
willing to download and try out. Giving me the option to deny permissions
would be wonderful.

Perhaps the next update (Cupcake -> Fruitcake? :P


On Tue, Apr 28, 2009 at 6:40 PM, Tom Gibara <m...@tomgibara.com> wrote:


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



Technique to Avoid, #2: Directly Manipulating Settings

by Paper Coder » Wed, 29 Apr 2009 10:56:55 GMT


 Indeed!






3:21 am, madcoder <paperga...

all we need. If an app r...
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

--~--~---------~--~----~------------~-------~--~----~ This message is part
of the topic "Technique...

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



Other Threads

1. how to use a static library in opencore

Hi,

I am trying to integrate a new coded to opencore.
But I dont have the source code for the codec
I only have the static library with me.
How to compile the omx component layer with the new codec.

Can you any one help me in this regard.

Regards
Giri



      See the Web&#39;s breaking stories, chosen by people like you. Check out 
Yahoo! Buzz. http://in.buzz.yahoo.com/
--~--~---------~--~----~------------~-------~--~----~

2. derive mcc and mnc from lac and cid`

Hello,

I have an application where I would like to be able derive a cell's
MCC and MNC when I know only its LAC and CID. Deriving the MCC has
been relatively easy (I think).

However, deriving the MNC is more complicated, for obvious reasons.

I would appreciate it if anyone has any ideas/pointers/suggestions on
how to go about doing this.

Thanks.

Alex Donnini
--~--~---------~--~----~------------~-------~--~----~

3. If Java nested class has native method,how to register the class methods?

4. Random question on app market

5. Does LinearLayout support Gravity.RIGHT?

6. adb - for developer handsets only

7. the max one page size in chrome lite