Slashdot Mirror
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."
What's that? Why, I think it's the sound of the other shoe dropping!
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
I'm out of my mind right now, but feel free to leave a message.....
Then they should set a cookie. We already went over this in the late 90s with the pentium 3. Universal hardware id = bad. Set a cookie unique to one company = good.
All iOS apps that ask for location info generate a permissions dialog.
You can set a default per-app in the Location Services option screen.
Trolling is a art,
The iPhone's UDID identifies my iPhone, not me so I don't see the problem.
Just wait... soon we will ALL have Apple's most important creation ever... the "iD".
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).
âoeThe wall between art and engineering exists only in our minds.â -- Theo Jansen
"We also confirmed that some applications are able to link the UDID to a real-world identity."
Hmmm... maybe we should ask Mr. Gathered Mass why he keeps changing his mind. Oh, what's that? You're talking about millions of *different* people holding *different* opinions? Wow, who would've thought! I think you've found the real story in all of this: apparently, not everybody feels the exact same way about different, although similar, events. Thanks for sharing this insight - you just blew my mind.
----
Not to be confused with Col.
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.
For example, Amazon’s application communicates the logged-in user’s real name in plain text, along with the UDID, permitting both Amazon.com and network eavesdroppers to easily match a phone’s UDID with the name of the phone’s owner. The CBS News application transmits both the UDID and the iPhone device’s user-assigned name, which frequently contains the owner’s real name.
Incorrect. Without using Location Services (and asking permission) apps have no access to anything involving the Wi-Fi SSIDs surrounding you.
And as for IP address...
WARNING! Your computer is broadcasting your IP address!
Be serious.
Incidentally, with rare exceptions, the IP address of your phone, as assigned from your carrier, is in a private IP range. If you're connecting to a server, which will then have your public IP address, do you really feel you have any expectation of privacy, as far as the server not attempting to map your IP address to a location?
iPhone and Android. Two peas in different pods.
The Internet is not secure.
Your phone company is not your mommy.
Software is more complex than humans can comprehend, and there will be holes in its behavior relative to your expectation, especially but not exclusively when you were not the one who wrote the requirements for it, but especially again when the people writing it want to leave avenues for future revenue growth.
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.
Sorry, but it has already been established in the discussion about possible privacy invasions in Android software that this can't happen on iOS. Because it simply can't happen.
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.
When information is power, privacy is freedom.
Unique device ID doesn't violate privacy whatsoever since there is no link to your name, address, etc..
It DOES however provide a great way of ensuring "trial" or "lite" apps handled by a server and doing what you intended in say limiting results or whatever.. it also is good for internal logs since you can refine your app by looking at how the app is used, both overall as well as individual patterns.
You don't need GPS, personal or any other information at all to provide LOTS of benefits and an IMPROVED app once you have a access to a unique ID that doesn't involve registering username or whatever as annoying websites do.
I think a credible business would disclose in an open way what server transactions are involved on a per-app basis and with our new server suite being rolled out I know we will provide a web page per app detailing this so it's all open and above board and the benefits given.
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.
The UDID is pretty long, doesn't really make for a good user name. This is an example UDID: 2b6f0cc904d137be2e1730235f5664094b831186
-]Phreak Out[-
Yeah, I noticed that with Pandora after my friend sold me his old phone (he had it wiped first). I downloaded Pandora and started screwing around with his stations because I thought they were just default stations Pandora gave me. They were basing access on the UDID.
So you have buttons that say "Use device ID" and "Select a Username". You don't have to actually display the ID.
Would also give you some data about how many people care enough to create a username rather than use the UDID.
On the server side you need to come up with a way to tie multiple devices to the one account if they use the UDID option. Possibly have a "link another device" option that has the server generate a code transmitted back to the first device, that they have to key in on the second.
I'm guessing that wasn't on their radar screen...