优化您的 iOS SDK 以适应 Safari 的 ITP 与跟踪预防机制 (ZH)

拥抱第一方上下文 Safari 的 ITP 严格限制第三方 Cookie。设计您的 iOS SDK，使其尽可能在第一方上下文中运行，利用服务器端解决方案或直接集成。

优先使用隐私保护标识符 摒弃持久的跨站点标识符。专注于临时或用户同意的标识符，尊重用户隐私设置和 Apple 的应用跟踪透明度框架。

实施强大的回退机制 预期某些数据点或跟踪机制可能会被阻止。构建您的 SDK 时，应具备优雅降级和回退策略，即使 ITP 处于活动状态，也能保持核心功能。

及时了解 Apple 的政策 ITP 和隐私政策是动态变化的。定期查阅 Apple 的开发者文档和隐私更新，以确保您的 SDK 保持合规和有效。

Safari 的智能跟踪预防 (ITP) 从根本上重塑了网络跟踪格局，特别是对于依赖第三方 Cookie 和持久标识符的开发者而言。对于 iOS SDK，这带来了一系列独特的挑战，尤其是在与网页视图集成或处理跨域通信时。Apple 对用户隐私的持续承诺，通过应用跟踪透明度 (ATT) 等功能和更严格的数据收集政策得到加强，这意味着 SDK 开发者必须积极调整其策略，以确保功能性、维护数据完整性并尊重用户同意。

这篇博文深入探讨了 iOS 上 Safari 中 ITP 和类似隐私机制的复杂性，提供了可操作的见解和实际示例来优化您的 SDK。我们的目标是帮助您构建弹性、保护隐私的 SDK，使其不仅能可靠运行，还能在日益注重隐私的数字世界中赢得用户信任。

了解 Safari 的 ITP 及其对 iOS SDK 的影响

智能跟踪预防 (ITP) 是 Safari（和 WebKit）中内置的一套增强隐私的技术。其主要功能是通过限制第三方使用 Cookie 和其他形式的网站数据来限制跨站点跟踪。多年来，ITP 已经经历了多次迭代，每次都引入了更严格的控制：

• 阻止第三方 Cookie： 最重要的方面。ITP 积极地分区或阻止第三方 Cookie，使广告商和分析提供商难以跟踪用户跨不同网站的行为。
• Storage Access API： 作为一种隐私保护方式引入，允许嵌入式内容在用户与其互动时请求访问其第一方存储。
• 链接装饰保护： ITP 还可以从 URL 中移除跟踪参数，以防止通过链接装饰进行跟踪。
• Referrer Policy： Safari 通常会发送更严格的 referrer policy（例如，strict-origin-when-cross-origin），限制传递给第三方网站的信息量。
• 临时跳出跟踪预防： 识别并缓解跟踪器通过其网站重定向用户以设置第一方 Cookie 的技术。

对于 iOS SDK，特别是那些与网络内容交互的 SDK（例如，应用内浏览器、身份验证流程、支付网关或嵌入式分析），ITP 的影响可能是深远的。如果您的 SDK 依赖于在 WKWebView 中设置或读取来自第三方域的 Cookie，或者它期望传递某些 referrer 信息，ITP 可能会破坏这些机制，导致：

• 身份验证或支付流程失败。
• 归因或分析数据不准确。
• 由于缺少状态或会话信息而导致的用户体验受损。

ITP-Proof iOS SDK 开发策略

适应 ITP 需要将思维方式从传统跟踪转向以隐私为中心的数据处理。以下是关键策略：

1. 优先考虑第一方上下文和服务器端解决方案

规避 ITP 对第三方 Cookie 限制的最有效方法是在第一方上下文中操作。这意味着设置 Cookie 或访问存储的域与用户当前访问的域相同。

实际示例：用于分析的服务器端跟踪

与其依赖嵌入在您的 WKWebView 中并尝试设置自己的 Cookie 的第三方分析脚本，不如考虑服务器端方法：

1. SDK 收集数据： 您的 iOS 应用（或 WKWebView 中的网络内容）收集相关的用户交互数据（例如，查看的产品、点击的按钮）。
2. 将数据发送到您的后端： 这些数据直接发送到您自己的后端服务器。
3. 后端转发给分析提供商： 您的后端随后将这些数据转发给您的分析提供商的 API。由于这种通信发生在服务器到服务器之间，因此它绕过了 ITP 对客户端 Cookie 的限制。

这种方法使您能够完全控制数据，确保数据可靠发送，并且不受浏览器端跟踪预防的影响。

2. 利用 Storage Access API 处理跨站点需求

当您绝对需要在嵌入式 WKWebView 中访问跨站点 Cookie 时（例如，用于与身份提供商进行单点登录），Storage Access API 是经批准的、保护隐私的方法。此 API 允许第三方内容请求用户明确许可，以访问其第一方存储。

实际示例：WKWebView 中的无缝 SSO

想象一下，您的 SDK 嵌入了一个 WKWebView，用于需要访问您的身份提供商 (IDP) 的 Cookie 以实现 SSO 的身份验证流程。如果没有 Storage Access API，Safari 将阻止这些 Cookie。

客户端（在您的嵌入式网络内容中）：

document.requestStorageAccess().then(function() {
    // 存储访问已授予，现在您可以发出使用 Cookie 的请求
    // 例如，加载 SSO iframe 或向 IDP 发出 XHR 请求
}).catch(function() {
    // 存储访问被拒绝或需要用户交互
    // 优雅地处理，也许回退到完整的重定向登录
});

iOS SDK (WKUIDelegate 和 WKNavigationDelegate)：

您需要处理 Safari 呈现的用户提示。WKUIDelegate 方法 webView:requestMediaCapturePermissionFor:initiatedBy:decisionHandler:（或类似的权限请求）可能会被调用，但对于存储访问，提示通常由 Safari 本身处理。确保您的 WKWebViewConfiguration 设置正确，特别是 websiteDataStore。

3. 采用隐私保护标识符和用户同意

借助应用跟踪透明度 (ATT)，Apple 要求用户明确同意才能在其他公司拥有的应用和网站之间进行跟踪。您的 SDK 应尊重这一点。在未经同意的情况下，停止依赖持久设备标识符进行跟踪。

实际示例：处理 ATT 和 IDFA

如果您的 SDK 以前依赖广告标识符 (IDFA) 进行归因或定位：

1. 请求 ATT 授权： 在访问 IDFA 之前，使用 AppTrackingTransparency.framework 请求用户授权。
2. 有条件地使用 IDFA： 仅当用户授予权限时才检索和使用 IDFA。
3. 替代标识符： 如果拒绝，则依赖于特定上下文的临时标识符（例如，会话 ID）或服务器生成的非持久性 ID，这些 ID 不用于跨站点跟踪。

Swift 示例：

import AppTrackingTransparency
import AdSupport

func requestTrackingAuthorization() {
    if #available(iOS 14, *) {
        ATTrackingManager.requestTrackingAuthorization { status in
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
                print("IDFA: \(idfa)")
                // 使用 IDFA 进行已同意的跟踪
            case .denied, .notDetermined, .restricted:
                print("ATT 授权被拒绝或未确定。")
                // 依赖其他隐私保护方法
            @unknown default:
                break
            }
        }
    } else {
        // iOS 14 之前版本的备用方案
        // 通过 ASIdentifierManager.shared().isAdvertisingTrackingEnabled 检查跟踪是否启用
    }
}

Didit 如何提供帮助

Didit 作为一个一体化身份平台，天生就符合隐私优先的方法，使其能够有效应对 ITP 和类似的跟踪预防机制。我们的核心重点是安全地验证真实人类，而不是进行跨站点跟踪。Didit 的架构旨在在一个单一、受控的系统中处理身份验证、生物识别、欺诈检测和认证，从而最大限度地减少对第三方跟踪 Cookie 的依赖。我们通过以下方式实现这一点：

• 第一方集成： Didit 的 SDK 和 API 旨在直接、第一方集成到您的应用程序中，确保身份验证过程在您的应用程序上下文中进行，从而在很大程度上绕过与跨站点跟踪相关的 ITP 问题。
• 服务器端处理： Didit 的许多强大功能，例如 AML 筛选和欺诈信号分析，都是在服务器到服务器之间运行的。这意味着敏感数据处理和身份检查在我们的后端安全进行，消除了客户端跟踪漏洞。
• 临时生物识别： Didit 在内存中处理生物识别数据并将其删除，只向您的应用程序返回布尔结果。这种“设计即隐私”的方法意味着我们不存储持久的生物识别标识符用于跟踪，这与 ITP 的目标完美契合。
• 安全身份验证流程： 我们的身份验证方法，包括生物识别重新身份验证，旨在安全和私密，使用不依赖跨站点 Cookie 进行状态管理的挑战-响应机制。
• 合规性和信任： Didit 符合 SOC 2 Type II、ISO 27001 和 GDPR 标准，建立在数据隐私和安全的基础上，这自然使我们的平台能够抵御跟踪预防技术的变化。

准备好开始了吗？

为 Safari 的 ITP 和更广泛的隐私环境调整您的 iOS SDK 不仅仅是为了合规性；更是为了与用户建立信任并确保您的产品的长久发展。通过拥抱第一方上下文，利用 Storage Access 等适当的 API，优先考虑用户同意，并及时了解 Apple 不断变化的政策，您可以创建强大且尊重隐私的 SDK。

探索 Didit 的隐私优先身份平台如何简化您的合规性并增强用户体验。访问我们的网站，查看我们的技术文档，或请求演示以了解 Didit 的实际应用。