Eric Johnston is VP Engineering and Chief Architect with Verve Wireless.
Last October, when Apple released version 5 of its mobile operating system, hidden deep in the developer documentation was a short note attached to a system function called uniqueIdentifier: “Deprecated in iOS 5.0.” It just so happens this simple function provides access to the value commonly called the UDID.
The UDID, short for “unique device identifier,” is a number Apple assigns to iOS devices during manufacturing. It’s ubiquitous: every iPhone, iPad, and iPod Touch has one. It’s immutable: it can’t be changed, and users have no control over its access. The UDID has offered pretty much everything an advertiser could want for distinguishing unique users.
So when app developers discovered this small change to the documentation, all hell broke loose. Apple, of course, provided no more information than these four words, which left developers, advertisers, and publishers to speculate wildly about what it meant and when they’d be cut off from the UDID altogether.
Apple was merely putting developers on notice. The uniqueIdentifier function continued to work in iOS 5 with the caveat that it may not work in future versions. The issue was largely forgotten until a couple of weeks ago when Apple rejected a few apps for transmitting the bare UDID over the network. Though the rejections were focused on a particular use of UDID, the move seemed to proclaim Apple isn’t bluffing.
The basic problem that UDIDs (or, frequently, hashed or otherwise obfuscated versions of the UDID) solve is that of tracking a user among different apps on the same device. Since apps are “sandboxed” for security and simplicity, they can’t really communicate with each other – not even with cookies, which can allow tracking across sites on the Web. Advertisers like to see the UDID in their ad requests to match up activity from disparate apps for conversion tracking, retargeting, and advanced targeting approaches. App publishers use UDID in their app analytics to get a very accurate picture of their audience.
Why is Apple disrupting their thriving app ecosystem with this change? The cynic might offer that Apple wants to give its struggling iAd network an advantage. Apple’s past behavior, however, indicates it is sensitive to this perception: With the improvements to user control over location data in iOS 5, Apple included an option to turn off location collection for iAd specifically. Instead, its motivation seems to be user privacy.
Mobile privacy is a hot-button issue on the heels of “locationgate,” Congressional hearings and lawsuits. While Web cookies have always been plagued by the stigma of privacy intrusion, the debate over device IDs on mobile is amplified by the personal nature of smartphones and the permanency of UDIDs. Apple clearly wants to proactively address this as a privacy issue rather than react to the publicity a large-scale abuse of UDID would provoke.
No matter its motivation, Apple has spurred a scramble among developers and advertisers to replace UDID with a workable solution. Some proposed solutions, such as use of the Wi-Fi hardware or MAC address (the Open Device Identification Number approach: http://www.odinmobile.org/), don’t resolve the privacy and user control issues. Others are creative hacks using the copy-and-paste clipboard (OpenUDID: https://github.com/ylechelle/OpenUDID).
Device fingerprinting schemes are an option and have the advantage of working across both mobile web and apps but suffer from the homogeneity of the iOS ecosystem. With other mobile platforms such as Android, the variety of device manufacturers, models, and firmware revisions provide a number of data points that, in aggregate, can establish an acceptable level of uniqueness among fingerprints for anonymously identifying individual users. On iOS, the limited number of device models and high adoption rate of firmware updates conspire to depress the uniqueness of typical fingerprinting techniques for anonymously tracking users beyond a single session.
On the Web, for all of their imperfections, cookies provide a standard and widely supported method for the delivery control advertisers need. If Apple is truly serious about being a leader in protecting user privacy in its app ecosystem, it can’t do that at the expense of advertiser needs. Otherwise advertisers are left to their own devices to craft solutions that serve only to fragment the technology and are frequently counter to Apple’s own goals.
Following are a couple of ways Apple might fill the UDID vacuum on iOS:
- Apple can eliminate a large part of the need for a cross-app identifier by simply allowing app download referral tracking, similar to what Google provides for Android apps.
- iOS currently allows apps from the same developer to share a limited amount of data via its “keychain” mechanism. Extending this to provide a way for all apps on the device to share information would, in effect, give developers “app cookies.” Apple could, of course, allow a user to control and view these data. (App cookies are essentially what the OpenUDID folks have implemented, albeit unofficially and without system-level controls over the information.)
- Most in-app advertising is presented in what are called “web views” – mini web browsers embedded in an app. Allowing cookies to be shared across Mobile Safari and in-app web views would, certainly, be the most useful solution for advertisers even with the conservative Mobile Safari default cookie settings. (This approach has the added potential of new mobile web and app synchronization features for users.)
Chances are that Apple will unveil the next major update to iOS at its developers’ conference on June 11. Presumably the documentation for uniqueIdentifier will include the note “Not available in iOS 6.0 and later.” The big question for the advertising industry is whether Apple will introduce any new functionality like the ones outlined above to take its place.