UDID is Gone. So What?

The last week has seen quite a bit of commotion in the mobile world as Apple has started enforcing their long-awaited deprecation of the use of the UDID. Honestly, I’m not sure what all the fuss is about. This change was announced by Apple last summer, so everyone has had nearly a year to prepare for it. The general set of questions I’ve seen on the topic can be reduced to the following.

Why did Apple do this?

Most people would simply state the the reason is related to privacy concerns, but I think that’s the short and easy answer. Before we can go deeper into this question we need to consider how the UDID is typically used by app developers and mobile advertising firms.

The problem with using the UDID is that, as the name implies, it is an identifier that is unique to the device. In that sense you can think about it like a license plate number on a car. The industry best-practice for dealing with the UDID is to anonymize it before it gets sent anywhere. So let’s just say at this point that if you are using the UDID and you aren’t anonymizing it first, you’re part of the problem. Having an anonymized UDID basically akin to having some encoded version of a license plate number from a car. This encoding is one-way so even if you have the encoded version of the UDID, that doesn’t mean that you can just reverse the process to obtain the UDID itself. This process is called hashing and the MD5 and SHA-1 algorithms are the ones most commonly used for this.

So what does having this anonymized identifier get you as an app developer? Namely it allows you to see how many people have downloaded you app, how it is being used, and various other kinds of analytics that you may be interested in. For example, perhaps you would like to know how often people have deleted and then re-installed your app. You can find this out by sending the anonymized UDID every time your application is launched. There are plenty of useful things you can measure using this identifier from an app developer’s perspective.

The other large group that makes use of the UDID is mobile advertising firms. One obvious use for the identifier is something like frequency capping, which is just an industry term for making sure you don’t see the same ad over and over again. I think everyone is happy not to be bothered by the same ad, especially if it isn’t even relevant. Another use for the UDID is for services like conversion tracking. Say you are an advertiser and you want to run advertisements for your new app. You also would like to know how often people are clicking on your ad, and how often people who click on your ad are actually downloading the app, and how many of those people are actually running the app, and so forth. This kind of information can be obtained using the UDID. The UDID can also be used to do so-called targeted advertising, which basically looks at the devices who fit into some group and makes some guesses about other devices. In other words, users who have app A and app B installed tend to be more likely to click on advertisements for app C. This allows for better targeting of ads and provides more efficient allocation of resources for advertisers and more relevant advertising for users.

Now that the groundwork has been laid on UDIDs, how they’re used, and why they’re used, we can begin to have a discussion about privacy issues.

I cannot pretend to know what went on in the debates leading up to the decision to deprecate the UDID, but here is the basic idea as I see it. Many developers were not anonymizing the UDID before making use of it, and this is bad no matter how you slice it. Secondly, people tend to be uncomfortable with the idea of “being tracked” and don’t have a firm concept of what that always means. For example, if you know an anonymized version of my license plate number, and you can’t see original license plate numbers, then you really don’t have any useful information about me. If you see my anonymized license plate in different places on different days then you’ll be able to re-recognize me, but that doesn’t mean you know who I am or where I live. Lastly, the UDID is something that is hardware based and therefore can’t really be changed or deleted from the device. In other words, it’s too permanent. All that being said, Apple didn’t want to be seen as making it easy for people to “be tracked.” I don’t blame them for that, but deprecating the UDID doesn’t change anything, as we’ll see.

Potential Replacements

Okay, so apparently the gospel says that using the UDID is bad. What happens next then? Well there are quite a few proposed solutions, some of which are below in no particular order.

• OpenUDID is a solution that came out last year and generates a unique token for the device that is stored in the UIPasteboard and consequently is available to all apps. In this way it still becomes a unique identifier for the device, which doesn’t solve any of the privacy problems mentioned earlier. There is some opt-out functionality present, but the fact remains that it’s still one identifier that goes back to one device.

• ODIN-1 uses the Media Access Control (MAC) address from the wireless network chip inside the device in order to generate a unique token for the device. In this way it is really no different than using the UDID as it is still a hardware-based identification system and therefore is difficult to change.

• SecureUDID is an effort by Crashlytics to produce their own UDID replacement. Apparently there is a bit of a scuffle between the SecureUDID people and the OpenUDID people over who contributed to which technology and when. In the end, the result is that you still have a token that you can use to differentiate between devices, but the problem is that the token is generated on a per-domain basis. In other words, a publisher of multiple apps will be able to use the same token in all their apps, but another publisher will not be able to see the same token. If you are an ad network and you process ad requests from multiple apps, then you will not be able to tell that two requests from different apps actually came from the same device except under very specific circumstances. In the end, this solution is a non-starter in cases where you need to be able to identify the same device across apps from different publishers.

There are other solutions out there, but the last one brings us to the key issue in the matter. The only way for the ecosystem to perpetuate is with one unique identifier per device, and that’s the point that is at odds with the privacy argument. The reason that there are so many apps available for iOS devices is because that can be a profitable endeavor. The app developer will try to make money by selling their app for some price, or by having some in-app advertising that generates revenue for them. This is why apps are free. If Apple started rejecting every app that was able to identify a device uniquely, people would be forced to develop for other platforms, and that would be horrible for Apple. Imagine having an iPhone or an iPad without any apps. So Apple has to walk a fine line now by addressing concerns of privacy advocates and also addressing concerns of those who make a living by developing apps on their platform.

What next?

I think most people in the industry will move towards using the anonymized MAC address. This is the easiest change to make and the one that is most likely to be done by most industry players. This also allows for a device-specific identifier and therefore all of the previous products and services that were using the UDID can convert to using the MAC address without issue. The problem with this approach is that it is fundamentally no different from using the UDID and therefore likely to receive push-back from Apple at some point. In the end there will (hopefully) be an industry-wide solution that provides the required level of identification on a per-device basis, but is also something that can be cleared by the user. I think that will be the best solution for everyone involved.

Additionally, mobile websites and app developers should take additional steps to clearly communicate to their users what kind of information is being collected, why it being collected, how it will be handled, and so forth. Additionally, opt-out capability is something that will need to become the rule rather than the exception. This doesn’t have to be anything complicated, and could be as simple as app developers displaying a Terms of Use window to the user when the app is run for the first time. These terms should be very clear on anything related to data collection, use, and storage, and allow the user to choose not to provide any data at all. At that point it will be up to the developer/publisher to decide if they want to allow the user to continue to use the app or if they want to make the use contingent on the ability to display ads. That’s how they’re making money from their trade.

Conclusion

So the UDID is gone now. So what? This was announced months ago, and in the end it doesn’t really change anything. The need to uniquely identify devices is greater than ever, and the number of apps in the iOS App Store is rapidly growing (over 500,000 at the moment). Apple won’t risk alienating their developers, who are an integral part of the reason that people buy iOS devices in the first place (There’s an App For That(tm)). The goal then is to be as transparent as possible and move toward solutions that allow users to opt out of data collection, even though there should be no personally-identifiable information being collected anyway. That will be the only solution to the problem of balancing the need to uniquely identify a device and also respect the privacy and desires of users. The downside may be that app developers will only allow their apps to be used by those that opt in since they need to put food on the table. Just like there is no free lunch, there are no free apps.