Many Top iPhone Apps Collect Unique Device ID

An anonymous reader writes "It looks like iPhone users are not immune to the types of data leaks recently discovered on the Android platform. Researchers looked at the top free applications available from the App Store and discovered that '68% of these applications were transmitting UDIDs to servers under the application vendor's control each time the application is launched.' The iPhone's Unique Device ID, or UDID, cannot be changed, nor can its transmission be disabled by the user. The full paper is available in PDF form."

Re:And? Care factor zero

[Dynedain]

DoubleClick's cookies identify my computer, not me so I don't see the problem. Some developers just want to see how many computers browsers are installed and in active use on.

Well, probably NOT a problem

[zentechno]

As has been said, it identifies the phone, and not the user (though a majority of the time it'll be the phone's owner). Many apps use the UUID as a unique ID (ahem) to store state, e.g. viewed pages, favorites, etc. Yes, this is also done with a log in, or it could be done transparently via the UUID; not sure there's a best/worse here. I know -- it's the transparency that's the controversy, but I'm a bit pressed to think of anything that's revealed that couldn't also be revealed with (or without) "vendor collusion" (e.g. an App-to-UUID database to see which apps are on the same phone -- oh, wait, Apple knows that).

Re:What's That?

[Lumpy]

No but it enables douchebaggery like LOCKING the app to one device. Which is Against apple's Eula. If I have 2 iphones 1 ipod and 2 ipads on my single apple account I get the app on all those devices for one purchase price. Problem is many app makers are greedy assholes and want to make it only work on ONE device.

Recommended alternatives?

[swamp boy]

This article is very timely for me. I'm an iPhone developer who's planning to add a server component for some of my iPhone apps. My initial thinking was to simply make use of the built-in UDID since it's there and doesn't require any effort on the part of the user. I did RTFA and I can see how the use of UDIDs could lead to unethical situations.

On the other hand, what's the alternative? Generally speaking, an iPhone app that has a server component with functionality that's geared to a specific user needs something to identify that user. Sure, I could force the user to enter their email address or make up a user id. Unless a user goes to the trouble of making sure that each service/app they deal with uses a separate and distinct user id or email address, you're back in the same situation (or close to it).

I'm genuinely interested in hearing suggestions on the preferred mechanism that helps to maintain privacy.

Re:As a developer thinking about such things ...

[raddan]

I am a university researcher doing iPhone development as a part of our project. We use UDIDs to allow our users to control information exchange between themselves and other iPhone users. We could probably use a hash of UDIDs (really, you'd probably want a hash of a UDID and a salt if you're hashing) or maybe even some other identifier, but I'm not really sure what additional privacy that gains iPhone users. From our perspective, we track them either way. Is the concern that someone else gets our users' UDIDs and combines that information with other UDID information? We were thinking that UDIDs were a step up from username + password, since this allows participation with a minimal amount of information being collected.

Re:Recommended alternatives?

[alannon]

Additionally, Apple's documentation on the API that provides the UDID specifically indicates that Apple considers it appropriate to use as a method of identifying a user/device.

Of course, that doesn't change the privacy implications, but it indicates that the UDID is provided by Apple to developers for precisely that purpose.

Re:What's That?

[grub]

I've never come across an app that wont install for free on another iOS device (we have 4). What apps have done this? You should definitely report them to Apple is this is the case.

Re:UDID does not identify a user

[Jah-Wren Ryel]

Go with a user-editable field that defaults to the unit's UDID for username and also defaults to a reasonably unguessable password.
That way you have a sane default that user can change if they have a need to.
Make sure to include a brief help description of that field and its purpose so that the user will know that it need not be a bunch of hex digits.

Also, on the server side keep a unique "user id" that never goes to the phone - that way changing the username on the phone side doesn't result in a brand new account on the server side.

Also, watch out for collisions - don't want some poor schmuck changing their username to one that already exists and then being both locked out and unable to change it to something else.

Re:As a developer thinking about such things ...

[perpenso]

One of my concerns would be that having the UDID allows for more general impersonation. With a hash specific to a particular app the impersonation is limited to your app.

Another concern would be related to personally identifiable information (PII). When non-PII is associated with PII the non-PII now falls under all the PII regulations. If you use a hash you do not have to worry about what others at the university are collecting. Keep in mind that what constitutes an association between non-PII and PII may be defined by a hostile lawyer. Maybe your team's data being on the same server as another team's.