Many More Android Apps Leaking User Data 299
eldavojohn writes "After developing and using TaintDroid, several universities found that of 30 popular free Android apps, half were sharing GPS data and phone numbers with advertisers and remote servers. A few months ago, one app was sending phone numbers to a remote server in China but today the situation looks a lot more pervasive. In their paper (PDF), the researchers blasted Google saying 'Android's coarse grained access control provides insufficient protection against third-party applications seeking to collect sensitive data.' Google's response: 'Android has taken steps to inform users of this trust relationship and to limit the amount of trust a user must grant to any given application developer. We also provide developers with best practices about how to handle user data. We consistently advise users to only install apps they trust.'"
This is why OSS is so important (Score:1, Interesting)
The problem here is that the apps themselves are closed, so you can't inspect the code to see if this kind of thing is going on.
It may just be sending some statistical data so the server can form better assumptions about the user and thus provide better service in the future. Or it may be sending such data for nefarious purposes. Without accessing the code, you can't know, and worse you can't control it.
Java was an interesting implementation language choice in Android, but with the browser-based interface, perhaps Javascript would have been a better system language. It would have been open and users could have more control over their own phone.
Unless removing such control is precisely why Google did it.
Re:This is why OSS is so important (Score:4, Interesting)
No, the problem is gold-rush developers. With a platform like the iPhone, or Android, you have a sudden perception among developers that they can get rich from relatively simple apps. This leads to the '200 fart apps' problem, and it also leads to a massive incentive to get things to market before the competition, which causes a complete lack of QA in the release process.
There is no simple solution to this, the only thing to do is wait for the platforms to mature.
A checklist (Score:5, Interesting)
Rather than a blanket "you can send anything you want anywhere you want/you can send nothing to anywhere" switch, a finer-grained constrained set of permissions may be the way to go. Specifically:
And if an app provider doesn't like the light shone on their activities... that's a pretty good indicator right there.
Re:What Android needs... (Score:5, Interesting)
which, incidentally, is what BlackBerry has. You can allow/deny each app permission to access your address book, calendar, internet connection, send SMS, open your mailbox, etc. I don't think even the iOS have that yet (or well, I think it does, but for GPS location only). An app must be prepared to get an "access denied" exception, and survive through it.
And for corporate users, an admin can even set your phone to not allow installation of custom programs, deny all requests to read the user's calendar/address book (except for a white-list of apps), etc, etc.
As an Android user I wish Android would copy this feature, and as a fan of superior technology, I wish BlackBerry could promote these security features more.
And In Other News... (Score:3, Interesting)
And in other news, smartphone security sucks. News at 11.
Re:But how? (Score:4, Interesting)
Re:This is why OSS is so important (Score:4, Interesting)
This is the value of the App Store that geeks/developers consistently underrate.
That's because a lot of geeks and developers don't need Apple to tell them what not to install, they're typically capable of figuring that out on their own. If a simple card game asks for fine-grain location information or full internet access, that should be a red flag to anyone paying attention.
Maybe it's just the case that Android is for "power users" and Apple is for everyone else, but the value that you see in Apple's store is simply not needed by a lot of the people who buy Android devices, and in fact becomes a negative.
Re:This is why OSS is so important (Score:2, Interesting)
> When rogue apps start to make Android painful to use and own expect consumers to start looking for The Next Big Thing (tm).
Yeah, it'll be like when everyone stopped using Windows and Microsoft was forced out of the OS busi....oh wait...
Comment removed (Score:3, Interesting)
Blackberry too (Score:3, Interesting)
One of the reasons that BB's are so popular with the corporate crowd - despite lacking some of the "nifty" features of other phones - is that they're really good on security. BES allows the corp to do a lot of things to a lost/stolen/etc phone. The data on the handset is supposed to be encrypted, and can easily be reset or wiped. Most apps have varying levels of security that *ASK* the first time (to access the internet, or whatever) whether they should be allowed a one-time or consistent access to various permissions.
I don't see why Android couldn't use a similar model, as it does this for "root" (su) access when it's unlocked. Just keep a small DB listing what apps are allowed to access what features. The problem with the current coarse controls is that they don't really say what access is needed for. Sure, a VOIP app might need your phonebook for making calls, and internet access to do so. How about a game needing internet access to update high-scores (just deny that part if you don't trust the app not to send important data home), or the almighty "can change data on the storage card" access...
Re:This is why OSS is so important (Score:5, Interesting)
Eh - malicious devs aren't retarded. If you are going to write code that does something bad, you'll hide it in an app that would also need that level of access.
For example - if I want to write an app that will secretly send text messages from your own to a premium text service that will cost you $9.99 per text - I wouldn't stick it into a card game app. I'd stick it into an app that claims to do something novel or useful with text messages. Like an app that takes your boring text message and translates it into ebonics, or leet speak or whatever.
If you code it in such a way that, it won't send out the premium texts until after a particular date - say 3 months after you write it; if it's a half-way decent app, you'd have plenty of time to build a user base with decent ratings.
Re:Google's response == fluff (Score:3, Interesting)
I don't see the big deal with this. Android gives you infinitely more information about what an app is going to do than anything on the PC.
On my phone, I'll at least know if the app is going to look at my location, contacts, etc. and can make the choice to install it or not.
On my PC, all I know is that I'm downloading some binary data that could do anything it wanted.
It's not that hard. If you download a game that wants access to your contact data and full internet access, don't install it. Yes, even if the game looks really, really, cool. You may claim that Google is the devil here because they allowed devs to have the possibility of accessing my data, but I claim that they're good for giving devs the option. If I want to write an app for my own phone to organize my contact list by area code, I can do that.
Re:And In Other News... (Score:4, Interesting)
"One of the benefits of a single app store" -- like the single Android Market, you mean? You don't know how good Apple's security screening is, so you just choose to trust them for no reason whatsoever.
Re:What Android needs... (Score:2, Interesting)
What's interesting is that if an Android app doesn't have permission an exception is raised, but you're taught to make sure to add the permission flag instead of catching the exception. (Which makes sense, because as it stands right now, if you don't set the flag you'll -never- get the permission). But if they had told you to catch the exceptions, applications would be ready for user-flippable permissions.
Exactly. Take Camera.open for instance. According to the javadocs...
Throws
RuntimeException if connection to the camera service fails (for example, if the camera is in use by another process).
What about a permission exception?!?!
No - instead they say - "If you want to use the camera, include this catch all crap!"
<uses-permission android:name="android.permission.CAMERA" / >
<uses-feature android:name="android.hardware.camera" / >
<uses-feature android:name="android.hardware.camera.autofocus" / >
That's been my biggest pet peeve so far in developing. It can turn into a "add permission until it works" game for lazy developers.
Re:This is why OSS is so important (Score:4, Interesting)
This is the value of the App Store that geeks/developers consistently underrate. Apple's walled garden provides a barrier to entry that helps to reduce the risk of ending up with a fart app that's also downloading your private banking information to China.
This could also lead to a false sense of security, which is also massively underrated. Apple can't possibly catch all software flaws. Indeed iOS4 was jailbreaked by a vulnerability in PDF code, leading to a simple website visit to gain root access to your phone. Which was a little scary to think what might have happend if that vulnerbaility was in the hands of a malicious party.
Android won't need anti-virus because it is very robust security model. It is linux after all, which is largely virus and malware free. The design of the OS is even more robust than desktop linux. With the exception of rooted phones, viruses would find it very difficult to propogate let alone do any real damage.
The occasional malicious app that steals some userdata is about all that can go wrong. For now.
The value of the Apple App store is Apple has done some of the thinking for you. Unfortunately this means iOS users will install everything without ever stopping to consider security. This is dangerous to have a user base completely ignorant of security matters and Apple is demonstrably guilty of keeping it's users in the dark as much as possible. Androids prompt for permissions is a rather good way of making people stop and think about the app you are about to install, and I believe this kind of thing is the correct initial approach. User education is 90% of the problem with security on digital platforms.
In practice, both iOS and Android have problems with malware already, and it's hard to say one has more of a problem than the other. Frankly, neither approach to app security is ideal therefore both platforms will be constantly fighting malware. Android could do with a lot more quality control - at very least stop neglecting the market, the moderation system for comments and ratings needs updating. Nothing beats weeding out bad apps by a good feedback system.
Re:But how? (Score:2, Interesting)
Good question. I wanted to install a recipe application by a popular brand name company (although the idea of trust with said company might be a little shaky - their guacamole only contains 2% avocado or somesuch) but I didn't feel right because of the permissions required. This app is available for the iPhone, so I don't know if it comes with the same restrictions. I emailed them asking them why the app needs to know my phone's identity and contact data as well as location. They responded thinking that I had a problem installing and downloading the app. I re-explained what I wanted to know and haven't heard back from them. That was at least two months ago.
Re:Core features of apps == "leaks"? (Score:2, Interesting)
You'll note that that part of the article to which you refer is describing the permissions that the app asks for... in other words, these are the categories for the intended behavior of the app. So, yes... you've discovered that the article succeeds in providing the intended behavior of each of the apps tested. Congratulations! You've cracked that sucker wide open!
Now, go ahead and read the rest of the article to find the parts that discuss the ways in which some of the apps misbehave.
Re:This isn't an Android problem (Score:3, Interesting)
Re:And In Other News... (Score:4, Interesting)
dialog to ask the user for technical permissions system is fatally flawed
understanding doesn't help me, not sure why it would help others. I think the flaw is it asks too late, and you can't block any of them to still use the App. IE I wanted a app to track car maintenance and MPG, I find the one that looks best, best reviewed... Now it comes up and says it wants phone, and internet access... Not needed for what I wanted, but what do I do now? Look for another, buy, install, and wait to see if it is worse?
Would be nice if google also disclosed that in the app market before choosing, then maybe developers would explain what they used the connections for...
Re:And In Other News... (Score:3, Interesting)
I own an iPhone, iPod Touch and iPad, and am also a developer.
And I know that apps for them have remarkably free reign over when they can do, what data they have access to, and where they can send the data. And Apple really can't do much to police it, other than to pull the app [and I suppose possibly remotely delete/disable apps] if it is reported that an app is doing something wrong. Because they can really only do black-box testing, as they don't have access to your applications source code, what any application does is primarily based on trust. The only API that asks the user for permission [where the OS asks, and the app can't just get the data without asking], is your current GPS location. And once the app has got your permission for this location, it can send that location wherever it wants.
As an example of this, an app in the App Store, which was sold as being a Flashlight app [basically just made your display all white, so you could see a little if you were somewhere really dark], but it also secretly had the ability to act as a wireless proxy [so you could tether your computer or other device to it and use your 3G connection for data without needing permission or to pay extra to your carrier (ahem, AT&T)]. If any app would get noticed by their approval process, this would be it, as there would be no reason for a flashlight app to even link against all the networking API's it would have to, to provide this functionality. And it only got pulled after it was publicized as having this tethering capability...
Re:And In Other News... (Score:3, Interesting)
There was a story on /. a couple of years ago about an iPhone app that sent the user's phone number back to the developer, and then he called them trying to sell the paid version. It is hardly a problem just limited to Android.