如何在后台处理cookie同意横幅？一个设置第三方cookie的网站可以要求允许其cookie吗？

Question

如何在后台处理cookie同意横幅？一个设置第三方cookie的网站可以要求允许其cookie吗？

4

我正在从事一项业余项目，该项目基本上是一个可集成的实时支持服务。为了方便描述我的问题，我将称呼我的服务为service.com，使用我的服务的网站为website.com。我正在考虑实现会话管理以恢复断开连接的访客聊天。为此，我计划使用基于cookie的会话管理。如果website.com的所有者想要使用我的服务，我将为他们提供一个JavaScript文件，该文件将在中注入一些HTML，在中注入样式标签，并实现交互。website.com所需做的就是导入JS文件并调用JS文件定义的函数。为了从service.com设置第三方cookie到website.com上，我将使用这个请求/响应。当website.com从service.com请求我的JS文件时，我的服务将响应该请求并发送包含JS文件和管理访客会话的cookie的响应。这样，service.com将在website.com的访客中设置第三方cookie。 第1个问题：可以使用请求的JS文件在前端或本地（从website.com的web服务器）上设置website.com的访客cookie吗？即使它在website.com的前端设置，它仍然是一个第三方cookie吗？ 第2个问题：我的另一个问题是关于cookie同意。是否可以要求为其他网站（例如website.com）设置第三方cookie（例如service.com）的网站（例如service.com）询问是否允许在website.com上使用他们的cookie？换句话说，我能否要求website.com的访客只允许通过我提供/分配给website.com的JS文件设置的第三方cookie？这合法吗？ 第3个问题： cookie同意横幅在幕后如何工作？当您接受/拒绝网站上使用的所有第三方cookie时会发生什么？或者当您仅允许其中的一些时会发生什么？允许/不允许的过程是如何进行的？当您单击"接受"按钮或"拒绝"按钮时是否会触发某种JavaScript？您可以向我提供有关此主题的任何资源。

谢谢！

- Muhammed Çağlar TUFAN

嗨，我的回答解决了你的问题吗？ - Benjamin James Kippax

@BenjaminJamesKippax，它确实有很大帮助，除了与cookie同意横幅的工作机制相关的问题。承诺将根据单击的按钮或用户交互而解决或拒绝，但是当访问者接受或拒绝cookie同意时，代码会执行什么操作？ - Muhammed Çağlar TUFAN

2个回答

3

第一问题 这取决于cookie的创建和存储方式。如果cookie存储用户特定、网站特定的会话ID，并且只在该网站上使用，可以使用由您提供给前端的JavaScript设置的1st party cookie进行存储。如果它将用于其他网站（如广告技术公司的唯一用户ID），那么这将是3rd party。

第二问题 这不是您的责任。作为“数据控制者”（网站所有者），网站提供程序有责任向其用户声明他们的“数据提供程序”（您）并让他们选择是否要存储和（可能）处理他们的数据。

但是，您可以尊重浏览器提供的DoNotTrack设置，并实施一个工作流程，允许您的代码等待某种许可。我的意思是，您可以确保您的代码不执行，直到像cookiePermissionProvided()这样的函数被调用。这将允许站点的开发人员有效地将您的代码实现到其站点的cookie同意回调中。

第三问题 您可能会惊讶地听到这一点，但其中一些根本不起作用。

然而，那些真正有效的通常使用一些promise或回调功能，例如...

const cookieConsentGiven = new Promise(resolve, reject => {
    // Add HTML to page with a 2x button
    // one triggering resolve (accepted)
    // one triggering reject (not accepted)
});

cookieConsentGiven.then(
    //resolved
    (val) => { 
        // Handle cookie approval, run code
    },
    //rejected
    (val) => { 
        // Handle cookie disapproval
        // only run code which doesn't control/process personal data
    })

网站所有人要负责过滤特定cookie时运行哪个代码，这不是你的责任。你需要确保你的代码遵守它必须等待被告知才能运行/存储特定用户数据的规定。

希望这对你有用。

当我们在数百个零售商网站上运行电子商务平台时，我也有类似的问题。最终，我们选择了一种基于promise的系统，在运行存储用户敏感数据的任何代码之前等待许可。有些cookie是无法避免的，例如ASP.net会话（这些已经考虑在法律中）。

总之，我认为你无需担心自己必须担心的那么多。只需确保你的代码在被告知后才执行。如果可能的话，请提供替代回调，以便你的功能可以在不存储个人数据的情况下运行。例如聊天功能在浏览器会话或页面重新加载时将无法工作 - 你应该通过在用户开始聊天之前告诉用户（解释原因并允许他们事后选择加入[你必须解释存储内容和原因] - 这也是被允许的）来考虑你的UI。

- Benjamin James Kippax

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- mattpr · Accepted Answer

http与JavaScript Cookies

所有的website.com只需要导入那个JS文件并调用由该JS文件定义的函数。为了在我的service.com上设置第三方cookie，我将使用这个请求/响应。当website.com从service.com请求我的JS文件时，我的服务将响应该请求，并附带一个cookie来管理访问者的会话。这样，service.com就可以在website.com的访问者中设置第三方cookie。

如果你所说的“请求/响应”是指向service.com发出的HTTP请求，该请求将回复要存储在website.com（客户域）下的cookie……那么这对于HTTP cookie是行不通的，因为你只能在你的域命名空间内读取和设置cookie。也就是说，对api.foo.example.com的请求的响应可以接收和设置cookie：

api.foo.example.com
foo.example.com
example.com

但不是在www.example.com设置cookie。

因此，如果来自website.com到service.com的请求... service.com只能在service.com下设置cookie。在这种情况下，它们被称为“第三方cookie”，因为“第一方”是website.com，而您的service.com是第三方（网站访问者正在与website.com交互）。许多浏览器（Safari、Firefox）默认阻止第三方cookie。

要解决这个问题并拥有更可靠的cookie（即使您仅在会话中使用它而不是跨多次访问website.com），您有两个选择：

客户白标 DNS。 客户创建了 DNS 记录 livechat.website.com，并将其 CNAME 到 api.service.com。然后，api.service.com 通过 livechat.website.com 域处理流量，并可以在那里读取/设置 cookie。但是，这需要客户方面更多的技术连接，因为除了添加脚本标签外，还需要添加 DNS 记录。
JavaScript cookies。 不要在 service.com 的 HTTP 响应中设置 cookie，而是从 service.com 返回的 JavaScript 在 website.com 域中运行，因此可以设置 JavaScript cookies，并且可以在该域下读取 cookie（只要它们没有使用 httponly 选项设置）。如果您不想在针对原生浏览器 document.cookies API 进行编码时担心跨浏览器问题，请查看js-cookie库。

如果您不执行上述操作之一，则在向 service.com 发送请求的响应中设置的 cookie 将是第三方 cookie，并且可能无法始终正常工作。

HTTP cookies

……通过HTTP响应头中的set-cookie设置的cookie，只能为请求的主机域命名空间设置。如果这个主机（包括子域）与用户地址栏中的域不同，那么它被视为第三方cookie，并受到一些限制。

如果客户将DNS记录指向您的服务，则可以将第一方HTTP cookie设置为第三方。

Javascript cookie

是由页面内的Javascript设置的cookie。它们可以在Javascript所在的框架的域/命名空间中设置cookie。它们也可以读取来自该域/命名空间的cookie，只要它们没有使用httponly选项设置（通常用于防止第三方Javascript劫持会话cookie）。

通过加载到适当域的框架中，您可以将Javascript cookie作为第三方使用。

如果客户在使用CSP锁定其站点，您还可以阅读内容安全策略，它可以阻止您的第三方Javascript作为部署文档的一部分运行。

第一个问题

这是关于编程的内容，只返回翻译的文本:

在website.com的访客阶段是否可以通过前端使用请求的JS文件来设置cookie？

是的，这是JavaScript cookie。请参考上述信息。

还是在本地（从website.com的Web服务器）请求的JS文件？

我不确定你具体指的是什么。website.com的Web服务器可以托管/代理您的JS文件，但这只是静态文件服务，对您的会话cookie逻辑没有太大帮助。

客户可以为您的API托管一个代理，并在您的响应中重写cookie标头，使其成为第一方。尽管在技术上是可行的，但这样做过于复杂，我不建议这样做。只是想表明许多事情都是有可能的。

当然，您可以构思出许多解决方案。例如，您的客户可以托管一个非常简单的Web应用程序，在JavaScript请求的响应中根据需求处理读取/设置cookie。也就是说，客户在自己的域名下托管了您构建的小型应用程序，以便在API调用时读取/设置某些HTTP cookie并提供相关信息。然而，与定制DNS（上述选项）相比，我认为这需要客户端进行更多的技术集成。

我建议您坚持以下几点...

第三方 Cookie 直接设置在 service.com 的 HTTP 响应中。
首方 Cookie 由您的 JavaScript 客户端在 website.com 框架内被加载/运行后设置。
直接在通过 DNS 指向 service.com 的 livechat.website.com 的 HTTP 响应中设置的首方 Cookie。

第二个问题

一个在其他网站（例如 website.com）上设置第三方 Cookie（例如 service.com）的网站是否可以请求允许设置其 Cookie 在那个 website.com 上？

所有这些Cookie同意都来自两个相关的法规，即欧盟的GDPR和加利福尼亚州的CCPA。

你看到的大多数cookie弹窗都与GDPR有关，并遵循由互联网广告局（IAB）管理的透明度同意框架（TCF）标准。在TCF规范中，提供cookie弹出功能的技术方被称为同意管理平台（CMP）。他们位于网站（也称为“发布者”）和可能希望在该网站上执行访问者数据（cookie或其他方式）的各种第三方供应商之间。供应商/ cookie被分组为“目的”，这允许访问者同意一种数据使用类型而不同意另一种。有必需的cookie（用于网站工作的必需cookie，如登录cookie），还有分析、营销和其他类型的目的。如果您想了解这些人（发布者-CMP-Vendors）如何工作的所有技术细节，请随意阅读规范。

简而言之，您不需要从cookie弹出窗口请求任何内容，您的公司已注册参与规范作为供应商，然后CMP可以将您列入访问者可以同意的网站上的第三方供应商列表中。作为个人爱好项目，成立公司并加入TCF框架可能超出了您目前想要做的事情。但是，如果您的cookie需要披露，网站通常可以手动添加您的cookie披露。

然而！

这仅在欧盟（以及加利福尼亚州、加拿大）需要，如果您没有以上地区的客户/用户，则可能无需担心此问题。

而且！

您的在线聊天将属于网站所需/功能性cookie，以使网站的在线聊天功能正常工作...只要您小心数据收集/存储位置/处理...您也可以在欧盟轻松运营，并且不需要任何特殊的额外cookie同意，因为您可以属于网站所需/功能性cookie的范畴。将数据处理和隐私责任交给website.com。

最好使用带有DNS选项的会话cookie（在website.com域下）。不要跟踪用户超出会话恢复或将任何敏感数据放入cookie（或本地存储），以便在会话之间保持。
如果您要在自己的服务器上存储聊天记录，则存在高风险，因为用户向支持代理提供个人数据（电话号码、姓名、地址等）。这在法律要求和披露方面变得非常棘手。如果您不是一家公司，欧洲没有合法的公司会使用您的实时聊天，因为缺乏数据安全/隐私问责制。
- 因此，您可能需要使聊天短暂。例如，使用客户端存储在客户的域名（website.com）下，以便聊天记录永远不会存储/持久化在您自己的服务器上。您的服务器只需将访问者连接到代理并来回传输数据而不存储它。
- 如果客户想保存聊天记录，请为他们提供一些选项，其中这些记录会流式传输到他们自己的服务器上，以便您不会接触它们。或者提供一个自托管的插件，他们可以自行托管，从而获得数据保留和报告（在他们的控制下，而不是您的控制下，因此更容易销售）。如果它足够大并且您围绕此成立了一家公司...您始终可以执行合规性操作，提供具有其中数据的SaaS托管应用程序。
最好为欧盟访问者使用位于欧盟的服务器，以避免未经同意无意中转移数据到国外（即使是短暂的）。
不要在service.com服务器上记录任何个人身份信息、用户ID等。只记录聊天ID、开始/结束时间、代理ID、主题和其他您需要进行计费的统计信息...但不涉及访问者。如果要记录IP地址，请截断最后一个八位（或将其设置为0）以半匿名化IP。
制作一个隐私说明“一张纸”，技术地解释如何避免接触（或持久化）任何可能敏感的数据（“设计时私有”），并将其与营销材料一起包括，因为这将有助于缩短潜在客户法律团队的任何查询。

第三个问题

Cookie同意横幅在幕后是如何工作的？

大多数大公司正在使用合法的cookie同意横幅，这些横幅实现了来自IAB Europe的TCF框架（政策和技术规范）。该网站上的所有技术规范都是公开的（针对CMP和供应商等）。实现对TCF支持的同意横幅供应商通常也会添加对CCPA规则的支持。加拿大现在也采用了来自欧盟的TCF以使事情更简单。但是，您也可以手动添加到大多数cookie弹出窗口中。

您不能仅通过回调集成TCF。那样行不通。您需要注册以参与框架作为供应商。然后，您可以调用由CMP提供的特定API函数，以检查访问者是否已经授权，以及您（作为第三方供应商）是否已经获得了任何特定目的的授权以及哪些目的。

cookie同意提供商通常提供网站手动（或通过爬虫自动）添加和声明超出TCF框架范围的其他供应商/ cookie的能力（这是广告重点关注的）。在需要时，这将适用于您。

一些Cookie同意提供者会复制/删除/解析页面，以阻止第三方脚本的触发，然后重新注入带有修改的页面。我不是粉丝，因为这可能导致奇怪的行为。一些提供者还使用MutationObserver来监视第三方加载的内容。通常/手动情况是使用数据属性手动修改第三方iframe/javascript/image等HTML标记，以便将其标记为cookie同意...并防止加载（即将src移动到不同的属性，使标记不加载）。如果给予同意，则可以通过cookie同意库更新这些元素以进行加载。

但是正如我在回答问题2时提到的，如果您小心谨慎，您可能不需要担心这个问题。

一些网站已经推出了自己的Cookie同意小部件，因为它们太小而无法处理完整CMP的复杂许可证，并且因为它们通常只需要披露非常有限的第三方供应商（可能只有Google Analytics和Google Ads以及Facebook Remarketing像素）。如果构建得很好，这些小部件应该防止在同意之前（或被拒绝）加载任何第三方JavaScript（或其他HTTP调用）。

我多年前建立的一个项目使用谷歌标签管理器（在同意后）来管理使用GTM触发器加载的内容。我们在收到用户信号之前不会加载GTM。在触发GTM之前，我们向数据层添加同意信号，指示用户同意（或不同意）哪些目的（功能/分析/营销）。如果用户以前访问过该站点，则从cookie中加载先前的同意，因此小部件不会再次弹出。如果同意披露详细信息（供应商、目的）发生了变化，则所有用户都会再次弹出窗口。一年过去后，他们也会再次弹出窗口。无论如何，在GTM中，我们设置触发器，只有在适当的同意被给予时才会触发标签。功能/必需的cookie始终在GTM之外加载。如果我们没有任何分析或营销同意，那么我们根本不会加载GTM，加快“无”访问者的网站速度。GTM在某个时候添加了特定于同意的功能。

TCF 的工作方式相反，大多数供应商总是会加载，但它们应该"自我管理"并检查来自 CMP 的信号，无论他们是否获得同意...这意味着他们的代码必须进行广泛修改，以支持在没有同意设置/读取 cookie（例如）的情况下如何处理请求。供应商可能会为一个目的获得同意，但另一个目的却不行...因此，他们的代码必须尊重这一点。如果供应商有许多不同的 cookie 和目的，情况就会变得非常复杂。遵循政策是加入 TCF 框架时供应商同意的一部分。此外，由于比利时数据保护机构的裁定关于实施隐私立法的 TCF 有效性，TCF 目前也面临着一些巨大挑战。但那是另一个问题了。关键是：在 TCF 的世界中，点击 "不接受" 的 cookie 并不一定意味着网络请求或 JavaScript 的减少。

如果你小心存储数据（不要存储）并将存储的内容保留在客户域下，那么作为功能性 cookie，你可能不需要担心 cookie 弹出框。

如果您决定基于聊天数据（例如 Disqus 风格）构建业务模型，那么您需要做更多的工作来确保合法合规，并向大客户的法律/隐私团队提供保证。

有些其他的 cookie 弹窗只是纯粹的视觉效果。旧网站有许多手动添加的脚本标签和没有标签管理。对他们来说，在技术上达到合规要求是一场噩梦。因此，他们添加了一个小部件，使其看起来像他们已经合规了，但实际上幕后并没有任何变化。这些通常是收入微薄的小型网站，所以他们认为欧洲数据保护监管机构永远不会找麻烦……然而，长尾网站的大规模骚扰自动化可能只是时间问题。目前的主要问题是这些律师事务所如何获得报酬，但如果他们设法谈判获得 DPA 罚款的一部分作为提供执行服务的报酬……那么这将成为一个大问题。