11 ms·

iOS developers: Say goodbye to UDIDs

89 points by chillericed 14y ago

cynix 14y ago
I vaguely remember some apps using the MAC address of the WiFi interface as an identifier. Has this been banned yet?
- forrestthewoods 14y ago
  Maybe yes maybe no, but either way that's not a good solution. iOS 6 - use vendor identifier iOS 5 - create an ID via CFUUIDCreate() and save it iOS 4 - can be safely excluded from support
  - revetkn 14y ago
    Vendor identifier is user-resettable. Storing UUIDs fails on reinstalls. MAC is persistent, as are other tricks like keychain storage
    - derefr 14y ago
      > Vendor identifier is user-resettable. And that is a feature, not a problem to be worked around. :)
  - cynix 14y ago
    > Maybe yes maybe no, but either way that's not a good solution. I'm asking this as an end user - I want to see this usage banned so that apps cannot track me using the MAC address.
    - deleted 14y ago
      [deleted]
KwanEsq 14y ago
Permalink: https://developer.apple.com/news/?id=3212013a https://developer.apple.com/news/?id=3212013a
seivan 14y ago
MacAddress or vendor identifier. You could also generate random... but it's a good idea to keychain it under its own namespace.
gilgoomesh 14y ago
It's not a big deal. Just use the: [[ASIdentifierManager sharedManager] advertisingIdentifier]; for advertising across apps from different vendors or: [[UIDevice currentDevice] identifierForVendor]; for tracking your own library of apps or save a: CFUUIDCreate(); for tracking a specific app. Developers who are upset that these IDs could be changed by the user if they restore their device or deliberately reset them are precisely the privacy violators that Apple are trying to eliminate. Yes, there are keychain tricks to create a more persistent ID (or MAC IDs to identify the device, regardless of user) but if you truly need long-term persistent, unique identification users, have them log into your service instead of trying to steal their identity without permission. Edit: I forgot to mention another clean option for persistent identification... store a uuid from CFUUIDCreate() in an iCloud ubiquity container. Yes, the user will need to have an iCloud account and allow your app to store there. However, it does not require the user log into anything new and is the only measure that will follow a user through both app deletion and device changes (other than logging into your servers).
- derefr 14y ago
  > but if you truly need long-term persistent, unique identification users, have them log into your service instead of trying to steal their identity without permission. I think the idea here is that some services just plain don't have login flows, and are marginal enough that they might see massive use-decreases if they begin to hassle their users to create yet another account to use their service. If the user loses their vendor token for one of these apps, they'll have no way to get their data back; it'll be like their account just evaporated (which doesn't at all follow the Principle of Least Surprise, which to me might justify the use of these "more permanent" tokens to give users what they were expecting--persistent accounts tied to their device.) This seems more like an argument for something like a "device profile" within your iCloud account--a generalization of device backups. Restoring the device and then logging back in with your iCloud ID would reattach the device to its profile, and then all your vendor tokens would be restored along with it, whether or not you chose to restore the whole device from a backup. Obviously, there would be an online interface to (selectively or completely) erase a device profile, achieving the same thing as a "token reset" but without the risk and allowing for a much clearer "you are doing something very permanent to your identity" signal.
deleted 14y ago
[deleted]
tqc 14y ago
Was there ever a good reason for using UDID anyway? The only examples I've seen are user tracking for ads (has privacy issues) or a horribly broken login system. Anyone bothered by this is probably doing something wrong.
- buddydvd 14y ago
  One use of UDID is verifying in-app purchase receipts. It's demonstrated in the sample code associated with Apple's article titled "In-App Purchase Receipt Validation on iOS". See: https://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_ReceiptValidation/index.html https://developer.apple.com/library/ios/#releasenotes/StoreK...
  - tqc 14y ago
    Never noticed that as I don't have any in app purchases that actually cost me anything. This usage would seem to be more because the ID is available rather than because it is needed though. The bit about non-public APIs on that page is interesting though - if there is a genuinely necessary use case for device IDs it may not be affected.
    - buddydvd 14y ago
      The UDID embedded in receipts prevents/deters people from sharing them with others using MITM techniques. Sharing does happen and Apple's article helps address that issue.
      - tqc 14y ago
        True, but that is only one solution and a flawed one, as device ID can legitimately change - no developer needs to know whether I am using the phone I bought today or the one I bought a year ago.
        buddydvd 14y ago
        Non-consumable in-app purchases are restorable on any iOS device you can sign in with your iTunes account. When you buy a new iOS device and use StoreKit's restore transaction feature, Apple will generate a new receipt with UDID of that device. In-app purchases are tied to your iTunes account whereas embedded UDIDs are tied to devices you sign in with your iTunes credential.
fnayr 14y ago
The real story here is not the UDID ban which we knew was coming (and is easily counter-able as demonstrated in the comments already), but the forced iPhone 5 support. Now this wouldn't be an issue except that Apple doesn't allow you to support the iPhone 5 without targeting iOS 4.3 or higher. So this kills off support for iOS 3.1.3-4.2. This might not seem like such a bad thing, but if you're targeting certain demographics like kids (as I am), it cuts off a significant percentage (7% in my case) of users.
- fnayr 14y ago
  Here's the announcement from Apple: https://developer.apple.com/news/?id=3212013b https://developer.apple.com/news/?id=3212013b
  - nicholassmith 14y ago
    Not sure how that's been passed up in favour of talk about the UDID change. That's quite a big move from Apple really.
- buddydvd 14y ago
  Apparently, with the lipo tool, you can still support iOS below version 4.3 and Apple won't reject it. See: http://stackoverflow.com/a/12678077 http://stackoverflow.com/a/12678077
  - fnayr 14y ago
    Whoa! Thanks for this! I would edit my original comment if it let me. Still it is a hack that Apple could start disallowing at any time.
    - wsc981 14y ago
      I don't think the lipo tool will ever be regarded as hack. It's pretty much required when supporting multiple architectures / instruction sets. At some point there will likely be a ARMv8 architecture (if it doesn't exist yet). Also many libraries make use of lipo to create convenient static binaries that can be used both in the simulator as well as on the device.
EGreg 14y ago
How will this affect TestFlight and other such apps? Don't they still need your UDID?
- perkof 14y ago
  I beleive testflight doesn't use the App Store to deliver the application so should be okay. An update to the testflight sdk should be sufficient for production applications with testflight integration.
- Aqua_Geek 14y ago
  TestFlight gets your UUID by having you enroll your device in their MDM system. Support for this will likely never go away.
  - JimDabell 14y ago
    They use the UDID when the application runs to associate particular sessions with particular users, which can be extremely valuable for debugging purposes.

89 points by chillericed 14y ago

cynix 14y ago

I vaguely remember some apps using the MAC address of the WiFi interface as an identifier. Has this been banned yet?

forrestthewoods 14y ago
Maybe yes maybe no, but either way that's not a good solution. iOS 6 - use vendor identifier iOS 5 - create an ID via CFUUIDCreate() and save it iOS 4 - can be safely excluded from support
- revetkn 14y ago
  Vendor identifier is user-resettable. Storing UUIDs fails on reinstalls. MAC is persistent, as are other tricks like keychain storage
  - derefr 14y ago
    > Vendor identifier is user-resettable. And that is a feature, not a problem to be worked around. :)
- cynix 14y ago
  > Maybe yes maybe no, but either way that's not a good solution. I'm asking this as an end user - I want to see this usage banned so that apps cannot track me using the MAC address.
  - deleted 14y ago
    [deleted]

KwanEsq 14y ago

Permalink: https://developer.apple.com/news/?id=3212013a https://developer.apple.com/news/?id=3212013a

seivan 14y ago

MacAddress or vendor identifier. You could also generate random... but it's a good idea to keychain it under its own namespace.

gilgoomesh 14y ago

It's not a big deal. Just use the: [[ASIdentifierManager sharedManager] advertisingIdentifier]; for advertising across apps from different vendors or: [[UIDevice currentDevice] identifierForVendor]; for tracking your own library of apps or save a: CFUUIDCreate(); for tracking a specific app. Developers who are upset that these IDs could be changed by the user if they restore their device or deliberately reset them are precisely the privacy violators that Apple are trying to eliminate. Yes, there are keychain tricks to create a more persistent ID (or MAC IDs to identify the device, regardless of user) but if you truly need long-term persistent, unique identification users, have them log into your service instead of trying to steal their identity without permission. Edit: I forgot to mention another clean option for persistent identification... store a uuid from CFUUIDCreate() in an iCloud ubiquity container. Yes, the user will need to have an iCloud account and allow your app to store there. However, it does not require the user log into anything new and is the only measure that will follow a user through both app deletion and device changes (other than logging into your servers).

derefr 14y ago
> but if you truly need long-term persistent, unique identification users, have them log into your service instead of trying to steal their identity without permission. I think the idea here is that some services just plain don't have login flows, and are marginal enough that they might see massive use-decreases if they begin to hassle their users to create yet another account to use their service. If the user loses their vendor token for one of these apps, they'll have no way to get their data back; it'll be like their account just evaporated (which doesn't at all follow the Principle of Least Surprise, which to me might justify the use of these "more permanent" tokens to give users what they were expecting--persistent accounts tied to their device.) This seems more like an argument for something like a "device profile" within your iCloud account--a generalization of device backups. Restoring the device and then logging back in with your iCloud ID would reattach the device to its profile, and then all your vendor tokens would be restored along with it, whether or not you chose to restore the whole device from a backup. Obviously, there would be an online interface to (selectively or completely) erase a device profile, achieving the same thing as a "token reset" but without the risk and allowing for a much clearer "you are doing something very permanent to your identity" signal.

deleted 14y ago

[deleted]

tqc 14y ago

Was there ever a good reason for using UDID anyway? The only examples I've seen are user tracking for ads (has privacy issues) or a horribly broken login system. Anyone bothered by this is probably doing something wrong.

buddydvd 14y ago
One use of UDID is verifying in-app purchase receipts. It's demonstrated in the sample code associated with Apple's article titled "In-App Purchase Receipt Validation on iOS". See: https://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_ReceiptValidation/index.html https://developer.apple.com/library/ios/#releasenotes/StoreK...
- tqc 14y ago
  Never noticed that as I don't have any in app purchases that actually cost me anything. This usage would seem to be more because the ID is available rather than because it is needed though. The bit about non-public APIs on that page is interesting though - if there is a genuinely necessary use case for device IDs it may not be affected.
  - buddydvd 14y ago
    The UDID embedded in receipts prevents/deters people from sharing them with others using MITM techniques. Sharing does happen and Apple's article helps address that issue.
    - tqc 14y ago
      True, but that is only one solution and a flawed one, as device ID can legitimately change - no developer needs to know whether I am using the phone I bought today or the one I bought a year ago.
      - buddydvd 14y ago
        Non-consumable in-app purchases are restorable on any iOS device you can sign in with your iTunes account. When you buy a new iOS device and use StoreKit's restore transaction feature, Apple will generate a new receipt with UDID of that device. In-app purchases are tied to your iTunes account whereas embedded UDIDs are tied to devices you sign in with your iTunes credential.

fnayr 14y ago

The real story here is not the UDID ban which we knew was coming (and is easily counter-able as demonstrated in the comments already), but the forced iPhone 5 support. Now this wouldn't be an issue except that Apple doesn't allow you to support the iPhone 5 without targeting iOS 4.3 or higher. So this kills off support for iOS 3.1.3-4.2. This might not seem like such a bad thing, but if you're targeting certain demographics like kids (as I am), it cuts off a significant percentage (7% in my case) of users.

fnayr 14y ago
Here's the announcement from Apple: https://developer.apple.com/news/?id=3212013b https://developer.apple.com/news/?id=3212013b
- nicholassmith 14y ago
  Not sure how that's been passed up in favour of talk about the UDID change. That's quite a big move from Apple really.
buddydvd 14y ago
Apparently, with the lipo tool, you can still support iOS below version 4.3 and Apple won't reject it. See: http://stackoverflow.com/a/12678077 http://stackoverflow.com/a/12678077
- fnayr 14y ago
  Whoa! Thanks for this! I would edit my original comment if it let me. Still it is a hack that Apple could start disallowing at any time.
  - wsc981 14y ago
    I don't think the lipo tool will ever be regarded as hack. It's pretty much required when supporting multiple architectures / instruction sets. At some point there will likely be a ARMv8 architecture (if it doesn't exist yet). Also many libraries make use of lipo to create convenient static binaries that can be used both in the simulator as well as on the device.

EGreg 14y ago

How will this affect TestFlight and other such apps? Don't they still need your UDID?

perkof 14y ago
I beleive testflight doesn't use the App Store to deliver the application so should be okay. An update to the testflight sdk should be sufficient for production applications with testflight integration.
Aqua_Geek 14y ago
TestFlight gets your UUID by having you enroll your device in their MDM system. Support for this will likely never go away.
- JimDabell 14y ago
  They use the UDID when the application runs to associate particular sessions with particular users, which can be extremely valuable for debugging purposes.