Submitted by Last week, a study was published that showed how 15 popular applications in the Android Market shared location data with advertisement servers, while 10 shared unique identifiers with them, as well. Glad you’re using an iPhone? Not so fast – another study, published over the weekend, shows that the iOS ain’t much better in this regard.
The Android study was done by people from Penn State University, Duke University, and Intel Labs, using a tool they created called TaintDroid. They studied 30 popular applications from the Android Market, chosen at random, and came to the conclusion that a selection of them transmitted location data and/or unique identifiers to advertisement servers.
Google already responded to this study last week, stating that applications always ask for permission to access any personal information upon installation – this is a requirement for the Android Market. As such, Google noted that “none of the applications studied in this research operated outside of the Android Permissions model, so in each case, a user would have already granted the application access to the resources listed (e.g. location, device ID, etc)”.
While this is true, it ignores the fact that while applications on Android may ask for permission to use personal information, it’s never really clear how or why they’re using this information. Sure, it makes sense for a, I don’t know, route tracking application to have access to your GPS data – but at the same time, you have no idea if the application isn’t also sending this information to third party advertisement servers.
While a far more controlled environment, Apple’s iOS isn’t free from these kinds of issues either, as noted by a study performed at Bucknell University. This study requires some historical background: back in 1999, Intel’s newly announced Pentium III processors contained a unique serial number per processor, which didn’t sit well with the industry and governments the world over. They worried that it could be used to track users’ online behaviour, and some governments even went as far as asking for a ban on Pentium III processors. Intel removed this serial number shortly afterwards.
The iPhone, iPod Touch, and iPad, however, contain something similar: the Unique Device Identifier (UDID). Apple promotes the use of UDIDs as a way for application developers to link information to specific devices, e.g. storing high scores in a game on a central server. While Apple states that the UDID may not be linked to personally identifiable information, there is no mechanism in place to prevent this from happening, nor is there a mechanism to prevent the UDID from being shared with third parties (such as advertisement firms).
The study in question was performed to “determine if the privacy fears surrounding the Pentium 3 have manifested themselves on the iPhone platform”. In order to do so, they studied 57 random popular applications from the App Store, and came to interesting conclusions.
“We found that 68% of these applications were transmitting UDIDs to servers under the application vendor’s control each time the application is launched. Furthermore, 18% of the applications tested encrypted their communications such that it was not clear what type of data was being shared,” the study notes, “A scant 14% of the tested applications appear to be clean. We also confirmed that some applications are able to link the UDID to a real-world identity.”
“For example,” the study continues, “Amazon’s application communicates the logged-in user’s real name in plain text, along with the UDID, permitting both Amazon.com and network eavesdroppers to easily match a phone’s UDID with the name of the phone’s owner. The CBS News application transmits both the UDID and the iPhone device’s user-assigned name, which frequently contains the owner’s real name.”
As a conclusion, the study states that all this poses a real threat to iOS users. “Privacy and security advocates, personal iPhone owners, and corporate iPhone administrators should be concerned that it would be feasible – and technically, quite simple – for their browsing patterns, app usage, and physical location collected and sold to unintended customers such as advertisers, spouses, divorce lawyers, debt collectors, or industrial spies,” the study argues, “Since Apple has not provided a tool for end-users to delete application cookies or to block the visibility of the UDID to applications, iPhone owners are helpless to prevent their phones from leaking this information.”
It’s difficult to ascertain how much of an issue this – both the Android and iOS one – really is. Sure, it’s a matter of principal that devices should not emit information like this for everyone to see without users’ consent, but at the same time, allowing very fine-grained control over these matters will only serve to confuse most users. This confusion could have two outcomes; users see a complicated privacy dialog and automatically cancel out of fear. However, considering just how many applications use personal data, it could also lead to users becoming numb to such dialogs.
In the end, it may already be too late, as a Google spokesperson notes. “Note that this trust relationship between the user and the software maker exists regardless of the platform – even in desktop software and more controlled application environments,” he said, “It is not specific to Android. As an industry, we’ve never been able to 100% guarantee what a software maker (on any platform) will do with data to which they are entrusted.”
Still, it is good to see people paying attention to this and questioning the uses and motives of these application developers.
If you see a notice that says “please bend over to use” …don’t install it.
Why should Android be different from any other OS?
On the technical side, the user should be able to selectively deny the application access to some of the resources. (ie. each permission should be associated with a checkbox, and its description should not only answer the question “what” resources are needed but also “why”)
On the policy side – if the application is found to abuse this contract – it should be removed from the Market and optionally from user devices.
It’s not an unsolvable problem. It’s just that no one simply thought about it in the first place. Which is not that surprising if you recall what is the privacy policy of Google itself.
0_o
That line of logic goes nowhere fast.
You can’t make every possible capability of every application able to be disabled.
It’s not ‘abuse’ of anything if you agreed to it.
Read the contracts you sign. Simple.
This isn’t really a platform issue at all, this is a developer issue: the application developers do things they are not supposed to. As such a simple fix is most likely the best one: if your application transmits identifying data anywhere it must clearly tell the user what it is going to transmit and where, and if the application doesn’t comply then it is removed from Android Market.
Simple, and efficient.
Yup.
That’s exactly what they do, so there’s no problem.
That’s exactly what they do, so there’s no problem.
No, they don’t. The app asks for permission to personal information and internet and yes, user is presented with the dialog, but then the application is not required to actually inform the user of what the personal information is used for and if it is transferred to another party, and to whom. That’s the whole point: Google should require the developers to have the application then clearly state all that.
Google should be your nanny?
trolls are getting uglier, I swear.
It’s not very likely as Google is part of the problem, they are not any better than lots of the 3rd party developers. Some Goolge apps actually require access to far more than their capabilities, functionality and usecase requires.
On some areas they are a little “better”, since at least some of their apps have EULAs. If you bother to read, as an example, the one for the Android Google maps application. It more or less spells out that it’s spyware(it don’t collect passwords and such, but anything else), giving Google rights to use all the information it collects in any way they see fit.
Call me old fashioned, but i would kind of prefer if they had the decency to shot me in the rear with a tranqualizer gun when they wanted to radio tag me.
Edited 2010-10-05 09:25 UTC
Shouldn’t the developer be removed from the market (“life”) as well? This kind of practice shouldn’t be tolerated.
That’s a bit naive. In general (fancy tainting aside) there is no way to tell what an app does with data it receives. The only way to solve this is to prevent the app from getting the data in the first place, *and* make it hard for it to know this. That is, if the app knows it is being denied private data it will just say “Let me access your private data or I won’t run.”
The solution is fairly simple and obvious: basically extend droidwall to all the other Android permissions, so if you ‘block’ GPS access, it doesn’t fail with an exception, it just reports a random/generic location.
This has been suggested many times on the Android bug tracker and mailing lists, but Google think their current approach works. Clearly it doesn’t.
Very true.
Also true. That’s the very reason why I didn’t install Yahoo Mail and Opera while I had the firm intention to install these apps… until I saw the permissions needed: access to non-free services, to the contact list, the SMS, control of system services, and what else. Why does Yahoo Mail wants to be able to send text messages from my phone? Having an unlimited number of short messages in my contract doesn’t make it acceptable.
On another subject, I was looking for a virtual keyboard app to replace the default one in HTC Sense. And I read somewhere that one of the major contenders in that field has started asking for network connections in one the latest releases while in the past, it didn’t have that network access permission. Really, why does a virtual keyboard app need network access? What could prevent them from logging all my usernames and passwords? One user (of their non-network version) contacted the developer about that issue and never got an answer… How carefree are the people who install such an app? That’s what I am appalled at.
Well, AFAIK, the real situation is that on both OS, the applications can access part of or all of your personal data.
The differences between OSs being that on iOS we’re sure that there’s a unique device identifier (on Android we don’t know) and that on Android applications have to tell the user that they want to access said data during install time.
So it’s rather iOS that’s a bit wrong from a security point of view. But well, the App store is a perfectly safe ecosystem so the local OS does not have to be secure, isn’t it ?
Edited 2010-10-04 16:37 UTC
OK, I scanned thru the linked paper and I found that Amazon, facebook and Twitter all track your identity.
I’m SHOCKED!!! that users would provide info to sites that require your identity to be functional.
In every case actually described, the UDID is a simple shortcut for associating info that you’ve allowed (maybe, even “demanded”) to be sent to the website.
And this is what kind of issue? None of the examples I described were in any way a compromise of users’ identity, rather, they were facilitators of users’ requests.
Help me understand why this is an issue again?
The problem is that this kind of notice is rarely very clear.
There are some apps that will track your movement with the GPS, have full access to the internet, access your Google account and read your memory card and your identity ^aEUR“ all for perfectly benign reasons. For instance, one of the sports tracking apps I use wouldn’t work well without it. Most actual phone apps (i.e. the ones that aren’t games or make fart sounds) are made for some kind of information sharing. One problem with the articles is that they treat most kinds of information sharing as “suspicious”, so they’re almost tailor-made for FUD.
However, even though it’s easy enough to avoid fart apps that demand access to your contact list, the GPS and network, the privacy policy of ad-supported apps that do make use of private information for good reasons isn’t often readily available. Google really ought to upgrade their access rights lists with more relevant information.
It’s not hard to read a contract, and if you don’t understand what your computer is doing, you’re going to get taken in, and that’s no one’s fault but your own.
If you understand your computer, you’ll realise there’s no need for a fart application to share anything.
If you don’t understand how your car works, you’re going to get sold blinker fluid and tire lubricant.
“Ignorance of the law is no excuse”.
Evidently, you’ve never seen the Android market. Contracts? It’s hard to find even a EULA, and I’ve certainly never signed a contract to use any apps there.
Evidently, neither did you read my comment.
I read it, and I read the article.
I haven’t used the market because the phone companies keep discontinuing things rather than lowering the price.
Your first comment seems full of information not relevant to the situation at hand, though the next one is.
If there’s no EULA-like thing shown, then there’s a problem, but I doubt that there isn’t one.
That said, I’m unlikely to get much from it, as most of it is non-free.
If there is no EULA visible, then there is no EULA at all. You can’t agree to something which you’ve never seen.
Look, I’m saying I don’t know if it’s shown.
I’m not taking your word for it that they’re not showing this, though Google requires it and says they do it.
IIRC there’s a setting for automatic agreement. I could be wrong there, as that’s the sort of thing that one can set on/off in Linux/BSD package managers.
You seem to take a lot of things for granted. Google shows what rights an app needs before install. That’s all. No EULA, and you can certainly not auto-agree to an EULA, as the very concept of an agreement sort of depends on both parties knowing what they agree to.
They tell you what it needs before install.
That’s an eula, if perhaps incomplete.
The main difference is that from iOS you can download only UDID. And that’s it. For server it’s only anonymous number. If you give more info to the app – your decision.
From Android apps can steal phone number, SIM ID, position (via GPS) and phone ID. I don’t think that the risk is even comparable. The UDID is only possible way to connect user and it’s profile on server. It can be used to identify user’s across services from WITHIN apps. Not web.
What’s the difference between this and your profile on i.e. facebook? Or any other side. If you give them your name – their have it. If you won’t – they won’t. It’s the same.
You can remove cookies but as soon as you log in -they know that it’s you.
Uhm, no. The main difference is that one article focused on the use of UDIDs on iOS and the other focused on how an Android app called Taintdroid could help you eavesdrop on how various apps use various bits of information. iOS apps can read your phone number and contact list as well. The article says nothing about whether they do or don’t.
It’s not ‘stealing’ if you give it to them.
On one hand they complain that the data is encrypted and as such could be secretly transmitting who knows what, then they complain that other apps transmit stuff in plain text so anyone can see it. If I give an app permission to use my data then I’ve given it permission, but I’d sure as hell want it transmitted securely…
Simplest model i could find.
Doesn’t even have a camera.
What?!
Why would highscores be linked to a device and not to an individual?
Does that mean if someone sells the phone, the new owner also gets to trash the first owner’s highscores?
Or that buying a new device means you’ll have to do all your scores all over again?
Wow! End of the world.
well it was when Microsoft was accused of doing it so why not Andriod? Oh that’s right – it’s by everyones flavour of the month – Google.
I actually had my LAN class in college with this guy.
He’s very smart, and really does know what he is talking about.
However, what he shows is common sense. Developers naturally take shortcuts and do the least amount of work possible to secure information. The fact that insecurely coded applications send information that they should not over insecure channels is not news in itself. The fact that they’re doing this in 2010, as opposed to 1996 (when I had this class with Eric and we discussed this openly), is just sloppy.
The PCI-DSS standards provide some assurance against storing of credit card numbers and mag stripe data by reputable vendors.
Apple and the carriers need to enact similar standards to prevent developers from doing this, especially with the push to use Mobile Phones as payment devices.
While this won’t stop people from getting ripped off by unscrupulous app vendors (think of the people who pirate applications and always try to get something for free), Apple does give the implied assurance (not the 55 page EULA that no one reads that probably says otherwise) to App Store customers that they applications that they purchase or acquire via their systems will not compromise their privacy.
Apple really needs to take this to heart and add some steps to their review process to ensure that their customers’ privacy is protected with the transmission of data. People care more about their privacy than whether or not an app meets their design standards.
Like I said, Eric Smith is a very smart person. However, it doesn’t take someone with his brains to figure out Apple has major egg on their face because they set themselves up as the arbiter of standards with their App Store, and were caught with their pants down.