UDID uncertainty continues – Part II
Since we published our client library update late last night to handle a post-UDID world, we got some more information from the ecosystem about what’s really going on given the swirling rumors of rejections connected to its use. It turns out that there is some truth to the rejection stories: TapBots posted a screen shot of their rejection notice on their blog earlier today. We had heard similar stories but it is good to have some first-hand confirmation that these rejections are indeed happening.
It is encouraging, however, that the rejection is based on the fact that the UDID, which is considered personal data, was passed to a third-party without user consent. The MoPub platform since inception has used SHA1 hash of UDID as a unique identifier rather than an unencrypted UDID. This hash function is referred to as a “one-way hash” because it is computationally impossible to determine the original UDID from a hashed UDID. Many ad networks, though not all, do this as well. Since the hash cannot be reverse engineered, we don’t consider this to be personal data and as a result, explicit consent would not be required. If the use of hashed UDID continues to be allowed by Apple, many of the dire scenarios that I outlined last night in my blog post will be avoided.
This controversy highlights a key benefit of MoPub’s open source client library approach. We didn’t have to choose between UDID or OpenUDID in our last library push – we were able to provide the choice between hashed UDID and OpenUDID’s open source alternative.
Ultimately though, I think many publishers would breathe a sigh of relief if there were an API introduced into the platform that allowed for conversion tracking but allowed users to opt-out if they chose to.