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."
What's That? (Score:3, Insightful)
What's that? Why, I think it's the sound of the other shoe dropping!
Re: (Score:3, Insightful)
Some people may not like this, but it doesn't seem that bad to me. After hearing that some Android apps report a user's physical location up to every 30s... this seems pretty tame.
Re:What's That? (Score:4, Insightful)
And phone number.
Unless Apple is helpfully giving out your name and address to go along with the UDID (which I very much doubt), it's just a way to see how many people are using your app.
Re: (Score:2)
how many unique devices it has been installed on...
Flipside5 does this with their apps, and when I swapped phones, even though I had done a restore (which transferred over all my other settings for everything else) I lost all my game status with them. Hence, based on UDID.
I didn't mind, but just thought it was interesting that was how they tracked uniques.
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.
Re: (Score:3, Insightful)
It enables things like that IF Apple weren't looking over their shoulder. Provided the app got past the approval process in the first place, someone would undoubtedly complain to Apple. Apple would then yank the app from the store and offer everyone refunds. Oh, and as a developer when you give a refund YOU give a refund. Apple doesn't give back their 30%.
So no, nobody's going to do anything that stupid.
Re: (Score:3, Informative)
The summary was specific to the top FREE apps. What do you expect they are going to refund? Why are we discussing locking it to one device? They are already free for all your devices. Its about tracking, pure and simple.
Re: (Score:3, Informative)
Re: (Score:2)
All right, Apple may or may not give back their 30%. Maybe not if they're pissed at you for fooling them, breaking your agreement, screwing their customers and refusing to fix it.
Am I not full of it now? Is your pedantry satisfied?
Re: (Score:2)
So no, nobody's going to do anything that stupid.
Why is it that those words always fill me with dread?
Re: (Score:2)
Have you ever purposely screwed over your customers and Apple and refused to be reasonable about it, as suggested by the OP?
I'm an iPhone developer too, and Apple does reserve the right to make you pay the whole refund amount.
I doubt we're supposed to post excerpts from the actual contract, but the relevant one is reproduced here:
http://techcrunch.com/2009/03/25/apples-iphone-app-refund-policies-could-bankrupt-developers/ [techcrunch.com]
You can check it in your own distribution contract in iTunes Connect.
Re: (Score:2)
It's not stealing if you explicitly agreed to let them do it. Which you did, if you're developing for iOS.
Apparently. I assume they have weighed up the potential profits from a captive audience of iPhone/iPad owners against the potential downsides of Apple's draconian policies and have calculated that they'll still make a nice profit even if Apple are dicks.
I mean, iPhone/iPad owners are the per
Re:What's That? (Score:4, Interesting)
Re: (Score:2)
Exactly. I call BS -- never heard of a developer doing this or attempting to do this.
Re: (Score:2)
That wouldn't help the dev very much, given that you can purchase any app only once on a single appstore account.
Against app rules (Score:2)
No but it enables douchebaggery like LOCKING the app to one device.
Specifically not permitted by application developer guidelines. In fact if you support things like in-app purchase, you MUST make sure purchases transfer across user devices.
Re: (Score:2)
Wife? Is that what you call him?
Re: (Score:2, Funny)
Re: (Score:2)
If you're running google maps on your iPhone or Android phone, it does this. This has been mentioned lots of places, when they explain how the maps app gets the traffic data. It gets the data from the phones, of course, which are reporting their position and speed back to a google server every so often,. The green/yellow/red/black color coding of roads is just a summary of how the phones on those roads are moving. It would be sur
Re: (Score:2)
Actually, no, it gets the data from the same place that all traffic maps get data from. The radio network that transmits traffic.
The data would be so incomplete from phones (as you have to have the app running) that it would be useless as a measure of traffic.
Re: (Score:2)
OTOH, if a traffic app were to do both, that would give more data than either alone. I can't be the first programmer to have had that thought. ;-)
In any case, there have been many reports that google maps is collecting some of the traffic data from phones running their software. Here's one of the earlier stories [jkontherun.com] that a quick google search turned up, from about a year ago. It's not hard to find other stories about this topic. This story has the additional comment that, at the time, the iPhone was unusual
Re:What's That? (Score:5, Informative)
The UID identifies the iPhone within XCode. It enables things like authentication without passwords for (trivial) applications. For example if I have an app with profiles, and that app is only usable on the iPhone, there is no need for a password or login, I can just use the UID.
Big whoop.
Re: (Score:3, Insightful)
Your big whoop amounts to someone data mining more stuff about you. You give up too easily protecting your information particulars. If you don't sweat them, they'll steal more.... and maybe already have.
Re: (Score:2)
That's IF they can steal more. So far, they can get your device ID, and access the address book.
I'm more concerned about the address book than I am about the device ID.
Given the APIs, that's probably about all they can take from you.
Re: (Score:2, Insightful)
SO they get a DID, a Mac address, an IP. They follow you around. Maybe they decide to go into various Java cache and sniff around if they can. Java cache locations aren't tough to figure out. There's more than one way to skin a cat, or a bad Java app.
Re: (Score:2)
Your big whoop amounts to someone data mining more stuff about you. You give up too easily protecting your information particulars. If you don't sweat them, they'll steal more.... and maybe already have.
So if this unique hardware device ID didn't exist, my app could generate a GUID (random 128 bit number) the first time it's run and use that as the unique ID on every internet request to my server? What's Apple going to do... prevent apps from using numbers?
Re: (Score:2)
Not necessarily.
The idea is to have applications STFU unless it's called for.
No random hey, here's the latest scoop on 0x38df803's location, the local temperature, and the last nine people she called.
Hey, look! She's on FB again, and just ordered something from Amazon. Upload to the mothership analytics engine NOW!
Wait, she's going to use us! Get ready to make the fart sound!
Re: (Score:2)
Hey, look! She's on FB again, and just ordered something from Amazon. Upload to the mothership analytics engine NOW!
Right, so the risk is cross-app and cross-site correlation, not the fact that a single app can uniquely identify each device it's installed on.
Re: (Score:2)
As the developer of a hacky (and permanently broken since 4.0) iPhone call log application, I can tell you that the iOS API does not allow an app to access the recently called list. And the local temperature is no trick, since it's an f() of the location.
Re: (Score:2)
The UID identifies the iPhone within XCode. It enables things like authentication without passwords for (trivial) applications. For example if I have an app with profiles, and that app is only usable on the iPhone, there is no need for a password or login, I can just use the UID.
Big whoop.
It may not be a big deal to you, but it sure is to me. Particularly given how atrocious the terms of their license are when it comes to privacy. They can, and do, track you and your physical location at all times, and can do anything they like with that information.
In my view, it's bad enough that they are so cavalier about personally identifiable information int he first place. It's even worse that such information is readily available to random app developers.
This is a showstopper.
Re: (Score:2)
Mobile phone networks know your physical location, near enough, with any mobile phone you might use. Apple doesn't. The iPhone doesn't "track you and your physical location at all times". Only when the application being run requests it, and the
Re: (Score:2)
The security model of both phones is quite different. iOS is based on digital trust (only downloading signed authorized apps from the appstore), android's model is permission based (although the default market could count as authorization as well).
If a free game is requesting permission to use my GPS coordinates or to use maps, then I simply don't install it.
Re: (Score:2)
Re: (Score:2)
I don't know, but it probably looked like this [childcostumes.com]
More like the shoe is in your mouth with foot (Score:2)
What's that? Why, I think it's the sound of the other shoe dropping!
Honestly, you are equating the release of a phone number and constant GPS feed, to a UDID that had no identifying information about you and is only used to detect if the same device is returning to a server? Really?
And? Care factor zero (Score:2)
The iPhone's UDID identifies my iPhone, not me so I don't see the problem. Some developers just want to see how many devices apps are installed and in active use on.
Re: (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.
Re: (Score:2, Insightful)
Re: (Score:2)
MAC only survives one hop.
Re: (Score:2)
Re: (Score:2)
I'm a lot less worried about DoubleClick having a cookie on my computer than I am about a piece of software that grabs my phone number, physical location, my contact information, my contacts' information, the contents of my drive....
Re: (Score:2)
Not much of a story although I do block call-homes with FirewallIP from the Cydia Store.
Re: (Score:2, Funny)
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".
Re: (Score:2)
Re: (Score:2, Insightful)
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.
Re: (Score:2)
I'd say that the two sets are fairly distinct. While there are iPhone using Ubuntu users (myself included), I'm guessing the majority on each platform wouldn't use the other. Ubuntu users are going to in general be more libertarian leaning and privacy minded than iPhone users.
That said, I personally feel the opposite. Ubuntu collecting that data doesn't bother me at all, and I definitely see the value. App developers doing so makes me a little bit uncomfortable, but I see the value in it to them too.
If you read the paper... (Score:3, Informative)
Re: (Score:2)
You must be the Cookie Monster.
Most cookies are unique values to identify you to web sites, and therefore also to ad networks. The more info about you that can be associated with that ID, the more they can specifically target you.
The UDID might be a value that's random, but if ad networks can tie your usernames to the UDID, then they can uniquely identify your phone as you, and tie that to the targeted information.
Re: (Score:2)
Target me?!? Oh no that sounds bad. That sounds like a hit man or something. Oh noes!!!
Wait, you mean they're going to use the information to display adverts for things I might actually be interested in, rather than random stuff I'm not interested in. How does this harm me again?
No hit man?
Re: (Score:2, Informative)
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.
Re: (Score:3, Insightful)
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.
Re: (Score:2)
I know you find it hard to distinguish one thing from another and don't RTFAs, but the Android apps which were the topic of that discussion were sending phone numbers from your address book. Which you might not realise is a different thing from the UID of your phone.
It's perfectly reasonable, and allowable under both developer and user agreements for apps to send the UID to a server for the purpose of distinguishing one phone from another. It's not reasonable, nor allowed, to send user data, such as phone
Re: (Score:2)
I know you find it hard to read comments, but some of the apps mentioned here send your name in plain text along with the UID, making the UID into an alias for your name. Perfectly reasonable when it's done with Apple's products, of course, as the limits of the reasonable moves along with them.
Notice how you go from full attack mode to full defensive mode along with corporate loyalty. You're a pathetic excuse of a human being.
Re: (Score:2)
I think the problem is that most people are reading this as "apps are sending off the UDID" and going "eh, who cares" because the UDID doesn't have any real inherent useful meaning outside of iOS development provisioning. Even when they read that you can associate the UDID with a real name somehow (as in the Amazon and CBS apps), they still see UDID isn't really useful data. All you know is "this hexadecimal value -- which, for all practical purposes, may as well be random -- is Joe Public." If Amazon ge
Re: (Score:2)
If I'm logged in, they already know my name. I wanted them to have it.
Re: (Score:3, Informative)
You can set a default per-app in the Location Services option screen.
Re: (Score:2)
Re: (Score:3, Informative)
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
Re: (Score:2)
Without using Location Services (and asking permission) apps have no access to anything involving the Wi-Fi SSIDs surrounding you.
I guess you haven't seen some of the new APIs in iOS 4.1/4.2, have you?
Re: (Score:2)
I have. If you're referring to what I think you're referring to, you still can't access the network settings to actually scan for SSIDs. You can get the CURRENT one, but that's it. That might identify the device's position. Maybe. Wifi location services generally require several SSIDs for a location.
It's a lot less of an issue than sending GPS coordinates back to the server.
Re: (Score:2)
Re: (Score:2)
Oh, that's OK then. That's totally secure. It's not like 99% of all computer users blindly click "yes" on every dialog that appears without so much as glancing at the message or anything.
Re: (Score:2)
You're right, that is a problem. And the problem is even worse with Android, that asks for such permission at install time, before the user knows why the app might need the permission. iOS at least asks at the time the first request is made, giving users more of a clue why the app is asking.
But iOS has a further line of defense. The one stop App Store. Badly behaved apps may be caught in the approval process, and if the do make it on to the store, can be removed again if user complaints come in.
The much v
As a developer thinking about such things ... (Score:2)
That could be done just as easily without sending the UDID.
Agreed. I would use a hash of the UDID.
However for some circumstances I don't think the developer needs any sort of device ID. For example I have a scientific and hex calculator app [perpenso.com], other modes are about to be released. I would like to get some usage data showing how much use the various modes get. I've considered adding counters that indicate how many operations are performed in each mode and sending these counters to a server periodically. All I want is aggregate data, I don't need any device ID in th
Re: (Score:3, Interesting)
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.
Re: (Score:2)
Steve Jobs rapes ninjas???
Seriously though, you must be new here if you expect the Slashdot crowd to bash Apple about anything. That's almost as bad as asking them to admit that Linux has a few flaws.
Disclaimer: I like Linux and run it on several machines as well as in VM's. Just sayin'...
Re: (Score:2)
Bashing Apple has been OK for some time, but there's still a very vocal minority that goes into full denial every time Apple does something objectionable. Like most of the first comments here.
Now that it's out there (Score:2)
I except to see a cydia patch in the new few weeks.
Re: (Score:2)
Re: (Score:2)
I except
Coding something that has to do with exceptions lately? I think you meant to say you expect.
Well, probably NOT a problem (Score:2, Interesting)
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.
UDID does not identify a user (Score:2)
Re: (Score:2)
Good point. I hadn't considered the multi-device situation for a single user. Like I said, it's all very preliminary ideas at the moment (having started work on any of the implementation yet).
Re: (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
Re:UDID does not identify a user (Score:4, Informative)
Re: (Score:2)
So? The point is to have something to fill in for a default of a field that 99% of the users won't ever even see.
If it ever needs to be changed, the user gets to pick something much shorter and more meaningful to them.
Re:UDID does not identify a user (Score:4, Insightful)
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.
Re: (Score:2)
Sounds more like a typical Linux UI than the sort of user friendly UI iPhone apps should have. Hex digits should never be displayed, especially not a scarily l
Re: (Score:2)
Perhaps we need something like OpenID for Apple iOS. Not that I care much as I don't plan on ever owning an iOS device. I'll wait for a capable Linux based tablet, and unless they put a real keyboard on the iPhone I won't be going there either. Still, maybe that's another project you could look into.
Re: (Score:2)
... unless they put a real keyboard on the iPhone ...
Bluetooth keyboards work. I think there is at least one case that accommodates both.
Re: (Score:2)
Have an username and password, and give the user the option to "automatically log in when connecting from this device".
That way you get the good sides of both implementations.
Re: (Score:2)
Re: (Score:2)
Using the Apple ID would help there, but I guess you can't access that from an iOS app.
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.
I guess I don't see a huge issue, really? (Score:2)
For decades now, your network cards all had unique MAC addresses which could theoretically identify you, too. So what?
It only identifies the particular piece of HARDWARE as unique. It doesn't prove anything about WHO owns the device, or even who is actually operating it at a given point in time.
Any privacy issues only come up because of specific implementations that do "bad" things. Anger at the hardware maker for including some sort of unique ID with the device is misplaced, IMO.
(You know, kind of like
Re: (Score:2)
I see nothing wrong with collecting UDID's, we do so to identify devices with APNS.
Just FUDD.
Is there a difference? (Score:5, Insightful)
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.
Same thing? Really? A test for you. (Score:2)
iPhone and Android. Two peas in different pods.
Really? Here's a test. Here's my actual iPhone UDID:
cf3e2f8e6515207d5d93ac315a8e07081d2ac3d9
Now you post your phone number and current GPS location as the Android apps were recording and we'll see how much each can find out about the other.
Push (Score:2)
How is this different than registering the Apple device with the app for Push notifications? The article is pretty thin on details and the PDF is kinda slashdotted. Granted, push access requires the user to agree to it via a popup on first launch.
it's all good (Score:3, Informative)
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.
Blown out of proportion (Score:2)
Bah, this is blown out of proportion a little bit. The UDID, by itself, tells a developer nothing about YOU. Its use is documented and encouraged by Apple for tracking user devices (which TFA admits). Now sure, if I were to also grab your address book I can tie that to your UDID, but it's my grabbing your address book that's the problem, not the UDID. I suppose if Apple wanted to make this more secure they could make the API automatically hash the UDID with your Application ID (also unique) and return that
Pandora (Score:5, Informative)
Re: (Score:2)
Happened to me, too. You can change your Pandora password 'til the cows come home, and the old phone will still be able to login!
Best part is, Pandora keeps their UDID databases inaccessible from your account, so you can't just login to Pandora and see the device(s) associated with that account. You have to email Customer Service and ask them to delete all your devices, whatever those may be. Happens on their (paid) desktop client, too. I put in a feature request to make our devices available in our account
Jailbreak FTW (Score:2)
This isn't a new problem - I think /. reported on it a couple of years ago. Sure it wasn't a UDID, but it was the phone number or other more identifiers. ICCID and IMEI is probably more risky to leak out - the UDID doesn't really tell you much of anything. It doesn't tell you the phone model, the user's phone number (which can change), ICCID, IMEI, etc. unless it's purposely linked. All it identifies is the particular piece of hardware.
And naturally, jailbreakers have solutions for all this.
First, there's U
most apps are likely using it for analytics (Score:2)
So what? (Score:2)
UDIDs are commonly used in order to estimate how many users an application has, especially on applications that don't require people to register an account.
Tons of web sites and ad servers are also sending cookies for this very purpose. It's not bullet proof, but it's better than nothing.
UDIDs can be also useful in order to block users (spammers, people sending illegal content, etc) on social networks, as it's more difficult to buy a new device that it is to create a new account.
Re: (Score:2)
OH YES (Score:2)
Mine too. I just came in here to gloat and feel smug as fuck about how this won't happen on my Maemo device, as pretty much all of my apps are open source, and I can see what's going on anyways with tools like ps, top, netstat and whatever else I can make run on my device. Because I have root access. That makes me the fucking boss.
Decision to choose Maemo over Android: 100% ~Vindicated~ B-)
Now excuse me while I put on my pimp suit and strut around to some 70s-tastic beats.