Washington, DC - In June, the Commission announced its first settlement with a mobile advertising network, InMobi. Among other things, the Commission’s complaint challenges the company’s location tracking practices. In this post, we explain the mechanism that the Commission alleges InMobi used to track users’ location without permission, and discuss technical steps that mobile operating systems have taken to try to address this practice.

Reaching over one billion devices and serving 6 billion ad requests per day, InMobi describes itself as “the world’s largest independent mobile advertising company.” By integrating InMobi’s software development kit (“SDK”) into their applications, Android and iOS application developers can monetize their applications by displaying third party advertisements. Advertisers, in turn, can target consumers across all of the mobile applications that have integrated the InMobi SDK.

InMobi offers several geo-targeting products through which advertisers can target consumers based on their current location and location history. When marketing its geo-targeting products, InMobi claimed that it obtained consumers’ opt-in consent for such location tracking:

First, we take in location data on each user, in the form of user opt-in lat/long signals. Then we add real world context to these signals to figure out what places or businesses the user has visited. Our machine learning algorithms mine for patterns in this location history to identify what these trends mean about the user, from which we can infer what kind of consumer the user is. (Emphasis added).

According to the Commission’s complaint, however, InMobi did not receive opt-in consent before tracking the consumer’s location. To the contrary, the complaint alleges that InMobi tracked the consumer’s location on both Android and iOS without consent and regardless of the consumer’s location settings, undermining consumers’ location privacy preferences.

While the Android and iOS operating systems both feature application programming interfaces (APIs) through which applications can access the consumer’s location, both operating systems protect these APIs through “permission” settings that allow consumers to decide whether or not to allow applications to access location information.

So how did InMobi circumvent these protections to track the consumer’s location without consent? By creating its own geocoder database. As explained in more detail in the complaint, InMobi collected information through consumers’ devices that allowed it to map out the real-world latitude and longitude coordinates of WiFi networks. InMobi then monitored the WiFi networks that a consumer’s device connected to (on both Android and iOS), and in many instances, the WiFi networks that a consumer’s device was in-range of (on Android). By collecting the BSSID (i.e., a unique identifier) of the WiFi networks that a consumer’s device connected to or was in-range of, and feeding this information into its geocoder database, InMobi could then infer the consumer’s location. Until December 2015, InMobi used this method to track the consumer’s location even if the application that had integrated the InMobi SDK had never asked the consumer for permission to access location, and even if the consumer had turned off all location services on the device.

In response to the Commission’s investigation, InMobi modified its location tracking practices at the end of 2015. The consent order announced in June ensures that InMobi does not engage in similar conduct in the future. Specifically, it prohibits InMobi from collecting or inferring a consumer’s location unless the consumer has granted the application that has integrated the InMobi SDK with permission to access location, and such access is consistent with the consumer’s location settings.

While the Commission’s order prevents InMobi from engaging in deceptive location tracking, mobile operating systems are also taking some steps to restrict access to BSSIDs and other WiFi network information.

In a series of blog posts last year, Tech @ FTC examined a few of the challenges that mobile operating system architects face in designing secure APIs. In many instances, operating system architects are balancing trade-offs between functionality, convenience, privacy, and security. In this case, developers can use BSSIDs and other WiFi network information to enable legitimate functionality. For example, developers can build applications that help consumers manage their WiFi networks or applications that assist consumers with setting up other devices in the home, such as a connected thermostat or IP camera.

Given these legitimate use cases, the Android operating system features APIs that allow applications to access WiFi network information. The operating system restricts access to these APIs through two permissions: Access WiFi State and Change WiFi State. However, as their names suggest, consumers would have no reason to know that developers or third party ad networks like InMobi could abuse the information collected through these APIs to infer and track the consumer’s location.

With the release of Android 6.0 (also known as Android M) in fall 2015, Android’s system architects recognized this privacy risk, and modified how the APIs work. On devices running Android 6.0, an application must obtain the location permission before it can access the BSSIDs of in-range WiFi networks. In response to a developer’s complaint about this change, an engineer on the Android team explained:

The MAC address and the SSID can be used to identify surrounding devices. Knowing the location of these devices can be used to infer the phone location. As we have no way to know if the app would try to infer user's location via WiFi scans we take a conservative approach to protect the user's privacy. If an app [that] is targeting pre M SDK does not have ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION it will get scan results only if it is in the foreground. For M SDK apps the location permission is required to get scan results.

This change ensures that, on devices running Android 6.0, applications cannot use the BSSIDs of in-range WiFi networks to infer location without first obtaining the location permission. However, as the developer’s complaint points out, this change could also lead to instances of consumer confusion since it requires that applications that are using BSSIDs for legitimate purposes, and that have no intention of collecting or inferring location, ask for the location permission. Although this over-inclusive approach is privacy-protective, it highlights the complexities involved in designing secure APIs and permission systems that are understandable to non-technical consumers.

In addition, applications can still access the BSSID of the currently connected WiFi network without obtaining the location permission. Although this provides a more limited opportunity for surreptitious location tracking since the consumer’s device must be connected to a WiFi network, consumers regularly connect their devices to public and private WiFi networks throughout the day, making it possible that a developer or third party ad network could continue to track location on Android without consent. (Of course, as in the InMobi case, the Commission could take action to prevent deceptive practices involving this scenario.)

The iOS operating system also features an API that allows applications to access the BSSID of the currently connected WiFi network. Known as the “Captive Network” API, this interface is not permission-protected, and the consumer has no means of denying an application access to the WiFi network information accessible through it.

According to the iOS developer documentation, the CaptiveNetwork API was intended to allow an application to “assum[e] responsibility for authenticating with [captive] networks,” such as the pay-to-use networks at hotels. However, it appears that many applications were using the CaptiveNetwork API for purposes other than authenticating to captive networks. In some cases, those other uses provided legitimate functionality. For example, one application used the API to assist consumers in setting up a baby heart rate and oxygen monitor, while another application used the API to assist consumers in setting up a connected barbeque grill.

While facilitating legitimate functionality in some cases, InMobi’s practices exemplify the fact that the CaptiveNetwork API is also open to abuse. As alleged in the Commission’s complaint, InMobi used the CaptiveNetwork API to collect BSSIDs through any iOS application that integrated its SDK, allowing it to infer and track location without consent and regardless of the consumer’s location settings.

In the run-up to the release of iOS 9, iOS’s system architects recognized that providing unprotected access to the CaptiveNetwork API presented a risk to consumer privacy, and the API was deprecated in an iOS 9-beta release. In response to developer complaints that claimed there are no privacy risks associated with BSSID and other WiFi network information, an iOS engineer explained:

I strongly disagree with this. The collection of SSIDs that the user’s device associates with is a fairly accurate fingerprint of that user. Moreover, that fingerprint is persistent, correlatable between apps, and can’t be reset by the user. Those are all Bad Things™ from a privacy perspective.

Contrasting the unprotected CaptiveNetwork API to the permission-protected location API, the iOS engineer further noted that access to the location API is “granted by explicit user consent and that consent can be easily revoked via the user interface.” Without such user control, the engineer implied, the CaptiveNetwork API was a risk to consumer privacy. Nevertheless, numerous application developers continued to complain that they used the API for legitimate purposes and that deprecating it would result in broken applications and features.

Responding to these concerns, the iOS engineer noted that the developers’ “feedback [was] being considered by the relevant parties here at Apple and there may be future changes based on it.” Indeed, the CaptiveNetwork API continues to function in the current consumer release of iOS 9. Although the API is still deprecated (i.e., it will be phased out over time), in the current release, BSSIDs are still accessible, and it is possible that a developer or third party ad network could continue to track location on iOS without consent. (Again, as in this case, the Commission could take action to prevent deceptive practices involving this scenario.)

Noting that the CaptiveNetwork API is being deprecated, the iOS 9 developer documentation requests that developers “please file a bug describing your use of this API so that we can consider your requirements as this situation evolves.” Once again, this example highlights the complexities that operating system architects face in designing secure APIs that support the needs of developers that would like to implement legitimate functionality while simultaneously limiting the potential for abuse.

Given these complexities, all actors in the mobile ecosystem have a role to play in protecting consumer privacy. While operating systems architects continue working on technical solutions to these thorny issues, both application developers and third party service providers (e.g., ad networks and analytics firms) should ensure that their use of APIs are consistent with their privacy promises. In addition, developers should consider contractual terms or other steps to help ensure that their third party service providers do not circumvent consumers’ privacy choices.

For its part, the Commission will use its enforcement authority as a backstop to such industry efforts. As exemplified by the FTC’s case against InMobi, and other recent cases such as Path and Snapchat, the Commission will bring enforcement actions against those companies that engage in deceptive practices by abusing APIs and undermining consumers’ privacy preferences.