Researchers report that 72% of American adults now own a smartphone and when they’re on their phones, 89% of their time is spent on apps. An analysis of how app developers generate revenue raises some interesting issues that touch on consumer privacy.
How do app developers make money? Some sell their apps directly to users. Others offer in-app purchases. A third business model is to generate revenue from ads. To facilitate that, app developers embed software code known as ad libraries, which lets them display ads within the apps. Of course, to make ads more relevant to individual users, ad libraries want specific information about those users – and that’s where consumer privacy comes in.
To learn more about the types of information ad libraries request about users, FTC staff looked at the top 25 software ad libraries listed on a well-known service that tracks the popularity of various players in the advertising ecosystem. We focused on information that ad libraries requested from mobile apps, as well as what they told developers and consumers about their use of consumers’ personal information. We focused on ad libraries developed for the Android operating system because the permissions requested on Android apps are visible.
An ad library gathers information from Android mobile users in three ways. First, in its documentation, each ad library specifies the permissions it requires to operate, and app developers must obtain these permissions from users to get access to ads. Second, the ad library can specify a number of optional permissions it would like to access to deliver more targeted advertising. Third, if an app has requested permission to access additional information, the ad library can take advantage of that even if it doesn’t list that type of information as part of its required or optional permissions.
In other words, on Android devices, ad libraries have access to the same information and functionality as their client app. As such, if a user grants an app permission to, let’s say, write to their calendar, the ad library will have access to write to the user’s calendar as well.
Here are some things we found in our look at ad libraries:
- Most ad libraries require the similar core set of permissions (INTERNET and ACCESS_NETWORK_STATE), which give the app use of the Internet and information about the mobile device’s network connections.
- Some ad libraries go a step further and ask – often optionally – for additional information like geolocation (ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION).
- Some ad libraries sought optional permissions that may be irrelevant to targeting and serving ads, such as permissions that allow the app to read and write on the user’s calendar data (READ_CALENDAR and WRITE_CALENDAR), connect to paired Bluetooth devices (BLUETOOTH), access the device’s vibrate function (VIBRATE), record audio (RECORD_AUDIO), and get a list of all registered Google and other email accounts (GET_ACCOUNTS).
We also looked at ad libraries’ publicly available disclosures. Here’s what we learned:
- Some ad libraries disclose how long they retain a consumer’s information, such as 90 days or 36 months. Others, however, indicate that they keep information as long as needed, or even indefinitely.
- Several ad libraries note in their developer documentation that the app developers should have privacy policies, and some note that developers should obtain the appropriate consumer consent to collect, use, and disclose their data to ad libraries.
Given these findings, here is some advice for ad libraries and for app developers when considering embedding those libraries into their apps.
What required and optional permissions do you really need? And are you disclosing those permissions to app developers? Don’t seek permissions to access information you don’t need. For the permissions you do need, clearly spell out in your developer documentation what permissions those are and the purposes for which you use the information. App developers integrating your code need to know, for example, why you’re seeking a specific permission so that they can accurately describe their apps’ data collection, sharing, and use practices in their privacy policies. Developers may even link to your disclosures in those policies. Misrepresenting the types of information you collect and use could be a violation of the FTC Act. That’s what the FTC charged in its complaint against Singapore-based mobile advertising company InMobi. The FTC alleged that InMobi misrepresented that its advertising software would only track consumers’ locations when they opted in and in a manner consistent with their device’s privacy settings. But as it turned out, InMobi’s software tracked consumers even if consumers denied access to that information. That also meant that app developers that embedded InMobi’s ad library couldn’t provide accurate information to consumers about their app’s privacy practices.
Are you trying to access information not listed in your required or optional permissions? Don’t probe for information that is protected by a permission other than your required and optional permissions. Neither the developer nor the consumer has reason to know you’re getting that information. If you feel you need a particular type of information, make sure to request the relevant permission and list it in your documentation.
For how long do you really need to retain consumers’ information? If the data you collect is integral to your product or service, you may need to hold on to it. But take reasonable steps to secure what you collect and store, and securely delete it once you no longer have a legitimate business need to retain it.
What permissions does your app – and consequently the ad library – really need? Remember: What your app can access, the ad library can access, too. That’s why you should make sure your app doesn’t request permission to access consumer information it doesn’t need. Not having access to consumer information in the first place reduces the risk of inadvertently misusing those permissions, can improve user adoption, and makes your app less attractive to attackers.
Do you need to give the ad library access to their optional requests? Look carefully into the permissions that ad libraries request. Even when you embed an ad library into your mobile app’s code, it’s still your responsibility to ensure the library’s information requests conform to your privacy promises and consumer expectations. If you don’t know why an ad library wants certain personal information, don’t provide it. In general, reducing your app’s unnecessary access to personal information reduces the potential for problems in this area.
The purpose of this blog and its comments section is to inform readers about Federal Trade Commission activity, and share information to help them avoid, report, and recover from fraud, scams, and bad business practices. Your thoughts, ideas, and concerns are welcome, and we encourage comments. But keep in mind, this is a moderated blog. We review all comments before they are posted, and we won’t post comments that don’t comply with our commenting policy. We expect commenters to treat each other and the blog writers with respect.
- We won’t post off-topic comments, repeated identical comments, or comments that include sales pitches or promotions.
- We won’t post comments that include vulgar messages, personal attacks by name, or offensive terms that target specific people or groups.
- We won’t post threats, defamatory statements, or suggestions or encouragement of illegal activity.
- We won’t post comments that include personal information, like Social Security numbers, account numbers, home addresses, and email addresses. To file a detailed report about a scam, go to ReportFraud.ftc.gov.
We don't edit comments to remove objectionable content, so please ensure that your comment contains none of the above. The comments posted on this blog become part of the public domain. To protect your privacy and the privacy of other people, please do not include personal information. Opinions in comments that appear in this blog belong to the individuals who expressed them. They do not belong to or represent views of the Federal Trade Commission.