Does this actually, you know, work?

[schwa]

According to the project agenda in the README:

• Enable OpenUDID to be accessed by any app

I assume this means the SAME OpenUDID for all apps that use it? How is that possible? The keychain does NOT allow sharing of keychain data between apps unless they belong to the same Keychain Access Group. See http://developer.apple.com/library/mac/#documentation/Security/Reference/keychainservices/Reference/reference.html for more information - but the gist of it is only apps released by one develop can share keychain items.

Without the ability to share the OpenUDID between apps you've really just re-invented CFUUIDCreate.

[ylechelle]

My tests were indeed not thorough enough. I tested across two distinct apps but compiled with the same certificate (same TLD bundle identifiers)... I need to do more testing. I'm afraid you might be right...

[mcorner]

I was wondering the same thing. Oddly it does seem to work on the simulator (build two apps with the library and both seem to get the same UDID). Tried it on a 4.2 device and got different IDs. I haven't updated my phone to 5.0beta, but someone would have to try that, but seems very likely that this doesn't work....

[ylechelle]

ok guys, I concur. Keychain is a no go across apps with a different certificate... #fail
Back to the drawing board. Looking at UIPasteboard right now, looks promising... #hope

[mcorner]

Hadn't seen the pasteboard, but very interesting... you can actually persist it across reboots. Let us know what you see, very interested in this. Other off-the-wall possibilities:

-iCloud (kv or documents), but it seems hard to share iCloud data across apps from different teamids. Haven't dug into that.
-new single signon capabilities (haven't dug into that either).

[ylechelle]

Ok, looks like it's working. Code is actually simpler and no longer depends on the Security framework.
Let me know what you think ;-)

[zac]

UIPasteboard is an option. The first app that includes this code will look for a shared pasteboard at the "org.openudid.udid". If it exists, it uses that. If it doesn't, it creates one and sets it.

The show-stopper with that is if the first application gets deleted, the shared pasteboard dies too. The next app to open up would then re-create the pasteboard with a new UUID. Not good.

Here's a (crazy) workaround solution.

The first app goes through the following pasteboards looking for a UUID. "org.openudid.0", "org.openudid.1", "org.openudid.2", etc. all the way up to some number which represents the number of concurrent apps on the system that can support this.

Two possibilities:

1. If it finds a UUID, It creates the first available pasteboard slot it can and copies the UUID it discovered into the new pasteboard. That way it owns a pasteboard and there is no single point of failure. It can cache in prefs so a restore from backup doesn't wipe the UUID. It should also cache the pasteboard it ends up using for defragmentation purposes (more on that below).
2. If it doesn't find one in the initial search, it creates a UUID (or uses the cached prefs UUID) and puts it into "org.openudid.0".

You'll also want to do some kind of defragmentation. When your app launches it should check to see if there isn't a lower slot it could occupy (signifying another app was deleted). If there is, it moves it's UUID to a lower slot and updates the cached prefs slot.

I might take a crack and implementing next week if there are no takers.

[ELLIOTTCABLE]

@zac, the obvious issue; what if you delete apps 1 to N (where N being how high it will check before deciding there are no apps, and resorting to creating a new one), without ever opening apps N+1 to M to cause defragmentation? You can never check high enough with that system.

Solution: org.openudid.fragments++ each time one copies the data. Then again, that “breaks” defragmenting (that is, the number will always climb upwards, because there’s no way to know, when defragmenting, whether a previous defragmentor decremented it†); so you’re basically stuck with each app searching even further past deleted apps as the phone (or rather, the set-of-restored-apps-and-prefrences) grows older and older. This could eventually become somewhat slow, especially if you’re doing this on-startup.

† If you try to decrement fragments with-defragmentation: App N+1 launches, finds nothing from 0 to N, decrements fragments by N (number of slots it just checked and confirmed-empty. App N+2 launches, finds slot 1 taken, and 1 to N empty; decrements framents by N-1. fragments is now fragments - 2N + 1 instead of fragments - N.

[schwa]

cough Greasy hack cough

[ylechelle]

Hi Zac.

Our messages crossed. I just finished implementing the UIPasteboard version.
It works across apps & certs! See latest commit.

I was also thinking about a distributed persistence managed by each individual subscriber app in the event the pasteboard does indeed vanish. I'll get to it by Monday.

[schwa]

@ylechelle See Zac's comments. If the app that creates the pasteboard is deleted the data is lost for ALL apps.

Zac has a lot of experience hacking with the pasteboard. I'd definitely take his advice to heart if I were you.

[ylechelle]

of course; DragKit ;-) Hats off @zac.

• Persistence against deletion must be built-in to avoid loss of OpenUDID; the way to do this is to distribute the responsibility to all subscriber apps; when the pboard vanishes, any app can rebuild it. I now see @zac's point. Creating numeric variation of the pboard on a per app basis should create some stability. Is there any way to find the "creator" of a pboard?
• Anti-tampering or at least notification of tempering must be built-in by checking against the local copy

more later...

[tbrannam]

Is there any reason why the MAC address of en0 (and/or en1) aren't used as the seed. MAC addresses are historically unique - combining two if available as a seed for a hash (SHA1 perhaps) would yield the same value for a given device. It can be independently calculable in each process.

[schwa]

Once you're using the MAC address you're back to why Apple deprecated UDID in the first place... There are some privacy issues related to distributing a MAC address even if it has been salted & hashed.

[ylechelle]

Agreed. And Apple could equally decide to deprecate access to it.
Better to use something rather different and random even.

On 2-Sep-2011, at 7:17 AM, schwa wrote:

Once you're using the MAC address you're back to why Apple deprecated UDID in the first place... There are some privacy issues related to distributing a MAC address even if it has been salted & hashed.

Reply to this email directly or view it on GitHub:
#1 (comment)

[tbrannam]

I see - somehow I thought that the object of the exercise was to build an algorithm that was recomputable and unique. Isn't the point of OpenUUID itself opening up privacy issues? Perhaps Apple would just ban any application that consumes this code?

I'm intrigued by the comment that the MAC address is somehow special as a unique value that shouldn't be used salted & hashed, have any recommended reading on that topic?

[ylechelle]

Actually, the object of the exercise was to build a process that was no necessarily recomputable because MAC address or indeed the original UDID are private and hardcoded addresses.

MAC addresses are used for Wifi security and other things like VPN, etc... it shouldn't be shared in the wild, even salted & hashed. Too sensitive.

A persistent and 99.9% unique key that can be shared across vendors which can also be opted- or wiped-out is a good enough proxy for what the industry needs.

[mcorner]

One comment on the loss of the pastebin when deleting apps:

I see that is in the documentation, but when I test that it seems to persist even though I deleted the app that created it. I can try rebooting as well, but has anyone verified this?

[ylechelle]

tested in Simulator or device? on the device, the pasteboard was lost for me.

[ylechelle]

@zac has the correct suggestion.

[mcorner]

Ah, never mind, just "rediscovered" the #if TARGET_IPHONE_SIMULATOR in the code.

[ylechelle]

@zac @mcorner @schwa @tbrannam please have a look and let me know what you think. This v1.0 seems to fit the bill. I'm closing this issue. Please open new ones if applicable.

[MechinMaru]

i doubt that
this code
if (_openUDID==nil) {

       CFUUIDRef uuid = CFUUIDCreate(kCFAllocatorDefault);

    CFStringRef cfstring = CFUUIDCreateString(kCFAllocatorDefault, uuid);
    const char *cStr = CFStringGetCStringPtr(cfstring,CFStringGetFastestEncoding(cfstring));
    unsigned char result[16];
    CC_MD5( cStr, strlen(cStr), result );
    CFRelease(uuid);

    _openUDID = [NSString stringWithFormat:
            @"%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%08x",
            result[0], result[1], result[2], result[3], 
            result[4], result[5], result[6], result[7],
            result[8], result[9], result[10], result[11],
            result[12], result[13], result[14], result[15],(NSUInteger)(arc4random() % NSUIntegerMax)];  
}

CFUUIDRef uuid = CFUUIDCreate(kCFAllocatorDefault); //// get udid from iphone device? please description this code, how it work

Thank you

[ylechelle]

CFUUIDCreate(kCFAllocatorDefault) creates a random UUID here, not a UDID.

[MechinMaru]

i want to know that OpenUDID algorithm get the UDID from IPhone devices to generate new UDID ?

if i uninstalled app and re-install again, the UDID will change or not?

[ylechelle]

i want to know that OpenUDID algorithm get the UDID from IPhone devices to generate new UDID ?

can't explain the algorithm simply here; but if you trace the call, you will see that the randomly generated OpenUDID is generated once and is persistent across apps via a distributed array of pasteboards.

if i uninstalled app and re-install again, the UDID will change or not?

it will not change theoretically, except if on your device there is only one app that uses OpenUDID which statistically isn't the case if you have 50 apps or more… (i.e. most people really)

[MechinMaru]

i want to know that openUDID will generate redundant UDID with another device or not?