OpenUDID is an independent and open-source effort; nevertheless, Appsfire is by default the primary sponsor of this effort, with one single goal: to try and help the mobile advertising industry at large to navigate the post UDID-deprecation era. From time to time, journalists come to us with questions. Here is a compiled Q & A.

Would you describe the current status of post UDID user tracking environment?

The environment is feeling the pressure right now because the deprecated API is almost inevitably turning into a private API, anytime soon. It is rumored that apps are now being rejected because their use of UDID or will be rejected for that reason. Typically, an API goes from deprecated to private/removed after the next major OS release. So if iOS 6.0 is announced at the upcoming WWDC, then it could mean the definite end of UDID as we know it.

Which is fine. Developers and stakeholders are resourceful: Apple created a thriving eco-system, with decent monetization potential all around. And so the eco-system is finding ways to keep playing the game, with or alongside Apple.

As is often the case with Apple, it’s the in-between period that is difficult. Apple has a policy and habit of not disclosing their roadmap, which seems to work well for them. In this case, the developers are caught between the fear of having their app rejected, and the need to carry on with their business until Apple settles on the matter, one way or another (offering an alternative solution in iOS 6, or simply remove the API for good). It’s quite stressful at the eco-system level.

How do app developers react for the news from Apple?

First of all, let’s be clear: Apple has been pretty cool about it; they did give advance warning!

The API deprecation was announced softly around a year ago, so in a way, there is no excuse to be caught unprepared.

However, since Apple didn’t really disclose nor discuss the reasons and future intent around this topic, then developers were left scrambling to find a replacement solution. In the deprecation notes, Apple suggested a mild alternative which only covered a few use cases; it would be unfair to assume that Apple knows everything about everything… But in the end, this became uneasy for a certain category of developers: it meant refactoring, reengineering code that was working just fine, and in most case, was very legitimate and harmless in terms of usage and privacy.

This is typical of the double-bind platform/developers relationship: developers always want more APIs and more flexibility as an enabler for their creation to exist on the platform, and platforms want more control over the destiny of the platform. It’s not frictionless.

Note that the UDID situation does not directly affect most developers in a major way, unless they used the identifier in a wrongful way. Here is one such example of misuse: the legacy UDID might have been used to lazily identify a given user, anonymously, without requiring a username/password user-interface or other unique identifier managed and saved locally or on a server; it’s a shortcut, it works, but UDID wasn’t meant to be used like that.

This was probably a shortcoming of the original API offered by Apple: offering a 1-line-of-code API to access the Unique and persistent Device IDentifier and no equivalent API to access a Unique and persistent User IDentifier. It can be done, but requires many more lines of code; developers (the author of OpenUDID included!) are lazy, so they went for the low hanging fruit!!!

Why did Apple remove access to UDID in the first place?

Privacy advocates and journalists looking for a quick and dirty controversy were quick to announce that Apple had done this to protect user privacy. The fact is, Apple did not comment on the matter - hence, the rest is pure interpretation.

While we recognize and admire how much Apple cares about the end-user experience, we actually don’t think this was the main motive. In fact, the deprecation was more of a warning to prevent developers from depending on this feature in order to build something better; again, probably to better serve the entire community: users and developers.

What are the typical uses for UDID again?

As described above, the UDID was used for many different things, some logical, some illogical as described above. In any case, some of the very legitimate 1st degree use cases are:

• testing services that need to collect UDIDs to facilitate installation of trials
• app usage analytics
• ad networks
• campaign efficiency tracking

Some really relied on the formal and official UDID (testing services), others found work-arounds. But all were disrupted.

How about mobile ad networks?

Mobile ad networks are on the other hand deeply affected by the deprecation of the UDID.

Again, Apple probably didn’t mean to adversely impact this community. Such an implicit intent would put Apple in an awkward position vis-a-vis iAd, which is an ad network that already enjoys quite a bit of an unfair advantage. iAd does click-to-install ratio measurements… and the UDID was precisely used by external ad networks to achieve the same measurements. Unfair because iAd probably doesn’t need to use the UDID - it’s tracking at the core; it’s built into the OS!

As mentioned before, our take is that Apple wanted to remove an API that was used for too many different and wrongful technical reasons (instead of a proper user ID or for tracking clicks to installs). Developments around using and sharing the UDID started to create a PR-headache for them as a result of privacy advocates claiming that Apple was facilitating the leak of personal user information… Apple simply killed two birds with one stone.

Now back to ad networks. Ad networks are engineered by Software architects and Developers, usually good ones too! While they are as resourceful as individual app developers, they have a problem to solve that is more complex by an order of magnitude. Because they work in networks, they need a common and universal token to trace the conversion rate between the clicks on an app advertisement and ultimately the download of that app. Because the iTunes transaction is opaque, then this unique token, formally the UDID, helps measure that ratio, in a way that cannot be contested by the buyer of advertising, or the network. The exchange is done via SDKs, APIs, etc… so mostly within the confines of the application sandbox, but with this one externally shareable and universal ID.

We totally realize that the strict UDID was also not the “perfect” tool to measure conversion. What ad network actually need is a Unique Transaction IDentifier, one that has a lifespan of a day or two, but persistent between the click and the download (i.e. to measure how many downloads were generated by a given batch of clicks). Apple could help in many ways here:

• by helping track aggregate measures of an advertising campaign (they somewhat do actually, but only for paid transactions within select geographies via iTunes affiliation networks)
• by providing a proper UTID API

There are many different approaches. What are pros and cons of each approach?

OpenUDID, Fingerprint, MAC Address, ODIN, Cookie. Safari Redirect, Landing Page Proxy

First tier UDID replacements:

1. OpenUDID is meant as a drop-in replacement; so it’s really the closest thing outside the common API.
• Pros: it mimics the behavior of UDID: same format, same attempt at persistence, etc… in addition, it has a built-in opt-out mechanism that will hopefully educate developers to deal with this case, and at least put user privacy concerns back inside the cycle
• Cons: it only works well if it is widely adopted, which appears to be the case today
• Risk: that Apple actually meant to clamp down on sharing any sort of unique identifier, in which case, OpenUDID might be questioned
2. The MAC address is another unique identifier available within the native API; it’s the ID of the WIFI card.
• Pros: there is code out there that makes it easy to access (add 2 files, 1 line of code), and it’s persistent and universal, like the UDID
• Cons: it’s a much more sensitive piece of information than Apple’s proprietary UDID! the MAC address is used to identify networks on private LANs…
• Risks: the backlash here could be much greater - Apple might be forced to impose restrictions or deprecate access to the MAC address which is an essential part of certain protocols and serious applications that depend on it. What’s worse, if ad networks start collecting MAC addresses, then it’s like having a clear database of social security numbers… not really acceptable.
• WE ARE A STRONG ADVOCATE AGAINST ANY USE OF THE MAC ADDRESS FOR ANYTHING THAT IS NOT WIFI RELATED
3. ODIN is a working group that basically proposed to use a hashed version of the MAC address (ODIN-1), which offers minor cloaking (one-way hashing). It’s as bad as using the plain MAC address really. With large datasets (rainbow tables) and supercomputers, it’s relatively easy to decode the hashed value and convert it into the original MAC address. The ODIN group recently reached out and they are reconsidering, looking at OpenUDID and it’s core approach (ODIN-2 ?); naturally, we should all strive to converge. It’s win-win given the “network effects” at stake.

Other alternatives:

Other solutions are slightly more complex and circumvoluted.

1. Cookie/Safari redirect:
• Explanation: each application lives in its own sandbox. Even the browser “view” within each app shares its own “cookie” space. So in order to share a common token to reconcile click & download, one must exit the app and go to the only default browser on iOS: mobile safari.
• Pros: one can track from mobile web banners to app download (web-to-app advertising), which is not covered by UDID techniques
• Cons: it quits the app as soon as you launch it (what?) and then comes back to the app after the tracking is done. It’s quirky and feels wrong at the UX level. First impressions and speed matter on an app, and having to go through this cycle requires a web connexion, and might delay the launch by several seconds. Not great. What’s worse is that using cookies and safari redirects also forces an exit to safari in the app-to-app context (instead of UDID techniques that go from app to appstore directly). Not great.
2. Fingerprinting:
• Explanation: here a mix of IP address, timestamp, and other contextual tidbits are used to create a unique identifier on the fly.
• Pros: It’s closer to an hypothetical UTID than the original UDID.
• Cons: the accuracy is much lower than UDID equivalents, below 90% and in certain cases, completely broken (e.g. large downloads volumes from behind the same router). Also, there is no universal formula here. Certain networks turn their formula into an asset which they do not want to share necessarily. We have yet to see a neutral and open-source implementation.

OpenUDID gets more tractions. Why do you think it does?

When UDID deprecation was announced last summer, we readily started working on a contingency plan for our own needs at Appsfire. It quickly became clear that the solution should not be proprietary, but rather open-source with all stakeholders in mind.

It took a dedicated few days to experiment with all the possible techniques: local storage, to iCloud, to Keychain, to Pasteboards, MAC address, etc… the goal was to achieve a decentralized, persistent, unique, universal equivalent to UDID, and add an opt-out component to it as bonus. Very early in September 2011, the foundation of OpenUDID was published on GitHub, and the code could be integrated by anyone, offering a safety net against sudden removal by Apple. The code has evolved a little since, but is backwards and forwards compatible by design.

To get to this level of traction, it has required quite a bit of individual effort and time at the coding and community management level, but also by extension by Appsfire, the “corporate” sponsor of this initiative. It has involved listening and discussing with contributors, watchers, bloggers, pundits, yeah- and nay-sayers. These months of lead time have given OpenUDID the opportunity to grow in awareness, and gain a solid followship: 450 followers on GitHub, 17+ networks and top vendors, and growing by the day.

And quite objectively, it’s the closest thing to the real deal

Pride aside, it’s work in progress which has little to do with code at the end of the day.

Middleware is a living system, so it must evolve and mutate within its environment anyways.

Do you think companies in the industry take multiple approaches to hedge risks or getting to one solution?

The use cases and sensibilities are quite varied, so certain networks have already chosen one solution vs. another.

Because of the network externalities, to be able to “speak” with everybody else, one must eventually support several/all solutions.

That being said, in our discussions with many networks, we feel that there is a desire to converge towards one/fewer solutions, that there is a general agreement that the MAC address is sensitive, and that user privacy concerns should be addressed.

Using multiple approaches is “as risky” as using only one; either way, this relative “risk” is inherent to Apple’s next move on this subject (which may be next week at the WWDC). And if Apple objects, the code base will have to be revisited.

Naturally, all of us would welcome a discussion with anyone at Apple on the matter.