Here’s an analysis I wrote on iOS UDIDs for the excellent PRIVACY Forum mailing list, which I’ve posted here for reference:

Last year we started building WasteNot, our free environmental iOS app, and we needed a way to uniquely identify our customers so they could access their accounts.  We spent a lot of time discussing the privacy implications and determined there were two options: use the UDID, or create our own identification system.

As a long-time privacy advocate (I co-founded a privacy infomediary in ’99), I foresaw a potential privacy backlash against the UDID.  It’s incredibly simple to access the UDID and transmit back to the server, but incredibly privacy invasive, easily linkable across different applications, and as it turns out, useless for actually tracking customer preferences across multiple iOS devices.

We’ve written a privacy chapter in our upcoming iPhone business development book discussing our key learning in detail, but I thought you might like some quick highlights of what we’ve learned:

• A UDID is unique to each device, but only Apple can link it back to an actual customer unless the customer provides more information, or another piece of data is sent along (e.g. telephone number, GPS location for google maps, etc..). Many duplicitous companies collect and transmit this secondary information. Rarely do they do use opt-in, nor does the Apple device warn the user of the majority of the data collection and transmission.
• A UDID identifies the *device*, not the customer — if a customer has a iPhone and an iPad, there are two different UDIDs.  If a customer loses their iPhone, their replacement iPhone has a different UDID.  If a family shares a single iPad, they all have the same UDID.
• A customer cannot change their device’s UDID, nor can they stop the collection and transmission of the UDID (like they can block the GPS location for which there is an Apple alert).  IMHO, Apple should require a pop-up notification for “this app is trying to collect and use your UDID: OK / Cancel”, but Apple is very against additional pop-ups as they detract from the customer experience.  I doubt this will ever become a feature, nor do I believe this would really do much other than annoy the customer with yet another alert they don’t read or think about before clicking “OK”.
• If you don’t use the UDID and want to uniquely identify customers (in our case to store preferences and content submissions so they are accessible from any device running WasteNot), your options are similar to the web-based world. In our case, we chose to use a fully opt-in model, where customers first had to sign up with an account using any email address they prefer.  In retrospect, there are several problems with this approach:
  
  1. Customers have generally used their real email addresses when they sign up for a WasteNot account.  From a privacy perspective, we don’t really want this information, since if our servers are hacked, their email addresses are at risk.  UDID’s are much less useful to a hacker since you can’t send spam to a UDID. Arguably, email address collection for account identification is much more privacy invasive than if we had just used the UDID.
  2. A significant percentage of people who download WasteNot do not ever sign up for an account because of the account creation hassle.  This limits the functionality.  I’m sure this has resulted in several of our less-than-5-star ratings, although we use an opt-in system and we do *no* behavioural tracking, so I have no way to verify this.  My guess is that had we used a UDID approach, we would have had significantly higher ratings, significantly more customers, and significantly better press as a result.
  3. People forget their passwords, so we needed to build a password retrieval system, too.  All told, it was more than 250 additional hours of work to build and test the system to handle user account generation, login, logout, password retrieval, email address verification, and other things that wouldn’t have been as necessary if we had just used a username and the UDID.
  4. On the flip-side, had we used the UDID we wouldn’t have been able to let our customers access their WasteNot account from any device.  This means that the UDID, which arguably was put in to allow for easy customer identification, is really only useful for behavioral tracking on a single device.  You still need a login system if you want your customers to be able to use their account from multiple devices.

Key Takeaways:
My takeaways from the last 22 months of development and watching our WasteNot app in the wild are:

• You need a customer account creation and login system if you want to have customer accounts.  UDID’s don’t fix the account problem, so they don’t really provide much value to privacy-conscious developers like us.

• Developing an account creation system is a LOT of work, and thus the majority of developers who don’t need multi-device accounts choose to use the UDID instead to save time and money.  (In other words, Apple incentivizes developers to use the UDID by not providing them with a similarly useful privacy-enhanced customer identification tool.)

• UDIDs are only useful for tracking the behaviour on the device.  This makes it incredibly useful to track behaviour within an app, and I’ve seen several advertising and behavioural tracking systems that use the UDID, without the customer’s knowledge or consent.  (One sales pitch I saw bragged about their ability to report on every action a user took within an app: every button click, every page viewed, every table cell viewed, and the time a person took between each action, all sent back to the server without any notification or customer access to that information.)

• Thus, UDIDs are most useful to people who want to track and collect user behavioral data without user notification or permission (ad networks and behavioural monitors).  And since the UDID is the same for every app on a device, this is a boon to advertisers and other data aggregators.  (Think of how happy the DoubleClick/Google’s of the mobile advertising world are that they no longer have to place a cookie to track a user across sites/apps, there’s already a permanent cookie that the user cannot turn off.  Eric Smith’s paper was insightful comparing this to the Pentium 3’s Processor Serial Number (PSN).)

• UDIDs are _initially_ only linkable back to an individual by Apple, unless the individual provides more information (e.g. GPS location, email address, telephone number, etc.).  Unfortunately it’s very easy to do this, either directly or indirectly.  Hopefully Apple is checking for this when they review apps before approving them on the App Store — I doubt it but I still hold hope — but if a developer who wanted to do this was smart, they would have the app query the server on load and have the server return a “don’t collect or transmit data” response during app review, and then once the app was approved, switch that to “start collecting data now that Apple isn’t reviewing this app anymore”.

• Once a network has linked a UDID to personally identifiable information (PII), they can then link that UDID to all of the apps that use that network. Once a customer uses the same app on two devices, the network can link all information between all apps across both devices. For example, say two apps both use the same advertising network. If app_A asks for an email address on a device (e.g. iPhone), and then provides that to the ad network along with the UDID, the ad network now has a link between the UDID and the email address and can use or sell that information to all the other apps in their network. If app_B collects geo-location data, and delivers that to the ad network along with the UDID, now the ad network can link the email address (from app_A) with the geo-location data (from app_B) and build out their database of PII for each UDID. Once a customer uses app_A on a different device (e.g. their iPad), the ad network can immediately link the two UDIDs together and now knows the geo-location data and email address for the user on the iPad, even if they never open app_B.

My take on the ideal iOS privacy solution:

• Apple forces opt-in for data collection and transmission for each app, including notification of what is being collected, why, and how it will be used (along with a link to the privacy policy governing the collection and usage).

• UDID’s are generated for each app on the device in a way that two apps on the same device can’t link their data.

• Apple develops a simple SDK to provide a privacy-enabled, blinded user account system, with ID’s unique per user per app (not per-device) so that it is as easy for developers to use that privacy-enhanced system as it is to use the UDID (removing the cost-savings argument for using a UDID).

I won’t hold my breath.