Slashdot Mirror
Android Data Stealing App Downloaded By Millions
wisebabo writes "A wallpaper utility (that presents purloined copyrighted material) 'quietly collects personal information such as SIM card numbers, text messages, subscriber identification, and voicemail passwords. The data is then sent to www.imnet.us, a site that hails from Shenzen, China.'"
According to this [http://phandroid.com/2010/07/29/another-app-stealing-data/].
"Your voicemail's password is also not transmitted unless you included the password in your phone's voicemail number field."
It is by my will alone my thoughts acquire motion; it is by the juice of the coffee bean that the thoughts acquire speed
What was the NAME of this evil app? Neither TFS nor TFA bother to tell us that. We got the Dev Name which is almost as good, but geez.
When I started learning android, one of the first programs I made was literally just text and a color background right... and it still asked for permission for calls! I was like hrm, maybe I got a tampered with version of the SDK? But that is why I'm just like *shrugs it off* when I see wall paper apps request phone call access. Now, I don't download wall paper apps lol but, I can see why those who did shrugged it off as well. This is probably something that google needs to explain better, or I need to learn better, or things need to be changed.
My abilities are only limited by my imagination
This is sort of like the early days of MS-DOS, back when everyone trusted everything they downloaded.
Although Android apps do run in a security "sandbox" whereby they can't access the user space of other apps (see http://developer.android.com/guide/topics/security/security.html for more information), they can and do access the general configuration information of the phone such as personal data, phone calls, and SIM information, and some apps obviously need to use the phone's dialup or networking capabilities.
At install time, the user is shown a list of resources the app will access, but since most apps need at least some resources on the device to be useful, we are all in the habit of just clicking past this screen and installing, and then hoping the app is not malevolent in some way.
I think there needs to be some sort of sandbox where apps can reside prior to full release into the wild. Probably, most users won't understand how to use such a feature, but knowledgeable users would make use of it, and ultimately it would help promulgate security concepts into the general consciousness. Power users who write reviews and prominent blog pieces on Android will be able to help guide the masses to safer use of apps.
it's = "it is"; its = possessive. E.g., it's flapping its wings.
Apple is doing an equally bad job of protecting its ecosystem.
There have been several customer-data-grabbing iPhone apps, and these have only been yanked after members of the public alerted Apple to them.
Pinchmedia: http://i-phone-home.blogspot.com/2009/07/pinchmedia-anatomy-of-spyware-vendor.html
Storm8: http://www.sfgate.com/cgi-bin/blogs/ybenjamin/detail??blogid=150&entry_id=51077
MogoRoad: http://www.theregister.co.uk/2009/09/30/iphone_security/
Smuggling tethering past the censors: http://top10.com/mobilephones/news/2010/07/app_smuggles_tethering_onto_iphone/
Apple don't look at the source code of apps, they just test the binary and scan it for badness.
Provided the binary encrypts its strings, and does nothing dodgy during the short testing window (less than two weeks), Apple approve it.
Apple's custodianship doesn't protect you from determined data thieves, only the incompetent ones.
Android market, while just as bad as Apple, at least gives you the opportunity to decide if you want an app based on what permissions it demands. If it demands too much, you reject it. Once you give it the "OK", it can't turn around and demand more. I'd prefer that Apple added that (telling you what permissions the code has, not letting it have more), even if they keep their approval process.
Does my bum look big in this?
Your manifest file is wrong. You request a list of permissions that your app is then allowed to use, but requesting them does not mean you used it. You probably have PROCESS_OUTGOING_CALLS or CALL_PHONE listed unnecessarily.
honestly, i think that you did something wrong with your test app. there are tons of highly intricate apps that do not request permission to make calls. now, if your app wanted to go to the background when a call came and relaunch when the call is over that's something different. however, that permission is "read phone state" which does not sound the same at all.
Yes, "read phone state" sounds totally different than "make phone calls" or whatever the exact verbage is... /sarcasm
Cellphones went mainstream about 10 years ago, and even smartphones like those based on Android are very common. This means they are in the market where you need it to be so simple that someone with a barely functioning grasp of English could figure it out.
To software engineers, there might be a difference between "read phone state" and "make phone calls" but to a layperson there really isn't. You really need to look at it with the "would it work in a car" mentality: is it simple enough to be put into a car and be figured out by anyone with a mild amount of training in "not crashing"? Hint: "turn key to start" is good, an arrow indicating which way to turn it is better, and "please select from the available options: Activate engine controls. Activate engine starter motor. Activate seat belt latch." is NOT going to go over well.
All this nonsense about "well the user was advised that SIM activity could be perturbed by the inclusion of application permission" as an excuse for a poorly implemented security platform needs to be thrown out the window unless you want Android to turn into Windows Mobile 6 in a matter of months while security and usability problems fly out of the woodwork and people flock to a different platform without such headaches.