透明度和同意字符串(TC 字符串)-Transparency & Consent String

在 TCF 中,TC 字符串用于封装有关如何建立和编码透明度和同意的相关详细信息,因为它适用于策略定义的每个目的、特殊用途、功能和特殊功能以及参与供应商。本文档指定必须如何设置该字符串的格式、谁应使用它以及如何使用它。

定义

有关与 TCF政策和本文档中描述的技术相关的具体定义,请参阅以下链接中的 IAB 欧洲透明度和用户意见征求框架政策:

IAB Europe Transparency & Consent Framework Policies - IAB Europe

TC 字符串有什么用途?

TC 字符串的主要目的是封装和编码向用户披露的所有信息,以及他们根据 GDPR 表达对个人数据处理的偏好。使用同意管理平台 (CMP),将信息捕获到编码且紧凑的 HTTP 可传输字符串中。此字符串允许将透明度和同意信息传达给处理用户个人数据的实体或“供应商”。供应商解码 TC 字符串以确定他们是否有必要的法律依据来处理用户的个人数据以达到其目的。简洁的字符串数据格式使 CMP 能够在需要时保留和检索用户的首选项,并将该信息传输给需要它的任何供应商。

TC 字符串中存储了哪些信息?

TC 字符串包含以下信息:

  1. 常规元数据:指示有关 TC 字符串的详细信息的标准标记,例如其编码版本、上次更新时间和初始创建时间,以及有关其包含的透明度和同意值条件的详细信息,例如使用的全球供应商列表版本、使用的 CMP 等。
  2. 用户同意:用户对处理其个人数据表示同意。用户的同意在两个级别上表示:每个目的和每个供应商。
  3. 合法利益:CMP为供应商和/或目的建立了合法利益透明度的记录,以及用户是否对其行使了“反对权”。这包括一般目的的信号和专门为给定供应商声明的目的。
  4. 发布者限制:发布者在用户贩运其数字资产的背景下对供应商数据处理的限制。
  5. 发布商透明度和用户意见征求:TC 字符串的一部分,发布商可以使用该段来建立透明度并获得用户的同意,以便根据自己的法律依据处理个人数据或与供应商共享(如果他们愿意)。
  6. 特定司法管辖区披露:发布商业务实体所在的国家/地区或参考的立法国家/地区,以及是否向用户披露目的 1“在设备上存储和/或访问信息”的记录,因为某些司法管辖区对此目的的处理方式不同。

谁应该创建 TC 字符串?

透明度和用户意见征求字符串只能由 IAB Europe TCF 注册的 CMP 根据政策使用其分配的 CMP ID 号创建。供应商或任何其他第三方服务提供商不得创建或更改 TC 字符串。这些和其他要求在政策中阐明,包括 CMP、发布者和供应商在内的所有各方都必须遵守这些要求

何时应创建 TC 字符串?

在用户采取明确的肯定操作以明确表示该用户的同意之前,不得创建包含肯定同意信号的 TC 字符串。但是,如果已根据政策建立了合法利益透明度,则可以仅使用合法利益建立信号创建TC字符串。

TC 字符串的范围是什么?

CMP 必须在特定于服务或特定于组的配置中运行。此上下文中的 TC 字符串仅适用于服务或一组服务,例如运行它的站点或应用程序。为给定网站/应用或网站/应用组上的每个用户创建一个。它们可能包含发布者限制发布者 TC段(当由 CMP API 返回时)。

全局范围和带外发生了什么变化?

TCF 策略以前允许在框架中建立具有全局范围的法律基础,这意味着法律基础不仅适用于获取和管理它的服务或服务组(特定于服务和特定于组的范围),而且适用于所有实现全局范围首选项的服务。在全局范围的上下文中,TC 字符串存储在与“consensu.org”域关联的第三方 cookie 中,该 cookie 使同意管理提供商 (CMP) 能够跨不同服务从其子域 [cmp-name].mgr.consensu.org 读取“TC 字符串”。已于 2021 年 6 月 22 日宣布弃用全局范围支持。除了弃用全局范围外,还弃用了对带外 (OOB) 的支持,OOB 是指尚未在全局范围上下文中使用 TCF 建立法律依据的情况。自 2021 年 9 月 1 日起,使用全局范围建立的 TC 字符串被视为无效。

什么是发布商限制?

该框架的2.0版引入了发布商对供应商如何处理个人数据发出限制的能力。限制可以有两种类型:

  • 目的。限制供应商处理个人数据的目的。
  • 法律依据。指定发布商要求供应商运营的法律依据,如果供应商在GVL 中表示了法律依据的灵活性。

发布者限制是由发布者指定的自定义要求。为了使供应商确定是否允许出于特定目的进行处理,或者哪种法律依据适用(如果他们在GVL中表示灵活性),必须遵守限制。

  1. 供应商必须始终遵守限制信号,该信号不允许他们出于特定目的进行处理,无论他们是否声明该目的为“灵活”。
  2. 声明具有默认法律依据(分别为同意或合法权益)但同时声明此目的为灵活的目的的供应商必须遵守法律依据限制(如果存在)。这意味着,例如,如果他们宣布某个目的为合法利益,但也声明该目的具有灵活性,并且有法律依据限制要求同意,那么他们必须检查同意信号,并且不得应用合法利益信号。

为免生疑问:

如果供应商已声明某个目的的灵活性,并且没有法律依据限制信号,则除了注册为灵活之外,它必须始终应用注册目的的默认法律依据。这意味着,如果供应商将某个目的声明为合法利益,并且还声明该目的具有灵活性,则在没有法律依据限制信号的情况下,不得应用“同意”信号以要求同意。

当基于 URL 的服务无法执行 JavaScript 时,如何处理 TC 字符串?

广告素材呈现后,可能包含多个像素下注。例如,从浏览器向供应商 A 的域触发 HTTP GET 请求。<img><img src="http://vendor-a.com/key1=val1&key2=val2">

由于像素位于 antag 中,无法执行 JavaScript,因此 CMP API 不能用于获取 TC 字符串。广告供应链中所有使用 URL 进行交易的各方都必须在其插入 TC 字符串的 URL 中添加宏。任何有权访问适用 TC 字符串的调用方都必须将其插入包含宏的 URL 中,其中接收 TC 字符串的供应商的数字供应商 ID。<img>${GDPR_CONSENT_XXXXX}XXXXX

例如,对于 ID 为 123 的供应商 A 要接收 TC 字符串,图像 URL 必须包含带有 URL 参数和宏的键值对。gdpr_consent=${GDPR_CONSENT_123}

生成的网址为:

http://vendor-a.com/key1=val1&key2=val2&gdpr_consent=${GDPR_CONSENT_123}

如果 TC 字符串为:COvFyGBOvFyGBAbAAAENAPCAAOAAAAAAAAAAAEEUACCKAAA.IFoEUQQgAIQwgIwQABAEAAAAOIAACAIAAAAQAIAgEAACEAAAAAgAQBAAAAAAAGBAAgAAAAAAAFAAECAAAgAAQARAEQAAAAAJAAIAAgAAAYQEAAAQmAgBC3ZAYzUw

然后,调用方将 URL 中的宏替换为实际的 TC 字符串,以便在调用指定服务器时按如下方式修改最初放置的包含宏的像素。

http://vendor-a.com/key1=val1&key2=val2&gdpr_consent=COvFyGBOvFyGBAbAAAENAPCAAOAAAAAAAAAAAEEUACCKAAA.IFoEUQQgAIQwgIwQABAEAAAAOIAACAIAAAAQAIAgEAACEAAAAAgAQBAAAAAAAGBAAgAAAAAAAFAAECAAAgAAQARAEQAAAAAJAAIAAgAAAYQEAAAQmAgBC3ZAYzUw

TC 字符串必须始终按原样传播,而不是修改。供应链中的其他 URL 与其他供应商的处理方式相同。

以下部分列出了用于在供应链中中继信息的可用 URL 参数和宏。

完整的 TC 字符串传递

使用用户浏览器中的 URL 调用的服务(如 Cookie 订书器、用户 ID 关联器和跟踪像素(“被调用方”))在 URL 中作为宏传递,格式为:

<span style="color:#24292f"><span style="background-color:#ffffff"><span style="background-color:var(--color-canvas-subtle)"><code>&url_parameter=${macro_name}
</code></span></span></span>

支持的 URL 参数和相应的宏定义如下:

网址参数对应宏网址中的表示形式
gdprGDPR&gdpr=${GDPR}
gdpr_consentGDPR_CONSENT_XXXXX

(XXXXX是数字供应商 ID - 供应商的 ID 期待的GVL 此网址调用)

&gdpr_consent=${GDPR_CONSENT_XXXXX}

例如,供应商 ID 123.&gdpr_consent=${GDPR_CONSENT_123}

gdpr_pdGDPR_PD&gdpr_pd=${GDPR_PD}

进行调用的服务必须将宏替换为下表中所述的适当值。对于宏,在替换宏之前,进行调用的服务还必须检查宏名称是否包含有效的供应商 ID。URL 的创建者应确保这些参数仅添加一次,并传递给需要它们并且可以正确处理它们的服务。${GDPR_CONSENT_XXXXX}

宏观可能的值目的
${GDPR}0 / 10GDPR 不适用;适用通用数据保护条例。如果 不存在,被叫方应进行地理IP查找,并且GDPR适用于欧盟 IP 地址1
${GDPR_CONSENT_XXXXX}URL 安全的 base64 编码的透明度和同意字符串。只 有意义的如果gdpr=1对从 CMP JS API 或 OpenRTB 获得的 TC 字符串进行编码。
${GDPR_PD}0 / 1(可选,默认值:1)对于通用 URL 参数,表示没有 它们包含个人数据(从被叫方的角度来看)。为 “定义的”URL参数,其定义应定义是否 它们包括个人数据。gdpr_pd=0

注意:其他个人数据,如IP地址或被叫方cookie,可能会作为请求的一部分传递,被叫方使用这些数据来确定是否可以设置和/或使用标识符cookie或其他个人数据。gdprgdpr_consent_xxxxx

如果同意在一个国家/地区受到不同的管理怎么办?

政策要求在“需要征得同意的情况下”在设备上存储和/或访问信息,目的 1 要求征得用户同意,而出版商和供应商则有责任确定是否需要征得这些管辖区的同意。

如果发布商在不需要同意即可在设备上存储和/或访问信息的管辖区内运营 CMP,因此不代表供应商出于目的 1 征求同意,则 CMP 将在“目的同意”字段中写入相应的位。尽管在该司法管辖区内,不就目的 1 征求同意是有效的,但供应商会将其解释为“不同意”信号,并且无法知道发布商运营所在的司法管辖区不需要同意。缺乏透明度最终会导致该发布商的广告收入损失。00

为了适应目的 1 根据司法管辖区的不同而对同意进行不同管理的情况,TC 字符串对于发布者的运营治理以及用途 1 是否向用户披露是透明的。然后,供应商可以使用这些详细信息来确定他们是否有足够的法律依据来处理该给定上下文中的个人数据。为了支持这一点,TC String:PublisherCC中有两个字段,它表示发布者的国家/地区代码和一个标志,用于指示是否已在名为PurposeOneTreatment的用途1上提供任何披露。每个字段的详细信息列在TC 字符串中使用的字段中

“已创建”和“上次更新”发生了什么变化?

“已创建”和“上次更新时间”字段以前对应于分秒时间戳。考虑 DPA 就数据控制者可用于提供所获得的同意及其有效性的证据的各种手段的实际指导,以及“创建”字段对发布商及其 CMP 的有限相关性,以便酌情至少每 13 个月提供一次, “已创建”和“上次更新”字段已更新为具有上次更新 TC 字符串时的日级时间戳相同的值。

创建 TC 字符串

以下详细信息提供有关创建、存储和管理 TC 字符串的信息。

应如何存储透明度和同意字符串?

在 TCF 规范版本 2 中,用于特定于服务和特定于组的 TC 字符串的存储机制最高为 CMP,包括任何非 cookie 存储机制。

支持哪些用途和功能?

IAB 欧洲透明度和用户意见征求框架政策定义了用途、特殊用途、功能、特殊功能和堆栈(目的和/或特殊功能的分组)。您可以在以下 URL 中找到的文档中引用这些用途和功能的详细信息:

IAB Europe Transparency & Consent Framework Policies - IAB Europe

管理冲突的字符串版本

2020 年 9 月 30 日之后,v1.x 字符串被视为无效。如果 CMP 遇到 v1.x 字符串和 v2.0 字符串同时错误存在的情况,CMP 应删除 v1.x 字符串,以确保字符串的使用者只有一个真实来源。

注意:TCF 版本 2.0 引入了“发布者限制”,如果发布者用尽了限制,可能会导致 TC 字符串大于 Cookie 的大小限制。虽然这种可能性很小,但应该加以防范——CMP 应该与出版商合作,帮助他们实现目标。CMP 在决定这些 TC 字符串的存储机制时可能需要考虑到这一点。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值