4. 设备标识的采集与合规

设备标识是移动端风控、反欺诈、账号安全体系的基础数据。没有稳定、可解释、可追溯的设备标识，账号风险关联就无从谈起。但在真实业务中，设备标识的采集从来不是纯技术问题，它同时受到操作系统权限、应用商店政策、用户授权意愿以及GDPR、CCPA、《个人信息保护法》等法规的约束。本节围绕“怎么采、怎么授权、怎么合规、怎么落地”四个层面展开。

一、核心原理：设备标识的三种稳定性层级

移动端可获取的标识种类很多，但它们的稳定性、可重置性和跨应用能力差异极大。工程上通常按“稳定性层级”来理解：

• 硬件级标识：如IMEI、MEID、序列号。唯一性强、难以重置，但属于敏感个人信息，Android 10以后普通应用基本无法获取，iOS早已不可用。
• 系统级标识：如Android的OAID、AAID（Google Advertising ID）、iOS的IDFV、IDFA。由系统或厂商提供，可被用户重置，其中IDFA还需ATT授权。
• 应用级标识：如自生成的UUID、Keychain/Keystore持久化ID、安装ID。卸载重装或清除数据后会变化，但完全由应用掌控，合规风险最低。

风险关联的实践原则是：不依赖单一标识，而是构建“标识组合+置信度”模型。例如用OAID作为主标识，IDFV/AAID作为辅助，自生成UUID作为兜底，再结合IP、机型、屏幕、时区等软指纹进行交叉验证。这样既降低了对敏感标识的依赖，也提升了关联的鲁棒性。

二、采集方式与授权流程

合规采集的核心是“告知—授权—最小必要—可撤回”。下面是一个典型的采集与授权流程：

1. 启动时判断授权状态：检查是否已获得用户同意，未同意则不采集任何非必要标识。
2. 展示隐私政策与授权弹窗：明确告知采集哪些标识、用于什么目的、保存多久、与谁共享。
3. 用户同意后初始化采集：按平台能力依次尝试获取标识，失败则降级。
4. 本地持久化与加密：标识写入Keychain/Keystore或加密SharedPreferences。
5. 提供撤回入口：用户可随时关闭个性化或撤回授权，系统应停止采集并清理可清理的数据。

以Android获取OAID为例，典型调用逻辑如下：

// 伪代码：在用户同意后初始化OAID
if (userConsent.granted) {
    OaidClient client = new OaidClient(context);
    client.getOaid(new OaidCallback() {
        @Override
        public void onSuccess(String oaid, boolean isLimitAdTracking) {
            if (!isLimitAdTracking) {
                deviceRepo.saveOaid(encrypt(oaid));
            } else {
                deviceRepo.saveOaid(null); // 用户限制跟踪，不采集
            }
        }
        @Override
        public void onFail(String msg) {
            deviceRepo.saveOaid(null); // 降级到自生成UUID
        }
    });
}

iOS侧则需先请求ATT授权，再读取IDFA：

// iOS：先请求ATT，再读取IDFA
if #available(iOS 14, *) {
    ATTrackingManager.requestTrackingAuthorization { status in
        if status == .authorized {
            let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
            DeviceRepo.shared.saveIDFA(idfa)
        } else {
            DeviceRepo.shared.saveIDFA(nil) // 未授权，不采集
        }
    }
}

三、三大法规的核心要求对比

GDPR、CCPA与《个人信息保护法》在设备标识上的要求有共性也有差异，下表做了归纳：

四、案例与复盘：一次因标识采集不当导致的下架

某工具类App在启动时即读取IMEI和MAC地址，未弹窗告知，也未提供撤回入口。上线后被检测机构通报，应用商店下架整改。复盘发现三个问题：一是采集时机过早，未等用户同意；二是采集范围超出必要，IMEI对核心功能并非必需；三是没有降级方案，导致合规改造后风控关联能力骤降。

整改方案值得借鉴：

• 把采集时机推迟到用户同意之后，并区分“必要”与“非必要”标识。
• 用OAID+自生成UUID替代IMEI，保留关联能力的同时降低敏感度。
• 建立标识置信度评分：OAID权重高，UUID权重中，软指纹权重低，综合判断设备是否为同一台。
• 增加隐私中心，用户可查看已采集的标识类型并一键撤回。

整改后，该App的设备关联准确率从原来的92%降至87%，但合规风险大幅下降，且通过软指纹补偿，长期关联能力反而更稳定。这说明合规不是简单地“少采”，而是“采得对、采得明、可解释”。

五、落地清单

• 建立设备标识清单：列出每个标识的来源、稳定性、是否敏感、是否可重置。
• 采集前必须获得用户同意，敏感标识需单独同意。
• 提供降级链路：主标识不可用时自动切换到备用标识。
• 本地存储加密，传输使用HTTPS，服务端脱敏存储。
• 提供撤回与删除入口，并确保撤回后停止采集。
• 定期做合规审计，关注应用商店政策与法规更新。