One of the few aspects of Apple’s AppTrackingTransparency privacy policy that the company has consistently broadcast through developer communications is that device fingerprinting is forbidden. That fingerprinting would not be permitted under ATT was explicitly stated at WWDC last June, and Apple has not wavered on that point since.
And yet, various ad tech companies have promoted two ideas since Apple announced the ATT policy:
- That Apple won’t enforce its fingerprinting ban in earnest, and that fingerprinting will continue to serve as a reliable tool for device identification;
- That their solution to device identification can’t technically be considered fingerprinting and instead falls into the broader bucket of “probabilistic attribution,” and is therefore permissible under ATT.
App developers should cast a skeptical eye on both of these notions. This morning, several developers publicly revealed on the Mobile Dev Memo Slack and on other channels that Apple had rejected their app updates on the basis of non-essential device data being collected for the purposes of algorithmic device identification and attribution. In some cases, these rejections cited specific MMP SDKs as being at fault; in others, the rejection simply listed the device parameters that were being collected or accessed (such as NSFileManager, NSFileCreationDate, getifaddrs, NSLocaleCountryCode, and systemTimeZone).
In mid-March, Apple began rejecting app updates from Chinese developers where the CAID identifier was integrated; since then, the Cyberspace Administration of China, a government entity with strong influence over internet-related policy in China, has banned the collection of non-essential data in consumer apps in a move that may be independent of but is nonetheless aligned with ATT.
Apple has been unambiguously clear since the announcement of ATT that fingerprinting is not compliant with its privacy standards. One reality that app developers need to face at this juncture, with the rollout of ATT likely just weeks away, is that full compliance with ATT is the only practical or prudent commercial path forward. Having an app update rejected is painful; removing or updating SDKs from an app is also painful. The strategies and techniques that many mobile ad tech companies have sold to clients as being permissible or workable under ATT while not fully compliant are not likely to persist into the rollout of ATT.
Putting aside the foolhardiness of some ad tech companies in promulgating theories around lackadaisical enforcement of ATT from Apple or of a 25th-hour reprieve from ATT being delivered in the form of an anti-trust injunction, developers at this point should not be relying on ad tech partners for guidance in navigating ATT. While Apple has been derelict in providing clarity and actionable instruction around certain adjacent aspects of ATT, such as eg. how privacy thresholds are calculated for SKAdNetwork, the company has been remarkably clear around what is not allowed under the ATT privacy policy. One of those forbidden resources is fingerprinting.
Photo by Immo Wegmann on Unsplash
Recent