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.
SecureUDID does not claim to emulate a hardware ID. Uniqueness-per-app-only and ability to be disabled are its two defining features.
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.
[1] https://developer.apple.com/library/mac/#documentation/CoreF...
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.
http://blog.radioactiveyak.com/2011/05/android-protips-where...
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!
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.
