

SecureUDID Is An Open Source Solution To The Apple UDID Problem - KB
http://techcrunch.com/2012/03/27/secureudid-is-an-open-source-solution-to-the-apple-udid-problem/

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

~~~
tejaswiy
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
It's often networks providing advertising or analytics services that want to
identify devices. Not the app/service itself.

------
gyardley
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
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
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...](https://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFUUIDRef/Reference/reference.html)

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

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

------
corysama
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
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
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...](http://blog.radioactiveyak.com/2011/05/android-protips-where-to-
download.html)

~~~
shareme
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
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
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
Ah, that makes sense, thanks.

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

