Risky behaviors abound in mobile apps

Risky behaviors abound in mobile apps

Summary: A study of the top 200 Android apps and the top 200 iOS apps shows that free apps are very risky, but even paid apps will sell you out.

SHARE:
TOPICS: Security, Apps, Mobility
5

Everyone understands that mobile apps are fraught with risks and unknown behaviors, even if it's hard to know or appreciate them when you install the app. Appthority's new Winter 2014 App Reputation Report provides a useful overview of the types and frequency of risky behaviors among today's top apps.

Appthority provides an app reputation service for enterprises that allows IT to set policies for particular groups of users to accept different forms and levels of risk in mobile apps. Appthority collects apps from app stores and analyzes them for their behaviors, such as location tracking, and scores them for customers. This data was used to create the report.

This report looked at the top 200 apps each from Google and Apple in their stores. Since Appthority's last report last year, almost 50 percent of the top 100 iOS apps have changed. This makes manual management of whitelists and blacklists impractical, and illustrates the need for Appthority's service, automating the process.

Both free and paid apps engage in risky behaviors, but free apps do so to a far greater degree. 70 percent of free apps and 44 percent of paid apps perform location tracking, often without any need of the app to do so.

Some of the other behaviors studied in the report are use of single sign-on (SSO), accessing the user's UDID (Unique Device IDentifier, a 40 character code unique to your device), in-app purchasing and sharing data with advertising networks or analytics companies. SSO is considered risky because loss of the credential (typically a social network) could compromise all the sites to which the user logs in with the SSO. Furthermore, any permissions granted to an app accessed with an SSO are also available to the SSO site. For instance, if you log in to an app using your Facebook credentials and grant that app access to your contact list, Facebook gets access to it as well.

Accessing the UDID used to be standard practice, but after iOS 6 Apple told developers not to do it anymore and provided reasonable alternatives which weren't quite as invasive. Use of the UDID dropped for a while, but it's back up at high levels on iOS, and much higher on Android. In-app purchases often end up on an employee's cell phone bill.

Some other highlights of the report:

  • 56 percent of the top 200 Android and iOS apps identify the UDID. 100% of free Android gaming apps identify the UDID.
  • 31 percent of free apps and 22 percent of paid apps access the user's contact list or address book.
  • 58% of the top free Android apps share data with ad networks, compared to 24% of paid apps.
  • Games are not always more risky than non-games. Overall, they have very similar characteristics.
  • Candy Crush is the top free app and also the top grossing app from in-app purchasing.

Appthority also announced two new features: They have a policy generator to let companies define their own risk profiles. Now they are announcing the ability to define different policies for different groups in the company. IT can also now schedule remediation of an app to occur automatically. For example, for a minor issue the policy may be to prompt the user periodically to perform the change; if they haven't after two weeks, the system can perform it automatically.

Topics: Security, Apps, Mobility

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

5 comments
Log in or register to join the discussion
  • WHA?

    How exactly do the ios apps get the UDID? They can't be published in the store if they do - they are rejected out-of-hand. Corporate, private apps can use it, but nobody else can. Now the rest of the report looks really, really, suspicious.

    It's a total PITA by the way. By FAR the easiest way to ensure that a user's account is safe from being hijacked is to tie it to their device, i.e. their UDID. It's also an effective key for licensing the app to the device. What Apple does now with its substitutes for UDID, adds layers of PITA to development, and never ensures that you are really on the device you hope you're on. Every other identifier that you are given for iOS is transient. The developer ID is static for the device, but only until the user removes all apps you have published. Then it changes. So let's say Something Bad Happens, and the easiest way to fix the problem is to have the user uninstall and reinstall the app. Well, if that's the only one of your apps they have installed, the ID is now different than it was before. The push id only works if the user allows you to push to them, but it also changes. First, it changes automatically every two years. Second, it changes when the user updates the OS to a new major version.
    m0o0o0o0o
    • Watch the language VERY carefully!

      "56 percent of the top 200 Android and iOS apps identify the UDID."

      That sentence does NOT mean that 56% of iOS apps identify the UDID! It means that someone took a MIXTURE of the "top" 200 games, at an unknown ratio of Android:iOS, and 56% *OF THAT MIXED BUNCH* were shown to report the UDID.

      I have no doubt that *some* iOS apps were reporting UDID, because older versions are still out there! from a time when UDID was okay to reveal.

      My point is, of this vague language, it could quite easily mean the NONE of the iOS apps reported UDID and only the Android ones did. Or vice versa (which I DO NOT believe).
      lelandhendrix@...
  • WHA?

    How exactly do the ios apps get the UDID? They can't be published in the store if they do - they are rejected out-of-hand. Corporate, private apps can use it, but nobody else can. Now the rest of the report looks really, really, suspicious.

    It's a total PITA by the way. By FAR the easiest way to ensure that a user's account is safe from being hijacked is to tie it to their device, i.e. their UDID. It's also an effective key for licensing the app to the device. What Apple does now with its substitutes for UDID, adds layers of PITA to development, and never ensures that you are really on the device you hope you're on. Every other identifier that you are given for iOS is transient. The developer ID is static for the device, but only until the user removes all apps you have published. Then it changes. So let's say Something Bad Happens, and the easiest way to fix the problem is to have the user uninstall and reinstall the app. Well, if that's the only one of your apps they have installed, the ID is now different than it was before. The push id only works if the user allows you to push to them, but it also changes. First, it changes automatically every two years. Second, it changes when the user updates the OS to a new major version.
    m0o0o0o0o
  • Ironic

    Getting Appthority's new Winter 2014 App Reputation Report requires you to provide a whole lot of personal information.
    Theo.X
  • Ha!

    IKR!? I didn't, but if you go through all their shenanigans to get the report, the first line of the report is "You should not be giving out so much information just to get a stinking report!"
    lelandhendrix@...