Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

DEPRECATED - SecureUDID is an open-source sandboxed UDID solution aimed at solving the main privacy issues that caused Apple to deprecate UDIDs.

branch: master
README.md

SecureUDID is Deprecated

With the release of iOS 6, Apple made great strides towards offering a powerful, secure UDID replacement. Now that iOS 6+ makes up the vast majority of active iOS usage and in concert with Apple's official deprecation of the UDID, it is time to retire SecureUDID as well. We recommend using Apple's iOS 6 vendor and advertising identifiers instead. Check out our other Crashlytics Labs projects for the latest from the Crashlytics team!

For posterity...

image

What is SecureUDID?

SecureUDID is an open-source sandboxed device identifier solution aimed at solving the main privacy issues that caused Apple to deprecate UDIDs.

SecureUDIDs have the following attributes:

  1. Developers can still differentiate between devices as if they were still using a UDID, but only within apps they control.

  2. User privacy is protected since developers are fundamentally prevented from accessing the same UDID as another developer. This greatly limits the scope of any potential leaks.

  3. End-users can globally opt-out of SecureUDID collection across all applications and services that use it.

How do I use it?

#import "SecureUDID.h"

NSString *domain     = @"com.example.myapp";
NSString *key        = @"difficult-to-guess-key";
NSString *identifier = [SecureUDID UDIDForDomain:domain usingKey:key];
// The returned identifier is a 36 character (128 byte + 4 dashes) string that is unique for that domain, key, and device tuple.

FAQ

Who is behind SecureUDID?

The team at Crashlytics needed to address the UDID situation while still adhering to privacy concerns. Crashlytics wanted to contribute this back to the community.

Is this a true UDID replacement?

SecureUDID has two properties that you should know about before you use it. First, as indicated above, the identifier is not derived from hardware attributes. Second, the persistence of an identifier cannot be guaranteed in all situations. This means that, while unlikely, it is technically possible for two distinct devices to report the same identifier, and for the same device to report different identifiers. Consider this carefully in your application. Here is a list of situations where this identifier will not exhibit the uniqueness/persistence of a traditional UDID.

  • The user has opted-out of the SecureUDID system, in which case you will receive a well-formed string of zeroes.
  • Device A is backed up and then restored to Device B, which is an identical model. This is common when someone breaks their phone, for example, and is likely desirable: you will receive Device A's SecureUDID.
  • 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 are uninstalled from a device, followed by a UIPasteboard data purge.
What about OpenUDID?

AppsFire unveiled OpenUDID back in September as one of the initial responses to Apple's deprecation of UDIDs and our very own Sam Robbins was its second contributor. Since then, we've spent time outlining what would make a more secure UDID, and the changes required turned out to be significant. Establishing a single identifier per device is fundamentally no different than a MAC address or Apple's UDID - the privacy concerns are the same.

Can I use SecureUDID with other UDID frameworks, including OpenUDID?

Yes, SecureUDID does not conflict with any other UDID implementation or framework.

What about Android?

We chose to initially implement SecureUDID on iOS, but the concepts can be applied equally to Android, Windows Phone, and other platforms. We welcome contributions!

How can I get involved?

Fork the crashlytics/secureudid project on GitHub, file issues, implement fixes, and submit pull requests!

Version History

May 1, 2012 - 1.1.1

  • Corrected use of availability macros
  • Removed an incorrect use of ARC qualifier in SUUIDHash
  • Lowered the minimum SDK target in the Xcode project to 3.1
  • Added some safer explicit casting after object deserialization

March 30, 2012 - 1.1

  • Greatly improved robustness to backing store corruption/correctness
  • Groundwork for Opt-Out application interface
  • Additional API for Opt-Out query and background identifier derivation
  • Support for unlimited number of installed SecureUDID applications
  • Renamed API to de-emphasize the notion of a salt
  • Improved detection of backup/restore

March 27, 2012 - 1.0

  • Per-Owner dictionary implementation to support Opt-Out functionality
  • Addressed an issue that could result in pasteboard overwriting

March 26, 2012 - 0.9

  • First public release
Something went wrong with that request. Please try again.