What about push notifications? I think that's the biggest legitimate use of UDIDs and was not mentioned in the article.
According to the docs, every time an iOS app starts up it sends a device token to the push provider. From time to time, this device token changes, so it is nice to have the token linked to the UDID so that one doesn't try to send push notifications to invalid device tokens.
Thanks for that info, I somehow overlooked this when rolling my own push provider.
For those still interested: There is a separate feedback service (feedback.push.apple.com) that providers should query periodically. It returns a list of device tokens that are no longer valid for your application.
The APNs token is unique to the install of iOS, not the hardware. So if a user moves to new hardware (with a different UDID), and they restore from a backup of their previous device, the token stays the same. Similarly, if a user does a complete restore of an iOS device (same UDID), but sets the existing device up as a new device, a new token is assigned.
I have about a year of data from providing push to ~100K active device tokens. The former scenario, where a user upgrades to a new device and restores from a backup of their old device is really common. The latter almost never happens. So the UDID is marginally useful, in that it allows you to abstract push-enabled iOS systems from iOS devices.
For doing something like user authentication, the APNs token is actually preferable, because it gets transported along with app data when a user upgrades to a new device. I'm guessing that developers use the UDID, because when you register with the system to get the APNs token, the user is prompted to accept or deny push notifications.
Edit: And, yes, tokens aren't specific to an app; there's one per system that all the apps share.
As an app developer, I have to say I agree with Apple on this decision. The UDID is harmless to share, but in the days before TestFlight when I would send out Ad Hoc builds to test apps before publishing, many people would get nervous about sharing their UDID with me. I'd often be asked "is this safe? Can you hack into my phone with this?"
Of course, classic Ad Hoc builds will probably still require handing over a UDID, but I would think it would be comforting for the average iOS user to see stories like this, because it gives the illusion of a little extra security and certainly helps regarding privacy.
The only thing I'm worried about is how this will affect TestFlight. Without programmatic access to the UDID, the on-boarding process for a tester in TestFlight is going to become much more complicated.
This change doesn't prevent reading the UDID through the web browser using a configuration profile. The article points out that AppBlade and similar services will continue to work just fine.
There are analytics and demographic research companies that actively buy and sell this data for very large sums of money.
This sounds believable - people are buying and selling my valuable data! - but it's completely mythical. (I wish it were true, since I'd be a lot richer.) Behavioral targeting data from application usage isn't worth a hell of a lot, especially since it can't easily be linked to profiles on the mobile or broader web. Analytics companies don't buy data at all and have difficulty selling it, if they're even attempting to - there's not enough money in it to make it worthwhile. Demographic research firms have all constructed their own small panels with full user opt-in, and the other interested parties out there aren't paying very much.
You can make a little bit of money off of usage data, but not enough to support a company.
The UDID is currently the only way to track an advertising conversion from an ad in one app to the installation of another app.
Well, it's currently the easiest, most reliable, and most user-friendly way - so it's the one everyone uses. The article itself goes on to mention some of the alternatives, so this is a curious assertion.
[T]he prevailing attitude around Apple violations is “we’ll know it when we see it.” Workarounds that break the spirit of a rule are likely to be rejected just the same.
It's just as likely that the services will continue using the deprecated but still available UDID call. If Apple decides to test for and police UDID usage or any other workarounds, they absolutely can, but that decision's up to Apple. If the subset of application developers important to Apple wants cross-application tracking, I suspect there will be a way to do cross-application tracking.
We'll only know the real implications of Apple's UDID deprecation after iOS 5 is broadly deployed.
> actively buy and sell data for very large sums of money.
This is happening and we've been approached by firms with non trivial offers. This is typically associated with shopping/e-commerce apps that can use the data to impact conversions. Companies targeted with these offers tend to collect billing/shipping information to further tie data to existing retail habits. (FYI: We said no thanks.)
> attitude around Apple violations.
The attitude is there but you are right that they haven't rejected apps for UDID usage, yet.
12 comments
[ 3.2 ms ] story [ 40.0 ms ] threadAccording to the docs, every time an iOS app starts up it sends a device token to the push provider. From time to time, this device token changes, so it is nice to have the token linked to the UDID so that one doesn't try to send push notifications to invalid device tokens.
Reference: http://developer.apple.com/library/ios/#documentation/Networ...
For those still interested: There is a separate feedback service (feedback.push.apple.com) that providers should query periodically. It returns a list of device tokens that are no longer valid for your application.
Reference: http://developer.apple.com/library/ios/#documentation/Networ...
I have about a year of data from providing push to ~100K active device tokens. The former scenario, where a user upgrades to a new device and restores from a backup of their old device is really common. The latter almost never happens. So the UDID is marginally useful, in that it allows you to abstract push-enabled iOS systems from iOS devices.
For doing something like user authentication, the APNs token is actually preferable, because it gets transported along with app data when a user upgrades to a new device. I'm guessing that developers use the UDID, because when you register with the system to get the APNs token, the user is prompted to accept or deny push notifications.
Edit: And, yes, tokens aren't specific to an app; there's one per system that all the apps share.
Of course, classic Ad Hoc builds will probably still require handing over a UDID, but I would think it would be comforting for the average iOS user to see stories like this, because it gives the illusion of a little extra security and certainly helps regarding privacy.
The only thing I'm worried about is how this will affect TestFlight. Without programmatic access to the UDID, the on-boarding process for a tester in TestFlight is going to become much more complicated.
There are analytics and demographic research companies that actively buy and sell this data for very large sums of money.
This sounds believable - people are buying and selling my valuable data! - but it's completely mythical. (I wish it were true, since I'd be a lot richer.) Behavioral targeting data from application usage isn't worth a hell of a lot, especially since it can't easily be linked to profiles on the mobile or broader web. Analytics companies don't buy data at all and have difficulty selling it, if they're even attempting to - there's not enough money in it to make it worthwhile. Demographic research firms have all constructed their own small panels with full user opt-in, and the other interested parties out there aren't paying very much.
You can make a little bit of money off of usage data, but not enough to support a company.
The UDID is currently the only way to track an advertising conversion from an ad in one app to the installation of another app.
Well, it's currently the easiest, most reliable, and most user-friendly way - so it's the one everyone uses. The article itself goes on to mention some of the alternatives, so this is a curious assertion.
[T]he prevailing attitude around Apple violations is “we’ll know it when we see it.” Workarounds that break the spirit of a rule are likely to be rejected just the same.
It's just as likely that the services will continue using the deprecated but still available UDID call. If Apple decides to test for and police UDID usage or any other workarounds, they absolutely can, but that decision's up to Apple. If the subset of application developers important to Apple wants cross-application tracking, I suspect there will be a way to do cross-application tracking.
We'll only know the real implications of Apple's UDID deprecation after iOS 5 is broadly deployed.
This is happening and we've been approached by firms with non trivial offers. This is typically associated with shopping/e-commerce apps that can use the data to impact conversions. Companies targeted with these offers tend to collect billing/shipping information to further tie data to existing retail habits. (FYI: We said no thanks.)
> attitude around Apple violations.
The attitude is there but you are right that they haven't rejected apps for UDID usage, yet.
http://iphonedevwiki.net/index.php/Lockdownd
UDID = SHA1(SerialNumber + IMEI + WiFiAddress + BluetoothAddress)