Apple phasing out developer access to the UDID in iOS 5

http://techcrunch.com/2011/08/19/apple-ios-5-phasing-out-udid/

by canistr • 15 years ago

128 62 15 years ago

llambda• 15 years ago

So does this mean things like TestFlight will no longer work?

justinvoss• 15 years ago

I'm sure Apple will still use the UDID for provisioning. This change sounds like they're removing access to it from the device API.

sumukh1• 15 years ago

Testflight seems to be grabbing UDID's to identify users. You still need to get UDIDs in your provisioning profiles though. It'll make beta testing harder since users will have to use itunes to get their UUID. I'd love it if Apple would let users see their UUID and email it.

spearo774• 15 years ago

What happens to analytics companies like flurry??

lawnchair_larry• 15 years ago

Hopefully they disappear. But, probably not.

nhangen• 15 years ago

Why would you want them to disappear? I have Flurry installed in my apps to help me identify usage patterns, and see which types of people use my apps. I don't think there's anything wrong with that.

metachris• 15 years ago

Shouldn't make much of a difference. It's more useful for services tracking users across several apps and building profiles without their knowledge (eg. most ad networks).

saurik3• 15 years ago

Yet, there are other ways of implementing this, from "nice" things like UIPasteboard coordination to "nasty" things like hiding data in AddressBook: it doesn't really affect these developers at all.

sirn• 15 years ago

There was this one time when I restore my iPhone without using backup, one application restored all my favorite items without me ever input anything into the application. There's no mention of this "feature" in their product page as far as I found find. While it's useful, it's rather scary that this could be done completely without user acknowledgement.

IMHO, removing UDID access is good, though I would prefers if they introduce something similar to Location Service and let me whitelist which app to allow reading UDID.

sanj4• 15 years ago

There are legitimate reasons to ask for a phone UDID -- namely tying together information from multiple applications. GameCenter does this, but only for a specific subset of games.

Is someone going to come up with another fingerprinting mechanism?

The obvious approach is to use the MAC address:

http://stackoverflow.com/questions/677530/how-can-i-programm...

spearo774• 15 years ago

If you have a suite of apps (free/paid) or that work together in a meaningful way, you can use a unique pasteboard to persist shared information.

If you did that for advertising reasons, I'm sure Apple would reject/revoke the apps once they found out about it.

sanj4• 15 years ago

Would that persist across resets?

wvenable• 15 years ago

> namely tying together information from multiple applications

That is not a legitimate reason. If I want my applications tied together I'll manage that myself.

stephth• 15 years ago

Another example of legit usage of UDID: TestFlight.

axiom• 15 years ago

This will result in a lot of broken apps in the app store.

danilocampos4• 15 years ago

Why?

edit: Seriously, Why? And why the down votes?

The API is deprecated, but so far not removed, there's a lot of lead-time, and iCloud is going to exist for user identification.

Are there truly that many apps whose assumptions are so brittle and developers so absent that this change will break them?

(Unless OP meant business models assumed in apps that need to identify everyone, even if they don't want to. That's valid, if less interesting.)

coffeedrinker• 15 years ago

Because developers have used it ID to store user information on servers, etc.

This allowed a simple way to keep user data without worrying about additional setup, username, login, etc.

If it is gone (and not merely deprecated) then developers need to get an update out now that can read the ID and cross reference it to other code.

Otherwise, all settings that might be stored by a user on a server will be lost if the developer relied solely on using this ID.

Zev2• 15 years ago

No, it won't. This is a deprecation. The API will still be there, and it will still work. Using the API will now have a compile-time warning that developers will see.

At some point — far off, in the future — the API might be removed. But, keep in mind: there are APIs that were deprecated in iOS 3 that Apple still keeps around for compatibility purposes.

ethank• 15 years ago

I think that this is mostly to force people toward AppleID/iCloud as a universal method of authentication, as well as a reaction to the Germany and South Korea lawsuits over location data.

It makes sense that Apple wants iCloud to be the defacto method of cross-device and application authentication.

In my time doing iPhone apps in the music business, I had many ideas of how to use the UDID for aggregated statistics and data, none of them entirely holy from a "own your data" perspective.

So mixed: as a product developer, the UDID was handy to have. As a consumer, I would rather my AppleID (something I can change/cancel) be tied to it.

kennywinker• 15 years ago

Sounds good. Show me how to use iCould/AppleID as authentication in my app.

Oh, wait... you can't?

Mostly kidding. Deprecating the UDID seems like a good thing, as the #1 use was advertising. It'll be annoying for developers, but not that bad... you just assign a UUID on first run. No big deal.

gte910h2• 15 years ago

If you're talking about the NDA, yes, that's true. But Yes, go read the iCloud docs, I think this is the point of this as well.

sanj4• 15 years ago

I'd find this laudable if the AppleId was something that was programmatically accessible. It doesn't appear to be.

danilocampos4• 15 years ago

Does it need to be? Store a unique identifier to the AppleID and use it to look up the account as needed.

seanalltogether• 15 years ago

I can understand the desire to discourage people from tracking the device itself, but this really has to be used unless Apple decides to provide a way of identifying the user of the device.

danilocampos4• 15 years ago

They have – it's called iCloud.

http://www.apple.com/icloud/

spearo774• 15 years ago

Remember this is deprecated, and not yet removed. TestFlight and UDID Sender etc all still work fine on the current betas of iOS5

jayfuerstenberg• 15 years ago

There should be a permissions-based access to it in my opinion. The same way that your current location is allowed to be viewed by the app.

My app (KEYBOX lite) uses UDID to help thwart cheaters who reinstall the lite edition and simply reimport their data from an earlier install. I know I'm the exception and not the rule but if I could ask for the permission to use the device ID in the lite edition I could still do this.

jazzychad• 15 years ago

I guess this will be a great new feature for Parse to offer iOS devs.

notphilatall• 15 years ago

It's a shame, because UDID-based user blocking has been quite effective for a lot of apps and communities. I suppose users could authenticate via iCloud, and Apple has an interest in users doing this, but it's a bummer for UX.

blasdel• 15 years ago

That's ingenious — per-device permabanning!

trotsky• 15 years ago

I wonder if google will feel any pressure from this decision to at least separate out the "phone state" and "phone identity" permissions. Given their advertising focus it seems unlikely that they'd remove it entirely, but at least make app developers be up front about what they're requesting. It's too easy to blame that permission on needing to pause/mute etc. during a phone call currently.

plusbryan• 15 years ago

One thing that Google did well when building their platform is integrating permissions into the install process. Like Facebook's OAuth permissions, users understand how to interact with this. Don't care about ads tracking you but want more features that rely on tracking? [x] Allow tracking.

If Apple took a page from their book, they wouldn't need to take such drastic action, but instead let developers decide if users want the features that require those permissions.

comex• 15 years ago

There is no "allow tracking" button: the user gets a list of required permissions and either installs the application, granting all of them, or doesn't.

antrix• 15 years ago

FWIW, Google discourages the use of UDID as a 'unique user id' and recommends these alternatives: http://android-developers.blogspot.com/2011/03/identifying-a...

laconian• 15 years ago

Good stuff. Let me as the user dictate the terms for how I am identified.

bnycum• 15 years ago

We are using the UDID as an extra precaution in an app currently. The user logs in with username, password and UDID. If the device is stolen the UDID for that user's device can be easily removed. We are dealing with sensitive data that needs a killswitch when things do go wrong. Guess we will have to come up with a new approach.

nitrogen• 15 years ago

You could just store a randomly-generated authentication token on each device and allow the user to revoke any/all authentication tokens after entering their username/password in the app or on a website, if that's not what you're doing already.

saurik3• 15 years ago

The UDID is a SHA1 of a few other identifiers, such as the MAC and Serial #. What Apple should just do is include the base Application bundle prefix (whatever the thing is that is used to give applications shared keychain access) into the mix as a per-application-suite salt.

Aqua_Geek• 15 years ago

I completely agree. You should file an enhancement request.

There are so few legitimate reasons to have access to the UDID in the first place - I was surprised Apple even allowed it. An app- or app suite-specific identifier, though, could be very useful (and would work perfectly as a replacement for a number of the cases about which people are complaining).

mtogo• 15 years ago

Wow, this is really fantastic news. I've always been annoyed at the huge privacy vulnerability developer access to UDIDs posed.

ansy2• 15 years ago

Now Apple just needs to do something about the address book and we're good. I don't particularly like any random app having silent, unrestricted access to my entire address book. It's only a matter of time before we find out some super popular free app has been sucking down contact lists and I don't trust the Apple review process to protect users.

There should be a "this app is trying to access your address book" notification and per app permissions in Settings just like Locations and Push Notifications.

nostromo• 15 years ago

> It's only a matter of time before we find out some super popular free app has been sucking down contact lists

I believe that moment already came and went when people discovered the sync feature on the iPhone Facebook App sent all of your friends' phone numbers to Facebook. (https://www.facebook.com/friends/edit/?sk=phonebook)

For the record, finding this didn't particularly bother me and I did approve it -- however unwittingly. (I thought I was just pulling info from facebook, not sending info back.)

ansy2• 15 years ago

Facebook has a responsibility to do the right thing or lose a lot. It has executives, investors, and assets which are all exposed to lawsuits and criminal investigation.

A dude in Thailand that makes a free "Angry Birds Cheats" app does not have a lot to lose. In fact he could probably get away with putting something up on the app store with a stolen identity. The app could suck down millions of people's address books with real names, real birthdays, real phone numbers, real addresses, a network graph, and maybe more completely silently. You know the network activity indicator doesn't even activate unless it's flipped on and off programmatically? Best case scenario Apple finds out, takes the app down, and tells the Thai police to go find the guy? Good luck with that. Worst case scenario nobody even notices and the app disappears after sinking off the charts.

There is zero consumer protection against the latter and quite frankly the former shouldn't be an issue to begin with either. Facebook was getting away with it without getting caught. How many of those other high throughput apps that aren't from Facebook receive the same scrutiny from the public and researchers?

mahyarm• 15 years ago

Our app asks explicitly when you first download it. It won't work much without it although.

pkaler• 15 years ago

UDID has been deprecated because iOS 5 supports a general purpose credential store. Instead of reading a UDID, an App drops an identifier. Very similar to how a web app would drop a cookie.

The token can be shared across Apps using oAuth. This is how Twitter integration works.

So, for Apps that use Flurry, Flurry would drop an identifier into the credential store. Then Apps would access this identifier using an oAuth token and token secret.

If you have access to the iOS 5 docs take a look at ACAccount, ACAccountStore, ACAccountCredential.

sanj4• 15 years ago

I can imagine OAuth being used to allow Twitter integration, but it doesn't really make a lot of sense as a mechanism to lock down identifiers on a single device.

The point of OAuth is to give a new web app access to data in an existing web app without giving up your password -- instead you enter your password into the original app and the new app is given a token with which to retrieve your data.

It makes complete sense for Twitter integration: you provide your Twitter password to Twitter and the iPhone ends up with a token it can use to access/post Twitter information.

I'm not sure what OAuth would be protecting when you've got multiple apps on a single device: would a user have a Flurry password that they'd enter into the Flurry app to provide access to the Flurry identifier to XYZ.app? Why would you want to do that?

Zev2• 15 years ago

While that may functionally be a replacement for UDIDs, that is not the intended purpose for those classes. They're supposed to do a lot more.

graiz• 15 years ago

I run a company called http://www.AppBlade.com and we provide a service to do OTA (Over the Air) installation. This OTA technique is the Apple recommended way to do secure wireless installation for enterprises to a specific hardware device (via UDID.) Anyone with access to the latest betas can try it and see that yes it still works.

dendory• 15 years ago

The main use (as far as benefiting users) for the UID was so that you could install an app on your iPhone, and without ever using any kind of username/password it knew who you were and restored all your data. Of course it also meant ad networks could track you as well. So overall this is a good change, just kinda weird it comes in so late.

pilif• 15 years ago

When we were writing an iPhone client for our web application, we were considering using the UDID as part of the authentication dialog with the server to allow for easy removal of devices if they get lost and to never have to re-prompt the user for their password.

In the end though, we decided against the UDID and just generated a random "installation id". This works much better in all regards:

1) when the user updates their device by applying an old backup to the new device, the app would continue to work exactly as before.

2) if the user wipes and sells their phone, the next user wouldn't automatically get access to the webapp if removing the device from the app was forgotten.

3) when something goes wrong and users try to reinstall the app, the user experience will be pristine, the server wouldn't know who you are.

4) the sometimes privacy sensitive UDID is never transmitted over a network.

5) it's not using deprecated APIs :-)

xsmasher• 15 years ago

What happens if two installs get the same random ID? Doesn't the new user log in as the old one?

Getting the UDID+installID and then saving that into a file/preference would work, or installID and username.

beder• 15 years ago

I'm doing this too, and we're using a 128-bit random GUID, which has an unfathomably small chance of being a duplicate.

tptacek• 15 years ago

This is a good thing; you wouldn't know it because you don't install a lot of enterprise iPhone apps, but UDID "abuse" (ie, broken security systems that pretend the UDID is something akin to cryptographically strong) is one of the top 10 security things that go wrong with iPhone apps.

I'm not sure I can think of anything the UDID does that you can't do better yourself.

incosta• 15 years ago

I have been using UDID to track on how many physical devices my app has been installed. In part - to see if there is any piracy (a spike in new devices would certainly mean something is going on).

If Apple removes support for UDID completely, I will have no way to track this information. Generating unique ids randomly will result in new ID being created when app is deleted and then reinstalled (something that happens all the time with iPhone apps). Are there going to be other ways to create unique ID based on some hardware specs, or Apple will provide a new function call?

tobylane• 15 years ago

Is this related to the hardware identifiers? When you sync any mobile Apple device to a computer it keeps some data, such as phone numbers, IMEI numbers and what I think is the UDID, which is all the ipod has. We need some replacement, if only to help the police track stolen ipods.

Apple phasing out developer access to the UDID in iOS 5

Related Stories