GDPR Consent — 本质、要求与获取同意

什么是GDPR Consent？

GDPR Consent是根据欧盟《通用数据保护条例》第4(11)条和第7条规定的处理个人数据的法律依据。该条例于2018年5月25日生效，取代了过时的95/46/EC指令，为所有欧盟成员国制定了统一的数据保护标准。

根据GDPR，同意必须是自由的——用户必须有真实的选择，拒绝时无负面后果。如果拒绝同意导致无法访问不需要数据处理的服务的访问，则该同意被视为受到强迫且无效。第7(4)条明确指出，相关合同条款不得以获取对履行合同并非必要的数据处理的同意作为履行合同的条件。

知情——第二个关键要素：数据主体必须了解具体收集哪些数据、出于什么目的、由谁处理以及数据将保存多久。欧洲数据保护委员会（EDPB）在05/2020号指南中强调，信息必须以易于理解的语言提供，不得使用复杂的法律术语。实践表明，如果隐私政策包含含糊或笼统的表述，同意将被视为无效。

毫不含糊意味着同意必须通过积极行为表达——勾选复选框、点击按钮或签署表单。不作为、沉默或预先勾选的复选框不符合明确性要求。欧洲法院在Planet49 GmbH案（C-673/17）的判决中确认，同意不能从用户的不作为中推断。

哪些数据受GDPR管辖

根据GDPR，个人数据是指与已识别或可识别的自然人有关的任何信息。这包括不仅明显的标识符——姓名、地址、电子邮件、电话，还包括IP地址、Cookie标识符、设备广告标识符（IDFA、GAID）、生物识别数据、地理位置和基因信息。

GDPR第9条列出了特殊类别数据，未经明确同意禁止处理：种族或民族出身、政治观点、宗教信仰、工会会员身份、基因和生物识别数据、健康数据和性取向数据。对于此类类别，需要最严格的同意形式——单独的、详细的且不能从一般上下文中推断的同意。

何时需要GDPR Consent

当数据处理不能基于其他合法依据时——合同必要性（第6(1)(b)条）、合法利益（第6(1)(f)条）或履行法律义务（第6(1)(c)条）——则需要GDPR Consent。在实践中，同意对于营销邮件、广告跟踪、收集非必要数据以及使用非服务运行所必需的Cookie文件是必要的。

根据IAPP-EY年度治理报告（2024）的研究数据，67%的公司使用同意作为移动应用中数据处理的主要法律依据，尽管在可能的情况下向合法利益过渡的趋势正在增长。这是因为同意提供了与用户最透明的关系，但同时也在同意的记录和管理方面施加了最大的义务。

GDPR对同意的核心要求

GDPR第7条规定了同意有效的六个条件，每个条件必须同时满足。违反任何一个条件都会使同意无效，数据处理也变为非法。让我们结合EDPB指南和司法实践详细讨论每个条件。

自由性——当控制者与数据主体之间存在权力不平衡时，同意即被违反。EDPB明确指出，由于劳动关系中的依赖性，雇主不能依赖员工的同意。同样，政府机构在提供公共服务时不能要求公民的同意。

具体性要求为每个处理目的分别获得同意。如果应用收集数据用于分析、广告个性化和服务改进——每个目的都需要单独的复选框。将多个目的合并为一项同意违反了具体性要求，使同意无效。

可证明性——技术上最具挑战性的要求。第7(1)条明确指出，控制者承担证明已获得同意的举证责任。在实践中，这需要维护所有用户行为的日志：谁、何时、出于什么目的给予了同意，显示了哪个版本的隐私政策，以及用户如何撤回同意。

如何在移动应用中实施同意收集

在移动应用中实施GDPR Consent需要综合方法，结合法律要求和技术实现。主要工具是同意管理平台（CMP），它管理同意的整个生命周期：显示请求、记录选择、存储数据以及与广告和分析SDK同步。

使用Google UMP SDK

Google为Android和iOS提供了User Messaging Platform (UMP) SDK，它与AdMob、Google Analytics和其他Google服务集成。UMP SDK根据用户的地理位置和GDPR要求自动确定是否需要显示同意。让我们看看Android的Kotlin集成：

val requestParams = ConsentRequestParameters
    .Builder()
    .setTagForUnderAgeOfConsent(false)
    .build()

ConsentInformation
    .getInstance(this)
    .requestConsentInfoUpdate(requestParams, { @Override
        fun onConsentInfoUpdateSuccess() {
            if (ConsentInformation
                    .getInstance(this@MainActivity)
                    .isConsentFormAvailable()
            ) {
                loadConsentForm()
            }
        }
    }, { @Override
        fun onConsentInfoUpdateFailure(error: FormError) {
            Log.e("UMP", error.message)
        }
    })

加载同意表单后，需要向用户显示。UMP SDK支持两种类型的表单：用于获取个性化广告同意的表单和用于将来管理选择的表单。结果处理必须考虑所有可能的结果——用户可能给予同意、拒绝或在未做选择的情况下关闭表单。

同意的存储和验证

为了满足可证明性要求，不仅需要存储同意的事实，还需要存储其获取的上下文。需要存储的最小数据集包括：用户或设备标识符、带时区的时间戳、隐私政策版本、具体的处理目的和所使用的同意机制。

data class ConsentRecord(
    val userId: String,
    val timestamp: Long,
    val privacyPolicyVersion: String,
    val purposes: List<String>,
    val consentGiven: Boolean
)

class ConsentRepository(
    private val dao: ConsentDao
) {
    suspend fun saveConsent(record: ConsentRecord) {
        dao.insert(record.toEntity())
        AnalyticsManager.logConsentEvent(record)
    }
}

欧洲数据保护委员会（EDPB）在01/2023号建议中强调，同意记录必须在整个数据处理期间保存，并在处理终止后保存三年。对于移动应用，这需要在服务器端存储记录，而不仅仅是本地存储，因为用户可能重新安装应用或更换设备。

GDPR与其他隐私法规的区别

GDPR并非世界上唯一的隐私法规，但它已成为许多国家数据保护法律的蓝本。理解GDPR与其他法规之间的差异对于处理来自不同司法管辖区的用户的国际应用开发者至关重要。

CCPA（加州消费者隐私法案）与GDPR有根本不同：它采用选择退出模式，而非选择加入模式。根据CCPA，公司必须为用户提供拒绝出售其数据的权利，但无需在收集前获得同意。然而，随着2023年CPRA（加州隐私权法案）的通过，对敏感数据的同意要求已更接近GDPR。

ePrivacy Directive（电子通信隐私指令）在Cookie和电子营销方面补充了GDPR。与规范所有个人数据的GDPR不同，ePrivacy侧重于通信数据。对非必要Cookie的同意要求正是源于ePrivacy而非GDPR，尽管同意机制相同。

巴西的LGPD几乎完全复制了GDPR的结构，仅有细微变化：同意年龄提高到18岁，对已故者数据的处理需要继承人的同意。相比之下，中国的PIPL引入了更严格的要求：数据强制本地化、所有自动化决策的数据保护影响评估（DPIA）以及数据跨境传输的通知。

实施GDPR Consent时的典型错误

对2018-2024年欧洲监管机构罚款和指令的分析显示，在实施同意方面反复出现违规行为。根据Enforcement Tracker（CMS Law, 2024）的数据，超过40%的GDPR相关罚款与不当获取和管理同意有关。让我们看看最常见的错误。

预先勾选的复选框和被动同意

最常见的错误——使用预先勾选的复选框来获取同意。欧洲法院对Planet49 GmbH案（C-673/17）的判决明确规定，同意不能从用户的不作为中推断。尽管如此，许多应用继续使用预先勾选的选项，尤其是在Cookie横幅中，这直接导致罚款和指令。

法国国家信息与自由委员会（CNIL）在2024年对一家大型RTB广告控股公司处以2.5亿欧元罚款，原因是使用预先勾选的复选框以及对用户的通知不够透明。这是与同意相关条款中金额最高的罚款，表明欧洲监管机构对同意管控的优先性。

将不同目的合并为一项同意

许多应用要求对所有类型的处理——分析、个性化、广告、向第三方传输——给予一项通用同意。这直接违反了具体性要求（目的限制）。EDPB在05/2020号指南中强调：如果一个目的可以在没有另一个目的的情况下实现，用户应有权分别同意每个目的。

爱尔兰数据保护委员会（DPC）在对Meta Platforms Ireland（2023）的决定中指出，将广告个性化和服务改进合并为一项同意是违规行为。Meta被强制要求在Facebook和Instagram中为不同的处理目的实施单独的同意机制。

困难或无法撤回同意

GDPR要求撤回同意应与提供同意同样简单。如果用户通过点击一次按钮就给予了同意，撤回不能要求填写表格、发送电子邮件或致电支持。在实践中，许多应用将撤回机制隐藏在设置深处，或需要多个步骤才能执行。

推荐做法——在应用设置中添加单独的同意管理界面，可以通过开关分别撤回每项同意。Google的UMP SDK提供了内置机制，用于重新显示同意表单，用户可以随时从应用设置中调用该表单。

缺乏获得同意的证据

许多开发者依赖口头同意或未保存获得同意的记录。这无法满足GDPR第5(2)条规定的可证明性（问责制）要求。在检查时，监管机构不仅会要求隐私政策，还会要求整个数据处理期间的同意日志。

解决方法是使用带有自动事件日志记录的同意管理平台（CMP）：表单显示、用户选择、文档版本、时间戳。适用于移动应用的流行CMP包括Usercentrics、OneTrust和ConsentManager——它们都支持同意的自动审计记录。