~ ~ ~ ~
Author’s Note 9/8/17: Following the release of additional versions of iOS 11, it appears that the “Blue Bar” notification discussed in the second part (below) will no longer be a mandatory feature for app developers. Questions? Email [email protected]
~ ~ ~ ~
From Pokémon Go, to the geo-targeting of abortion clinics, to state legislative efforts, the last year has seen significant attention paid to the many ways our apps use and often share location data. In the midst of this heightened awareness of geo-location privacy, iPhone users and app developers may notice a difference this Fall, when Apple will be releasing updates to iOS 11 that will increase users’ control over how their geo-location may be collected and used. The changes highlight the ongoing importance—and legal implications—of platform settings for consumer privacy.
At Apple’s 2017 Worldwide Developer Conference, a variety of privacy updates to iOS 11 were announced that may have potentially far-reaching impact when they become broadly available in the Fall. Apple has made two significant changes related to how apps can access users’ location: (1) the “Only When In Use” setting will now be required; and (2) the prominent Blue Bar notification that indicates when persistent, real-time location is being collected, will now appear more often.
Requiring the “Only When In Use” Authorization Setting for Location Services
In iOS 11, mobile apps seeking to access a user’s location will now be required to offer the intermediate authorization setting “Only When in Use.” Previously, location-based apps had the ability to bypass this option and present the user with only two choices: Always or Never. In iOS 11, this binary consent flow will no longer be possible: if an app wants to request access to location “Always,” it must also provide the user with the option of accessing location “Only When in Use.” (Of course, if “Always” is not needed, it is still possible to provide the two lesser options, Never or Only When in Use).
Apple reports that about 21% of location-based apps are currently offering their users only those two choices: Always or Never. At the June developer conference, Apple technologist Katie Skinner reasoned that this is likely due in part to developer confusion. While this is probably true, it is also the case that some apps might be seeking Always authorization in order to monetize the additional location history data for location-based marketing, interest-based advertisements, and other data analysis.
“Why do apps ever need ‘Always’ authorization for location?” This is a question we often hear from privacy-minded observers, and the answer lies in the added functionalities that “Always” authorization enables. As shown in the chart below, with “Always” authorization, apps can make use of a number of lower-energy background monitoring services that permit them to incorporate contextual triggers based on movement or specific geographical areas (“geo-fences”).
For example, a retail app might offer discounts or points when the user enters a store; an airline app might launch a boarding pass when the user enters the airport; or a smart home app might send a parent a notification when their child enters or leaves a location, such as home or school. These sorts of location-based actions could not occur if the user were required to have each app open and running in the foreground for it to access location.
Although there are legitimate reasons to request “Always” authorization, apps do not always provide good explanations for why they are asking for it. Because Apple’s update ensures users will always have the option of choosing “Only While In Use,” developers that want “Always” access to location will now have a greater incentive to justify their request. In a small way, this shifts some of the burden from the iPhone user (of understanding apps’ data practices) to the app developers (of explaining them), which is a consumer-friendly step.
Expanding the “Blue Bar” Notification to Match User Expectations
Another significant update to iOS 11 is that the “Blue Bar” notification will now appear any time an app has requested “Continuous Background Location” and the user subsequently navigates away from the app.
Currently, this Blue Bar does not appear for apps with authorization to collect location “Always.” In theory, users that have agreed to share location “Always” do not need (or necessarily want) this notification for most of the typical, approved uses of background location described above, such as receiving reminders when they enter a geo-fence. But do users expect that an app might also be receiving high frequency, high accuracy, battery intensive location data? For those apps–and only when they are collecting “Continuous Background Location”– the Blue Bar will now appear.
Importantly, most methods of accessing location using the “Always” permission will not trigger the Blue Bar, presumably because they are expected when a user approves “Always” authorization. These include visit monitoring, significant change monitoring, and geo-fencing. (For more on these background location services, read Apple’s Developer Documentation, “Getting the User’s Location” (here) or the Location & Maps Programming Guide (here)). Only the “Continuous Background Location” service will be impacted—i.e. the accurate persistent, real-time collection of location after a user leaves an app. Compared to the other services, it is the most power-intensive, but delivers the most accurate and immediate data.
Generally speaking, the only apps that need this particular high-energy location service are the ones providing real-time navigation, or mapping a route (e.g. a Runkeeper or a MapMyRun). As Apple tells developers: “Use this service only when you really need it, such as when offering navigation instructions or when recording a user’s path on a hike.” For these kinds of apps, the Blue Bar is more than just a notification, it’s also feature—it makes it easy to return to the app after leaving it to take a call or do something else on the phone.
For these reasons, industry sources are noting that most location-based mobile marketing are unlikely to be affected. We agree, although it’s worth noting that there are almost certainly some small number of actors in the mobile marketing space whose overzealous collection of location data will be halted by this OS upgrade. So far, the only incentive not to use this feature to collect unnecessary data has been that it depletes the user’s battery significantly; and that it causes the OS to occasionally generate notifications to users.
Operating Systems Play a Key Role in Shaping Expectations
Understanding the details of iOS and Android upgrades is important not only because of their direct effect on consumer privacy, but because platforms can have a powerful effect on user expectations—both in creating trust by aligning privacy controls with what they are, and in shaping what they become. When those consumer expectations are particularly strong and clearly expressed, we have seen in recent years that the Federal Trade Commission (FTC) is willing to step in and take actions against companies who violate them.
In 2016, mobile ad network Inmobi settled with the FTC for ignoring the mobile operating system settings of users who disabled apps’ location access, and inferring those users’ location anyway through other means. As we discussed at the time, the ad network was able to infer location by detecting the users’ proximity to known Wi-Fi access points. Aside from the practice being a violation of the OS’s Terms of Service, the FTC considered it to be a “deceptive business practice,” in part because they had misrepresented the practice to their app partners. Under the FTC’s Section 5 authority, the agency can take action against companies who deviate from their stated policies in a way that is considered deceptive.
In addition to setting user expectations, recent research demonstrates that operating systems influence how app developers view privacy. In May 2017, Katie Shilton and Daniel Greene at the University of Maryland analyzed hundreds of discussions in iOS and Android developer forums, and concluded that platforms act not just as intermediaries but as regulators who define what privacy means:
Mobile platforms are not just passive intermediaries supporting other technologies. Rather, platforms govern design by promoting particular ways of doing privacy, training [developers] on those practices, and (to varying degrees) rewarding or punishing them based on their performance. . . “Privacy by design” is thus perhaps better termed, at least in the mobile development space, “privacy by permitted design” or “privacy by platform.”
– Daniel Greene & Katie Shilton, “Platform privacies: Governance, collaboration, and the different meanings of “privacy” in iOS and Android development” (Read full article here)
As consumers increasingly interact with platforms controlling data from their children’s toys, connected cars, and their homes, it is important that privacy settings evolve and become increasingly nuanced. We look forward to continuing to see Apple and other platforms refine privacy settings to ensure they match consumer expectations.
For more, we recommend watching two sessions from Apple technologists at WWDC 2017, “Privacy and Your Apps,” and “What’s New in Location Technologies” (find all WWDC 2017 videos here).