What is the udid of the "Go" iOS device? Why does Apple refuse to get an iOS device Udid app? How to replace Udid?

This article is mainly about why Apple launched iOS 5 in August 2011 to reject the Udid of the app acquisition device and the Udid replacement program, especially to remind developers that Apple App Store prohibits access to the Udid app shelves (recommended: app is Apple app Store rejected for n reasons), the following first to understand the next udid.

What is Udid?

The full name of Udid is unique device Identifier, which, as its name implies, is the unique identifier of the Apple iOS device, which consists of 40 characters of letters and numbers.

Second, what is the use of Udid?

Mobile networks can use UDID to identify mobile devices, such as iphones and ipads. The Udid is unique to each device, making it a useful tool for advertising agencies, market analysts, and app test systems to track user behavior.

The main reasons for the current use of UDID include:

• 1) For statistics and analysis, such as third-party statistical tools Flurry, friends of the league, such as advertising, admob, etc.
• 2) Udid as the user ID to uniquely identify the user, save the user name, password and other registration process.

This shows that Udid is a very important message for iOS app developers (although jailbroken devices can change the device's Udid by some tools). However, starting with IOS5.0 (August 2011), Apple has announced that it will no longer support the acquisition of UDID for devices in the following ways.

1	[Uidevice Currentdevice] uniqueidentifier];

Iii. reasons for denying IOS apps access to UDID devices

Udid is intended to facilitate an application to statistical user behavior, but because it is a unique ID, and directly do not see the relationship with the user's privacy, so it is open. However, when there are a large number of apps in the market, and Udid for each app is the same time, the user's privacy has been a certain degree of infringement. Let's say that there are a lot of apps that come together because udid are unified, so they can piece together the privacy of the user. So from this angle, Apple removed the Udid support, and each app can generate its own UUID, so the statistics of the single app will still not be a problem. so the main reason is the privacy issue.

Iv. recommended UUID Alternatives when udid must be used

1. Apple's recommended UUID alternatives

1 2 3 4 5 6 7 8

-(nsstring*) UUID { Cfuuidref Puuid = cfuuidcreate (nil); Cfstringref uuidstring = cfuuidcreatestring (nil, puuid); NSString * result = (NSString *) cfstringcreatecopy (NULL, uuidstring); Cfrelease (PUUID); Cfrelease (uuidstring); return [result Autorelease]; }

Apple recommends using the above code to generate a unique identification string for your app. The developer can call once at the first launch of the app and then store the string for later use instead of Udid. Obviously, there are many problems with this approach. If the user deletes the app again, a new string is generated, so it is not guaranteed to uniquely identify the device; If you back up files from an old device to a new device, both devices have the same cfuuid; if you back up the operating system from a temporary file, There is a situation where there are different cfuuid in a device.

2. Using Open Source Solution Openudid
Contributors in the Readme document say:

Openudid is a drop-in replacement for the deprecated [Uidevice uniqueidentifier] a.k.a. UDID on IOS, and otherwise are an I ndustry-friendly equivalent for IOS and Android.
The agenda for this community driven project was to:–provide a reliable proxy and replacement for a universal unique Devi Ce identifier. That's, persistent and sufficiently unique, on a per device basis. –not use a obvious other sensitive unique identifier, like the MAC address, to avoid further deprecation and to protect Device-level privacy concerns–enable The same openudid to being accessed by any apps on the same device–supply Open-source Code to generate and access the Openudid, for IOS and Android–incorporate, from the beginning, a system that would enabl E user opt-out to match Apple ' s initial intent.

The vision is good, and it does not use MAC addresses, and it ensures that the same openudid can be used for different applications on the same device. But careful analysis, still can find the problem.
Openudid code that generates a unique identification code is:

1 2 3 4 5 6 7 8 9

Unsigned char  result[16]; const char *cstr = [[[nsprocessinfo processinfo] globallyuniquestring]  Utf8string]; Cc_md5 ( cstr, strlen (CSTR), result ); _openudid = [nsstringstringwithformat:             @ "%02x%02x%0 2x%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], ResU LT[7],             RESULT[8], result[9], result[10], result[11],             RESULT[12], result[13], result[14], result[15],             Arc4ran Dom ()  % 4294967295];

The Nsprocessinfo class is used here.
When the first application on the device that uses the Openudid solution is called for the first time, it does generate a unique identification code. At the same time, a 8-bit random code is appended to the MD5 value for the same number of official udid digits. The scenario then uses the Nsuserdefaults class (app settings). The application will obtain a unique identification code saved to the app's Userdefaults, if the program needs to use a unique identification code, it is obtained from the userdefaults, so that the same identification code can be obtained. However, if the user deletes the app, the Userdefaults is also emptied, and the Uipasteboard class (device clipboard) is used to avoid rebuilding the unique identification code. The app saves the unique identification number to userdefaults and saves it to a uipasteboard that is identified with a special key. Code such as:

1 2	uipasteboard* SLOTPB = [Uipasteboardpasteboardwithname:availableslotpbid create:yes]; [SLOTPB setdata:[nskeyedarchiver archiveddatawithrootobject:dict] forpasteboardtype:kopenudiddomain];

Where Availableslotpbid is a string key, the prefix is "org." Openudid.slot. ", add a number to the back of the dot. This number defaults from 0 to 99 (you can, of course, modify the source code to make it larger or smaller).
If a second application with the Openudid solution is installed on the device, when the application calls the method that generates the Openudid, a unique identification number (traversing the uipasteboard of key 0 through 99) is obtained from the Uipasteboard. This is where the first app was saved to Uipasteboard. That is, as long as a openudid application exists on the user's device, any subsequent installed application will get the one generated by the first application if it gets openudid.
It seems very good and complex. But think about it, or there is a problem, if the use of the Openudid program are all deleted, and then regain Openudid, at this time the Openudid is not the same as before (I measured it, indeed). Visible, this method is still not insurance.

3. Open Source Solution Secureudid

A little look at the next Secureudid source, found that it is similar to Openudid, but the initial acquisition of the unique identification code slightly different. At the same time, as can be seen from the author's readme document, there are also many problems with this scheme. As the original:

Is this a true UDID replacement?
Secureudid has the properties that is should know about before your use it. First, as indicated above, the identifier is not derived from hardware attributes. Second, the persistence of an identifier cannot is guaranteed in all situations. This means, while unlikely, it's technically possible for a distinct devices to report the same identifier, and FO R the same device to report different identifiers. Consider this carefully in your application. Here are a list of situations where this identifier would not exhibit the uniqueness/persistence of a traditional UDID.
* The user has opted-out of the Secureudid system, in which case you'll receive a well-formed string of zeroes.
* Device A is backed up and then restored to Device B, which are an identical model. This was common when someone breaks their phone, for example, and is likely Desirable:you would receive Device A ' s secureud Id.
* The Secureudid data is removed, via user intervention, Uipasteboard data Purge, or by a malicious application.
* The Secureudid backing store becomes corrupt.
* All Secureudid applications is uninstalled from a device, followed by a uipasteboard data purge.

I found that in fact, the previous Openudid also basic problems, but the author did not write it out. It seems that Secureudid's contributors are more honest.
4. Related to WiFi MAC address
There are also some alternatives to WiFi MAC address, mainly in three kinds: the first direct use of "MAC address", the second, the use of "MD5 (MAC Address)", and the third, "MD5 (Mac address+ Cfbundleidentifier) ". There is an open source project (UIDEVICE-WITH-UNIQUEIDENTIFIER-FOR-IOS-5) on GitHub that implements these methods.
The use of this method is also problematic: 1, there are some machines on the market (although the number of very few, but I did find this situation in the use process) can not get MAC address, some people say this part of the machine is Unicom castrated no WiFi version, specifically unknown. 2, MAC address as Udid, there is a privacy issue. Apple now disables Udid, and there is no guarantee that MAC addresses will not be disabled in the future.

5, some large companies private solutions, but how can they tell you?

So, if you want to track a device in a foolproof way, there is no more appropriate option than UDID. But what should Apple do now, when it is not allowed to use, the hard-pressed developers?

Transferred from: http://www.dapps.net/dev/iphone/whats-udid-and-how-to-replace-udid.html

What is the udid of the "Go" iOS device? Why does Apple refuse to get an iOS device Udid app? How to replace Udid?