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. Setting a Dialog width to fill screen?

Hey folks,

I've created a custom class that extends Dialog and have a custom view
I use inside it.  When the dialog is activated, it looks like this:

http://img.waffleimages.com/278aad1d375a3e73c87189beac335c5d7100c8b5/device.png

It only seems to increase in width as I type into text boxes.  I've
tried to override the layout attributes of the dialog below, but it
still doesn't seem to stretch out to fit the screen.  I've also
included the XML for the view I want inside the dialog.

Can anyone suggest anything?

@Override
        public void onCreate(Bundle savedInstanceState) {
                super.onCreate(savedInstanceState);
                this.setTitle("Create New List");
                setContentView(R.layout.dialog_create_new_list);
                LayoutParams params = getWindow().getAttributes();
                params.height = LayoutParams.FILL_PARENT;
                getWindow().setAttributes(params);
                .....
                .....


<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/
android"
            android:orientation="vertical"
                android:layout_width="fill_parent"
                android:layout_height="fill_parent"
                android:theme="@android:style/Theme.Dialog">
<ScrollView
            android:layout_width="fill_parent"
        android:layout_height="wrap_content">
  <LinearLayout
            android:orientation="vertical"
                android:layout_width="fill_parent"
                android:layout_height="fill_parent">

            <TextView
                android:id="@+id/label_enter_list_name"
                android:layout_width="fill_parent"
                android:layout_height="wrap_content"
                android:text="Enter List Name" />
            <EditText
                android:id="@+id/edit_enter_list_name"
                android:layout_width="fill_parent"
                android:layout_height="wrap_content" />
            <TextView
                android:id="@+id/label_select_list_type"
                android:layout_width="fill_parent"
                android:layout_height="wrap_content"
                android:text="Select List Type" />
            <Spinner
                android:id="@+id/spinner_select_list_type"
                android:layout_width="fill_parent"
                android:layout_height="wrap_content" />
            <TextView
                android:id="@+id/label_enter_list_description"
                android:layout_width="fill_parent"
                android:layout_height="wrap_content"
                android:text="Enter List Description" />
            <EditText
                android:id="@+id/edit_enter_list_description"
                android:layout_width="fill_parent"
                android:layout_height="wrap_content" />
            <TextView
                android:id="@+id/label_pick_list_icon"
                android:layout_width="fill_parent"
                android:layout_height="wrap_content"
                android:text="Pick List Icon" />
            <ImageButton
                android:id="@+id/imagebutton_pick_list_icon"
                android:layout_width="fill_parent"
                android:layout_height="wrap_content"
                android:src="@drawable/icon" />
            <LinearLayout
        android:orientation="vertical"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent">
        <Button
          android:id="@+id/button_create_new_list"
          android:layout_width="fill_parent"
          android:layout_height="wrap_content"
          android:text="Create List" />
        <Button
          android:id="@+id/button_cancel_new_list"
          android:layout_width="fill_parent"
          android:layout_height="wrap_content"
          android:text="Cancel" />
      </LinearLayout>
</LinearLayout>
</ScrollView>
</LinearLayout>
--~--~---------~--~----~------------~-------~--~----~

2. Enable Upload on Android's Browser

How can I enalble upload on Android's Browser ????


Thanks
--~--~---------~--~----~------------~-------~--~----~

3. Working through Notepad Tutorial - Problems...

4. It's a Gift , Keep it

5. Babylon Pro 7.5.2 (r5)

6. Question about spinner and quick text search.

7. Market Copy Protection options