SecureUDID 是一个开源的隔离设备标识符解决方案,旨在解决导致 Apple 弃用 UDID 的主要隐私问题。
SecureUDID 具有以下属性:
开发者仍然可以像以前使用 UDID 一样区分设备,但仅限于他们控制的范围内。
由于开发者基本无法访问其他开发者的相同 UDID,用户隐私受到保护。这大大限制了任何潜在泄漏的范围。
最终用户可以全局退出 SecureUDID 在所有使用它的应用程序和服务中的收集。
#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.
Crashlytics 团队需要在遵守隐私关注的同时解决 UDID 文件的问题。Crashlytics 想要将此贡献回社区。
在使用 SecureUDID 之前,您应该了解它的两个属性。首先,如上所述,标识符并非由硬件属性推导而来。其次,标识符的持久性不能在所有情况下保证。这意味着虽然在技术上可能存在两个不同设备报告相同标识符,或者同一设备报告不同标识符的情况,但这种可能性不大。在您的应用程序中请仔细考虑这一点。以下是该标识符不会显示传统 UDID 的唯一性和持久性的情况列表:
AppsFire在去年九月宣布了OpenUDID,作为对苹果公司淘汰UDID和我们自己的Sam Robbins作为第二个贡献者的初始回应。自那时以来,我们已经花了时间概述如何创建一个更安全的UDID,而所需的变化最终证明是重大的。为每个设备建立一个单一的标识符与MAC地址或苹果的UDID根本不同 - 隐私问题是一样的。
是的,SecureUDID不与任何其他UDID实现或框架冲突。
我们最初选择在iOS上实施SecureUDID,但这些概念可以同样应用于Android、Windows Phone以及其他平台。我们欢迎贡献!
在GitHub上Fork crashlytics/secureudid项目,提交issue,实现修复,并提交pull request!
2012年3月30日 - 1.1
2012年3月27日 - 1.0
2012年3月26日 - 0.9