|Android should provide a "PERMISSION Firewall"||Kevin Veroneau||7/24/12 10:50 AM|
If Android implemented a PERMISSION Firewall, it can better allow the
user to control what happens on their mobile device. This would be
similar to how a user can manage their browser settings for individual
websites. If I only want a specific amount of website to be-able to
set cookies, I can do that. I can also control which websites can use
All the time, I see apps requesting permissions which quiet obviously
I'm spectacle about providing them. Most of the time, I just don't
install the app, due to the permissions being requested are a little
too much for my tastes.
In the settings on Android, the user can whitelist and black list
permissions for specific apps. Think of how NoScript works, you can
choose to block all, be prompted, or unblock everything.
Rather than an app crashing when requesting a permission which has
been blacklisted, it should respond back with the appropriate error
message. For an Internet black list for example, it would merely
respond back to the app, saying that there was no network connection
available. The app can then handle this error message like normal.
This will ensure backwards compatibility with old apps. If it's the
first time an app is requesting network access, and if the settings
are set to prompt, then a subtle box will appear asking the user if
they wish to "Allow", "Allow once", or "Block" the attempted
I would prefer a rich interface, or at least advanced options for
advanced users. Such as if an app if requesting GPS, what should the
app be provided if I block the request. Examples could include a
random location in my current country(as some apps use GPS for
regional locking or settings). If an app is to send out texts or call
a number, having an "Allow once" button would make it much easier to
understand what the heck the app is using these features for, and if
it should just be blocked entirely.
If XDA developed such a system into their custom ROMs, I would forever
move over to a 3rd party ROM from XDA and forget about official google
ROMs, as this is a needed security feature in Android or any mobile
device for that matter. This device stores our personal information
for crying out loud, and the way security is handled in Android is
absolutely archaic and needs to change NOW!
Please Google, or even some third party ROM developer, release some
sort of android patch to make this a reality. If for some odd chance,
a cell phone manufacturer implemented this and left out the rest of
Android, then I will be forever loyal to you, as this is a handset
selling feature. I am sure other consumers will agree that this is
currently a must-have android security feature. If Android is going
to survive against the other mobile OSes out there, it needs to clean
up it's security big time, or consumers may flock over to iOS or even
worse, Windows Phone. Although security issues haven't stopped
Microsoft's flagship OS from selling, so who knows, maybe consumers
don't really care about this security mumbo jumbo, and only us geeks
and privacy advocates do.
I also give permissions to any Android blog out there to publish an
article about such a system being implemented in Android. However,
please reference this googlegroups.com post and give credit were due.
I'm not entirely sure if this type of security was previously thought
about by someone else, if it was, then why hasn't it been implemented
|Re: [android-security-discuss] Android should provide a "PERMISSION Firewall"||Kevin Chadwick||7/24/12 11:06 AM|
> Please Google, or even some third party ROM developer, release someFrom the discussions and chimes in about this from a good looking lady
from berkeley. I would expect mozillas OS to allow permission
revocation. May be a while though?
Why not do something good every day and install BOINC.
|Re: [android-security-discuss] Android should provide a "PERMISSION Firewall"||Dominik Schürmann||7/24/12 11:15 AM|
I don't think Google will implement this at any time, as it does not
provide real value to Android and will scare off some developers. In my
opinion you are right and we need a usable solution for permission
See PDroid: http://forum.xda-developers.com/showthread.php?t=1357056
|Re: [android-security-discuss] Android should provide a "PERMISSION Firewall"||Nathaniel Husted||7/24/12 11:32 AM|
I think it is also worth noting that while those of us who are
knowledgeable about permissions (we're members of the android security
discussion mailing list obviously) could be make use of such a tool,
it is difficult to extend that to the wider Android community as a
whole. It's readily apparent that users have a hard enough time
understanding permissions and the risks they entail in general, let
alone be able to make an informed choice about how to limit them with
certain applications. While it's certainly a solution I'd love to see,
it's not necessarily something that I could see being a default system
in the AOSP mainline or Google's internal repo.
I think it's also worth mentioning, as I put on my Faraday cage
headgear, that such a system would most likely destroy (or greatly
harm) the free application ad-based app economy (as well as Google's
cut of that revenue).
|Re: [android-security-discuss] Android should provide a "PERMISSION Firewall"||Kevin Veroneau||7/24/12 1:14 PM|
Lots of great comments, thank you. Also, thank you the link to the
AndroidPolice article, it appears like a step in the right direction,
although it needs some fine-tuning.
As for scaring off Google, developers, and consumers, here's a
Google/Developer ads: Android should have a "system application"
which is installed in Android by default to manage Ads and it's
network usage. The application should allow for "ad providers", of
which you need to be a trusted advertiser to be added to the provider
list. Of course this provider list is not displayed to end-user, and
neither is the application itself, it's transparent. The provider
list is updated from Google every so often. I say use a provider
list, so that Google doesn't get lawsuits from other ad vendors. If
the ad vendor is legit, they can request being added as an ad provider
on Android. Applications which use ads, would call this Android
application to display their ads to the user within the application.
The application itself will not require network access, as the ads
system app manages all that. Problem solved!
Consumers being scared off like what Vista's UAC did: Android will
obviously have this as a "security feature", which like any firewall,
can be turned off. A great way to prevent too much user confusion, is
that app developers can register their permissions with Google Play,
which keeps a list of "top developers", which are known not to abuse
permissions. Apps downloaded from these well known sources will
default to being open, however advanced users will be free to revoke
perms for these apps if needed. Play Market already keeps a list of
"top developers" and ones which are trustworthy, so using this list to
provide a set of defaults for end-users shouldn't be much of a
problem. Now, if a consumer wants to download an app which is not
verified, it can provide a basic set of perms which most apps should
use lawfully. Say, if an unverified app wants to send a text message,
or call a phone number on your behalf. Prompt the user that the
application is about to do this, and ask if the user would like to
proceed or block the app from doing this in the future. Most
consumers should know what a phone number is, and if it will cost them
money. Actually, every consumer which owns a phone in this day and
age should know, it's common sense that a 900# is going to cost ya.
I believe the problem with past implementation was that it was
implemented wrong, or not thought out too well. Users did get used to
UAC eventually, and now it's the norm on Windows PC, OS X, and Linux.
It never stopped sales of Windows, people still bought Vista(although
not as much), and definitely bought Windows 7. Give end-users some
credit here, not all of them are going to run the other direction, and
neither are developers.
As platform developers and security enthusiasts, we need to think
about the future. Malware, viruses, and hackers are only going to get
> You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
> To post to this group, send email to android-secu...@googlegroups.com.
> To unsubscribe from this group, send email to firstname.lastname@example.org.
> For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
|Re: [android-security-discuss] Android should provide a "PERMISSION Firewall"||pof||7/24/12 3:58 PM|
There are a few apps that implement something similar to what you are
proposing here, although all of them need root access or changes in the
framework like the Cyanogen permission revocations.
Check out the following:
LBE privacy guard (Free):
Works by hooking the permissions API calls, IMHO it's the best app
although it doesn't work properly on Android 4.1 yet but it's perfect if
you have an older Android version.
Permissions Denied (Free):
Permissions Denied Pro:
|Re: [android-security-discuss] Android should provide a "PERMISSION Firewall"||Kristopher Micinski||7/24/12 5:44 PM|
One thing you might want to consider: it's hard to dynamically just
"deny" permissions, because you can easily crash apps.
Let's say you do this the dumb way: you get apps that randomly die
So obviously you would never do it that way. Instead what you do is
do something like have the security protected calls and (when the
permission is denied) map them to nulls. This also doesn't work, and
still crashes apps. Most of the time, it turns out that you *can* do
something sensible here, and this occasionally works / is done. You
can also imagine doing something like "failure oblivious computation"
to recover apps at runtime.
I'm not saying this isn't possible, but I'm saying it isn't (easily)
sensible to randomly "deny" apps permissions at runtime.
And of course, you usually need system support for this, as others
have pointed you can get around this with binary rewriting...