• 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

Hi Roze, yes Barcode Scanner was one of many, but I have found the Barcode Scanner particularly inaccurate over its pricing. I just tried it on a few items in my cupboard, and the barcode on the goods must be for an outer rather than a single item because the prices need to be divided either by 12 or 10 to become accurate. However, how will you know how many packs make an outer?

The problem is the way some of the permissions are described - they often sound worse than they really are. For example the one that searches your contacts, as the Barcode Scanner admits it is used for making the codes and nothing else. However unless you search each app back to their website you are never going to be sure exactly how the information is going to be used.

Multiply doing that for over 100 barcode scanner or qr code apps and it would take days to check every one.
 
alostpacket said:
update: 2/17/12

-updated the info about how to find permissions and the market screenshot

-added links to each section
Click to expand...

This is a great thread and original article. On another android tablet site (where I am a mod) I keep a malware & security FAQ thread up to date & reference this thread as the defacto standard on the subject. Great job. :)

Will you also be updating your original post to include info on Google Bouncer?
 
Yep -- good call!

I had known about Bouncer but not thought to add it. But yeah the next big update will be a content update to both my app and all my guides.

This will include:

Info on Bouncer:

New permissions
- BT Admin
- NFC
- CHECK_LICENSE

And at least a few others I am forgetting off the top of my head.

(btw feel free to check out my app version of this guide, I just released the tablet HC/ICS version yesterday)

Link: http://androidforums.com/android-ap...-0-app-version-my-security-guide-updated.html
 
I know its over two years since your post on this subject but I had to thank you for giving me all the information I was looking for in one easy to read post. You would think by now there would be more done about it and it would be safer but there isn't. I have shared this link with all my friends as it has give me peace of mind and will make me sleep alot easier and give me more confidence in downloading apps and using my tablet. You should receive a medal for helping people and explaining this topic in such a manner that all can understand and learn. My hat is off to you sir and I wish you all the best in life. If karma is real then your life should be fruitful and long lived.
If every one could know this information then no one would download the app thus giving them no reason to create these tricks. Once again my hat goes off to you good sir.
Kind regards, Bobbie stringer. England :):):):):):):):):):):):):):):):):)
 
It's been a long time since I posted here, feeling mostly in control of my Android. But recently, various press have started published articles such as this:But naturally they're in "captain-dummy-talk" mode so the hard details are mostly lacking. Hence I come here to ask:

Can Android apps in fact secretly copy photos merely based on the permission "Full internet access"?
Or is it an inflated misunderstanding, and you do in fact also need other permissions such as "Modify/delete SD card contents" (which I believe is required to obtain read access)?
 
Good to see you Klaymen!


Anyways, actually - reading files from an SD card does not require any permission. It's considered "unprotected storage" - so sadly that article is not incorrect. Dripping with the spite of the journalist and a bit of sensationalism, but not incorrect.

So, in theory, yes they could send pictures. In practice, it's not that simple. It would be hard to go unnoticed.

However I do believe this is why Android has moved to a more "internal" storage design. This allows for more things to be placed in "protected" storage. Though photos take from the camera have not moved into protected storage (yet).

This really was done on purpose, and is pretty much the same for all computing platforms. (Windows, OSX). There is only separation between user accounts.

There is a limit to what you can reasonably enforce at the file level. When you think about it, there are a lot of issues that arise when trying to protect hundreds (possibly thousands) of photos/files.

Imagine someone takes thousands of photos and swaps SD cards all the time: How would Android protect the images if the person were to take the SD card out like a camera and plug it into their printer?

Anyways, with the newer devices I'd expect to see some "tinkering" in this area -- maybe in jellybean.
 
Thanks for the hello. Makes me feel all warm and fuzzy. :o
Perhaps that first point --about the SD being considered unprotected storage-- ought to be mentioned in the first post, but I concede that (ironically) it's not a permission per se.

Could you go into greater detail about why it would be hard to go unnoticed? I imagine an observant user might notice a peak in traffic, but other than that ... I am disinclined to agree, as much as I would love to.

About the file systems, well, yes and no. Agreed, there's only so much (which is hardly anything) you can do as long as the file system is straight old FAT, and even *nix file system are a little dodgy on the access control when you've moved the drive to another host. But locally (i.e. on a single Linux-based device), it certainly ought to be rather simple to do better than what we have ... but this is a whole 'nother discussion (one I considered looong ago when it was evident that apps could benefit from a better organised file system hierarchy).

Finally, another thank you for taking time to enlighten us!
 
KlaymenDK said:
Thanks for the hello. Makes me feel all warm and fuzzy. :o
Perhaps that first point --about the SD being considered unprotected storage-- ought to be mentioned in the first post, but I concede that (ironically) it's not a permission per se.

Could you go into greater detail about why it would be hard to go unnoticed? I imagine an observant user might notice a peak in traffic, but other than that ... I am disinclined to agree, as much as I would love to.

About the file systems, well, yes and no. Agreed, there's only so much (which is hardly anything) you can do as long as the file system is straight old FAT, and even *nix file system are a little dodgy on the access control when you've moved the drive to another host. But locally (i.e. on a single Linux-based device), it certainly ought to be rather simple to do better than what we have ... but this is a whole 'nother discussion (one I considered looong ago when it was evident that apps could benefit from a better organised file system hierarchy).

Finally, another thank you for taking time to enlighten us!
Click to expand...


I thought I mentioned it in the guide but I may have just implied it. I'll take note to make it more clear.

You're right in that there is some level of enforcement they can and do perform. Contacts, for example are in protected storage. But when they built the system they had to consider a number of factors. Like you stated FAT file systems being one. Another being that they can't encrypt SD cards for fear they would be unreadable once removed. Another is the number and size of the files. Finally I think it's good to consider the evolution of Android. The G1 had what, like 256MB of internal? 512? And 4 GB SD card?


Anyway will write more soon gtg
 
First, alostpacket- your app was the first thing I ever downloaded from the market when I bought an android, and it's invaluable! And the updated version just takes it over the top- I really think that google should be throwing tons of money at you and baking that functionality into the OS itself :-)

Couple general security questions for you, and the collective wisdom of the forum: First, how safe in general are keyboard replacements? I'm frustrated with my stock one, but the possibilities associated with trusting someone else to potentially see what I write makes me hesitate. Some keyboards like SwiftKey are "editor's choice" in the market, and seem to have robust privacy policies, but I'm wondering what the take is on these things from the more security-conscious android users.

Second, can someone explain more clearly what kind of information exactly gets stored in sensitive logs? It every minute action stored (i.e. including things like key presses when entering a password for example), or is it more system-related information? I've been VERY wary of installing anything that wants that permission, and have shied away from even highly rated apps like Evernote because they require it (much to my frustration). However, there are some services that don't really have alternatives. I've noticed a number of streaming services that want that permission for example (and up here in Canada there aren't many good alternatives to things like Netflix or Rdio- both of which have that permission). Is there a particular reason why a streaming service would need access to those logs?

Third (though related to the last question), to what degree are apps vulnerable to being hacked by other apps or programs to take advantage of their permissions? For example, if I decided to trust Netflix to access my logs so I can stream video (and lets assume I download the correct app to begin with and not something masquerading as Netflix :-)), would it be possible for a different program to spoof the connection, or somehow link into it and get to my logs through that app? Is that even something that can be done theoretically?

Thanks!!
 
The reason those apps request the permission is for debugging if something goes wrong. However, that isn't a GOOD reason to request it. They can easily write their own logs. The READ_LOGS permission gives them access to all the other logs.

I'd write to any app maker using that and complain.

Common things you will see "leaked" into the global log include:

-Network coordinates
-GPS coordinates
-Network IDs
-WiFi IDs
-Contact information (phone numbers, addressses, email addresses)

The number of apps that put this information in the global logs is staggering. So that's what makes this a permission that should not be granted. It was actually never intended for publicly released applications, but rather for developers.

So ultimately, while I think those apps are unlikely to be doing anything nefarious to you, I'd still complain to them.


hope that helps and thanks for the kind words about PocketPermissions! I agree Google should pay me truckloads of cash :D
 
I read a comment on one of the AC's article about sending in crash report:

we developers actually get very little information from the report sent, the Log report only shows the error and nothing else. We DONT see what phone, version, carrier etc. writing in the comments what you were doing can also help because we can only see the comments
Click to expand...
How true is this statement?
 
This is mostly true. We're supposed to get info about the type of device and version of Android it was running but it always shows as "other" :rolleyes:

However, we do get what is called a stack trace. This is the line number and methods (functions) that caused the error. This is very helpful for tracking down bugs.

For example, here's one of mine from PocketPermissions:

(in case you are wondering, this happens if a user uninstalls an app while using PocketPermissions, then presses the back button to go back to my app.)

Caused by: java.lang.NullPointerException
at com.alostpacket.pocketpermissions.fragments.AppDetailFrag.displayContent(AppDetailFrag.java:306)
at com.alostpacket.pocketpermissions.fragments.AppDetailFrag.continueFragment(AppDetailFrag.java:507)
at com.alostpacket.pocketpermissions.fragments.BaseFrag.checkForModelOrLoad(BaseFrag.java:146)
at com.alostpacket.pocketpermissions.fragments.BaseFrag.onResume(BaseFrag.java:136)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:917)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1080)
at android.support.v4.app.BackStackRecord.run(BackStackRecord.java:622)
at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1416)
at android.support.v4.app.FragmentActivity.onPostResume(FragmentActivity.java:413)
at android.app.Activity.performResume(Activity.java:3883)
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2114)
... 12 more
Click to expand...
 
Yep the battery permission is mostly innocuous. But I will add it to my notes for permissions to add to the list.

thanks! and thanks to EM/xyro for helpin out :)
 
mieramohamad said:
tq for sharing.
i need ur help.can u give me some example of logs for android?
other then iptables log.
Click to expand...

When it comes to the READ_LOGS permission they are primarily referring to the ADB log, also know as LogCat.

This is master log all apps use for debugging. The problem is, some apps put info into the master log that they shouldn't.
 
1hamster said:
great sticky can i just ask one question what if a program nees phone calls read phone state and identitity?
Click to expand...

Most of the basics about that permission are discussed in the first post. However, let me know if there is a specific question you have about it, and I would be glad to try and help :)
 
You must log in or register to reply here.
Back
Top Bottom