SecureUDID Is An Open Source Solution To The Apple UDID Problem | Hacker News Reader

SecureUDID Is An Open Source Solution To The Apple UDID Problem

techcrunch.com

48 pointsKB18 comments

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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

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!

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.

Ah, that makes sense, thanks.

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

Reply on news.ycombinator.com