Many Top iPhone Apps Collect Unique Device ID 194
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 (Score:3, Interesting)
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 (Score:2, Interesting)
Re:What's That? (Score:5, Interesting)
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? (Score:5, Interesting)
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 ... (Score:3, Interesting)
Re:Recommended alternatives? (Score:5, Interesting)
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? (Score:4, Interesting)
Re:UDID does not identify a user (Score:3, Interesting)
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 ... (Score:5, Interesting)
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.