9 ms·

Apple phasing out developer access to the UDID in iOS 5

128 points by canistr 15y ago

pkaler 15y 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.
- sanj 15y 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?
- Zev 15y 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.
llambda 15y ago
So does this mean things like TestFlight will no longer work?
- justinvoss 15y 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 15y 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.
    - ldar15 15y ago
      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.
spearo77 15y ago
What happens to analytics companies like flurry??
- lawnchair_larry 15y ago
  Hopefully they disappear. But, probably not.
  - nhangen 15y 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 15y 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).
  - saurik 15y 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 15y 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.
sanj 15y 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-programmatically-get-the-mac-address-of-an-iphone http://stackoverflow.com/questions/677530/how-can-i-programm...
- spearo77 15y 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.
  - sanj 15y ago
    Would that persist across resets?
    - saurik 15y ago
      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.
    - spearo77 15y ago
      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.
- wvenable 15y 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.
- 15y ago
axiom 15y ago
This will result in a lot of broken apps in the app store.
- danilocampos 15y 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 15y 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.
    - danilocampos 15y ago
      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.
      - gte910h 15y ago
        Sometimes users have different things on different devices. Hell the requirements for auto-renewing subscriptions pretty much FORCE you to track udids.
- 15y ago
ethank 15y 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 15y 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.
  - gte910h 15y 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.
- sanj 15y ago
  I'd find this laudable if the AppleId was something that was programmatically accessible. It doesn't appear to be.
  - danilocampos 15y ago
    Does it need to be? Store a unique identifier to the AppleID and use it to look up the account as needed.
seanalltogether 15y 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.
- danilocampos 15y ago
  They have – it's called iCloud. http://www.apple.com/icloud/ http://www.apple.com/icloud/
spearo77 15y 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 15y 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 15y ago
I guess this will be a great new feature for Parse to offer iOS devs.
notphilatall 15y 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 15y ago
  That's ingenious — per-device permabanning!
trotsky 15y 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 15y 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 15y 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 15y 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-app-installations.html http://android-developers.blogspot.com/2011/03/identifying-a...
laconian 15y ago
Good stuff. Let me as the user dictate the terms for how I am identified.
bnycum 15y 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 15y 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.
saurik 15y 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 15y 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 15y ago
Wow, this is really fantastic news. I've always been annoyed at the huge privacy vulnerability developer access to UDIDs posed.
ansy 15y 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 15y 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 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.)
  - ansy 15y 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?
graiz 15y ago
I run a company called http://www.AppBlade.com 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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?
deleted 15y ago
[deleted]
tobylane 15y 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.

128 points by canistr 15y 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.

sanj 15y 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?
Zev 15y 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.

llambda 15y ago

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

justinvoss 15y 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 15y 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.
  - ldar15 15y ago
    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.

spearo77 15y ago

What happens to analytics companies like flurry??

lawnchair_larry 15y ago
Hopefully they disappear. But, probably not.
- nhangen 15y 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 15y 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).
- saurik 15y 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 15y 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.

sanj 15y 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-programmatically-get-the-mac-address-of-an-iphone http://stackoverflow.com/questions/677530/how-can-i-programm...

spearo77 15y 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.
- sanj 15y ago
  Would that persist across resets?
  - saurik 15y ago
    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.
  - spearo77 15y ago
    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.
wvenable 15y 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.
15y ago

axiom 15y ago

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

danilocampos 15y 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 15y 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.
  - danilocampos 15y ago
    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.
    - gte910h 15y ago
      Sometimes users have different things on different devices. Hell the requirements for auto-renewing subscriptions pretty much FORCE you to track udids.
15y ago

ethank 15y 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 15y 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.
- gte910h 15y 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.
sanj 15y ago
I'd find this laudable if the AppleId was something that was programmatically accessible. It doesn't appear to be.
- danilocampos 15y ago
  Does it need to be? Store a unique identifier to the AppleID and use it to look up the account as needed.

seanalltogether 15y 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.

danilocampos 15y ago
They have – it's called iCloud. http://www.apple.com/icloud/ http://www.apple.com/icloud/

spearo77 15y 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 15y 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 15y ago

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

notphilatall 15y 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 15y ago
That's ingenious — per-device permabanning!

trotsky 15y 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 15y 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 15y 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 15y 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-app-installations.html http://android-developers.blogspot.com/2011/03/identifying-a...

laconian 15y ago

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

bnycum 15y 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 15y 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.

saurik 15y 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 15y 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 15y ago

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

ansy 15y 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 15y 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 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.)
- ansy 15y 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?

graiz 15y ago

I run a company called http://www.AppBlade.com 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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?

deleted 15y ago

[deleted]

tobylane 15y 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.