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.'"
I'm going back to winmo where it's "Safe!"
My abilities are only limited by my imagination
A wallpaper APP? Why would you need an app? It can't just display a jpg as wallpaper?
Free Martian Whores!
This is a very good reason to run Droidwall. However, the bad news is that Android apps are going to a model where they ping one of Google's servers to check if they are licensed for that user. Of course, Droidwall can be updated to allow any apps to connect to that server farm's IP address range even if they are disallowed from anywhere else, but that may take some programming.
Droidwall also requires root access.
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.
God help anybody who used facebook and this app... there's every chance they will get home tonight and find an imposter in bed with their wife.
Reminds me of advertisements in magazines where you text a code to a phone number, and they send you a wallpaper and sign you up for a subscription. Nope, they won't be sending you any text spam. Not a single piece. ::wink wink nudge nudge shank shank::
Living With a Nerd
This is one good reason to have a unified app service, where all the apps are first vetted before they are released. I think mozilla's addon collection is a good model to follow.
I am surprised, shocked, and dismayed to see a fine journalistic source such as Slashdot stoop to yellow journalism, as it were. There is absolutely nothing suspicious about the origin of the website being being in Shenzen, China and the summary's implication of this is absolutely untoward. I expect a full apology posted immediately, then duped again tomorrow.
A NYC lawyer blogs. http://www.chuangblog.com/
Do you really need to know the name of the app in order to avoid it? I think that you should know well enough to avoid wallpaper apps! Those (and screensavers) were something like number 1 way for viruses to spread on computers in the late 90s or so. The same people who fell for those then can now afford expensive phones and fall again for the same scam.
Well, part of the news here is the comparison to Apple's heavily-controlled store model. Would this have happened on the iPhone? Would the app have even been approved?
Even if they're told exactly what the app will have access to, people will click through anything.
Update from TFA:
Update: Lookout notes it does not capture browsing history and text messages: It collects your browsing history, text messages, your phone’s SIM card number, subscriber identification, and even your voicemail password, as long as it is programmed automatically into your phone.
Looks like it doesn't collect browsing history and text messages after all.
I'm not convinced that such an app would necessarily be caught by Apple's model. Apple doesn't even really review the source code; there was a tethering app disguised as a flashlight app that made it to the app store and stayed there until the media brought attention to it.
Developers bitch about the app store approval process but this is exactly why it exists. Yes it would be nice to sever ties with the app store but apple is doing a fairly good job of protecting it's ecosystem.
Got Code?
When I read TFA, I saw the part where 47% of Droid apps use third party coding, and 23% of Apple apps also use it. Then I realized, there's no safe place to hide. I like my walled garden, but even that has leaks.
Here's to hot beer, cold women, and Glaswegian kisses for all.
You might want to read this cousin post and the links contained therein before you hold on too tightly to that belief.
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.
Well, part of the news here is the comparison to Apple's heavily-controlled store model. Would this have happened on the iPhone? Would the app have even been approved?
Yes. Yes it would have.
Living With a Nerd
Hey, the Flashlight app was approved
http://apple.slashdot.org/story/10/07/21/0148214/Flashlight-iPhone-App-Enables-Tethering
Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
They've both pulled out of someone's ass. Google doesn't release those stats.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
None of those apps stole data from people's phones. Instead, they artificially voted one another up to generate sales, and users' iTunes accounts were hacked. That's obviously still a grievous security failure, but it's server-side, and has nothing to do with the app store's approval process.
I remember looking at the permissions required required for this background image application thinking, why could a wallpaper application really need my contacts, location, browsing history etc..
If you live and breathe technology like we do, it was obvious that this application was spyware.
I've got the "Lookout" application on my phone, both for the location based phone recover, backup, and antivirus. I wonder if the company will one day use my backups for profit, sleaze, or stupidity.
At the end of the day, life is insecure. I fret over every application I install to my computer. The same is true of my phone. I also assume that the government already reads all my text messages.
I don't begrudge Apple for keeping a close eye on application store. I just insist on the kind of flexibility and power that android applications have.
You won't find a text message reading background application on the iPhone app store. You also won't find a replacement for the home screen, because Apple doesn't approve of that.
You win some, you lose some.
It's too bad that malicious people have to ruin an open-source forum like the Android with crap like this. I can see why Apple scrutinizes over the application approval process because I'm sure this is one concern on top of just being plain difficult about the whole matter.
I guess don't have a criminal mindset and have put my tomfoolery hat away, it's bad enough having hack and malicious threats on the computer level, now my phone? I miss the days of my 2x10 backlit serial display analog cell phone that did nothing more than dial a phone number.
The platforms may vary but at the end of the day, this is just yet another stupid article about stupid people giving away their private data because they did something stupid. Since we, or at least anyone in IT, engineer and support alike already know that stupid people do stupid things why are these articles considered "news worthy" here? Is it meant to inspire us to come up with our own interesting ways to dupe stupid people? Surely we get enough reminders in our day to day that we don't need them for that.
Two of my imaginary friends reproduced once
So these apps were removed for being scams, or because they were doing questionable things...but Apple shouldn't have caught on to this during the approval process?
That's...that's awesome. Nicely done. ::eye roll::
Living With a Nerd
let the down-modding begin! adios to your score. you can't go into an android thread and start saying private API's are a good thing. recipe for disaster. Open is god! Open is right!
Looking at one of these apps ("Dark World Wallpapers") the app asks for the following permissions:
- Storage - modify/delete SD card contents
- Your location - coarse (network-based) location
- Network Communication - full Internet access
- Phone calls - read phone state and identity
It's nice android warns what permissions an app needs, but some of them (especially the "Phone calls" section) could be worded better to make it clearer what an app can potentially do.
(Deep voice): Hahahahahahaha we got them my minions
I'm here for the experience, not the Hyperbole.
It's Shenzhen, not Shenzen. And note to gweilos: 'zh' is pronounced roughly like a 'j' in 'Benjamin'.
I support the Slashcott and will not be reading or commenting from 2/10/14 to 2/17/14. Beta is steaming pile of dog shit
The apps (or rather, the Android Market) told you at install-time that they wanted access to your Google accounts. Anyone who didn't back out on seeing that... well, I wouldn't say "deserves what they get", but I will say "was adequately forewarned".
;this is the type of bad PR that can & should change some policies
This is the type of PR that has nannies running about to enact new policies to "protect the users" -- when if the users had paid attention in the first place (eg - denied the requested permissions) this never would have been a problem. Don't punish the few because the many can't or don't read.
The app store was gamed by a company or companies submitting thousands of near-identical and practically useless, though innocuous, apps that were voted up artificially. How would the app store approval process catch that, exactly? The apps themselves did not break any rules. It's more of a social engineering hack than anything else.
The iTunes server hack was a separate thing altogether - a security failure on Apple's part, but nothing to do with apps or approval.
Just to be clear, 95% of all apps submitted are approved by Apple. What they look for is simple:
1. Does it work as advertised?
2. Does it crash?
3. Does it present a privacy violation or objectionable content (porn, basically)?
The "objectionable content" thing is dubious, but if you want porn on your iPhone, just use the browser.
Right. Because that's worked so well. Keep in mind that these refer to apps that made it through the vetting process.
Knees jerking much? The parent mentioned Mozilla's add-ons, not Apple's App Store.
Also, you should note that the stories you're linking to are about the hacking of iTMS accounts for the abuse of a community rating system, rather than rogue spyware apps stealing personal data.
I personally don't know whether Apple's approval process or Mozilla's add-on review process has a better or worse record or screening out such things, but if you're going to go all "linky! looky! Apple has apps with these problems too!" you should make sure that you're talking about the same thing as the article. Or the parent comment you're responding to.
Tweet, tweet.
I'm not convinced that such an app would necessarily be caught by Apple's model. Apple doesn't even really review the source code; there was a tethering app disguised as a flashlight app that made it to the app store and stayed there until the media brought attention to it.
The iOS App Store approval process might not have caught this; but there is a non-zero probability it might have. Of course, given the problems with the approval process, there is also a non-zero possibility that Apple might have unintentionally blocked it for reasons having nothing to do with security. In any case, it would be interesting for Apple to release statistics on how many malware apps the App Store has blocked.
The current Android app distribution system, totally lacking any security review, has a zero probability of catching malware. Anyone with a brain knew that this was a significant possibility inherent in the more open model that Google has championed. However, this presents Google with a serious potential long-term problem--if Android phones are perceived as being insecure, it will impact sales. The market reaction will be interesting the first time somebody having a heart attack tries to dial 911 on an Android phone and dies because the phone said "u bin pwned noob!" instead of calling the rescue squad.
Fans of Android can mock Apple for its antenna woes and screwy app approval process (and rightly so); but if Android ends up being constantly hacked, it will hurt the Android platform far more than Apple's antenna and App Store problems. Nobody wants to have to download and manage anti-virus apps or firewalls onto their cell phone. That would make Apple look prescient for establishing a system that offers at least some promise of blocking malware from the iPhone ecosystem.
someone named "Job Stevens"
"Waste not one watt!" - CZ
PC Mag reports 4.6 million. However...
Brian Heater writes:
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
Huh? It says right in the Marketplace listing how many times an app has been downloaded.
OK: there is still an opportunity for new apps, or recent 'urgent' patches, to do evil before they have been looked at, but the risk is greatly reduced.
Unless they read the code (do they?) they'd be hard pressed to detect this exact malicious behavior before it occurred.. Anyone know how this works on Apple's store?
Bad, knee-jerk analogy - removing this application from the marketplace isn't "punishing the few" - who on Earth would ever want it? Policies to prevent similar apps would only be beneficial, so long as they were *sanely* implemented, and specifically addressed security/deceptive practices, not profanity, obscenity, etc. A basic level of review for security and some very OPEN standards would be a good thing. Doesn't /. moderate its comments for a reason??
Hey, it only took you three tries to make this post on-topic!
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Well, part of the news here is the comparison to Apple's heavily-controlled store model. Would this have happened on the iPhone? Would the app have even been approved?
Yes. Yes it would have.
Those are examples of a developer "hacking" into people's itunes accounts to buy his crappy apps, not the app itself stealing data from the phone and sending it to a server. Still sucks, but it's a different issue. I think the itunes username and passwords were harvested via good old-fashioned viruses, trojans and phishing. Maybe some brute force attacks.
Some privacy policy Slashdot.
Apple's private API setup would work for geeks IF they put a checkbox in the config like Android does for app installs to allow 3rd party utilization. Walling off the API is fine if I can override the manufacturer's wall if desired.
Hey, don't tell me, I know. But studies show people will basically answer "Yes" to anything, and there's no reason a BASIC level of scrutiny couldn't be applied to Android marketplace apps, especially those that do access account info, without going too far and blocking legitimate apps as Apple has. Actually, there is a reason, and I suppose it has to do with cost and trying to juxtaposition Android as the "open" alternative, but "open" doesn't have to mean "jam-packed with spam apps & sexy wallpaper crap that steals data if you're not careful"...
Now they can use their Remote Application Removal feature.
"If fifty million people say a foolish thing, it's still a foolish thing."
Okay, so the iPhone vetting process sucks and the Android is to easy to install malware.
I've noticed that with chrome, each extension I install asks for permission to use a specific list of services. I'm assuming that if they try to use a service that they haven't asked to use, they will be denied.
I'd really like this to be THE universal security measure. When I install a game, I expect it to tell me that it wants to use the registry (under it's name only), read/write the hard disk (under it's directory and user/saves) and the Network.
If I install word and it tells me it want's to use the network, I expect I'd be able to uncheck that selection and word would function but it would be completely blocked from using the internet at the OS level.
These apps really need to be sandboxed. This generally involves a virtual memory space, but I think Google should be able to pull it off.
In the long run I think Google is headed in the right direction, I'm not sure Apple will be able to keep up in the security arena. Apple is stuck compiling to C which is a little harder to sandbox--Google can manipulate it's code a little better and already has the right idea (if not in the right department yet).
There's no requirement to submit source code, though you can if you want to, I suppose. I'm not sure if they look at network activity or not - I expect they do, as there hasn't been any malware on the scale of this Android app yet. But to be honest, I think it's only a matter of time before something slips through.
As for the iTunes hack, I was wrong - apparently, people's credit card info was stolen from their Windows PCs by malware they installed. These numbers were used to purchase tons of copies of apps by a Vietnamese developer, thus improving his app store rankings.
It's not enough for an app to say what things it needs to do. By default any action by a 3rd party app involving personal data or phone calls should explicitly request user permission each and time it is accessed. If the user really trusts an app they could disable these screens from the app's management settings.
They already did that with Ubuntu users despite all the proclamations that Loonix was immune to such things.
I don't know what Loonix is, but no-one ever said that Linux was immune to a virus, only that it's very hard to create one because of the restrictive user permissions.
The screensaver in question required you to download a .deb file from the web and then install it with root permission. When you're dumb enough to run random downloads as root it's game over on any operating system.
And, in any case, wasn't it just a trojan rather than a virus? I don't remember it actively spreading anywhere.
Thanks. It seems like a relatively trivial engineering activity to suppress the malicious behavior until the developer puts a "green light" beacon on his website. Having the app phone home wouldn't look suspicious on the wire during Apple's app review, and then once Apple signs off on the app, turn the beacon green and start stealing data. As you say it's only a matter of time. Unless you want to analyze every app's source code which seems ludicrous for a bunch of reasons.
Thanks again for a little more insight into how all this is working.
That can be easily addressed via social engineering.
Here's an example of what seems to be a benevolent app that required some questionable permissions to do some very useful things. The app in question is the official XBMC remote control app, for which the source code is thankfully available. The point is, however, that certain potentially dangerous permissions (or combinations of permissions, like Internet access plus access to contacts) are sometimes needed to perform harmless but useful functions. In the wrong hands, though, the same permissions can be fraught with danger.
Here are the XBMC Remote App's permissions explained (http://code.google.com/p/android-xbmcremote/wiki/Permissions):
We don't like apps demanding permissions that don't seem obvious, so here we'll explain each permission XBMC Remote asks prior to installation:
INTERNET - We need to connect to XBMC. The INTERNET permissions actually controls any socket, internet or not, so this is unavoidable.
ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE, CHANGE_WIFI_STATE - We've introduced an option that avoids connecting to XBMC when not connected to WiFi. In order to check this we need this permissions.
VIBRATE - Remote control screen lightly vibrates to give a more realistic user experience (configurable).
READ_PHONE_STATE - We have a feature that pauses anything playing on incoming calls. In order to receive this event, we need this permission.
RECEIVE_SMS - The feature that displays SMS on the TV screen needs this permission in order to obtain the messages.
READ_CONTACTS - In order to display contact info (and picture) on incoming calls or messages, we need permission to read the phone book.
READ_SMS - When displaying SMS, we actually display the first part of the message, so we'll need read permissions of SMS.
WAKE_LOCK, DISABLE_KEYGUARD - A requested feature was overwriting the power manager to keep the processor from sleeping or the screen from dimming. This is configurable, but we'll need the permissions in any case (activated or not).
WRITE_EXTERNAL_STORAGE - In order to save cover and poster thumbnails locally for caching purpose, we need write access to your SD card. This permission was introduced with Android 1.6.
Explained this way, the permissions seem quite reasonable. In fact, they are necessary for the app to work properly. Yet because Google/Android grants permissions as they do, they still require a "trust us" post like this to explain why the permissions are needed.
The take-home point is that even people that are actively trying to personally filter apps by screening the permissions can't do a good job of it, because quite a few apps need risky permissions to be useful. So often it still comes down to "trust us", and that's just not the most comfortable situation. It could be done much better.
I'd prefer the ability to selectively reject certain permissions, or at least be able to whitelist them rather than allowing everything wholesale at install time. NoScript can be a PITA, but it's a good model of how this could work. Allow questionable actions only by permission at run time, and allow them to be revoked at any time. I could live with that.
I really doubt it would have. Apple would have put the app through its testing process and discovered its attempt to send personal data to a third-party server.
The examples you give aren't the same as what is being discussed here. They didn't steal personal data.
The apps didn't steal personal data and send it to some third-party server. Instead, people's accounts were hacked through phishing so that the apps could be voted up in the store. So no, Apple wouldn't have caught onto it during the approval process.
Anything else? You're not very good at this.
Too bad it does not. The fact is malicious and even tethering apps have gotten through. You are a fool.
..if only there was a phone that had a tightly controlled app store that would at least have a chance of catching stuff like this before it gets into the wild. Oh. Wait. There is. Never mind.
Nitewing '98
Everything works...in theory.
So these apps were removed for being scams, or because they were doing questionable things...but Apple shouldn't have caught on to this during the approval process? That's...that's awesome. Nicely done. ::eye roll::
The apps were perfectly fine and didn't scam anything. From the Independent article a few posts up:
"... it is estimated that hundreds of Apple customers have become victims. It is thought that some may have been hit by a "phishing" scam, in which an apparently legitimate email convinces the recipient to part with sensitive information."
This is no different than if some phisher sends you an email purportedly from your bank, and you click on it and give them your banking account number and password. The phisher then goes on a spending spree and buys Android phones with your money. Now, you'd be hard-pressed to argue that Android phones are a scam... it's a means of generating revenue for the phisher if it's bought from their store or if they can sell the phones.
Similarly, if users fall for a phishing scam through email and they click on a link in the email, go to some rogue iTunes-like website, give their iTunes account info, and the phisher uses that harvested account info to buy and positively rate the phisher's apps... that doesn't mean the apps being bought are a scam -- it's simply a means of generating revenue for the phisher.
However, please don't let the facts interrupt a good eye roll. I'm sure it's cathartic for you to vent your anti-Apple sentiments on a routine basis.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
but Apple shouldn't have caught on to this during the approval process?
Please explain how an app approval process can catch something external to the approval process (hacking iTunes accounts through means other than apps) and which hasn't happened yet at the time the approval process takes place.
Unless you want to analyze every app's source code which seems ludicrous for a bunch of reasons.
Apple doesn't examine the source code but it does check to see if the app uses any unapproved APIs. That sort of check is relatively trivial and easy to automate.
My understanding (which is possibly incorrect) is that you would have to use unapproved APIs in order to steal data, and that would get your app rejected.
What malicious apps have gotten through Apple's approval process? I'm open to any links you may have. Don't bother linking to the guy who hacked into iTunes accounts and used them to buy his otherwise legitimate app -- the app itself was not malicious, so there's no reason to blame the approval process for the incident.
You say "tethering apps" as if that's a bad thing. The app didn't steal any data, or use any APIs that could reveal the user's personal data. Apple checks all submissions against their list of approved APIs... an app that steals personal data would have to use unapproved or custom APIs and would therefore be rejected from the app store.
I'm not saying Apple's approval process is perfect, but it *is* set up to catch malicious data-stealing apps.
Lets see, a simple whois shows:
Administrative Contact Name: Ice Ysl
Administrative Contact Organization: 1sters
Administrative Contact Address1: china
Administrative Contact City: shenzhen
Administrative Contact State/Province: guangdong
Administrative Contact Postal Code: 86
Administrative Contact Country: China
Administrative Contact Country Code: CN
Administrative Contact Phone Number: +7.5526814587
Administrative Contact Email: iceskysl@gmail.com
A google search on iceskysl@gmail.com comes up with a surprising number of hits. No fake email here.
Android Intent is so powerful and great.
Our boy has been busy on the Android
And it goes on...
I'd rather say it's because people find technology scary and would rather have someone hold their hands about it, and Apple's business plan relies and thrives on that.
There comes a point where you must expect users to be responsible for themselves. The OS already does what it should: it provides granular permission controls and allows the user to decide what to allow. (I daresay BB OS does it one step better, in that it allows the app to include detailed explanations with the prompts. Though Android's UI for it is better... )
Whether the user chooses to blindly accept that; or whether they actually question why a wallpaper app needs access to their phone books should absolutely be up to the user.
The only thing you can put on top of the controls already in place are the standards you mentioned -- but those standards require people to sit down and review the code of every app coming in the door.
I think comparing this to /. comments is a good analogy though not in the direction you intended: anyone can submit anything and it is published. Only after the comment is published does it get reviewed for behavior (community etiquette/standards); if it fails that test it gets hidden from view -- though not deleted if you want to see it anyway.
Apps today already have stringent requirements: the OS will not allow them to do anything that the user says is bad. Trying to add additional review requirements on top of that will only slow down the process for the vast majority of legitimate developers; and punish those few people who are willing to take responsibility for themselves when installing applications to their devices.
Excuse my ignorance, but to continue your supposedly improved analogy, if I post a comment that is nothing but spam, filled with links to malware, illegal torrents, or whatever, it doesn't get deleted, and /. readers can still see it? I would have expected otherwise, based simply on the potential legal repercussions & CYA policies... that's really what we're talking about, here - violations of law, or at least terms of service...
A fool is someone thinks that because any given deterrent does not achieve 100% success, that all deterrents are completely useless. Go ahead and apply that logic to any scenario you can construct in life.
Unless your app's legitimate/purported purpose involves those same API's.. Apple may make malware authors jump through a few more hoops which might be deterrent enough for now, but they don't strike me as running a service that can inherently protect consumers from malware (as opposed to software which Apple or other trusted developers might provide which is much much less likely to have bad things in them).
These wallpaper apps cannot access your contact's phone numbers, SMS messages or personal information.
Check out the manifest permissions on the apps in question. It is the last item that is the problem.
!Storage
modify Delete
!Your location
coarse (network-based) location
!Network communication
full Internet access
!Phone calls
read phone state and identity
The permission only allow the app to read the IMEI number of your phone (your hardware's unique identifying number), your phone number, and your currently programmed voice-mail number. If you hard coded your voice-mail password as part of your voice-mail number, then they have that too.
They shouldn't be stealing this info, and Google should separate "read phone state" from "read identity", but the stories on this app stating that your SMS's, contacts and grandmother's girdle being stolen and sent to China just plain wrong.
Read the paper by Nick Seriot to see what iPhone apps can do without users being aware of it. And given that iPhone apps can be obfuscated to avoid automatic analysis by Apple, the real question is, how many apps are on the app store that steal your data without anyone knowing about it? Bear in mind that this report is here because Android apps tell you what they can do when you install them. All this company did was grep the market for apps that seemed to request more permissions than they should for their category.
But if you do include malicious code you are running real risks. First off you can be ejected from the store, second all your revenue goes through Apple so maybe they can claw some of it back, third you have to have a legit business to accept the money coming through Apple which you have now opened up to lawsuits from both Apple for not adhering to store policies and your customers.
If all else fails, immortality can always be assured by spectacular error.
You can get it here - http://www.apple.com/webapps/socialnetworking/facebook.html
Starbucks, Harbuckle of Breath.
And everyone then jailbreaks because the platform does not allow them to do what they want, which of course makes them more vulnerable to social engineering attacks as well as maintaining exploitable vulnerabilities in the OS.
Jailbreaking on the Iphone I equate to showering in prison. It may seem like a good idea (from a hygene perspective) and you pretty much end up with no other choice but to do it due to the restriction of the warden but in the end you've just dropped you pants and left yourself exposed and very vulnerable.
The gentry of Europe tried this once, keeping the bloodlines pure and noble. In the end they became so inbred it's not funny (If you think this is a joke, think about Prince Charles and Camilla bumping uglies and there certainly is a lot of ugly to bump).
Calling someone a "hater" only means you can not rationally rebut their argument.
Bingo, it's OS X users who claim an inherent immunity to virus and malware.
Linux users take threats seriously. But this one came in via the user, which is the weakest point of any computer systems security no matter which platform. An unused Windows XP box connected to the internet with AV and Auto Updates on is safer then a used Ubuntu or Mac as almost all security in this day and age is dependent on the user not being stupid.
I'd say it was neither, perhaps a Trojan with the wall paper being camouflage but it fits the definition of spyware better, like Gator, Bonzi Buddy or Facebook.
Calling someone a "hater" only means you can not rationally rebut their argument.
Android has really granular security, which is great! Everything from using bluetooth to writing to the sd card has a permission which the developer must explicitly ask for.The problem is that there are *lots* of these permissions, and a user is presented with a list at install time! I installed an IM client the other day (Nimbuzz, which is popular enough and has a good reputation AFAIK), and I don't even remember the 2 screens of permissions which I agreed too.
When presented with "This application has access to the following": ... .....
Your location: coarse (network-based) location
Network communication: full Internet access
Phone calls: Read phone state and identity
System tools: display system-level alerts, modify global system settings, prevent phone from sleeping, retrieve running applications
Uses bluetooth
Writes to your sd card
Changes your volume settings
Executes instruction 0xdeadbeef
Even a geek's eyes glaze over - everybody just clicks ok and hopes for the best.
And to take the Nimbuzz example again, I am quite sure I agreed to authorize permissions which are associated with features I will never use. The fact that there is no way to say "grant this permission but not that one" is a shortcoming which needs to be fixed. There should probably be an "Advanced..." dialog for that, and some system that catches runtime violations and asks if you want to change your settings to allow them or not.
As all analogies must, that one begins to fall apart there -- 230 of the Communications Decency Act ensures that forum owners are not generally liable for the content posted by participants.
Doubt anyone can pull that off, I have full faith with my left hand.
I'm not sure what you mean. Apple can easily scan for which iOS functions a particular app is linking against. If that list includes APIs which are not on Apple's official "approved" list, then they can reject the app on that basis alone. That part could easily be entirely automated.
At this point, it's clear *you're* not a programmer, so please, just stop. (For the record, I am a programmer, and apparently a better one than you.)