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.
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?
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.
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.)
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?
Couldn't care less. The fact that they did this without being clear and honest about it is more than enough to completely obliterate any trust they might inherit for having much to loose. Especially since this alone should be more than enough for them to "loose a lot".
There is absolutely zero consumer protection against facebook as well.
And then you take into account that people most likely have had secret phone numbers in their contact list, what facebook did/do should be a criminal offence, especially considering they are a large corporation and exploits the inherited trust from that.
I work at Facebook, but I am not involved in that team and from my perspective it looks like an honest attempt is being made to help people understand what is going to happen, and I don't see any "getting away with it without getting caught" going on.
I'm totally with you on how much of a problem this could be when someone is actually attempting to be malicious. I think Apple should probably protect the contact database in a similar way to how it protects your location from applications. It doesn't prevent an app that ostensibly is using your contacts for some good purpose (and getting your permission) from using it for bad ones, but it does reduce the likely distribution/success of the application.
The increasing prevalence of warnings and confirmations when signing up for a site, when downloading/connecting applications, or when enabling features has encouraged people to skim these attempts to educate them about what it going to happen without reading them. Trying to effectively communicate and emphasize the importance of the information contained in warnings and confirmations is a growing problem that I don't think anyone has cracked just yet, but I know people are concerned about it and working on it.
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).
Is someone going to come up with another fingerprinting mechanism?
The obvious approach is to use the MAC address:
That is not a legitimate reason. If I want my applications tied together I'll manage that myself.
If you did that for advertising reasons, I'm sure Apple would reject/revoke the apps once they found out about it.
They may even survive restoring from backup (say after upgrading iOS or moving to another device), but I haven't tested that.
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.
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.
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 :-)
Getting the UDID+installID and then saving that into a file/preference would work, or installID and username.
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.
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.
I'm not sure I can think of anything the UDID does that you can't do better yourself.
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?
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.
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.)
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.
Assuming access to the UDID – and absolutely nothing else – is... dumb. What happens when users change devices, for example? I'm having a hard time imagining any large number of apps that are that reliant on this one thing. Even OpenFeint had provisions to handle non-UDID-based account authentication.
Hell the requirements for auto-renewing subscriptions pretty much FORCE you to track udids.
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.