Forgot your password?
IOS Iphone Privacy Software Apple

Unauthorized iOS Apps Leak Private Data Less Than Approved Ones 179

Posted by Soulskill
from the curated-for-a-different-purpose dept.
Sparrowvsrevolution writes "In the wake of news that the iPhone app Path uploads users' entire contact lists without permission, Forbes dug up a study from a group of researchers at the University of California at Santa Barbara and the International Security Systems Lab that aimed to analyze how and where iPhone apps transmit users' private data. Not only did the researchers find that one in five of the free apps in Apple's app store upload private data back to the apps' creators that could potentially identify users and allow profiles to be built of their activities; they also discovered that programs in Cydia, the most popular platform for unauthorized apps that run only on 'jailbroken' iPhones, tend to leak private data far less frequently than Apple's approved apps. The researchers ran their analysis on 1,407 free apps (PDF) on the two platforms. Of those tested apps, 21 percent of official App Store apps uploaded the user's Unique Device Identifier, for instance, compared with only four percent of unauthorized apps."
This discussion has been archived. No new comments can be posted.

Unauthorized iOS Apps Leak Private Data Less Than Approved Ones

Comments Filter:
  • by mehrotra.akash (1539473) on Wednesday February 15, 2012 @01:31AM (#39041619)
    Or atleast a virtual "profile" with random data in it, and while launching apps, you should be able to choose which data you want to give it access to
  • Methodology? (Score:3, Interesting)

    by tartles (2540270) on Wednesday February 15, 2012 @01:32AM (#39041623)
    I checked the source publication and the following paragraph describes how they chose the apps:

    Since iTunes does not support direct searches for free ap- plications, we rely on [2] to provide a contin- uously updated list of popular, free iOS applications. Once a new application is added to their listings, our system au- tomatically downloads the application via iTunes and de- crypts it. Subsequently, the application is analyzed with PiOS.

    I didn't see anything that described how they chose the Cydia apps however. I bring this up because there are numerous very popular Cydia apps that are simply iOS tweaks that adjust a piece of the interface or something similar. These apps would intuitively be less likely to require any sort of user information at all, so I'm not sure how much I trust these results.

  • by Taco Cowboy (5327) on Wednesday February 15, 2012 @01:45AM (#39041681) Journal

    Anyone has done any research on Android apps, on the same topic ?

  • Re:Profit. (Score:3, Interesting)

    by fightinfilipino (1449273) on Wednesday February 15, 2012 @02:51AM (#39041955) Homepage

    and exactly what data do you have showing 1) that these groups are the same and 2) that people "claim that pirating movies isn't stealing"?

    quit it with the troll bait.

    what's really problematic is not whether there are legit uses for the data, but that the app developers aren't up front about data being shared at all.

  • Bullshit (Score:2, Interesting)

    by Anonymous Coward on Wednesday February 15, 2012 @05:33AM (#39042467)

    "21 percent of official App Store apps uploaded the user's Unique Device Identifier"

    In iOS 5.x it's impossible to read out the UDID.
    Everybody still on 4.x should ask himself: Why?

  • by fuzzyfuzzyfungus (1223518) on Wednesday February 15, 2012 @08:43AM (#39043193) Journal
    What android really needs(and probably won't get, for actively self-interested reasons; but so it goes...) is the ability to lie.

    Right now, you can at least see what outrageous demands an application is making; but it's a take-it-or-leave-it thing. You cannot, for instance, specify that an application that wants your contacts list for no reason useful to you installed such that any attempt to access the contacts list returns a false one, rather than the actual system-wide contacts.

    It'd likely add some resource overhead; but you could theoretically have a per-app 'virtual' set of android.* interfaces: some could transparently map to the real ones, others could be defined by a filter against the real ones(for network access, a specific set of firewall rules, or android.location interface that is based on the genuine android.location data; but with resolution reduced or a fictitious offset introduced, for instance), and some could be based on pure fictions unrelated to the real interface.

    The ability to lie would allow you to push back against the creeping trend to just demand all kinds of permissions without obvious reason; but still provide well-formed inputs where applications expect them, so that things will still work(alternative uses, such as polluting the databases of the various 'social' scum who treat hoovering up contacts as a business model, are left as an exercise to the reader); but the device owner's wishes will be preserved.
  • by lordbah (2498352) on Wednesday February 15, 2012 @09:17AM (#39043359)

    I've tried to discuss the permissions they require with some Android app makers but I've never gotten anywhere. It usually goes something like this:

    I inquire as to why an article reading app would need permission to use my camera. They say the app has a function to take pictures and submit them. I say I don't currently have any interest in doing that - can't they have a base app which doesn't require that permission, and then for those who want to do something like that, have an add-on app which does require that permission? They tell me that Android permissions don't work that way. I tell them that I won't be installing their app.


    I ask why a game wants access to my contact list and permission to make phone calls. They tell me it's just for a "friends" function, and they only want to read my phone's ID, they promise they would never do anything unwanted. I say I don't trust you that much yet, can't you have a version which doesn't require those permissions, and over time maybe I will come to trust you and then I can install the full version? They tell me that Android permissions don't work that way.


    I ask why a streaming music app would need permission to "send email without my knowledge" or access my calendar. They say the app has the ability to share stations with my friends, "entirely under your (my) control", and display ads with a button which can add an event (concert presumably) to my calendar. I ask why then they would need to be able to do these things "*without my knowledge*". They say thank you, come again. I say I won't be installing your app then.

    So I would say the permissions are nice in theory but in practice many app developers are not willing to finely tune them and either unwilling or unable because of (they claim) platform restrictions to provide variants of the app with different functionality and different permission requirements.

    I have no experience with iOS so I can't say anything about that.

  • by Rich0 (548339) on Wednesday February 15, 2012 @09:55AM (#39043689) Homepage

    Yup - I've been advocating the same thing. LBE Privacy Guard is the closest I've seen to it in implementation - I assume it actually works.

    This was proposed as a feature for Cyanogenmod and shot down. CM now has the ability to revoke individual permissions, but it tends to lead to lots of force-close issues. Most likely they're just sending errors to applications, and not simply lying to them (which is less likely to cause a force-close - app designers already have to handle the case where a user has one contact named John Smith and they never leave Topeka with an IMEI of 12345678). When the app force closes CM tells the user it is their fault for revoking permissions and offers to let them unrevoke them.

    Android puts far too much control in the hands of app developers. It is like Windows 3.1 - it works great until some app decides to misbehave. Users, and not app designers, should be the final word in whether an app can run a service all day, or use the GPS vs the network, or transmit x GB of data per day, or whatever. And that final word shouldn't simply be to use or not to use - that is a race for the bottom.

Never test for an error condition you don't know how to handle. -- Steinbach