Apple phasing out developer access to the UDID in iOS 5(techcrunch.com)
techcrunch.com
Apple phasing out developer access to the UDID in iOS 5
http://techcrunch.com/2011/08/19/apple-ios-5-phasing-out-udid/
63 コメント
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.
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?
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?
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.
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.
> 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.)
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.)
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?
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?
"Facebook has a responsibility to do the right thing or loose a lot. It has executives, investors, and assets which are all exposed to lawsuits and criminal investigation."
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.
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.
If you use the Facebook app and enable contact syncing, it prompts:
"If you enable this feature, all contacts from your device (name, email address, phone number) will be sent to Facebook and be subject to Facebook's Privacy Policy, and your friends' profile photos and other info from Facebook will be added to your iPhone address book. Please make sure your friends are comfortable with any use you make of their information."
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.
"If you enable this feature, all contacts from your device (name, email address, phone number) will be sent to Facebook and be subject to Facebook's Privacy Policy, and your friends' profile photos and other info from Facebook will be added to your iPhone address book. Please make sure your friends are comfortable with any use you make of their information."
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.
Our app asks explicitly when you first download it. It won't work much without it although.
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.
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).
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).
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...
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...
> 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.
That is not a legitimate reason. If I want my applications tied together I'll manage that myself.
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.
If you did that for advertising reasons, I'm sure Apple would reject/revoke the apps once they found out about it.
Would that persist across resets?
The pasteboards are persistent across power-cycling.
They may even survive restoring from backup (say after upgrading iOS or moving to another device), but I haven't tested that.
They may even survive restoring from backup (say after upgrading iOS or moving to another device), but I haven't tested that.
If you mean reboots, then the various applications in the suite could store the identifier on disk and recover it if it is missing; and, if you mean restores, that place on disk could be something that is backed up by iTunes.
Another example of legit usage of UDID: TestFlight.
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.
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.
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.
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.
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.
I'd find this laudable if the AppleId was something that was programmatically accessible. It doesn't appear to be.
Does it need to be? Store a unique identifier to the AppleID and use it to look up the account as needed.
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 :-)
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 :-)
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.
Getting the UDID+installID and then saving that into a file/preference would work, or installID and username.
I'm doing this too, and we're using a 128-bit random GUID, which has an unfathomably small chance of being a duplicate.
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.
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.
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.
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.
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...
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.
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.
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.
That's ingenious — per-device permabanning!
I guess this will be a great new feature for Parse to offer iOS devs.
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.
I'm not sure I can think of anything the UDID does that you can't do better yourself.
Good stuff. Let me as the user dictate the terms for how I am identified.
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.
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.
So does this mean things like TestFlight will no longer work?
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.
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.
They make it so difficult in fact that just yesterday i got a screenshot of a UDID instead of the text because apple makes it look like you cant cut/paste the thing. Sooo frustrating.
[deleted]
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?
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?
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.
Remember this is deprecated, and not yet removed. TestFlight and UDID Sender etc all still work fine on the current betas of iOS5
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.
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.
Wow, this is really fantastic news. I've always been annoyed at the huge privacy vulnerability developer access to UDIDs posed.
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.
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.
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.
They have – it's called iCloud.
http://www.apple.com/icloud/
http://www.apple.com/icloud/
What happens to analytics companies like flurry??
Hopefully they disappear. But, probably not.
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.
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).
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.
This will result in a lot of broken apps in the app store.
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.)
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.)
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.
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.
But will it break lots of apps?
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.
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.
Sometimes users have different things on different devices.
Hell the requirements for auto-renewing subscriptions pretty much FORCE you to track udids.
Hell the requirements for auto-renewing subscriptions pretty much FORCE you to track udids.
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.
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.
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.