文章分类
7.4减轻处理许可方面的挑战
获得个人数据处理许可的第二步是通过（1）请求许可和（2）存储许可来处理许可。公司在这些行动中面临着几个挑战（表8）。TCF提供了缓解挑战的工具，我们将在本节中介绍。
7.4.1协助请求许可
7.4.1.1全球供应商列表（GVL）
根据TCF，公司必须满足的要求，才能处理数据处理许可，这取决于公司是出版商（第2.1节）还是供应商（第2.4节）。发布者和供应商在处理权限方面的关键区别在于，发布者与用户直接接触并自行请求权限，而供应商与用户没有直接接触，需要依赖发布者代表供应商请求用户权限。
第7.1.2节指出，请求许可具有挑战性。为了获得许可，供应商必须告知其合作伙伴出版商其需要此类许可的目的。由于出版商与许多供应商合作，出版商必须集中所有供应商的许可请求。供应商及其各自请求的异质性使得集中化供应商权限具有挑战性。在TCF内，供应商通过注册流程统一披露其所需目的。第7.3节中引入的标准化注册流程和标准化目的规范简化了集中供应商许可请求的挑战。
要在TCF注册，供应商必须具有足够的声誉（例如，在某些行业协会中是信誉良好的成员），并支付1500欧元的年费。向TCF注册的供应商披露了其所追求的TCF规定的（特殊）目的和（特殊）功能（表9-12）。同时，供应商还决定这些（特殊）用途和（特殊）功能的法律依据。在宣布合法利益为GVL的法律基础时，供应商必须证明他们已经进行了充分的合法利益评估（LIA），以平衡用户和供应商的利益。IAB Europe为如何做到这一点提供了指导。
收到供应商的注册申请后，IAB Europe将验证供应商的身份以及供应商在遵守TCF法规的同时维持其服务的能力。批准的供应商出现在全球供应商列表（GVL）（www.iabeurope.eu/Vendor-List-tcf-v2-0）上。GVL是TCF注册供应商以及每个供应商使用的各自（特殊）用途和（特殊）功能的列表。GVL通过其官方网站公开，每周更新一次，提高了每个供应商的数据处理透明度。
请注意，IAB Europe进行的验证过程不保证GDPR合规性。换句话说，TCF没有证明其批准的供应商完全符合GDPR。
从GVL中，出版商知道每个供应商追求的TCF目的以及法律依据。然后，出版商从GVL中选择其打算合作的供应商（以下称为合作伙伴供应商）。默认情况下，每个供应商根据GVL追求的目的适用于所有出版商。如果发布者希望特定TCF目的的法律依据与特定供应商指定的不同，则发布者可以使用发布者限制来修改其协作方式。例如，如果特定供应商将合法权益用于目的3，则出版商可以限制TCF目的并要求获得同意。通过这种方式，出版商和供应商可以更灵活地合作。
如果供应商更改其使用的（特殊）用途和（特殊）功能，则需要更新其提供给IAB Europe的信息。这些更新包含在GVL的下一次每周更新中。通过连接到GVL，所有出版商都可以通过其CMPs（也在TCF注册；参见第7.4.1.2节）自动访问最新版本。然而，假设更新需要更多的权限，因为额外的（特殊）用途和（特殊）功能、额外的供应商，或者法律基础从合法权益变更为同意。在这种情况下，发布者需要再次请求所有用户的许可。
总之，TCF的注册流程和GVL规范了供应商如何向出版商披露其目的。此外，该流程和GVL为出版商集中和管理其合作伙伴供应商的权限提供了一种有效的方法。
7.4.1.2在TCF注册的许可管理平台（CMP）
要获得用户许可，出版商需要在其网站上设置cookie横幅。由于公司在设计和运行cookie横幅方面面临技术挑战（第7.1.1节），出版商依赖在TCF注册的CMP（第6.1节）来帮助设计和运行cookie横幅。与供应商一样，CMP也必须向TCF提交注册申请，并支付1500欧元的年费。IAB Europe验证CMP的技术操作是否符合TCF法规。同样，通过验证并不能保证CMP完全符合GDPR。如果发行商参与TCF，则必须使用TCF注册CMP公开列表中的CMP。发布者可以使用商业CMP服务或注册自己的（私有）CMP。截至2021 11月，TCF共有170家注册CMP。其中53人（31%）是私人中医。
TCF注册的CMP为设计和运行cookie横幅提供技术支持。更重要的是，只有TCF注册的CMPs才能创建、更新和存储透明度和同意字符串，这是一个存储同意的工具，我们将在下一小节中介绍。
TCF注册的CMPs必须遵守TCF指南。IAB Europe随机审核CMPs，以确保在出版商网站上正确实施TCF，如果发生违规行为，可以对CMPs提出警告。三次警告后，TCF可以暂停CMP，这意味着所有发布者都不能再使用暂停的CMP。因此，IAB Europe为CMPs提供了强大的激励，以确保出版商在使用其服务时正确实施TCF。
7.4.2使用透明度和同意字符串（TC字符串）促进存储许可
出于两个原因，为用户存储许可在技术上具有挑战性。首先，有很多信息需要存储。例如，对于每个供应商的每个目的，用户可以决定是否为此目的提供许可。其次，发布者必须以允许供应商轻松访问和读取存储的信息的方式存储许可信息。TCF创建了透明度和同意字符串（TC字符串）来处理这两个问题。
TC字符串是一段编码字符串，用于捕获和存储有关用户的权限决定和发布者的其他隐私偏好的所有信息。TC字符串包括（1）与出版商合作的每个供应商的（特殊）目的和（特殊）功能，（2）每个供应商处理每个目的数据的用户许可状态（同意或不反对合法利益），（3）元数据和其他限制（例如，TC字符串创建的时间）。
只有TCF注册的CMP才能创建和更新TC字符串。TC字符串中的所有信息都以节省空间的方式编码，以便使TC字符串能够通过具有存储限制的HTTP GET请求在公司之间传递。TCF中的所有发布者都使用TC字符串来存储同意。所有发行商和供应商都依赖TCF注册CMP的应用编程接口（API）来解码和读取TC字符串。因此，实际上，TCF使所有公司在传输和读取用户权限信息（TC字符串）时都能“说相同的语言”。
7.4.3整合请求许可和存储许可
以协调的方式将cookie横幅、信息存储和数据处理结合起来是一项挑战，因为这涉及到来自多个领域的技术知识。TCF试图提供一个标准化的程序来整合这些不同的领域，这依赖于前面章节中描述的组件（例如，TCF目的规范、TCF工具以方便请求和存储许可）。
我们用表14中总结的三个代表性案例详细描述了TCF程序。对于这些案例，我们假设一个用户连续五天访问一个出版商，每天访问一次，并且同意是所有追求目的的法律基础。从第1天到第5天，我们按照时间顺序从简单到复杂排列病例。
Table 14: Overview of Cases of Asking for and Storing Consent under the Transparency and Consent Framework (TCF)
案例1是一个帮助理解TC字符串如何工作的简单示例。发布者代表自己请求用户同意，并为用户存储同意。案例2是一个通用案例，描述了出版商如何代表其合作伙伴供应商请求并存储同意。案例3是一个案例，解释了当参与者具有不同的同意状态时，他们如何相互影响。例如，如果供应商的合作伙伴未获得用户的同意，供应商可能会失去对用户数据的访问权。为了使示例更直观，我们使用图形来显示如何请求和存储同意信息。
7.4.3.1案例1：出版商自行获得许可
案例1描述了收集和存储同意的最直接的案例，如图16所示。第1天描述了用户第一次访问出版商网站时发生的情况，第2天描述了第二次访问。第1天，用户X第一次访问发布者A。出版商A没有合作伙伴供应商，因此它只需要用户同意就可以实现我们示例中指定的TCF目的，目的6（选择个性化内容）和目的8（衡量内容性能）（表9）。
Figure 16: Process of Getting Consent under the Transparency and Consent Framework (TCF) for Case 1
当用户X到达发布者的网站时（图16中的步骤1），发布者A通过CMP标记（添加到发布者A网站的JavaScript标记）联系其CMP，CMP A（步骤2）。然后，CMP代码在页面上运行，并检查用户X的本地存储（例如，第一方cookie）中是否存在与发布者a对应的TC字符串（步骤3）。由于这是用户X第一次访问发布服务器A，因此未找到此类TC字符串。在这种情况下，CMP a在网站上显示一个cookie横幅，例如，如图10所示。图16（步骤4）中显示的简化cookie横幅列出了我们示例中涵盖的两个TCF目的：选择个性化内容和测量内容性能。
接下来（图16中的步骤5），用户X在cookie横幅上为每个目的做出选择，个性化内容选择“否”，性能衡量选择“是”。然后，CMP A通过根据标准对同意信息进行编码，为用户X–发布者A创建TC字符串（步骤6）。发布者A将TC字符串本地存储在用户X的设备上（步骤7）。在步骤8中，发布者A依赖其CMP API来解码TC字符串。然后，发布者A知道用户X允许它追求的目的，我们在中心的“隐私偏好信息”黄色框中看到了这一点。最终，发布者A可以基于用户X的数据来衡量内容性能，但不能向用户X提供任何个性化内容。
第2天，用户X第二次访问发布者。图16中的步骤1-3保持不变。假设用户X自上次访问以来未删除本地存储，CMP A可以检测到先前保存的TC字符串并为发布者A解码。换句话说，无需显示cookie横幅并再次执行步骤4-7。只要用户X不更改隐私策略页面上的同意信息，发布者A将依赖存储的同意信息而无需重新获得许可。总的来说，在最简单的情况1中请求和存储用户同意已经是一个复杂的过程。
7.4.3.2案例2：出版商代表供应商获得同意
案例2如图17所示，描述了发布者如何代表供应商请求和存储同意。第3天描述了新假设下的第一次访问示例，而第4天描述了第二次访问示例。在第3天，出版商A决定在其网站上提供广告时段，以广告收入将其内容货币化。因此，出版商A从GVL中选择一家广告技术供应商供应商S作为其合作伙伴，并将此变更通知CMP A。在本例中，供应商S是一个需求侧平台（DSP），发布者列出其广告库存，供广告商购买。供应商S使用用户的个人数据有两个目的：表9中的目的2（选择基本广告）和目的4（选择个性化广告）。
Figure 17: Process of Asking for and Storing Consent under the Transparency and Consent Framework (TCF) for Case 2
当用户X访问发布服务器A时，CMP标记代码运行并检查是否存在包含完整同意信息的TC字符串。尽管发布者a的TC字符串存在，但由于供应商S最近才被添加，因此供应商S没有明确同意处理用户X的数据。因此，CMP A向用户X显示了一个新的cookie横幅。新cookie横幅包含了供应商S和发布者A的TCF目的。为了使说明简洁，我们排除了为发布者A本身获取许可的程序，案例1示例已经描述了这一程序。用户X在cookie横幅上看到供应商S及其TCF目的，并选择“是”进行基本广告选择，选择“否”进行个性化广告选择。在步骤6中，CMP A将同意信息编码为用户X–发布者A的新TC字符串。然后，发布者A将新TC字符串保存在用户X的本地存储中。
在步骤8中，发布者A通过供应商标签向供应商S发出广告呼叫信号。在处理用户X的数据之前，供应商s通过CMP API读取TC字符串，并知道它只能使用用户X的信息来选择基本广告。然后，供应商s在步骤12中为用户X向发布商A提供基本广告。第4天，用户X再次访问发布商A。在这种情况下，与第2天描述的情况（情况1）类似，如果用户X没有删除本地存储中的TC字符串，发布者A和供应商S可以依赖先前保存的权限。换句话说，除了步骤4-7之外，不会弹出cookie横幅。
7.4.3.3案例3：出版商代表多个供应商获得同意
案例3如图18所示，描述了发布者如何代表多个供应商请求和存储同意。第5天描述了新假设下的首次就诊示例。第5天，出版商A开始通过另一家广告技术供应商供应商P（一家广告交易所）销售广告位。因此，供应商S（DSP）现在只能通过供应商P（广告交换）购买广告位。供应商S和供应商P都使用个人数据来选择基本（目的2）广告和个性化广告（目的4）。再次，出版商A通知CMP A最近添加了供应商P及其TCF用途。
Figure 18: Process of Getting Consent under the Transparency and Consent Framework (TCF) for Case 3
当用户X访问发布服务器A时，再次执行步骤1-3。与第3天（案例2）描述的场景一样，CMP A检查用户X的本地存储，并发现存在用户尚未提供同意决定的供应商和TCF目的。因此，CMP A向用户X显示了一个新的cookie横幅，其中包含发布者A、供应商S和供应商P的目的和功能。为了简洁起见，我们再次忽略了请求和存储发布者A自身同意的程序。假设用户X仅在供应商S的基本广告选择中勾选“是”，在剩余的TCF中勾选了“否”，如图18中的简化横幅所示。CMP A将同意信息编码为新的TC字符串，由发布商A、供应商S和供应商P通过CMP API解码和解释。
当网站上的供应商标签在步骤8中运行时，发布者A向供应商P发送广告呼叫。但是，供应商P不能将用户X的数据用于任何TCF目的。因此，供应商S无权访问数据，即使其已获得用户对基本广告选择的同意。步骤12中的灰色虚线箭头捕获对用户数据的访问丢失。这种情况意味着，在步骤14中，供应商S不能再显示基本广告，根据用户的许可决定，否则它将能够为用户X显示基本广告。
7.4.3.4示例程序：结束语
为了使我们的示例简洁明了，我们举例说明了出版商仅代表自己、一个供应商或两个供应商获得许可的基本情况。即使我们简化了重点，所描述的程序也相当复杂。案例2和案例3甚至比案例1更复杂。事实上，出版商和供应商之间的复杂相互作用要求这些案例的技术解决方案比概述的还要复杂。TCF为在线广告行业的参与者提供了整合许可请求和许可存储的明确程序，从而有助于减轻这种复杂性。
然而，目前的TCF程序无法处理复杂相互作用中的每一个联系。例如，当用户撤回同意或希望删除其个人数据时，供应商是否删除收到的个人数据没有受到严格监管。
- 登录 发表评论