SecureUDID Is An Open Source Solution To The Apple UDID Problem

SecureUDID Is An Open Source Solution To The Apple UDID Problem(techcrunch.com)

48 points by KB 14 years ago | 18 comments

shangrila 14 years ago |

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. The information can still be lost in the event of an OS restore.

For some (most?) developers, this might be sufficient. But if you need to actually, truly identify devices, these solutions are not good enough. The only way to identify a device itself is to use actual hardware-specific info. Since Apple is removing the UDID, the WiFi MAC address is pretty much the only thing left.

Any solution not based on hardware-specific info but which pretends to "distinguish devices" (as SecureUDID does) is not actually doing what it claims to do. It's a subtle but important distinction.

mattmass 14 years ago | |

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.

tejaswiy 14 years ago | |

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..

hboon 14 years ago | | |

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

gyardley 14 years ago |

Interesting. Based off of the FAQ, the only thing that keeps developers from sharing their users' SecureUDID with other developers and/or SDK-based companies seems to be their own discretion - turning over the domain and salt unlocks the keys.

There's also, as far as I can see, nothing to stop a company with a SDK from including this code in their SDK and tracking across every application that uses it. If I was still running an iOS analytics company, I'd be pretty tempted by this in the post-UDID era.

Well intentioned, I'm sure, but to me this looks like a great tool for continuing business as usual. I'm no expert, though - please let me know if I missed something.

antirez 14 years ago |

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.

mpakes 14 years ago | |

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...

mikeash 14 years ago | | |

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.

Aqua_Geek 14 years ago | |

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.

corysama 14 years ago |

What a lot of apps really need is for Apple to provide a UDID replacement that gives a different ID per app, but is consistent if the app is deleted and re-installed on the same device. SecureUDID is still based on CFUUID which is not consistent across re-installs.

idunno246 14 years ago | |

They store it in the pasteboard, which potentially will persist across reinstalls.

If its like how openudid works(and I understand it right), as long as one app remains that has secureudid installed, it will persist all the apps whether installed or not.

cpeterso 14 years ago |

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-where...

shareme 14 years ago | |

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..

EvilTrout 14 years ago |

Question: In the example given, you supply a salt and a domain when coming up with your UDID.

Isn't the salt of another app really easy to decompile and figure out?

After that, a competing app could find out if you've used the device ID already, which actually seems less secure than the original UDID apple provided.

The last thing I want is for apps I install to phone home with a list of other apps I have installed!

gyardley 14 years ago | |

If any of your apps has registered a custom URL scheme, and many do, any other app on your phone can easily check to see whether it's installed. That's by design.

Back when I was keeping up, it was also possible to read the mobile installation cache and get access to all of your installed applications, which is what some 'app recommender' applications did. That was an exploit which violated App Store policies - no idea if it still works.

EvilTrout 14 years ago | | |

Ah, that makes sense, thanks.

marktronic 14 years ago |

Not very useful given users will be able to opt-out of the SecureUDID system...