UDID … or Didn’t U?

Developers all around are struggling to update their ad network libraries as a reaction to rumored app rejections. It has been reported that apps which access the unique device identifier are getting semi-randomly singled out.

But, in light of recent revelations this apparently is not entirely true. Here’s a quick rundown of what is actually happening and what companies seem to be beginning to agree that the best solution is going forward.

This is Apple’s official statement. Well, the most official that one can find, from the documentation.

How nice of Apple to even suggest how to fix it. But we can read between the lines as to what their actual intentions are. According to these “Special Considerations” Apple sees a privacy problem with being able to uniquely identify devices. Rather they are stressing that one should create a UUID per app and store that in the user defaults.

That works fine if you control all the code that goes into your app. You can even share the user defaults between your apps if they have the same bundle identifier prefix, if I remember correctly. But there is also the case that the developer is trying to monetize his app via banner advertisements served through the plethora of available ad networks. This means he has to use code that they created to interact with their respective ad platforms.

The problem is that most ad network’s income is directly dependent on being able to track conversions. A conversion is the situation where an advertisement is shown and then the user taps on the banner. Or if the banner leads to the user buying an app on the app store. Imagine an ad for an app showing in your game, the user taps through, purchases and downloads the app. Then when he starts the new app for the first time this can also report that it has been installed on this device. This is valuable information being able to correlate an install and banner ad campaigns.

Ideally – from the point of view of the advertiser – we would get access to the Apple ID and be able to track those conversions per person. This is indeed how Google does it. Through your Google Single-Sign-On they know if you saw an ad on one machine, but then reacted to it on another. Other web banner networks would track “uniques” by setting one or more cookies with a GUID. In theory a cookie is limited to just the domain that set it, but due to the nature of HTML pages you can have one page trigger multiple sub-requests that also retrieve stuff from other domains. On every such request the server has a chance to inspect and set the cookies. Imagine the privacy problems that being able to track users across devices would entail.

So using the UDID was sort of an accepted fall-back. Most users would have a limited number of devices, like one iPad and one iPhone. So so the ad networks that meant tracking two identities based on these two devices’ UDIDs. Worked as advertised, pardon the pun.

But then Apple went and deprecated the uniqueIdentifier method. This means that in the next major iOS version it will no longer be available. If they remove it and not just make it private then this would also mean that apps accessing the property would crash with an “unrecognized selector” exception. Now it is perfectly normal in the software industry to wait until the last possible moment to come up with a fix if there is no obvious workaround.

And there really IS no obvious workaround for the dilemma of the ad networks. Those are generally a thorn in Apple’s side – competing with iAds – and thus they don’t get any free lunch. Apple clearly has the user in mind first and the developer with his apps second. Apple couldn’t care less about conversions, except those in happening via iAds.

We all took it for granted that all apps even accessing the uniqueIdentifier get rejected now. But that really does not seem to be the total truth. We know that Apple is scanning our apps for use of private APIs, so we all assumed that this is the same case in this situation. But then TapBots actually published the actual rejection letter they received from Apple.

Aha!

“To collect personal user data with your app, you must make it clear to the user that their personal user data will be uploaded to your server and you must obtain the user’s consent before the data is uploaded”

From this we can deduct that in the approval process Apple is also monitoring HTTP traffic initiated by your app. And since they know the identifiers of the test devices they can easily and automatically spot if any HTTP request contains this string. Now this case is quite obvious with the UDID being contained in HTTP GET URL itself, but I assume that sending it via HTTP POST and form-encoding it would have the same effect because HTTP inherently is a plain text protocol.

So the truth behind these rumored rejections seems to be the sending of the UDID to a server without having informed the user or asked for his permission. Think about it, there are so many other uses for uniqueIdentifier besides tracking conversions that Apple simply cannot blanket reject all apps using it. So it’s not by scanning your binary for the use of the deprecated API, because that would simply find too many false positives. But scanning network traffic is dead on.

In short: Apple does not want for the UDID to be transmitted outside of the circuits of the device.

Oliver Fürniß of Curious Times reported:

Great, Apple did NOT reject my latest update of HappyDayz! due to using the UDID (only used for Push Notifications on devices with iOS 3).

… which further proves my point.

But this relief comes a bit too late, as we can see from the reaction of several players who have been scrambling especially in the past 2 weeks to change to some other identifier.

• OpenFeint – implements SSO system and suggest to use this instead
• Appsfire – initiated OpenUDID initiative started 7 months ago
• MyID – a for-sale component with the UUID+private pasteboard implementation
• Ole Bergmann blogged 4 months ago, his solution is basically the same as Apple’s
• MobFox – switched to OpenUDID
• MoPub – implemented OpenUDID
• w3i – uses the Mac address
• Google/AdMob – doesn’t use HTTP so that Apple cannot inspect their network traffic

If you know any more to put on this list, please let me know in the comments.

Conclusion

Much of the commotion was a result from basing series of FUD articles on big-traffic sites on incomplete information. Unfortunately that’s something that’s occurring more and more frequently. AntennaGate, WarmGate, etc.

Of all the alternatives for conversion tracking networks the OpenUDID implementation seems to be the clear winner for now. But unfortunately this is still a patch on a big privacy wound that needs to be addressed. Ad networks need to change their business model away from performance tracking on a per-device basis. Users are NOT their devices.

Apple – always on the lookout for the user’s privacy interests first and foremost – does not want users to be tracked by unique device any more, but even less they like sloppy ad network code transmitting unique device ids as plain text without asking the user for permission.

Categories: Apple