cookie 同意横幅如何在后台运行？在另一个网站上设置第 3 方 cookie 的网站可以请求允许其 cookie 吗？
How do cookie consent banners work on the background? Can a website that sets 3rd party cookies on another website ask to allow its cookies?
我正在做一个业余爱好项目。该项目基本上是一个可集成的实时支持服务。为了方便描述我的问题，我将调用我的服务 service.com 并调用使用我的服务的网站 website.com。我正在考虑实施 session 管理来恢复断开连接的访客聊天。为此，我计划使用基于 cookie 的 session 管理。如果 website.com 的所有者想要使用我的服务，我会为他们提供一个 JavaScript 文件，该文件将在 body 上注入一些 HTML，头上的样式标签并实现交互。 website.com 所要做的就是导入该 JS 文件并调用该 JS 文件定义的函数。要在我的 service.com 的那个 website.com 上设置第 3 方 cookie，我将使用这个 request/response。当 website.com 从 service.com 请求我的 JS 文件时，我的服务将使用 JS 文件和一个 cookie 来响应请求，以管理访问者的 session。这样 service.com 将为 website.com 的访问者设置第 3 方。
第一个问题： 在 website.com 的访问者上设置 cookie 的这个阶段是否可以在 front-end 上使用请求的 JS 文件或本地（来自website.com 的 Web 服务器）请求 JS 文件？那仍然是第 3 方 cookie，因为它将设置在 website.com 的 front-end 上吗？
第二个问题： 我的另一个问题是关于 cookie 许可。在某些其他网站（例如 website.com）上设置第 3 方 cookie（例如 service.com）的网站是否可以要求在 website.com 上允许他们的 cookie？换句话说，我可以要求 website.com 的访问者仅允许 service.com 使用我 serve/give 到 website.com 的 JS 文件设置的第 3 方 cookie 吗？这合法吗？
第 3 个问题： cookie 同意横幅如何在幕后工作？当您 accept/deny 在网站上使用所有第 3 方 cookie 时会发生什么？或者当您过滤并只接受其中的几个时会发生什么？ allowing/disallowing 的过程是如何工作的？单击“接受”按钮或“拒绝”按钮时是否会触发某种 JavaScript？您可以向我提供有关此主题的任何资源。
谢谢！
第一个问题
这取决于 cookie 的创建和存储方式。如果 cookie 正在存储 user-specific、website-specific 会话 ID 并且只会在该网站上使用，则可以使用您服务的 JavaScript 设置的第一方 cookie 进行存储front-end。如果它要在其他网站上使用（例如广告技术公司的唯一用户 ID），那将是第 3 方。
第二题
那不是你的责任。作为“数据控制者”（网站所有者）的网站提供商有责任向其用户声明其“数据提供者”（您），并让他们选择是否愿意存储他们的数据，并且（可能）已处理。
你 可以 但是尊重浏览器提供的 DoNotTrack 设置，你也可以实现一个工作流，允许你的代码 await 某种许可.我的意思是，您可以确保您的代码在调用 cookiePermissionProvided() 等函数之前不会执行。这将允许网站开发人员有效地将您的代码实施到他们网站的 cookie 同意回调中。
第三题
你可能对此感到惊讶，也可能不会感到惊讶，但他们中的一些人确实深蹲。
但是，实际 工作的那些通常使用某种承诺或回调功能，例如 ...
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 时将哪个代码 运行 的责任放在网站所有者身上，而不是您。您的责任是确保您的代码尊重必须等待被告知 run/store user-specific 数据。
希望这有用。
我在为我们的电子商务平台（在数百家零售商的网站上 运行 实现此功能时遇到了非常相似的问题。最终我们只选择一个 promise-based 系统，它在 运行 任何存储 user-sensitive 数据的代码之前等待许可。有些 cookie 是无法避免的，例如 ASP.net 会话（这些在立法中有规定）。
总而言之，我认为您不必担心您认为可能需要担心的一半。只需确保您的代码在被告知之前不会执行。如果可以，请提供替代回调，这样您的功能就可以 运行 而无需存储个人数据。例如聊天功能无法跨浏览器会话或页面重新加载 - 您应该在 UI 中考虑到这一点，方法是在用户开始聊天之前让他们知道（解释为什么会这样，甚至允许他们 opt-in事后[你必须解释存储的内容和原因] - 这也是允许的）。
http 与 javascript cookies
All the website.com's have to do will be importing that JS file and calling a function defined by that JS file. To set 3rd party cookies on that website.com from my service.com I will use this request/response. When website.com requests my JS file from service.com, my service will respond the request with the JS file along with a cookie to manage visitor's sessions. This way service.com will set 3rd party on website.com's visitors.
如果“request/response”是指对 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（即使您仅将其用于 session 而不是多次访问 website.com），您有两个选择：
客户白标 DNS。 客户创建 DNS 记录实时聊天。website.com 并将其 CNAME 到 api。service.com . api.service.com 然后通过 livechat.website.com 域处理流量，并且可以在那里 read/set cookies。但是，这需要在客户方面进行更多的技术联系，因为除了添加脚本标记外，还涉及添加 DNS 记录。
javascript cookies。 没有在 service.com 的 http 响应中设置 cookie，而是返回 javascript from service.com 是 运行 在 website.com 域中，如果您不想担心 cross-browser 编码时针对本机浏览器的问题，set javascript cookies as well as reading cookies under that domain (as long as they weren't set with the httponly option). Take a look at js-cookie 库也可以document.cookies API.
如果您不执行上述任一操作，您在对 service.com 请求的响应中设置的 cookie 将成为第三方 cookie，并且可能无法始终如一地工作。
http cookies
...是通过 http 响应 header set-cookie 设置的 cookie，并且只能为请求的主机的域命名空间设置。如果此主机（带子域的完整域名）与用户地址栏中的域不同，这将被视为第三方 cookie 并受到一些限制。
您可以将first-party http cookie 设置为third-party 如果客户将在您的服务中指向他们域下的DNS 记录。
javascript 饼干
是由 javascript 在页面内设置的 cookie。他们可以在 javascript 位于 运行 的框架的 domain/namespace 内设置 cookie。他们可以从 domain/namespace 读取 cookie，只要它们没有设置 httponly 选项（通常这样做是为了防止第三方 javascript 劫持 session cookie）。
您可以将 javascript cookie 加载到适当域的框架中，作为第三方使用。
您可能还想阅读 Content Security Policy，如果客户使用 CSP 来锁定，它可以防止您的第三方 javascript 作为客户部署文档的一部分 运行下载他们的网站。
第一个问题
Could this stage of setting cookie on website.com's visitor...
done on the front-end with that requested JS file
是的，这是 javascript cookie。见上文。
or locally (from the website.com's web server) requested JS file
不确定你的意思。 website.com 网络服务器可以 host/proxy 你的 js 文件，但那只是静态文件服务，所以它并不能真正帮助你处理 session cookie 逻辑。
客户可以为您的 api 提供代理，其中包括 re-writing Cookie header，使他们成为第一方。虽然技术上可行，但这是 over-complicated 的方式，我不推荐它。只是表明很多事情都是可能的。
当然你可以想出很多办法。例如，您的客户可以托管一个非常简单的网络应用程序，该应用程序可以根据需要处理 reading/setting cookie 以响应 javascript 请求。也就是说，客户在他们的域下托管了一个您构建的小应用程序，以便 read/set 某些 http cookie 并提供此信息以响应来自您的 javascript 的 API 调用。但是，我认为这需要在客户端进行比 custom-DNS（以上）选项更多的技术集成。
我建议您坚持以下其中一项...
- 第三方 cookie 直接设置在来自 service.com
的 http 响应上
- 第一方 cookie 由您的 javascript client-side 在 website.com 帧内 loaded/run 后设置。
- 第一方 cookie 直接设置在 livechat 的 http 响应上。website.com 已通过 DNS 指向 service.com。
第二个问题
Can a website that sets 3rd party cookies (e.g service.com) on some other website (e.g website.com) ask to allow their cookies on that website.com?
所有这些 cookie 同意都来自两个相关的法规。欧盟的 GDPR 和加利福尼亚的 CCPA。
您看到的大多数 cookie 弹出窗口都与 GDPR 相关，并且遵循由互联网广告局 (IAB) 管理的称为透明同意框架 (TCF) 的标准。提供 cookie 弹出功能的技术方在 TCF 规范中称为 Consent Management Platform (CMP)它们位于网站（又名“发布者”）和可能想要对该网站上的访问者数据（cookie 或其他方式）做某事的各种第三方供应商之间。 Vendors/cookies 分为“目的”，允许访问者同意一种类型的数据使用，而不是另一种。有必需的 cookie（网站工作所必需的……就像登录 cookie）以及分析和营销以及其他类型的目的。如果您想了解这些人（发布商 - CMP - 供应商）如何工作的所有技术细节，请随时阅读规范。
但长话短说，您不需要从 cookie 弹出窗口中请求任何内容，您的公司已注册作为供应商参与规范，然后 CMP 可以将您包含在网站上的第三方供应商列表中访问者可以同意。作为个人hobby-project，成立公司并加入TCF框架可能已经超出了你此时想做的事情。
但是！
只有在欧盟才需要，如果您在欧盟没有customers/users，您可能不需要担心这个。
还有！
为了使网站的实时聊天功能正常工作，您的实时聊天将属于网站的 required/functional cookies...所以只要您注意数据 collection/storage-location/processing.. .您可能也可以在欧盟运营，没有问题，并且不需要任何特殊的额外 cookie 同意，因为您可以属于该网站的 required/functional cookie 保护伞。将数据处理和隐私责任交给 website.com。
最好使用带有 DNS 选项的 session cookie（在 website.com 域下）。不要在 session 恢复后跟踪用户，也不要将任何敏感数据放入将持续 session 秒的 cookie（或本地存储）中。
如果您打算将聊天记录存储在自己的服务器上，那么您获取个人数据的风险很高，因为用户将其提供给支持代理（phone 号码，姓名、地址等）。就法律要求和披露而言，这很快就会变得棘手。如果您不是公司，在欧洲开展业务的任何合法公司都不会使用您的实时聊天，因为缺乏数据 security/privacy 问责制。
- 所以你可能需要让聊天变得短暂。例如在客户域 (website.com) 下使用 client-side 存储，这样聊天记录永远不会 stored/persisted 在您自己的服务器上。您的服务器只是将访问者连接到代理并在不存储数据的情况下来回传输数据。
- 如果客户想要保存聊天记录，请为他们提供一些选项，将它们流式传输到他们自己服务器上的文件中，这样您就不会触及它们。或者提供一个 self-hosted add-on 他们可以自己托管，让他们保留数据和报告（在他们的控制下，而不是你的更容易销售）。如果它变得足够大并且您围绕它组建了一家公司......您始终可以做合规性的事情来提供一个包含数据的 SaaS 托管应用程序。
最好为欧盟访问者使用欧盟的服务器，以避免在未经同意的情况下无意中将数据传输到国外（即使是短暂的）。
不要在您的 service.com 服务器上记录任何个人身份信息、用户 ID 等。只需记录一个聊天 ID、start/end 时间、代理 ID、主题和您需要用于计费的其他统计信息……但与访问者无关。如果要记录 IP 地址，请截断最后一个八位字节（或将其设置为 0）以 semi-anonymize IP。
制作一个隐私解释器“one sheet”，从技术上解释您如何避免接触（或保留）任何潜在的敏感数据（“设计为隐私”）并将其包含在您的营销材料，因为它将帮助 short-circuit 潜在客户法律团队的任何查询。
第三题
How do cookie consent banners work behind the scenes?
大多数大公司都在使用实施来自 IAB Europe 的 TCF 框架（政策和技术规范）的合法 cookie 同意横幅。所有技术规格都在该网站上 public（针对供应商的 CMP 等）。
您不能只与回调集成。那样不行。您需要注册才能作为供应商参与该框架。然后，您可以调用 CMP 提供的特定 API 函数来检查访问者是否已提供同意，以及您（作为第三方供应商）是否已就任何特定目的以及哪些目的获得同意。
然而，正如我在问题 2 的回答中提到的，如果您小心的话，您可能不需要担心这一点。
一些网站推出了自己的 cookie 同意小部件，因为它们太小而无法处理完整 CMP 的复杂许可，并且因为它们通常需要披露的第三方供应商非常有限（可能只是 google分析和 google 广告和 Facebook 再营销像素）。这些如果构建良好，应该可以防止任何第三方 javascripts（或其他 http调用）从被加载直到同意被给予（或拒绝）。
我多年前构建的一个使用 google 标签管理器（post 同意）来管理使用 GTM 触发器加载的内容。在收到用户的信号之前，我们不会加载 GTM。在我们触发 GTM 之前，我们向数据层添加同意信号，指示用户同意（或不同意）的目的 (functional/analytics/marketing)。如果用户之前访问过该网站，则之前的同意将从 cookie 加载，因此小部件不会再次弹出。如果同意披露详细信息（供应商、目的）已更改，所有用户都会再次收到弹出窗口。一年过去后，他们也会收到弹出窗口。无论如何，在 GTM 中，我们设置了触发器，以便只有在获得适当的同意后才会触发标签。 Functional/Required cookie 总是在 GTM 之外加载。如果我们没有任何分析或营销许可，那么我们根本不会加载 GTM 来为“无”访问者加速网站。 GTM has added consent-specific features 在某些时候也是如此。
TCF 以相反的方式工作，大多数供应商总是会加载，但他们应该“自我管理”自己并检查来自 CMP 的信号是否同意...这意味着他们的代码必须修改广泛支持在他们不同意 set/read cookies 的情况下如何处理请求（例如）。供应商可能会出于一个目的而获得同意，但不会出于另一个目的……所以他们的代码必须尊重这一点。如果供应商有许多不同的 cookie 和目的，就会很快变得复杂。遵守该政策是供应商在加入 TCF 框架时同意的一部分。由于 Belgian Data Protection Authority's ruling 关于 TCF 实施隐私立法的有效性，TCF 目前也面临着一些重大挑战。但那是另一罐蠕虫。重点是：对 cookie 单击“否”并不一定意味着更少的网络请求或 TCF 世界中的 javascript 运行。
如果您注意存储（不存储）哪些数据并将存储的内容保存在客户的域下，那么您可能不需要担心 cookie 弹出窗口作为功能性 cookie。
如果您决定基于聊天数据（例如 disqus 样式）构建业务模型，那么您需要做更多的事情才能遵守法律并让您的大客户放心 legal/privacy 团队。
其他一些 cookie 弹出窗口是纯光学的。有很多手动添加的脚本标签且没有标签管理的旧站点。从技术上讲，他们的噩梦是为了合规。因此，他们添加了一个小部件，使其看起来合规，但在幕后没有任何变化。这些通常是收入很少甚至没有收入的小型网站，因此他们认为欧洲 DPA 永远不会费心去追捕他们……然而，专业律师事务所拥有机器人和信件生成来自动化大规模骚扰只是时间问题long-tail 个站点。目前的主要问题是这些律师事务所如何获得报酬，但如果他们设法就提供执法即服务的 DPA 罚款的百分比进行谈判……那么这将成为一件大事。
我正在做一个业余爱好项目。该项目基本上是一个可集成的实时支持服务。为了方便描述我的问题，我将调用我的服务 service.com 并调用使用我的服务的网站 website.com。我正在考虑实施 session 管理来恢复断开连接的访客聊天。为此，我计划使用基于 cookie 的 session 管理。如果 website.com 的所有者想要使用我的服务，我会为他们提供一个 JavaScript 文件，该文件将在 body 上注入一些 HTML，头上的样式标签并实现交互。 website.com 所要做的就是导入该 JS 文件并调用该 JS 文件定义的函数。要在我的 service.com 的那个 website.com 上设置第 3 方 cookie，我将使用这个 request/response。当 website.com 从 service.com 请求我的 JS 文件时，我的服务将使用 JS 文件和一个 cookie 来响应请求，以管理访问者的 session。这样 service.com 将为 website.com 的访问者设置第 3 方。
第一个问题： 在 website.com 的访问者上设置 cookie 的这个阶段是否可以在 front-end 上使用请求的 JS 文件或本地（来自website.com 的 Web 服务器）请求 JS 文件？那仍然是第 3 方 cookie，因为它将设置在 website.com 的 front-end 上吗？
第二个问题： 我的另一个问题是关于 cookie 许可。在某些其他网站（例如 website.com）上设置第 3 方 cookie（例如 service.com）的网站是否可以要求在 website.com 上允许他们的 cookie？换句话说，我可以要求 website.com 的访问者仅允许 service.com 使用我 serve/give 到 website.com 的 JS 文件设置的第 3 方 cookie 吗？这合法吗？
第 3 个问题： cookie 同意横幅如何在幕后工作？当您 accept/deny 在网站上使用所有第 3 方 cookie 时会发生什么？或者当您过滤并只接受其中的几个时会发生什么？ allowing/disallowing 的过程是如何工作的？单击“接受”按钮或“拒绝”按钮时是否会触发某种 JavaScript？您可以向我提供有关此主题的任何资源。
谢谢！
第一个问题 这取决于 cookie 的创建和存储方式。如果 cookie 正在存储 user-specific、website-specific 会话 ID 并且只会在该网站上使用，则可以使用您服务的 JavaScript 设置的第一方 cookie 进行存储front-end。如果它要在其他网站上使用（例如广告技术公司的唯一用户 ID），那将是第 3 方。
第二题 那不是你的责任。作为“数据控制者”（网站所有者）的网站提供商有责任向其用户声明其“数据提供者”（您），并让他们选择是否愿意存储他们的数据，并且（可能）已处理。
你 可以 但是尊重浏览器提供的 DoNotTrack 设置，你也可以实现一个工作流，允许你的代码 await 某种许可.我的意思是，您可以确保您的代码在调用 cookiePermissionProvided() 等函数之前不会执行。这将允许网站开发人员有效地将您的代码实施到他们网站的 cookie 同意回调中。
第三题 你可能对此感到惊讶，也可能不会感到惊讶，但他们中的一些人确实深蹲。
但是，实际 工作的那些通常使用某种承诺或回调功能，例如 ...
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 时将哪个代码 运行 的责任放在网站所有者身上，而不是您。您的责任是确保您的代码尊重必须等待被告知 run/store user-specific 数据。
希望这有用。
我在为我们的电子商务平台（在数百家零售商的网站上 运行 实现此功能时遇到了非常相似的问题。最终我们只选择一个 promise-based 系统，它在 运行 任何存储 user-sensitive 数据的代码之前等待许可。有些 cookie 是无法避免的，例如 ASP.net 会话（这些在立法中有规定）。
总而言之，我认为您不必担心您认为可能需要担心的一半。只需确保您的代码在被告知之前不会执行。如果可以，请提供替代回调，这样您的功能就可以 运行 而无需存储个人数据。例如聊天功能无法跨浏览器会话或页面重新加载 - 您应该在 UI 中考虑到这一点，方法是在用户开始聊天之前让他们知道（解释为什么会这样，甚至允许他们 opt-in事后[你必须解释存储的内容和原因] - 这也是允许的）。
http 与 javascript cookies
All the website.com's have to do will be importing that JS file and calling a function defined by that JS file. To set 3rd party cookies on that website.com from my service.com I will use this request/response. When website.com requests my JS file from service.com, my service will respond the request with the JS file along with a cookie to manage visitor's sessions. This way service.com will set 3rd party on website.com's visitors.
如果“request/response”是指对 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（即使您仅将其用于 session 而不是多次访问 website.com），您有两个选择：
客户白标 DNS。 客户创建 DNS 记录实时聊天。website.com 并将其 CNAME 到 api。service.com . api.service.com 然后通过 livechat.website.com 域处理流量，并且可以在那里 read/set cookies。但是，这需要在客户方面进行更多的技术联系，因为除了添加脚本标记外，还涉及添加 DNS 记录。
javascript cookies。 没有在 service.com 的 http 响应中设置 cookie，而是返回 javascript from service.com 是 运行 在 website.com 域中，如果您不想担心 cross-browser 编码时针对本机浏览器的问题，set javascript cookies as well as reading cookies under that domain (as long as they weren't set with the
httponlyoption). Take a look atjs-cookie库也可以document.cookies API.
如果您不执行上述任一操作，您在对 service.com 请求的响应中设置的 cookie 将成为第三方 cookie，并且可能无法始终如一地工作。
http cookies
...是通过 http 响应 header set-cookie 设置的 cookie，并且只能为请求的主机的域命名空间设置。如果此主机（带子域的完整域名）与用户地址栏中的域不同，这将被视为第三方 cookie 并受到一些限制。
您可以将first-party http cookie 设置为third-party 如果客户将在您的服务中指向他们域下的DNS 记录。
javascript 饼干
是由 javascript 在页面内设置的 cookie。他们可以在 javascript 位于 运行 的框架的 domain/namespace 内设置 cookie。他们可以从 domain/namespace 读取 cookie，只要它们没有设置 httponly 选项（通常这样做是为了防止第三方 javascript 劫持 session cookie）。
您可以将 javascript cookie 加载到适当域的框架中，作为第三方使用。
您可能还想阅读 Content Security Policy，如果客户使用 CSP 来锁定，它可以防止您的第三方 javascript 作为客户部署文档的一部分 运行下载他们的网站。
第一个问题
Could this stage of setting cookie on website.com's visitor...
done on the front-end with that requested JS file
是的，这是 javascript cookie。见上文。
or locally (from the website.com's web server) requested JS file
不确定你的意思。 website.com 网络服务器可以 host/proxy 你的 js 文件，但那只是静态文件服务，所以它并不能真正帮助你处理 session cookie 逻辑。
客户可以为您的 api 提供代理，其中包括 re-writing Cookie header，使他们成为第一方。虽然技术上可行，但这是 over-complicated 的方式，我不推荐它。只是表明很多事情都是可能的。
当然你可以想出很多办法。例如，您的客户可以托管一个非常简单的网络应用程序，该应用程序可以根据需要处理 reading/setting cookie 以响应 javascript 请求。也就是说，客户在他们的域下托管了一个您构建的小应用程序，以便 read/set 某些 http cookie 并提供此信息以响应来自您的 javascript 的 API 调用。但是，我认为这需要在客户端进行比 custom-DNS（以上）选项更多的技术集成。
我建议您坚持以下其中一项...
- 第三方 cookie 直接设置在来自 service.com 的 http 响应上
- 第一方 cookie 由您的 javascript client-side 在 website.com 帧内 loaded/run 后设置。
- 第一方 cookie 直接设置在 livechat 的 http 响应上。website.com 已通过 DNS 指向 service.com。
第二个问题
Can a website that sets 3rd party cookies (e.g service.com) on some other website (e.g website.com) ask to allow their cookies on that website.com?
所有这些 cookie 同意都来自两个相关的法规。欧盟的 GDPR 和加利福尼亚的 CCPA。
您看到的大多数 cookie 弹出窗口都与 GDPR 相关，并且遵循由互联网广告局 (IAB) 管理的称为透明同意框架 (TCF) 的标准。提供 cookie 弹出功能的技术方在 TCF 规范中称为 Consent Management Platform (CMP)它们位于网站（又名“发布者”）和可能想要对该网站上的访问者数据（cookie 或其他方式）做某事的各种第三方供应商之间。 Vendors/cookies 分为“目的”，允许访问者同意一种类型的数据使用，而不是另一种。有必需的 cookie（网站工作所必需的……就像登录 cookie）以及分析和营销以及其他类型的目的。如果您想了解这些人（发布商 - CMP - 供应商）如何工作的所有技术细节，请随时阅读规范。
但长话短说，您不需要从 cookie 弹出窗口中请求任何内容，您的公司已注册作为供应商参与规范，然后 CMP 可以将您包含在网站上的第三方供应商列表中访问者可以同意。作为个人hobby-project，成立公司并加入TCF框架可能已经超出了你此时想做的事情。
但是！
只有在欧盟才需要，如果您在欧盟没有customers/users，您可能不需要担心这个。
还有！
为了使网站的实时聊天功能正常工作，您的实时聊天将属于网站的 required/functional cookies...所以只要您注意数据 collection/storage-location/processing.. .您可能也可以在欧盟运营，没有问题，并且不需要任何特殊的额外 cookie 同意，因为您可以属于该网站的 required/functional cookie 保护伞。将数据处理和隐私责任交给 website.com。
最好使用带有 DNS 选项的 session cookie（在 website.com 域下）。不要在 session 恢复后跟踪用户，也不要将任何敏感数据放入将持续 session 秒的 cookie（或本地存储）中。
如果您打算将聊天记录存储在自己的服务器上，那么您获取个人数据的风险很高，因为用户将其提供给支持代理（phone 号码，姓名、地址等）。就法律要求和披露而言，这很快就会变得棘手。如果您不是公司，在欧洲开展业务的任何合法公司都不会使用您的实时聊天，因为缺乏数据 security/privacy 问责制。
- 所以你可能需要让聊天变得短暂。例如在客户域 (website.com) 下使用 client-side 存储，这样聊天记录永远不会 stored/persisted 在您自己的服务器上。您的服务器只是将访问者连接到代理并在不存储数据的情况下来回传输数据。
- 如果客户想要保存聊天记录，请为他们提供一些选项，将它们流式传输到他们自己服务器上的文件中，这样您就不会触及它们。或者提供一个 self-hosted add-on 他们可以自己托管，让他们保留数据和报告（在他们的控制下，而不是你的更容易销售）。如果它变得足够大并且您围绕它组建了一家公司......您始终可以做合规性的事情来提供一个包含数据的 SaaS 托管应用程序。
最好为欧盟访问者使用欧盟的服务器，以避免在未经同意的情况下无意中将数据传输到国外（即使是短暂的）。
不要在您的 service.com 服务器上记录任何个人身份信息、用户 ID 等。只需记录一个聊天 ID、start/end 时间、代理 ID、主题和您需要用于计费的其他统计信息……但与访问者无关。如果要记录 IP 地址，请截断最后一个八位字节（或将其设置为 0）以 semi-anonymize IP。
制作一个隐私解释器“one sheet”，从技术上解释您如何避免接触（或保留）任何潜在的敏感数据（“设计为隐私”）并将其包含在您的营销材料，因为它将帮助 short-circuit 潜在客户法律团队的任何查询。
第三题
How do cookie consent banners work behind the scenes?
大多数大公司都在使用实施来自 IAB Europe 的 TCF 框架（政策和技术规范）的合法 cookie 同意横幅。所有技术规格都在该网站上 public（针对供应商的 CMP 等）。
您不能只与回调集成。那样不行。您需要注册才能作为供应商参与该框架。然后，您可以调用 CMP 提供的特定 API 函数来检查访问者是否已提供同意，以及您（作为第三方供应商）是否已就任何特定目的以及哪些目的获得同意。
然而，正如我在问题 2 的回答中提到的，如果您小心的话，您可能不需要担心这一点。
一些网站推出了自己的 cookie 同意小部件，因为它们太小而无法处理完整 CMP 的复杂许可，并且因为它们通常需要披露的第三方供应商非常有限（可能只是 google分析和 google 广告和 Facebook 再营销像素）。这些如果构建良好，应该可以防止任何第三方 javascripts（或其他 http调用）从被加载直到同意被给予（或拒绝）。
我多年前构建的一个使用 google 标签管理器（post 同意）来管理使用 GTM 触发器加载的内容。在收到用户的信号之前，我们不会加载 GTM。在我们触发 GTM 之前，我们向数据层添加同意信号，指示用户同意（或不同意）的目的 (functional/analytics/marketing)。如果用户之前访问过该网站，则之前的同意将从 cookie 加载，因此小部件不会再次弹出。如果同意披露详细信息（供应商、目的）已更改，所有用户都会再次收到弹出窗口。一年过去后，他们也会收到弹出窗口。无论如何，在 GTM 中，我们设置了触发器，以便只有在获得适当的同意后才会触发标签。 Functional/Required cookie 总是在 GTM 之外加载。如果我们没有任何分析或营销许可，那么我们根本不会加载 GTM 来为“无”访问者加速网站。 GTM has added consent-specific features 在某些时候也是如此。
TCF 以相反的方式工作，大多数供应商总是会加载，但他们应该“自我管理”自己并检查来自 CMP 的信号是否同意...这意味着他们的代码必须修改广泛支持在他们不同意 set/read cookies 的情况下如何处理请求（例如）。供应商可能会出于一个目的而获得同意，但不会出于另一个目的……所以他们的代码必须尊重这一点。如果供应商有许多不同的 cookie 和目的，就会很快变得复杂。遵守该政策是供应商在加入 TCF 框架时同意的一部分。由于 Belgian Data Protection Authority's ruling 关于 TCF 实施隐私立法的有效性，TCF 目前也面临着一些重大挑战。但那是另一罐蠕虫。重点是：对 cookie 单击“否”并不一定意味着更少的网络请求或 TCF 世界中的 javascript 运行。
如果您注意存储（不存储）哪些数据并将存储的内容保存在客户的域下，那么您可能不需要担心 cookie 弹出窗口作为功能性 cookie。
如果您决定基于聊天数据（例如 disqus 样式）构建业务模型，那么您需要做更多的事情才能遵守法律并让您的大客户放心 legal/privacy 团队。
其他一些 cookie 弹出窗口是纯光学的。有很多手动添加的脚本标签且没有标签管理的旧站点。从技术上讲，他们的噩梦是为了合规。因此，他们添加了一个小部件，使其看起来合规，但在幕后没有任何变化。这些通常是收入很少甚至没有收入的小型网站，因此他们认为欧洲 DPA 永远不会费心去追捕他们……然而，专业律师事务所拥有机器人和信件生成来自动化大规模骚扰只是时间问题long-tail 个站点。目前的主要问题是这些律师事务所如何获得报酬，但如果他们设法就提供执法即服务的 DPA 罚款的百分比进行谈判……那么这将成为一件大事。