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!
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:
Developers can still differentiate between devices as if they were still using a UDID, but only within apps they control.
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.
End-users can globally opt-out of SecureUDID collection across all applications and services that 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.
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.
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.
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.
Yes, SecureUDID does not conflict with any other UDID implementation or framework.
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!
Fork the crashlytics/secureudid project on GitHub, file issues, implement fixes, and submit pull requests!
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