Andrea Arias

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 had documentation directed at app developers, which explained the types of information they acquired about users through the apps. Other ad libraries had a privacy policy directed at consumers, but few had both.
A few ad libraries had either documentation or a privacy policy that clearly listed the type of information they obtain from mobile users. For example, some specify they collect information about the mobile device’s carrier, make and manufacturer, operating system, language settings, connection speed, IP address, unique device IDs, browser, and more. Others simply state they collect non-personally identifiable information.
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.

We often get the question, “If I comply with the NIST Cybersecurity Framework, am I complying with what the FTC requires?” From the perspective of the staff of the Federal Trade Commission, NIST’s Cybersecurity Framework is consistent with the process-based approach that the FTC has followed since the late 1990s, the 60+ law enforcement actions the FTC has brought to date, and the agency’s educational messages to companies, including its recent Start with Security guidance.

The Framework is not, and isn’t intended to be, a standard or checklist. It’s meant to be used by an organization to determine its current cybersecurity capabilities, set individual goals, and establish a plan for improving and maintaining a cybersecurity program, but it doesn’t include specific requirements or elements. In this respect, there’s really no such thing as “complying with the Framework.” Instead, it’s important to remember that the Framework is about risk assessment and mitigation. In this regard, the Framework and the FTC’s approach are fully consistent: The types of things the Framework calls for organizations to evaluate are the types of things the FTC has been evaluating for years in its Section 5 enforcement to determine whether a company’s data security and its processes are reasonable. By identifying different risk management practices and defining different levels of implementation, the NIST Framework takes a similar approach to the FTC’s long-standing Section 5 enforcement.