• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Android permissions explained, security tips, and avoiding malware

I chuckle that they added "and the like" at the end. Google really needs to hire some project managers and proofreaders. I love that they are a company full of engineers and developers but it's like whoever was writing that description got distracted mid-sentence and stop caring so they finished with "and the like" heh.

And yeah the developer docs are #$%^ing TERRIBLE. /end rant

Anyways, back on topic: The thing about the IMEI is that it's not all that dangerous. WiFi only tablets don't even have an IMEI/IMSI and any app can give you it's own version of a unique ID number right when it's installed. I wouldn't grant it out willy nilly to everyone.... But for now, I wouldn't worry too much about it. I fully expect them to split that permission in two or three in Ice Cream.

The most obvious "danger" it poses is that someone like an ad network can aggregate data from multiple apps with different permissions and match them all together with an IMEI. However this is possible on your home computer with just a cookie in the browser. And would still be possible without an IMEI with just a file on your SD in Android.

So at the end of the day you, or I, or most people will probably let our IMEI out to some shady (but maybe not malicious) characters. And at the end of the day there isn't a lot they can do with it.

Going forward too, Android is going to require hardware makers to provide a unique ID for app devs to use. It's pretty fundamental for any kind of tracking & DRM/copy protection. It's just that the IMEI is what was used because there was no uniform ID accross different hardware, and now with so many WiFi tablets, it isn't recommended.

Android Developers Blog: Identifying App Installations

What I'd really like to see:

1) Read Phone State: gives app the following states/events: idle, incoming call, outgoing call, in call. (with no further information).
2) Read Phone Call details: gives app the numbers being called/calling in.
3) Read Phone Network ID (GSM/CDMA/LTE/HSPA)

Most apps would only need #1.
Dialer replacements could ask for #1 and #2.
And hardly any apps would need #3.


NOTE: before anyone comes saying they can use my IMEI and spoof me on the network, sure there are some very advanced hacks out there that can do stuff like that. However, they require a VERY high level of technical knowledge and having someome's IMEI wouldn't matter at that point. At that level of tech knowledge people could imporsonate a GSM tower or just make up an IMEI, they wouldn't care about your IMEI.
 
Always there with the answers ALP :) lol

1) Read Phone State: gives app the following states/events: idle, incoming call, outgoing call, in call. (with no further information).
2) Read Phone Call details: gives app the numbers being called/calling in.
3) Read Phone Network ID (GSM/CDMA/LTE/HSPA)

I'm looking at ZDbox's permssions betwee, lol. Yeah, I do hope they break it up like what you've shown. Would make me less paranoi. Speaking of paranoia, these permission descriptions are throwing 'red flags' in my head. But at least they are warning us what a malicious application can do.

System tools
retrieve running applications
Allows application to retrieve information about currently and recently running tasks. May allow malicious applications to discover private information about other applications.
Would that be the Application's state or the App's cache memory? Are the cache memory that easy to break through?

System tools
modify global system settings
Allows an application to modify the system's settings data. Malicious applications can corrupt your system's configuration.
 
Would that be the Application's state or the App's cache memory? Are the cache memory that easy to break through?

Just the app state. App data storage is private by default. Unless the app specifically saves data to the SD, which is public.

The system setting is just anything found under the settings menu. Not particularly dangerous, and nothing that cant be reset with a factory wipe, or even manually under the settings menu.

It's basically an "all settings" permission widets can use so they dont sound so scary asking for 40 permissions to manage each setting.

I'll have to remember to check the guide to explain those a bit more, as they do sound confusing the way Google explains them don't they?

I think I'll add also maybe some info about how the SD is fair game for almost all apps to read so it's not a safe place to store personal info.

cheers rose :)
 
Thanks for this great thread, alostpocket! Very helpful for an Android newbie like myself.

Went in and checked the permissions of the apps I've installed. What I've found is that many of them requires this one:
androidwarning.gif
Development Tools read logs
This permission is of very high importance. This allows the application to read what any other applications have written as debugging/logging code. This can reveal some very sensistive information. There are almost no reasons an applications needs this permission. The only apps I might grant this permission to would be Google apps.

Including Evernote as mentioned above. As well as Handcent, ChompSMS, GO SMS, gTasks... Is that normal?
 
Thx a lot,
It was professional, useful and.... interesting for me is what u could read between the lines, that you care about users, developers and Android community, as an individual, equally. I really enjoyed it, best of lock mate.:):)
 
Thanks for this great thread, alostpocket! Very helpful for an Android newbie like myself.

Went in and checked the permissions of the apps I've installed. What I've found is that many of them requires this one:
androidwarning.gif
Development Tools read logs
This permission is of very high importance. This allows the application to read what any other applications have written as debugging/logging code. This can reveal some very sensistive information. There are almost no reasons an applications needs this permission. The only apps I might grant this permission to would be Google apps.

Including Evernote as mentioned above. As well as Handcent, ChompSMS, GO SMS, gTasks... Is that normal?


Personally, I wouldn't grant anyone but maybe Google that permission. And even then, I'd think long and hard about it.

But you need to decide for yourself if you want to give them that info, that's not for me to say. I just describe the roads, you have to choose one ;)
 
Thatlooks like the most intrusive permission of them all. I wonder if there a log of apps found with this permission? I dont think I need an app bad enough that require this one.
 
For what is worth, I asked Evernote about the read log permission and the reply I got was that it is used to create an error reporting log when you encounter a problem. The log is then copied to the email client where you can review them before sending it over. Read the whole reply here:


Well I've always considered Evernote pretty respectable. But in all honesty, that's what's called "the brush off." That's what everyone will say about the logs. And there's no technical reason they need all the log data from the phone "if you encounter a problem."

"They
aren't using them for bad purposes, only the next guy."

They just gave you the canned response.

Really, it's just lazy programming, that permission was never designed for consumers to see. It was meant for testing development builds of an app. You should never have to put your trust in a company because they are lazy either. That's ridiculous on so many levels.

There already is a built in error reporting mechanism to Android that users can (and do) use. It shows what the app was trying to do when it crashed (called the stack trace). Also, they can easily log their own stuff to a separate log and catch errors with a peice of code called a try/catch block. All of this without needing that permission.



More importantly though:

I think from now on it's a good idea to remind people, this thread isn't about Evernote, or any other specific app. I can not judge apps for people as that puts me in a very precarious position.

I am an app developer too and it puts me in an adversarial relationship with specific app makers if people make this thread about them.

I think going forward I am going to ask that no apps are mentioned by name here anymore and if they are I will ask the mods to edit them out.

That's not to say you shouldn't ask about apps -- people should always ask about apps, just do it in a separate thread. This is a guide about permissions, but those apps should still be asked about, just not here.
 
Updated: Continued overhaul of the permissions section.

-Added common permissions related to account management.
-Made the formatting a bit easier to read for permissions
-Fixed a lot of typos in the permissions section.
-Added images to show how to check permissions

Todo:
- Add gmail related permissions,
- look for other/new permissions to add
 
Just wanted to give a "heads up" on this. Basing your install decision on market comments alone is not a good idea. The reason it's not a good idea is because there are sites like Star My App that developers can pay to add fraudulent comments to their market apps. This makes the market comment system useless as a sole means if deciding whether or not to install an app.
 
Just wanted to give a "heads up" on this. Basing your install decision on market comments alone is not a good idea. The reason it's not a good idea is because there are sites like Star My App that developers can pay to add fraudulent comments to their market apps. This makes the market comment system useless as a sole means if deciding whether or not to install an app.


Link doesn't work
 
Link doesn't work

I forgot to say, that doesn't matter. For most apps, I only read the bad reviews. See how many people make complaints in the past week and what kind of complaints are they.

Complaints like, '1 star because does not have Apps2SD' I ignore
 
Patrick, great guide. This is for the PDF version. My nitpick-y contribution below. Hope it helps.

1) Page 1, paragraph 1: This is a guide that hopes to give...
Guide, as in "an informative document," is an inanimate object. It cannot hope.

2) Page 1, paragraph 2: with some common sense diligence and the right knowledge
Should say: with some common sense, diligence, and the right knowledge

3) Page 1, paragraph 3: While most all
It is either most, or all. Those are mutually exclusive terms.

4) Page 1, paragraph 3: is written specifically with Google's original Android.
Should say: is written specifically for Google's original Android Market.

5) Page 2, last paragraph: Often times this includes keystroke loggers
Should say: Oftentimes this includes keystroke loggers
This point applies to all further uses of the word “oftentimes.”

6) Page 3, paragraph 2: example of this would be a app or website
Should say: example of this would be an app or website

7) Page 3, paragraph 4: example might be when a virus send emails to everyone
Should say: example might be when a virus sends emails to everyone

8) Page 3, paragraph Adware: Adware is typically a bit of a grey area.
Should say: Adware is typically a bit of a gray area.
I understand “grey” is the British version and “gray” is the American English version. This point applies to all further uses of the word “gray.” Note, however, the correct spelling is somewhat of a gray area. Pun intended.


9) Page 3, paragraph Adware: in return for providing a service to the user of dubious quality
Should say: in return for providing a service of dubious quality to the user
It appears that “dubious quality” is a property of the user. While that may be true with some users, I am certain you mean to describe the service and not the user.


10) Page 3, last paragraph: Furthermore this is very often the most
Should say: Furthermore, this is very often the most


11) Page 4, paragraph 1: If you are a user that cannot access
Should say: If you are a user who cannot access


12) Page 4, paragraph 3: These are places that independent developers can upload free and/open source apps
Should say: These are places where independent developers can upload free and/or open source apps


13) Page 4, paragraph 5:
Missing a period.


14) Page 4, paragraph 6: help you understand how well an app work on your particular phone
Should say: help you understand how well an app works on your particular phone


15) Page 4, last paragraph: Any app that fails to maintain abpve 2.5 stars
Should say: Any app that fails to maintain above 2.5 stars


16) Page 4, last paragraph: Nevertheless almost all good apps
Should say: Nevertheless, almost all good apps


17) Page 5, paragraph 3: This is often again a good indication of quality
Should say: This is often a good indication of quality


18) Page 5, paragraph 4: This is not definitive indicator
Should say: This is not a definitive indicator


19) Page 5, paragraph 4: Their are a lot of exceptions to this particular
Should say: There are a lot of exceptions to this particular


20) Page 5, paragraph 6: seems to be asking for more permissions that it should, or it's comments and ratings are mediocre , go ahead and ask about the app in these (and other) forums .
Should say: seems to be asking for more permissions than it should , or its comments and ratings are mediocre , go ahead and ask about the app in this (and other) forums .


21) Page 5, paragraph 6: You will often find dozens if not more people
Should say: You will often find dozens, if not more, people


22) Page 5, last paragraph: The community are usually the first to identify any Malware or dangerous programs, and are the best
Should say: The community is usually the first to identify any Malware or dangerous programs, and is the best


23) Page 6, paragraph 1: high praise for what seems a simple app
Should say: high praise for what seems to be a simple app


24) Page 6, paragraph 3
First sentence doesn't look right – two thoughts collided?


25) Page 6, paragraph 4: To do this go into the Market and press [menu] > [downloads].
I do not have “downloads” option on Market v2.3.6


26) Page 6, paragraph 5: will only ever be as good as both it's developers and it's users
Should say: will only be as good as both its developers and its users


27) Page 7, paragraph 2: They several instances of Malware and actually remotely uninstalled the applications from users phones .
Should say: They identified several instances of Malware and actually remotely uninstalled the applications from users' phones .


28) Page 7, paragraph 4
Generally good advice. However, a better advice would be to never enter a password on any website where the URL does not start with https://. Since all banks, most email services, and now even facebook use SSL, entered credentials are encrypted in transmission and cannot be easily decoded by someone operating a rogue Wi-Fi access point.


29) Page 8, paragraph 1: However this is not a common to cheat people
Should say: However, this is not a common way to cheat people


30) Page 8, paragraph 3: This includes, pictures, videos
Should say: This includes: pictures, videos


31) Page 8, paragraph 3: However there are many
Should say: However, there are many


32) Page 9, paragraph 3: Many software developers legitamately use these numbers
Should say: Many software developers legitimately use these numbers


33) Page 10, paragraph 4: data off of your phone, this is one of the setting it would
Should say: data off of your phone; this is one of the settings it would


34) Page 11, paragraph 1: application sometimes expects the user to not interact with the phone directly sometimes
Drop 2nd instance of “sometimes.”


35) Page 11, paragraph 2: However there are a lot of these setting that
Should say: However, there are a lot of these settings that


36) Page 11, paragraph 4
There is a “hotspot” feature on some phones. This probably can change the SSID for the hotspot. Any app that needs to write this better be some Wi-Fi utility. This is only a speculation.


37) Page 11, paragraph 4: Essentially however I believe this to
Should say: Essentially, however, I believe this to


38) Page 11, paragraph 5: not a danger in an of itself, it can point to an applications intent
Should say: not a danger in and of itself, it can point to an application's intent
This point applies to all further uses of “in and of itself.”


39) Page 12, paragraph 2: However if you have more than one browser
Should say: However, if you have more than one browser


40) Page 12, paragraph 4
I would bump up the importance. I can envision a spy app which at random intervals secretly sends off a snapshot of whatever the camera happens to point to.
 
I forgot to say, that doesn't matter. For most apps, I only read the bad reviews. See how many people make complaints in the past week and what kind of complaints are they.

Complaints like, '1 star because does not have Apps2SD' I ignore
That's actually a good practice because most people aren't going to post a bad review unless it's worth taking the time to type in some text.
 
That's actually a good practice because most people aren't going to post a bad review unless it's worth taking the time to type in some text.
And I keep an eye out for bad Reviews from someone with an Atrix. That is usually a good indication for me not to use the app. I usually send an email out to the developer (I think they are getting annoy with my emails XD) and ask them about the issue :)
 
App permissions get odd and downright scary. If you're rooted, you can get an app called "Permissions Denied" (maybe only called "Permissions" in the market). Then it gets really odd/scary. Using Pandora as an example, I don't see why I would want Pandora modifying my bluetooth setup or being able to pair with any other bluetooth devices, on it's own. I understand being able to use bluetooth devices, like headphones. But I can create those links myself. So, I denied it that permission. There is no reasonable need for Pandora to be able to access my calandar, much less modify it. So on and so forth.

Again, you have to be rooted to use this app. But it is possible to change what an app can use. Also, if you go on a denying binge, you may find the app will force close whenever you try to use it. If that is unacceptable, I guess it's bye-bye app.
 
App permissions get odd and downright scary. If you're rooted, you can get an app called "Permissions Denied" (maybe only called "Permissions" in the market). Then it gets really odd/scary. Using Pandora as an example, I don't see why I would want Pandora modifying my bluetooth setup or being able to pair with any other bluetooth devices, on it's own. I understand being able to use bluetooth devices, like headphones. But I can create those links myself. So, I denied it that permission. There is no reasonable need for Pandora to be able to access my calandar, much less modify it. So on and so forth.

Again, you have to be rooted to use this app. But it is possible to change what an app can use. Also, if you go on a denying binge, you may find the app will force close whenever you try to use it. If that is unacceptable, I guess it's bye-bye app.

Oh that's great to know. That sounds like my kind of app :) Thanks for recommending it!
 
App permissions get odd and downright scary. If you're rooted, you can get an app called "Permissions Denied" (maybe only called "Permissions" in the market). Then it gets really odd/scary. Using Pandora as an example, I don't see why I would want Pandora modifying my bluetooth setup or being able to pair with any other bluetooth devices, on it's own. I understand being able to use bluetooth devices, like headphones. But I can create those links myself. So, I denied it that permission. There is no reasonable need for Pandora to be able to access my calandar, much less modify it. So on and so forth.

Again, you have to be rooted to use this app. But it is possible to change what an app can use. Also, if you go on a denying binge, you may find the app will force close whenever you try to use it. If that is unacceptable, I guess it's bye-bye app.

Now T H I S app is well worth rooting. I think you have a believer here! Now can i git uh ayemen up in here!
 
App permissions get odd and downright scary. If you're rooted, you can get an app called "Permissions Denied" (maybe only called "Permissions" in the market). Then it gets really odd/scary. Using Pandora as an example, I don't see why I would want Pandora modifying my bluetooth setup or being able to pair with any other bluetooth devices, on it's own. I understand being able to use bluetooth devices, like headphones. But I can create those links myself. So, I denied it that permission. There is no reasonable need for Pandora to be able to access my calandar, much less modify it. So on and so forth.

Again, you have to be rooted to use this app. But it is possible to change what an app can use. Also, if you go on a denying binge, you may find the app will force close whenever you try to use it. If that is unacceptable, I guess it's bye-bye app.

I think this app poses some interesting questions. On the one hand it's great that it gives more control. On the other it is a dangerous precendent to let apps muck around with the functionality of other apps.

I think the developer is a great guy and fantastic dev (stericson), but changing permissions in other apps is a questionable practice and (may) provide a false sense of security.

I feel the same is true of Xeudoxus's Privacy Blocker app.

Both are very interesting ideas, but I'm hesistant to reccommend these methods of protecting phones. So proceed with caution (as with any app) :)
 
Back
Top Bottom