Apple begins rejecting apps that access UDID

Apple has begun rejecting iOS apps that access the device's UDID, which is the unique identification number that is attached to every iPhone and iPad, supposedly due to privacy scrutiny from Congress.

While the move was telegraphed by Apple in iOS documentation over half a year ago, these reported rejections are ahead of schedule and the first confirmation that Apple is indeed rejecting apps outright for using UDIDs. According to TechCrunch, two of Apple's ten app review teams have started rejecting all apps that access UDIDs as of last week. Two more teams will start rejecting apps this week, and keep escalating until all 10 teams are rejecting these apps.

The UDID was a privacy concern because it is permanently linked to the specific iPhone or iPad device, and security researchers discovered that some apps were transmitting user data out to remote servers, with real names in plain-text attached to the UDID. Even without specific information like a user's name or contact information, the UDID could identify a user with collected data.

Aside from the privacy concerns, Apple's rejection of apps that access UDIDs is a major issue for another reason: Advertising networks use the UDID to track data and improve advertisements, so a whole industry and a whole lot of money is tied into accessing this information. Without it, the ad agencies would have to figure out new ways to track data and statistics for their purposes. This could also have an impact upon app developers, who may have to spend significant amounts of time and resources to remove UDID access to update pre-existing apps.

Report a problem with article
Previous Story

More Windows 8 pre-Release Candidate screenshots leaked

Next Story

Hacker group taking over LulzSec name for new attacks

9 Comments

Commenting is disabled on this article.

Either do or don't, why roll it over the 10 teams gradually instead of giving them all the memo at once. Leads to inconsistency.
Why allow apps to use it at all if it is not allowed? If they changed their mind about using it, then just block it from working in the API in a software update (and give devs fair warning) rather than make it a manual part of the review process.

Simon- said,
Either do or don't, why roll it over the 10 teams gradually instead of giving them all the memo at once. Leads to inconsistency.
Why allow apps to use it at all if it is not allowed? If they changed their mind about using it, then just block it from working in the API in a software update (and give devs fair warning) rather than make it a manual part of the review process.

Yoda was more concise.

They just need a way to confirm with Apple that a device is unique, not access an actual value.

Simon- said,
Either do or don't, why roll it over the 10 teams gradually instead of giving them all the memo at once. Leads to inconsistency.
Why allow apps to use it at all if it is not allowed? If they changed their mind about using it, then just block it from working in the API in a software update (and give devs fair warning) rather than make it a manual part of the review process.

Devs do get fair warning, it is marked as "Deprecated" in the API documentation, which means don't use it as it may be removed at a future date. They can't just go and remove it as existing apps (which may never recieve an update) would just stop working. What they are doing now is scanning for use of the particular method (similar to their private API checks) and rejecting on that basis.

Simon- said,
Either do or don't, why roll it over the 10 teams gradually instead of giving them all the memo at once. Leads to inconsistency.
Why allow apps to use it at all if it is not allowed? If they changed their mind about using it, then just block it from working in the API in a software update (and give devs fair warning) rather than make it a manual part of the review process.

The implementation was probably considered far more heavily than I could offer, but I agree it seems a strange way to handle both the security aspects of the usage and moving developers away from its usage.

Why not just deprecate the functionality, or is there no way to update iOS to keep Apps from grabbing this information from the hardware due to the lower levels of access granted to Apps?

WP7 originally also had a UniqueID functionality (Which was a carry over of the device API set going back to the PocketPC days), but it was deprecated and removed so Apps no longer have a way to obtain the information.

However, the Unique Device ID is only a part of the problem, as this type of security and privacy issue isn't stopped by restricting just the use of this information by an App.

A developer can still triangulate the User Info along with other system information that is unique and available in the iOS framework. (For example, even just pulling the UserID and the global key locks identity information to a single device.)

It is good that Apple is addressing this issue, but it is a bit late and also there are so many other big holes in the overall security model of iOS Apps from the way background encryption is handled to limited isolation, and on and on.

Apple's main approach to security is the review and certification process, which is good, but doesn't address holes in this process that their review process could easily miss. Just a bit of obfuscation and behaving 'properly' when it knows it is in the test environment will allow it to pass, and then cause harm once it is running on a user's device.

Which is why the 'upfront' review/certification process has flaws that don't protect the user when this system fails to catch malicious software, especially software that is using web services to share information with that can change on the server side.

No matter what is thought of WP7, Apple would be smart to pay attention to its security model at both the kernel, and platform levels. It has very rigid App isolation and restricted hardware access. (Which is a complaint for developers that just want to port code that is hardware specific, or access parts of the OS and other Apps that they easily have access to doing on iOS and Android.)

Microsoft's certification process is also more robust than Apple's, that literally rips uses test users to rip the App apart and looks for code that is attempting malicious behavior. Additionally, sharing of information by the App to a server requires a certification process for the server that is linked to the unique AppID. So if the server side functionality of an App changes that obtains information, the certification has to be recreated, so that all data sharing is known and approved by the 'complete' certification process.


At least Apple is getting it, or being forced to get it through the scrutiny of the public eye. If they are going to be a leader, they must take on the mantle of providing a higher level of security than they have been held responsible in the past. I just hope this continues beyond a few fixes to make the inquiries go away and extends to a more robust security model, even if they have to break some eggs to do it, since iOS wasn't created with a strong security model at the start.

At least Apple has a chance to make progress, where Google doesn't seem to get it or care about Android, and even if they did, would require a rewritten OS model from the ground up, breaking most Apps. Android, essentially is as close to no security as any OS we have seen in the last 20 years. Its internal security model is not even used in Dalvik, there is no real sense of App isolation, and there is no screening or review process for App publishing or certification of the developers. Google is either overwhelmed with the thought of securing the platform and avoid it, or don't care and avoiding it.

thenetavenger said,

At least Apple has a chance to make progress, where Google doesn't seem to get it or care about Android, and even if they did, would require a rewritten OS model from the ground up, breaking most Apps. Android, essentially is as close to no security as any OS we have seen in the last 20 years. Its internal security model is not even used in Dalvik, there is no real sense of App isolation, and there is no screening or review process for App publishing or certification of the developers. Google is either overwhelmed with the thought of securing the platform and avoid it, or don't care and avoiding it.
Source?