ability to temporarily disable permission

by Disconnect » Fri, 01 Oct 2010 14:03:51 GMT


Sponsored Links
 As Android privacy becomes increasingly under attack, maybe it is time to
revisit an old idea - allow a user to (temporarily or permanently) remove
permissions from an app. The UI doesn't have to be a mess, and the API
interface is easily backward-compatible. (Add an API call to find out if a
permission is revoked, and older API apps receive a reasonable, valid "no
data" return on reads and either "temporary error" or "ok" on writes.)
 http://arstechnica.com/security/news/2010/09/some-android-apps-found-to-covertly-send-gps-data-to-advertisers.ars 

"They used TaintDroid to test 30 popular free Android applications selected
at random from the Android market and found that half were sending private
information to advertising servers, including the user's location and phone
number. In some cases, they found that applications were relaying GPS
coordinates to remote advertising network servers as frequently as every 30
seconds, even when not displaying advertisements. These findings raise
concern about the extent to which mobile platforms can insulate users from
unwanted invasions of privacy."

The proposal is simple, and it has come up before.

 http://code.google.com/p/android/issues/detail?id=10340  (looks quite well
fleshed out, and not dramatically different from the other times it has been
proposed)

The idea is simple: take the more sensitive permissions, the ones users are
likely to be concerned about, and allow them to be enabled/disabled on the
fly by the user. Provide an api to allow apps to query their permissions
status - they could then refuse to run, or run in a more limited mode, based
on the permissions granted. Apps that haven't been updated simply receive
the appropriate 'no data' or 'write succeeded' returns from their blocked
calls.
Perhaps this time google will respond to the technical aspects of the
proposal.

--



ability to temporarily disable permission

by Chris Palmer » Fri, 01 Oct 2010 18:22:05 GMT


 



The term "attack" is a little strong, given that nobody is claiming
these dubious apps bypass the permission system or otherwise break the
Android security model. Note that the TaintDroid video,

 http://www.networkworld.com/news/2010/092910-android-privacy.html?page=2 

doesn't show the install screen. Presumably, the wallpaper app asks
for the various permissions it uses, just like all apps. For
privacy-conscious users, the combination of INTERNET and (say)
READ_PHONE_STATE for a wallpaper app should be a big warning sign.

If an app uses the permissions you give it in a way you don't like,
why not uninstall it and give it a bad review on Market? TaintDroid
seems like a good tool for detecting bad behavior in apps that don't
try to bypass TaintDroid. And there's always Wireshark and
smali/baksmali.

Also, the problem is not specific to Android --- Android just surfaces
these pre-existing concerns and deals with them better. Not perfectly,
but better. Other platforms give all apps all the goods all the time,
no permission screen required.


In an earlier message you said users are not going to wise up and will
click OK on anything. I don't think you're right about that, but if
you are, increasing the complexity of the UX is surely
counterproductive.

Personally, I'm not against the idea of having the permission screen
be (for example) a list of checkboxes rather than a yes/no for all.
But we'd have to have some way to cope with all the existing apps that
are not prepared to catch the (unchecked) SecurityExceptions they will
get when permissions they thought they had are gone.


You're underestimating the complexity and scope of that project. But
it could be a good project. It'd be cool to try out this idea out in
Cyanogen or another distribution. If it flies, you could contribute it
back to AOSP?

--


Sponsored Links


ability to temporarily disable permission

by Disconnect » Fri, 01 Oct 2010 18:52:40 GMT


 n Fri, Oct 1, 2010 at 2:21 PM, Chris Palmer <snackypa...@gmail.com> wrote:

http://www.droidsecurity.com/ would disagree, although I agree they are
spinning huge piles of bs and fearmongering.

More to the point, "am i on the home screen" or "what is my battery level"
(both reasonable interpretations of "PHONE_STATE") doesn't translate, to
most users, into "send my phone number to a third party who's privacy policy
may not even exist". (
http://groups.google.com/group/android-developers/browse_thread/thread/c97c3eb5dcef0519is
an earlier push about this.)


To continue along this line, I think "phone state" is a very misleading name
anyway - "access your phone number, IMEI and other phone information".
"Phone state" sounds like "awake, asleep, dim" "no data" etc..


OSX keychain is a great counter-example, and passes the grandmother test: an
app can get account (or other secret) information by asking the user. The
user can say "yes", "no", or "always yes"/"always no". (Since its a general
purpose system, the user may be required to authenticate - not amazingly
feasible on android, although an optional security PIN could work.) Windows
popup-of-doom (going all the way back to ... blackice? or the other one?
anyway, >10 years ago) handle it better. "This app is attempting to do this
SPECIFIC thing, right now." Not "Please allow this app to do some or all of
this large, vague list, at some point."

A user who is confused by the addition of "remember these permissions" (or
possibly just an "Advanced" button) is not going to get that far to begin
with. For the more advanced users, there is no way to teach them differently
right now.


Personally, I'm not against the idea of having the permission screen

That sounds a lot more complex for the standard "click ok to make this work"
case.


Older API versions get 'no data', not a new, api-breaking SecurityException.
(For example, no gps fix. No data network available. No contacts. No
accounts. No sd inserted. No phone number, or a localized false number such
as 555-555-0000. Etc. These are all events that could occur anyway in the
device. Off the top of my head, I can't think of a permission that couldn't
be spoofed in this way - if there is, it is worth evaluating whether it
should be disablable in the first place..)

>



ability to temporarily disable permission

by Dianne Hackborn » Fri, 01 Oct 2010 19:00:17 GMT


 


> 



ability to temporarily disable permission

by Chris Palmer » Fri, 01 Oct 2010 19:15:50 GMT


 



Unfortunately, it's not. If you download Goat.app, a hypothetical
malicious IM app or game, it can debug Keychain, take screenshots of
it, spoof its dialogs, keylog it, and so on. Keychain runs as the same
UID as Goat. Unix and OS X provide no security boundary between
processes running as the same UID. If somebody pops Firefox, your SSH
keys, email, documents, et c. are all at risk.

(There are mechanisms on OS X like Seatbelt, but, well... what's your
Seatbelt policy file look like? In any case I just attached gdb to
Keychain Access.app, so...)

--



ability to temporarily disable permission

by Disconnect » Fri, 01 Oct 2010 19:20:49 GMT


 



Arguably that is a security flaw, not a design/interface flaw. Technically
android is just as vulnerable because I can gain root (frequently trivially)
and bypass any permissions I like..


>



ability to temporarily disable permission

by Disconnect » Fri, 01 Oct 2010 19:24:02 GMT


 




>> 



ability to temporarily disable permission

by Chris Palmer » Fri, 01 Oct 2010 20:06:29 GMT


 >> processes running as the same UID. If somebody pops Firefox, your SSH

I don't know what distinction you're trying to draw there. OS X,
Firefox, SSH, et c. are working as intended.

The Unix/NT security model is: UIDs are protected from each other, but
not from themselves or from root. The design is outdated and no longer
sufficient, but it made a bit more sense when it was invented. Android
uses the old mechanism in a new way, to be relevant in a world of code
from many sources.

The kernels may, and do, have implementation flaws that allow
malicious programs to break that guarantee. That's a serious problem
--- for all platforms.

--



ability to temporarily disable permission

by Disconnect » Fri, 01 Oct 2010 20:17:27 GMT


 


OSX in your example isn't working as intended - the intended use of gdb is
not to allow users to bypass keychain access restrictions any more than the
intended use of the recovery mode (on a galaxy) is to allow users to bypass
android platform security.

I don't know what purpose the primer on unix user security was, but thanks I
guess. It has - as you sort of pointed out - very little to do with this
discussion. Lets backtrack a bit - it was, primarily, a UI discussion at the
time:

 Also, the problem is not specific to Android --- Android just surfaces

If we're to continue applying the criteria you listed later (-can- it be
bypassed somehow) then we should junk all the permissions entirely, since
they aren't 100% effective. Including the existing android permissions.

As an attempt to move the discussion forward, what is to stop an app from 1
developer from collecting information and sending it as an intent to a
different app to be distributed? At least in the proposed model, there is a
chance that a user will see "AppFoo wants to connect to the internet." and
think "That's weird, I was using my credit-card-number saving app. Why is
AppFoo running suddenly?"

--



ability to temporarily disable permission

by Chris Stratton » Fri, 01 Oct 2010 21:09:50 GMT


 



Without this, you must have a design that is perfect for all users for
all purposes.

With it, the user has the ultimate authority over their device, their
personal information and their bandwidth bill.

No real-world engineering system can be so perfect as to not need
timely maintenance in the face of the unexpected (or noted but
unwisely dismissed) problems which develop over its user life, and no
carrier update system is going to be reactive enough.  Android does
not provide app-store-level auditing, which is is fine (welcome
freedom to publish, really) - but android also does not let users
perform necessary permissions maintenance in the face of new security
threats, especially those unwisely played down by google.

--



ability to temporarily disable permission

by Chris Stratton » Fri, 01 Oct 2010 21:12:29 GMT


 



But ironically in android, that "security problem" is actually the
only viable end user security solution - the only way an end user can
do anything about google's refusal to provide the user with a line
item veto on application permissions is to leverage what would
traditionally be regarded as a "bug" to gain the power to patch their
device.

--



ability to temporarily disable permission

by Dianne Hackborn » Fri, 01 Oct 2010 22:09:41 GMT


 



You are welcome to make a contribution here.



I guess we just see things differently.  I am will to bet though that you
will see a lot of developers go, "hey I can now add all these permissions,
and if users complain I can just tell them to turn off the ones they don't
want."  Which means users now get confronted with more permissions for each
app they install, and are now becoming expected to fine-tooth vet those
permissions themselves.

Anyway, it's not worth continuing this discussion; we have different
opinions on this, and talking about it more clearly isn't going to change
them.  I'll let you have the last comment if you want.



Contributions welcome.



So, you have the source code, you can code, go and implement this how you
think it should be done.  Get it into cyanogen to see how people use it.  We
aren't stopping you from pursuing this and showing us that it works well.

Abstract discussion on this topic has become at this point mostly a waste of
time.

Btw, for some perspective on this, when I was first designing the permission
system, I proposed that we show all of the permissions with check boxes to
control them and possibly even make the user go through and explicitly turn
on the dangerous ones they want.  (In fact that was originally the purpose
of "dangerous", to be something the user had to explicitly enable.)  After a
lot of thought about UX we decided not to do that, and it is a decision I
very much agree with at this point.

-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.

--



ability to temporarily disable permission

by Disconnect » Fri, 01 Oct 2010 22:12:18 GMT


 




The scheduler/task killer is a great example of the android team's
occasional insistence (at least in public) that they know better than the
users and can perfect any system. (Until, of course, a few versions later
where they implemented the 'stop tasks' button in the app manager and added
the associated permission. As far as that goes, I think it is in a healthier
place - better automatics plus the ability to override them. Except for the
probably-neverending fight against autokillers created by their original
claims that it was already perfect and the user must be doing something
wrong...)

With any luck, we've hit that "few versions" on this problem also and it'll
get very quiet, then suddenly appear in a code dump... :)



Remember when "no roaming data" wasn't even an option? I think a lot of the
problems with data permission comes from the fact that the android team
tends to be somewhat US-centric, where unlimited plans are the norm. In the
US in general we're not used to thinking per-meg..


"people will disable ads, then developers will stop doing 'free' apps and
nobody will buy paid apps and the whole thing will fall apart."  I also
think it isn't an issue - devs that have that problem can simply upgrade to
the new API, discover they have been blocked, and refuse to run...

There was a post a very long time ago by hackbod indicating you could just
use the ad provider as a separate app, thereby making sure that the app with
the sensitive data doesn't need to request gps/internet perms solely for
serve ads. Had that become "the way", I suspect we'd see a lot less support
for this plan and a lot less "click ok to make it work" from the users. Huge
permission lists would be the exception rather than the rule.

--



ability to temporarily disable permission

by Chris Palmer » Fri, 01 Oct 2010 22:44:10 GMT


 > OSX in your example isn't working as intended - the intended use of gdb is

Ok. How would you report the bug to Apple? If you worked at Apple, how
would you fix this bug?

Before you answer, read ptrace(2) and
 http://www.steike.com/code/debugging-itunes-with-gdb/ . 

--



ability to temporarily disable permission

by Chris Stratton » Sun, 03 Oct 2010 14:17:38 GMT


 


But what about when there actually is no data connection?

I find that 90% of my usage of "apps" is on the subway.  Above ground
I primarily use the web browser.

--



Other Threads

1. Default Styles?

Where can I find default styles for my widgets? Let me give you an
example. In the Contacts application, when adding a new contact, at
the very bottom there are two buttons that have a particular
background. I have traced that to here:
http://android.git.kernel.org/?p=platform/packages/apps/Contacts.git;a=blob;f=res/layout-finger/edit_contact.xml;h=a3a1849e600d22a6736eabcdedb8cc172139b8a1;hb=065dbad4fd142645e54c301ea6e6febdedaf9843
and it would seem that that background is achieved by using
style="@android:style/ButtonBar" on a LinearLayout. From what I
understand, this is a system-wide theme default for button bars.
However, what I am searching for is not a ButtonBar, but similar, so I
tried searching for this ButtonBar in the documentation, hoping to
find other similar styles I could use. I *thought* I would find it in
R.style: http://developer.android.com/reference/android/R.style.html ,
but it seems I have mistaken. It is not there. Can anyone tell me
where I can find such styles?

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

2. Issue Steaming MPEG4 movies from the web?

We are having issues with playback streaming MPEG4 movies from the web
for a client? Is this is a issue with Andriod phone?

Does anyone have feedback on this issue?
--~--~---------~--~----~------------~-------~--~----~

3. Android camcorder is not responding

4. playing video at highest speed in opencore

5. building pv_drm_plugin_test

6. getting mainmenu applications

7. Can we use static class that holds all the constants for the applications?