Mobile App Privacy Continued…

[UPDATE! April 15: Pandora removes all advertising libraries from its Android and iPhone apps!]

The blog post we made earlier this week entitled, Mobile Apps Invading Your Privacy, gives detail around the information being requested by the advertisement libraries embedded inside a popular online radio application. There have been a number of great posts and comments that got us thinking more about the issues and the types of data being requested.

First off we want to thank some people who commented about the Pandora application not having permission to actually access the GPS on the device. Below are the Manifest permissions for the version of Pandora currently in the Google Application Marketplace:

  • Full Internet Access
  • Create Bluetooth Connections
  • Read Contact Data
  • Add or Modify Calendar Data and Send Emails to Guests
  • Read Phone State and Identity
  • Modify Global System Settings
  • Prevent Device from Sleeping
  • Bluetooth Administration
  • Change Wifi State
  • Change Network Connectivity

As you can see, GPS access is NOT included in that list. There was an error in the original post we made stating that some of the library code was requesting permissions from the Google system for GPS access, and as the commenter pointed out, that is incorrect. The code snippet we posted is only checking whether the parent application, Pandora in this case, has permission to access the GPS. If the parent does not have permission, the accessing of GPS data can’t occur.

However, the overarching theme of the original post is still valid. If Pandora had required GPS access for a legitimate reason, the embedded advertisement library would have been able to request the GPS data and send it off device. As we mentioned in the original post, there is a chance that Pandora has no idea what the embedded advertising library actually does, simply taking it from the advertising partner and embedding it into their application.

To further illustrate this point, we downloaded a few more applications that use some of the same advertising libraries. In particular, we found AdMob (the code snippets we outlined on the previous post) embedded into the free CBS News Android application and the TVDotCom application. Both of these applications have GPS coarse and fine permissions allowed within their application manifest. They don’t have some of the other permissions required to send certain data, but in these cases the advertising code will fail silently. Essentially, the advertising libraries use the parent application as an enabler, taking advantage of whichever permissions happen to be available. It also seems revelant to note that AdMob was acquired by Google in May 2010.

The current model where permissions are granted to applications combined with the way 3rd party libraries such as mobile ad network libraries request many different types of information sets up a situation where the ad network will get the information if the application needs it to operate.

Veracode Security Solutions

 

Security Threat Guides

hanson | April 15, 2011 9:09 am

1) Study had ONE error:
“As you can see in the code, the library requests permissions for both COARSE_LOCATION, and FINE_LOCATION data”

This code you reference is NOT requesting permissions, it is merely checking whether said permissions HAVE BEEN requested by the parent app. Permissions are requested in the Android Manifest file and would show up when you go to download the app in “Security”. I just checked, and Pandora does not request location permissions at all and also the GPS is never turned on when running Pandora.

You should really understand what the code means before you make assine assumptions about it.”

Comment by Jon — April 8, 2011 @ 10:16 am

2) study correction on the ONE error made:

“As you can see, GPS access is NOT included in that list. There was an error in the original post we made stating that some of the library code was requesting permissions from the Google system for GPS access, and as the commenter pointed out, that is incorrect. The code snippet we posted is only checking whether the parent application, Pandora in this case, has permission to access the GPS. If the parent does not have permission, the accessing of GPS data can’t occur.”

ISSUE: WHY IS AD MOB CODED TO FETCH GPS, IF PERMISSION WAS GRANTED?

Comment by hanson — April 15, 2011 @ 9:08 am

brentwhopkins | August 1, 2011 3:48 am

I appreciate the clarification. However, to me the significant issue is not so much about an individual app vendor such as Pandora, but rather, about the advertising networks and their shared data. Since AdMob et al are endemic across the Android platform, it is highly likely that often a combination of apps and their permissions will give the advertisers all the data they want. The app vendors may not even be aware of the details of what data is being collected by their advertising partners.

I won’t belabor the obvious risks inherent in such a detailed dossier of personal data. Clearly there is a critical need for real user controls. Since government is a major attacker of privacy, legislative protection is very unlikely. Therefore, it is up to the developer community to solve this problem. I think it’s a significant business opportunity.

Tony | September 27, 2011 12:56 am

If you’re interested in learning more about security and privacy issues related to mobile devices, stop by SmartphoneSentry.com, a new blog focusing specifically on how to protect yourself and your privacy while using the mobile web.

iPhones, Location and Threats to Your Assets | Threatpost | March 24, 2013 11:35 pm

[...] for the Pandora music service seeking the location data from the phone earlier this month. It turned out, the Pandora app wasn’t collecting the location data but had it been, those requests would have been fulfilled.  Not only do you have to worry [...]

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

*

RSS feed for comments on this post