Privacy and iPhone/iPad/iPod touch Unique Device Identifiers (UDIDs)

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.

This entry was written by Lie Njie , posted on Monday October 04 2010at 12:10 am , filed under Corporate Principles and Philosophy, Marketing Mobile Applications, Mobile Applications, Privacy, WasteNot and tagged , , , . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

4 Responses to “Privacy and iPhone/iPad/iPod touch Unique Device Identifiers (UDIDs)”

  • Lie Njie says:

    Here’s a description and link to Eric Smith’s paper about UDIDs, as mentioned above:

    http://www.pskl.us/wp/?p=476

    iPhone Applications & Privacy Issues: An Analysis of Application
    Transmission of iPhone Unique Device Identifiers (UDIDs)

    by Eric Smith
    October 1, 2010

    Abstract

    Every Apple iPhone shipped since its introduction in 2007 contains a
    unique, software-visible serial number — the Unique Device
    Identifier, or UDID. Apple provided this functionaly to allow
    application developers to uniquely identify the iPhone being used for
    purposes such as storing application preferences or video game high
    scores. While the UDID does facilitate the process of collecting and
    storing certain types of data, it also creates a tempting opportunity
    for use as a tracking agent or to correlate with other
    personally-identifiable information in unintended ways. In this
    paper, we investigate where and how UDIDs are being shared, with
    whom, and how the UDIDs are being used.

    http://www.pskl.us/wp/wp-content/uploads/2010/09/iPhone-Applications-Privacy-Issues.pdf

    —– End forwarded message —–
    _______________________________________________
    privacy mailing list
    http://lists.vortex.com/mailman/listinfo/privacy

  • ED Fochler says:

    Comment 1: I know Eric, he’s an awesome guy, and his paper is well written.

    Comment 2: I agree with points 2 and 3 in your conclusion. It’s all about the SDK. Apple won’t degrade the user experience by filling it with pop-ups, alerts, and confusing choices. But there’s no reason that UDID’s should be capable of linking across apps by different developers.

    I think the UDID generator should hash as a function of the cryptographic signature of the publisher of the software. New versions and obvious follow-on games/apps by the same publisher should logically receive the same UDID.

    Comment 3: I’d like to have pages of apps with security restrictions. Page 1 allowed to access network and my address book. Page 2 just network. Page 3 no network, no address book. Some sort of obvious and logical sandbox grouping must occur as these apps become more powerful. I’m willing to put up with more work to ensure proper security than most though, so this idea is probably not commercially viable outside the NSA and DefCon. Yet.

    • Lie Njie says:

      Great comments — thanks!

      But there’s no reason that UDID’s should be capable of linking across apps by different developers.
      Agreed — and I think your hashing algorithm is a good first step, although IMHO developers shouldn’t lose the ability to store customer preferences if they lose their private cert. Instead, I think the hash should be based on (1) the customer’s iTunes account (so the resulting ID is the same across devices for the same user) and (2) a unique ID generated for each App (that stays the same for upgrades). This way the ID is the same for all versions of an app on all devices for the same customer, which is what the customer and the app developer both would find ideal.

      I’d like to have pages of apps with security restrictions. Page 1 allowed to access network…
      I think pages would be too hard to manage. Instead, something similar to how location services work now (iOS 4.1) would be good — I’m asked the first time, I grant/deny permission, and then I can go in and change it later if I need to (but rarely do). They’ve got the system in place for location because you have to use the CoreLocation framework and the legal risks of leaking geo-location data without a customer’s permission are HUGE (stalkers, etc). What they need to do is push access to the rest of the personal information through a similar framework. Won’t happen fast, if at all.

      I’m willing to put up with more work to ensure proper security than most though, so this idea is probably not commercially viable outside the NSA and DefCon. Yet.

      I’m with you but we are in a group that is by far and away a tiny fraction of a percent of the total user base.

      Probably not commercially viable *ever* unless there’s some sort of widely publicized “data valdez” that forces people to start to care, but even then, I’m not sure they will do anything unless there’s a financial incentive in it for them.

      So, the question becomes: what kinds of financial incentives would motivate the majority of iOS customers to (1) care about the privacy of their data, and (2) demand privacy controls?

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>