了解 Trust Insights

一句话判断

Apple 终于把“防诈骗/防胁迫”做成了系统级 API，金融和社交 App 以后不用自己瞎猜用户是不是被洗脑了。

这场 Session 讲了什么

现在的黑客不攻系统，改攻人脑。骗子打着语音电话指导老人转账，用户自己刷脸、自己输密码，你 App 里的多因素认证（MFA）和生物识别全成了摆设。为了解决这种“合法用户被迫操作”的社会工程攻击，iOS 27 拿出了 Trust Insights（信任洞察）框架。

它通过 InsightEvaluator 评估用户当前操作（比如 payment 或 account）的上下文，利用设备端的机器学习模型判断用户是否正在被“指导”或“胁迫”（IsLikelyBeingCoachedInsight），并返回 unknown、medium 或 high 三个风险等级。

这对做金融、社交、高价值交易的团队影响最大。以前你们只能靠 IP、设备指纹和交易金额做风控，现在 Apple 把系统级的行为上下文（Behavioral Context）直接喂给你，你的风控引擎必须把这个信号接进去。

值得深挖的点

行为上下文（Behavioral Context）降维打击传统风控

传统风控的盲区在于“操作者是本人”。Apple 做 Trust Insights 的底气在于，它能拿到 App 拿不到的底层数据：交互模式、打字时序、传感器微调，甚至当前是否在进行持续的语音通话。这些设备级信号在本地处理后，只吐出一个风险评级。

这种设计的 trade-off 很明显：App 开发者成了黑盒的调用方。你只知道结果是 high，但不知道是因为用户在通电话，还是因为打字犹豫不决。Apple 明确建议，不要仅凭这个结果直接阻断交易（Block），而是增加摩擦（Friction），比如弹个警告、加个 24 小时延迟，或者把结果传给后端调整整体风险评分。这对习惯了“一刀切”拦截策略的风控产品经理来说，需要转变思路。

强制反馈闭环：开发者成了免费的数据标注员

这是我觉得最鸡肋但也最无奈的设计。为了让模型持续进化，Apple 强制要求每次评估后必须调用 reportConsumption 上报你的 App 是怎么处理这个结果的（比如 usedIncreasedFriction）。如果漏报，你的 App 会被限速（Throttle）。更狠的是，如果这笔交易几天后被证实是欺诈，你还得通过 Apple Business Register 提交离线标签（Offline labels）。

好的一面是，这确实能让全生态的防诈骗模型越来越准。坑在于，这极大地增加了后端的对接成本。你的业务系统必须能把“几天后的客诉/欺诈确认”和“几天前的 Trust Insights 评估 ID”关联起来，并定期跑批上报。对于中小团队，这套离线反馈机制的维护成本不低。

代码片段

1. 发起胁迫风险评估

场景：在用户点击“确认转账”时，异步请求 Trust Insights 评估。

import TrustInsights

// 构建请求，指定 schema 和模型版本
let request = IsLikelyBeingCoachedInsight.request(schema: .version1, modelVersion: .current)

// 设置上下文，operationCategory 决定底层应用哪种模型逻辑
let context = InsightEvaluator.InsightContext(
    operationCategory: .payment, // 支付场景
    requestedEvaluations: request
)

let evaluator = InsightEvaluator()

// 检查用户是否在系统设置中授权了 Trust Insights
guard try await evaluator.requestAuthorization(for: context) == .authorized else { 
    // 未授权时的降级处理
    return 
}

// 异步请求评估，注意这可能需要几秒钟，需要网络
let assessment = try await evaluator.requestEvaluation(context: context)

坑：requestEvaluation 是网络请求且耗时，千万别放在主线程同步等，最好配合现有的 Loading 动画或过渡页使用。

2. 处理结果与强制反馈

场景：根据风险等级增加 UI 摩擦，并必须上报消费结果。

do {
    let outcome = try assessment.insight.outcome.get()
    
    switch outcome {
    case .unknown:
        // unknown 不代表安全，只是系统没找到证据，保持原有流程
        proceedTransaction()
    case .medium:
        // 中等风险，增加轻微摩擦，如二次确认弹窗
        showConfirmationDialog()
    case .high:
        // 高风险，强烈警告或延迟交易
        showHighRiskWarningAndDelay()
    @unknown default:
        break
    }
    
    // 必须上报！否则会被限速
    // 根据实际情况选择 usedIncreasedFriction, usedUnchangedFriction 等
    assessment.reportConsumption(.usedIncreasedFriction)
    
} catch {
    // 处理评估级别的错误
    handleError(error)
    assessment.reportConsumption(.notUsedError)
}

坑：永远不要把 unknown 当作低风险（Low Risk）处理，它只是“未知”。另外，忘记调 reportConsumption 会导致后续请求被 Apple 服务端限速。

最佳实践

已有项目的风控系统不要试图用 Trust Insights 替换现有逻辑，而是把它作为一个新的特征维度（Feature）喂给你们的决策引擎。当返回 medium 或 high 时，在原有的风险评分上增加权重。

新项目在接入时，优先覆盖高价值且不可逆的场景：点对点大额转账、账户安全信息修改、远程访问权限授予。别在买个 6 块钱游戏道具的地方调这个 API，浪费资源且影响体验。

实战中最容易踩的坑是授权状态检查。用户随时可以在“设置”里关掉 Trust Insights。如果用户被骗子洗脑，骗子可能会诱导用户去设置里关闭它。Apple 为此设计了冷却期（Cool-down period），你的 App 在查到未授权时，UI 提示要委婉，别直接报错阻断。

还有什么值得关注

多模型版本采样：可以在请求中同时指定 modelVersion: .current 和之前的版本，方便你在生产环境做 A/B 测试，观察新模型对风控决策的影响。
隐私冷却期：用户在设置中关闭 Trust Insights 后，系统可能会触发冷却期，防止攻击者在实施诈骗前逼迫受害者关闭该功能。
结合 App Attest：Apple 建议将 Trust Insights 与 App Attest 结合使用，前者确认“人”没被胁迫，后者确认“请求”确实来自你的合法 App 实例。