Live data from Hacker News

SecureUDID Is An Open Source Solution To The Apple UDID Problem

techcrunch.com

11–19 of 19 posts

Re: SecureUDID Is An Open Source Solution To The Apple UDID Problem

#11

Most of the UDID replacement "solutions" proposed so far are just cookies. They generate an identifier and write the data to a location such as the keychain, or a private pasteboard as in the case of SecureUDID. These locations may be somewhat persistent and might even outlast a delete & reinstall of a particular app in some cases, but in the end they are still volatile and therefore do not actually identify devices.…

Your point is completely valid. These aren't guaranteed to persist across all events, though OS installs should be ok if the user restores from a backup afterwards. The ability to delete/turn off is important, though. A tracking number that cannot be deleted and is shared across all applications is fundamentally at odds with user privacy.

SecureUDID does not claim to emulate a hardware ID. Uniqueness-per-app-only and ability to be disabled are its two defining features.

Re: SecureUDID Is An Open Source Solution To The Apple UDID Problem

#12

Most of the UDID replacement "solutions" proposed so far are just cookies. They generate an identifier and write the data to a location such as the keychain, or a private pasteboard as in the case of SecureUDID. These locations may be somewhat persistent and might even outlast a delete & reinstall of a particular app in some cases, but in the end they are still volatile and therefore do not actually identify devices.…

Agree. But I've been wondering what exactly do people want with a "Device ID"? I've changed my code to generate a new GUID and save it to NSUserDefaults. Sure, it doesn't persist even across app reinstalls, but so what? I maintain it as a currently active device ID instead of a unique device identifier..

Re: SecureUDID Is An Open Source Solution To The Apple UDID Problem

#13
post #10

I don't understand why Apple instead of just deprecating the UDID API did not added at the same time an API returning an application-specific UDID. No privacy problems, no issues for developers.

Such a thing has existed since iOS 2.0 (CFUUIDCreate [1]), and Apple's updated docs on UDID specifically recommend using CFUUIDCreate. The problem is that an application-specific UUID doesn't address all current use cases for UDID. Specifically, ad networks that support Cost-Per Install (CPI) need to use an identifier that crosses the application boundary.

[1] https://developer.apple.com/library/mac/#documentation/CoreF...

Re: SecureUDID Is An Open Source Solution To The Apple UDID Problem

#14
post #13
post #10

I don't understand why Apple instead of just deprecating the UDID API did not added at the same time an API returning an application-specific UDID. No privacy problems, no issues for developers.

Such a thing has existed since iOS 2.0 (CFUUIDCreate [1]), and Apple's updated docs on UDID specifically recommend using CFUUIDCreate. The problem is that an application-specific UUID doesn't address all current use cases for UDID. Specifically, ad networks that support Cost-Per Install (CPI) need to use an identifier that crosses the application boundary. [1] https://developer.apple.com/library/mac/#documentation/Co…

Perhaps I misunderstood, but CFUUIDCreate doesn't create an application-specific UUID, it just creates a new, arbitrary, UUID that isn't tied to anything. You could then use that to build your own app-specific UUID mechanism, but the API won't do it for you.

Re: SecureUDID Is An Open Source Solution To The Apple UDID Problem

#15
post #10

I don't understand why Apple instead of just deprecating the UDID API did not added at the same time an API returning an application-specific UDID. No privacy problems, no issues for developers.

For what it's worth, I filed a bug report for this a while back and it got closed as a duplicate. Hopefully it's something that is coming before they remove the UDID method.

Re: SecureUDID Is An Open Source Solution To The Apple UDID Problem

#17
post #14
post #13

Earlier quoted context omitted.

Such a thing has existed since iOS 2.0 (CFUUIDCreate [1]), and Apple's updated docs on UDID specifically recommend using CFUUIDCreate. The problem is that an application-specific UUID doesn't address all current use cases for UDID. Specifically, ad networks that support Cost-Per Install (CPI) need to use an identifier that crosses the application boundary. [1] https://developer.apple.com/library/mac/#documentation/Co…

Perhaps I misunderstood, but CFUUIDCreate doesn't create an application-specific UUID, it just creates a new, arbitrary, UUID that isn't tied to anything. You could then use that to build your own app-specific UUID mechanism, but the API won't do it for you.

Good point; I may have replied too hastily.

It's relatively straightforward to use CFUUIDCreate as a building block for an application-specific UUID, but you're correct in stating that the API itself simply returns a new, pseudorandom UUID.

Re: SecureUDID Is An Open Source Solution To The Apple UDID Problem

#18
post #3

In his Android Pro-tips talk, Reto Meier (tech lead on the Android Developer Relations team) recommends generating a random UUID and saving it in your app's SharedPreferences. The Android BackupManager will backup SharedPreferences in the Google cloud. If the user restores their user profile from the BackupManager to a new phone, their UUID will be preserved. http://blog.radioactiveyak.com/2011/05/android-protips-whe…

that is an UUID which every linux/unix OS device has one including desktops. Its what URI is based upon, even MS has their own version of such a thing in MS windows..

Re: SecureUDID Is An Open Source Solution To The Apple UDID Problem

#19

Most of the UDID replacement "solutions" proposed so far are just cookies. They generate an identifier and write the data to a location such as the keychain, or a private pasteboard as in the case of SecureUDID. These locations may be somewhat persistent and might even outlast a delete & reinstall of a particular app in some cases, but in the end they are still volatile and therefore do not actually identify devices.…

Agree. But I've been wondering what exactly do people want with a "Device ID"? I've changed my code to generate a new GUID and save it to NSUserDefaults. Sure, it doesn't persist even across app reinstalls, but so what? I maintain it as a currently active device ID instead of a unique device identifier..

It's often networks providing advertising or analytics services that want to identify devices. Not the app/service itself.
Post reply on HN