When Apple’s App Tracking Transparency (ATT) privacy policy was initially introduced nearly two years ago at WWDC 2020, most commentators and industry operators expected its prohibition of device fingerprinting — which is explicit — to be enforced following some brief grace period. WWDC 2022 is now just one week away, and fingerprinting throughout the mobile advertising ecosystem is commonplace and happens more or less in plain sight. I’ve consistently argued that Apple should police fingerprinting, and I’ve questioned why it has yet to do so. Fingerprinting is a privacy nightmare, and it is a crutch that disincentivizes the ad tech ecosystem from making investments into measurement and attribution solutions that embrace the new privacy landscape.
That fingerprinting is being allowed to happen punishes the app advertisers that built infrastructure to accommodate SKAdNetwork. So why doesn’t Apple police fingerprinting? One potential explanation is that Apple isn’t concerned with fingerprinting being used to attribute installs outside of user consent, as I describe in Why isn’t Apple policing mobile ads fingerprinting?:
Fingerprinting is the process of aggregating hardware and network parameters from a device into a combination that is likely to be unique, or unqiue enough to provide a sense of identity, within some period of time. The more parameters that are combined, the less common the combination, but the primary components to a device fingerprint for mobile advertising: device IP address, OS version, and model code. A fingerprint is not persistent, and it can expire rapidly, so fingerprinting can really only be used for install attribution: the time between a click and an app install tends to be abbreviated such that a fingerprint match between an ad click and app install is considered reliable. So while a fingerprint can be credibly used to attribute app installs, the same is not true for in-app events that happen hours or days later.
While this use case — of matching an install to an ad interaction — violates the spirit and letter of ATT policy (per the screenshot above), it’s understandable that going to great lengths to prevent it from happening with a technological solution would not be a priority for Apple given that no persistent identifier is derived from that match. ATT was seemingly designed to disrupt the “events stream” of conversion data between advertisers and ad platforms when a user hasn’t expressly consented to have their data transferred between parties. Fingerprinting can’t support the events stream and (mostly) can’t be used to build durable user-level behavioral profiles.
Mobile device fingerprinting for app traffic is undertaken by ad tech measurement vendors. One beneficiary of the practice is the group of ad networks that I’ve termed “broker networks” (sometimes known as SDK networks). These ad networks aggregate ad supply through SDKs integrated into publishers’ apps and sell that inventory to advertisers. I describe how these broker networks have benefited from fingerprinting in light of Apple’s non-enforcement of its fingerprinting prohibition in this article. At a high level:
- Mobile device fingerprinting uses a relatively small set of device parameters, and it is coarse and imprecise. Fingerprinting can’t facilitate dependable, user-level matches, as did the IDFA. Instead, a fingerprinting system identifies a user as belonging to a group that matches a set of device parameter values. In this way, it is prone to false positives in terms of matching ad interactions to app installs, which may result in conversions being over-attributed;
- SKAdNetwork doesn’t provide for real-time install attribution, but fingerprinting does. The singular threat of ATT to broker networks is therefore eliminated if fingerprinting is allowed.
In October 2020, I wrote a piece titled IDFA deprecation: winners and losers in which I constructed an impact matrix for various categories of participants in the mobile economy. I posited at the time that broker networks would feel minimal impact from ATT, since broker networks primarily target ads using contextual cues, not behavioral profiles, and thus ATT would really only disrupt attribution for them. The reality is that, because fingerprinting has not been policed, the measurement disturbance didn’t even occur for these networks.
In February of this year, in a piece titled How Apple might break fingerprinting in iOS 16, I speculated that Apple might introduce a separate SDK runtime to iOS that decouples the device permissions granted to ad tech SDKs from those granted to apps. This proposal mirrors what Google announced with its Privacy Sandbox for Android initiative (which goes live in Android 13), but Apple could take this one step further and apply its Private Relay feature, which currently obfuscates the IP address of iCloud+ subscribers when they use the Safari browser, to this iOS SDK runtime, obfuscating the IP address in the data accessed by ad tech services. Since the IP address is a critical component for a device fingerprint, this approach would render the practice of fingerprinting nonviable.
How much damage would this cause to the broker networks that have benefited from ATT? Any gains on pre-ATT revenue baselines enjoyed by these networks resulting from the over-attribution of installs would evaporate since SKAdNetwork would be left as the only means of install attribution. SKAdNetwork postbacks, while delayed and often lacking conversion values, are precise for installs at the campaign level. My sense is that the broker networks would feel limited pain from fingerprinting enforcement: the gains from over-attribution are not likely substantial relative to the overall sizes of broker network businesses, and real-time attribution estimates can be modeled from SKAdNetwork postback and ad engagement data. The obstruction of fingerprinting would create frictions for broker networks, but I doubt those frictions would be disastrous or company-threatening.
The more important question related to fingerprinting, to my mind, is whether any ad platforms — the walled gardens that sell owned-and-operated ad inventory — are surreptitiously doing it, or at least using the IP address for conversions matching. The Financial Times alleged as much last year, and given the severe depredations wreaked on the mobile advertising ecosystem by ATT, it wouldn’t be surprising to see this functionality developed. That said, it’s not at all clear if any ad platform is pursuing this. Evan Spiegel, Snap’s CEO, stated last week for instance, at the JPMorgan Global Technology, Media and Communications Conference: “we don’t collect IP addresses for our opt-out users.”
If any ad platform or large, integrated advertiser is using the IP address for the purposes of conversion matching, the obfuscation of the IP address would inflict more pain from neutralizing that use case, given the relatively higher value of conversion data, than it would in breaking fingerprinting for install attribution. Remember that Apple did intervene in preventing the Chinese Advertising ID, or CAID, from gaining adoption: the real-time, cross-company IP address exchange would have allowed for persistent identities to be derived from device IP addresses, absolutely undermining ATT.
The CAID would have required an extraordinary degree of collaboration (I called it a “data co-op”) between companies, and platform-specific IP address matching, if it is happening, wouldn’t have as blunting of an effect on the restrictions of ATT. But nonetheless, IP address matching could be very helpful for advertisers and ad platforms in terms of accounting for conversions at the user level, even if it can only do so for conversions that take place very soon after an ad click.
It’s unclear whether or when Apple will introduce any technological solution for obfuscating the IP address for in-app traffic. But it seems likely that Apple wants to do it, because:
- Apple has already introduced Private Relay for Safari;
- Google announced its upcoming SDK Runtime months ago, which means that Google currently has a leg up on Apple in terms of the consumer optics of privacy preservation (although Google hasn’t published any consumer-facing material touting the benefits of an SDK Runtime).
I’m not sure how new this is, but Google is using on-device conversion measurement to attribute installs with e-mail addresses via Firebase. H/T @Thomasbcn on the @mobiledevmemo slack. pic.twitter.com/br3wKkM0vH
— Eric Seufert (@eric_seufert) May 17, 2022
My understanding is that Google is now enthusiastically advocating for advertiser adoption of its on-device conversion measurement tool in Firebase, its analytics SDK. This measurement approach keeps all relevant user data on the device while allowing for conversions to be matched at the user level; the match is made on the device using a hashed email, and only campaign-level results are transmitted back to Google.
On-device measurement, in conjunction with other privacy-centric methodologies, will exist in an ensemble that comprises the next moment in digital advertising optimization. But that moment can’t unfold while fingerprinting is being utilized as a workaround. Any measurement system that relies on user-level data moving between contexts and parties isn’t long-term sustainable, given the momentum and direction of the thrust of the current privacy climate.
Photo by Matthew Ansley on Unsplash
