UDID is now UDIDon’t
- March 29th, 2012
- 30 Comments
There’s been a lot of rumors going around lately that Apple is rejecting applications that send out device UDIDs but there’s not been any direct confirmation from Apple that this is a new policy. Well this morning we just got that confirmation in the form of a rejection.
Now this isn’t a particularly big deal for us since we already had code in place, for Tweetbot 2.3, that removes the need for UDID. It was a simple matter of moving that code back into 2.2 and re-submitting to Apple. We had a fixed version updated and uploaded to Apple within 2 hours of getting this message and are once again waiting for approval. If you are an app developer and depend on UDID for any functionality it’s time to migrate away from it, sooner or later Apple will catch you.
Why did we use UDIDs? We used them only for our push notification services in order to be able to match up a given device to its push notification settings. This allowed us to restore push notifications settings after Tweetbot was deleted and re-installed. With this new change in place this is no longer possible, if you delete and re-install Tweetbot you’ll have to setup your push notification settings again. Your device’s UDID never went anywhere besides our push notification services and has never been shared with anyone.
http://www.secureudid.org/
Thank you for the update.
Funnily enough, however, if you did want push notifications to persist through deletions and reinstalls, you can still receive the MAC address of the WLAN interface and use that as a pseudo-UDID without Apple rejecting your app.
The way this reads, all you need to do to keep using the UDID is to prompt the user with a clear message that you are sending their device ID to your server only to use to sync with push notifications, per their request, and allow them to decline. Am I reading that wrong? Or is UDID completely verboten for use in all cases?
I guess I undestand why Apple is removing this. If I sell my iPhone today and the new user installs some app I already have and assumes its me it could restore some info that is personal.
Interesting to see a good example of where the UDID allows for a better UX. Love your work by the way, guys. I’m writing this in Tweetbot in a beautiful web view and couldn’t be happier. :)
@David it’s not 100% clear, but regardless the UDID is deprecated and will likely go away in iOS 6.0. So no point in putting in extra UI to prompt for something that has to go away eventually anyways.
Thank you for the UDIDon
Paul take a look at http://openUDID.org
let us know what you think. Maybe you wish to contribute as well
It looks like Apple is using very reasonable discretion. This is the first documented rejection I’ve seen, and in this case the app owner apparently didn’t have the appropriate privacy policy, and the unprotected UDID was being passed in a URL.
I know many more apps that have been accepted this week, all using various advertising and analytics tools.
Quick thought: Keychain entries persist after the app is deleted and reinstalled so you could put the app-generated ID there..
Hm, why aren’t you using iCloud to synch such settings? Or are there any users that don’t want the same config on iPhone and iPad?
Interesting and thank you for sharing.
Looking under Settings > General > About > Diagnostics & Usage > Diagnostic & UserData:
I see Apple uses the deviceid in awdd_* logs. (as of 5.1). The “Diagnostics & Usage” view does contain “Send” / “Don’t Send” options and an “About Diagnostics and Privacy”.
–Brian
I am curious, was the UDID that you are passing done in plain text? I noticed that you’ve blocked it out.
It would be interesting to see if Apple has an issue with the UDID being openly shared or if the function is called at all.
What would be the issue (despite being depreciated) for the UDID to be used internal to the application but never transmitted back as the exact UDID?
@Dave: Yes but if a user restores on a backup on a new phone there’d be two devices with the same ID
@MSt: Yes there are
@Lee: It’s encrypted via standard HTTPS/SSL
For those who are wondering: Yes, the URL gets encrypted in an SSL connection.
I don’t think this functionality makes sense. When I delete an app, it asks me “Deleting “App Name” will also delete all of its data.” To me, that means all of its data, including settings.
Ah, Dave beat me to it: Keychain entries survive uninstalls, so you could put your custom CFUUID there and look for it when (re-)installed.
$ grep -ZlR “UDIDON\’T” . | xargs -0 -l1 sed -i ‘s:UDIDON\’T:UDIDN\’T:g’
@Paul you could always put the UDID, or a hash of it, or a hash of it + the unique id in the keychain as well, which would allow you to detect restores.
Well. I think the presumption might be that, if you’re passing it along as plain text, then you’re likely storing it as plain text, too. Don’t see why performing standard hashing/salting/hashing on the UDID isn’t just done when transmitting it. And then stored that way, regardless of SSL.
Likewise, it seems inherently weak to simply assume UDID === user. Most implementations I’ve seen use UDID and some form of app-centric (i.e. user-defined and managed) ID along with it. This abstracts it from devices while retaining device specific settings. This could also facilitate migrating user info to a new like-minded device.
Finally, this is also one of the reasons settings syncing on iCloud has been made free to every iOS user.
’cause no one’s said it yet:
Oh no UDIDn’t!
Even over HTTP/SSL, it still makes sense that they rejected you. Having the UDID in any form of plain text is not good. A hashed version (even if just by itself) is substantially better/safer than the approach taken here. This was the case before grabbing UDID was depreciated, and even moreso now.
The fact that Apple was able to pull the clear text URL (inclusive of the UDID) shows the risks with the approach taken.
In one of my apps, I use the UDID in a URL when the app requests some data updates from my server. I just use it to tell whether I have thousands of users using the app occasionally, or a hundred using it constantly.
I would have hashed the UDID first, but Apple requires extra process for apps that use encryption (which hashing qualifies as a form of, according to the docs I could find). I’m not tying the UDID back to anyone else’s database, so my purposes are entirely benign.
Yes, I use SSL, though the argument that someone nefarious could sniff the UDID over the air and accomplish some dastardly deeds is unconvincing.
Thanks for the sharing this information….
Well, you could keep using it, simply by asking if the user if they wanted to send the UDID to your server to restore their push notification settings….
A very detailed and apt explanation for the topic. This post just opens up a lot of hidden layers. Thank you for the information.
Thank you for superb explanation. This another reason why I love you guys and your stellar work.
I agree with @David at the top that all you need to do is ask for permission. I’d call this the fallout from the Path app uploading data without user permission.
The company I work for all had 5 apps approved this week, all with UDID tracking through an ad service in and no rejections.
@Dave @markerrett asking for permission may be enough, its not 100% clear to me since Apple hasn’t come out and stated the exact details of this new policy.
That being said for us it was easier and much safer to just nuke it, we don’t need it for most normal uses of the app and it’s easier than risking another rejection.
@PaulHaddad yes seeing it’s being depreciated anyway, is just a good idea to get rid of it if your ready.
Seems a lot of reporting is hysteria, making developers panic and rush changes they don’t need. Hopefully not many people will break their apps because of this.