(Note: Lab Tuesday is when we take an important topic that we have seen in our internal privacy testing lab and discuss it at length. When we have specific illustrations, they are always taken from non-client sources, with the name of the relevant commercial party left off--we are not looking to throw anyone under the bus here, but rather improve practices and awareness.)
Recently, the mobile platforms have played an important role in improving end-user privacy. Along these lines, Apple, in or around iOS version 6.0, created a new, unique identifier that could be used in place of the UDID and MAC address for advertising and certain other purposes. This new identifier is Apple's Identifier for Advertising, also referred to as the "IDFA" or "IFA." The IDFA, unlike the UDID and MAC address, has an important privacy feature insofar as it can be reset by the end-user. In later versions of iOS, the UDID and MAC address have been fully deprecated, leaving the IDFA as the only unique ID that can be tied to the end-user and collected across different apps.
Apple's developer documentation gives clear guidance on the proper use of the IDFA, including the instruction that "you [i.e., the developer] should not cache it." By "caching," Apple is referring to storing an old or existing IDFA in memory on the device.
By not caching the IDFA, a developer helps to preserve the privacy impact of a reset.
What we have seen recently, however, with various apps, including one very popular one, is that when an end-user logs-in to the app after resetting the IDFA, the app transmits—in the same HTTP Request—both the reset IDFA as well as the prior IDFA. This negates the whole purpose of the reset.
We observed this behavior using an SSL-enabled, intercepting web proxy to see the data flow. Below is the body of an HTTP Request sent from the app to its back-end servers:
View larger image
We witnessed the same data transmission even when "Limit Ad Tracking" was activated (although the "tracking_enabled" flag was switched to zero).
View larger image
It may be that there is a good technical reason why the app noted above needs to correlate both the old IDFA with the reset IDFA, although it is difficult to think of what that reason would be. Moreover, it would appear that the only way for the App to send HTTP Requests containing both the old and new IDFA is if the app is, at some level, caching the IDFA (we didn't dump the app specific storage to determine the exact mechanism, we just looked at the network traffic).
The bottom line for developers: When using the IDFA, don't cache it.
The bottom line for chief privacy officers, is that these are the types of issues--the technical "gotcha!"--that the FTC likes to pursue. Although that wouldn't stop us from mounting a persuasive defense in a case such as this, it would be much less expensive, and also better for the brand, to address these issues before they become a problem.
