http vs javascript cookies

所有的website.com需要做的就是导入那个JS文件，然后调用那个JS文件定义的一个函数。要从我的www.example.com在那个website.com上设置第三方cookieservice.com我将使用这个请求/响应。当website.com请求我的JS文件service.com，我的服务将用JS文件沿着一个cookie来管理访问者的会话。这样，service.com将在www.example.com的访问者上设置第三方website.com。
如果“请求/响应”指的是对www.example.com的http请求，service.com请求将使用存储在website.com（客户域）下的cookie进行回复......这不适用于http cookie，因为您仅限于在您的域命名空间内阅读设置cookie。即，对www.example.com请求的响应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是第三方（网站访问者正在与www.example.com交互website.com）。许多浏览器（safari，firefox）默认情况下阻止第三方Cookie。
要解决此问题并拥有更可靠的cookie（即使您仅在会话中使用它，而不是多次访问website.com），您有两个选择：

***客户白标DNS。**客户创建DNS记录livechat.website.com和CNAME，这些DNS记录指向api.service.com。api.service.com然后通过www.example.com域处理流量livechat.website.com，并可以在那里读取/设置Cookie。但是，这需要客户方面的更多技术连接，因为除了添加脚本标记外，还需要添加DNS记录。
***javascript cookies。**不是在来自www.example.com的http响应中设置cookieservice.com，而是从service.com返回的javascript在www.example.com域中运行website.com，因此set javascript cookies也可以在该域下阅读cookie如果你不想在使用原生浏览器文档.cookies API进行编码时担心跨浏览器的问题，可以看看js-cookie库。

如果您不执行上述任何一项操作，您在对www.example.com的请求的响应中设置的cookieservice.com将是第三方cookie，可能无法始终正常工作。

http cookies

...是通过http响应头set-cookie设置的cookie，只能为请求的主机的域名空间设置。如果此主机（完整域名和子域）与用户地址栏中的域不同，则将其视为第三方cookie，并受到一些限制。
如果客户将其域下的DNS记录指向您的服务，您可以将第一方http cookie设置为第三方。

javascript cookies

是由JavaScript在页面内设置的cookie。他们可以在JavaScript运行的框架的域/命名空间内设置cookie。他们可以从该域/命名空间读取cookie，只要它们没有设置httponly选项（通常这样做是为了防止第三方JavaScript劫持会话cookie）。
您可以通过加载到适当域的框架中作为第三方使用javascript cookie。
您可能还想了解Content Security Policy，如果客户使用CSP锁定其站点，则可以阻止第三方javascript作为客户部署文档的一部分运行。

第一个问题

在www.example.com的访问者上设置cookie的这个阶段是否可以website.com...
在前端使用所请求的JS文件完成
是的，这是javascript cookie。见上文。
或本地（从website.com的Web服务器）请求的JS文件
不知道你的意思是什么。website.com网络服务器可以托管/代理你的js文件，但这只是静态文件服务，所以它并不能真正帮助你处理会话cookie逻辑。
客户可以托管一个代理到你的API，包括重写你的响应的cookie头，使他们成为第一方。虽然技术上可行，这是过于复杂的方式，我不推荐它。只是表明很多事情是可能的。
当然，你可以设计许多解决方案。例如，你的客户可以托管一个非常简单的网络应用程序，它可以根据JavaScript请求按需处理阅读/设置cookie。即客户托管一个你在其域下构建的小应用程序，以便读取/设置某些http cookie，并提供此信息以响应来自JavaScript的API调用。然而，我认为这需要对客户进行更多的技术集成。s结束比自定义DNS（以上）选项。
我建议你坚持以下其中一项...

• 第三方cookie直接设置在来自www.example.com的http响应service.com

• 在www.example.com框架内加载/运行后，由您的javascript客户端设置的第一方cookiewebsite.com。

• 第一方cookie直接设置在来自www.example.com的http响应上livechat.website.com，该响应已service.com通过DNS指向www.example.com。

第二个问题

在service.com其他网站（例如www.example.com）上设置第三方Cookie（例如www.example.comwebsite.com）的网站是否可以要求允许其在该www.example.com上使用Cookiewebsite.com?
所有这些Cookie许可都来自两个相关法规：欧盟的GDPR和加州的CCPA。
您看到的大多数cookie弹出窗口都与GDPR相关，并遵循称为透明度同意框架的标准（TCF）由互联网广告局管理（IAB）。提供cookie弹出功能的技术方在TCF规范中称为Consent Management Platform (CMP)。它们位于网站（又名“发布者”）和各种第三方供应商，他们可能想对该网站上的访问者数据做些什么（cookies或其他）。供应商/cookies被分组为“目的”，允许访问者同意一种类型的数据使用，而不是另一种。有必要的cookies（需要网站的工作...像一个登录cookie）和分析和营销和其他类型的目的。随时阅读规范，如果你想知道这些家伙如何所有的技术细节（出版商-CMP-供应商）工作。
但长话短说，你不从cookie弹出请求任何东西，你的公司注册参与规范作为一个供应商，然后CMP可以包括您在第三方供应商名单上的网站，访问者可以同意.作为一个个人爱好项目，组建一家公司并加入TCF框架可能超出了您现在想要做的事情。但是，如果您的cookie需要披露，网站通常可以手动将您添加到他们的cookie披露中。

然而！

这只在欧盟（和加州，加拿大）需要，如果你没有客户/用户在上面，你可能不需要担心这一点。

还有！

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

• 理想情况下，使用带有DNS选项的会话cookie（在website.com域下）。不要在会话恢复后跟踪用户，也不要将任何敏感数据放在cookie（或本地存储）中，这些数据将在会话中保留。
• 如果您打算将聊天记录存储在自己的服务器上，那么当用户将其提供给支持代理时，您就有很高的风险获得个人数据（电话号码，姓名，地址等）。这在法律的要求和披露方面变得非常棘手。如果您不是公司，在欧洲开展业务的合法公司将不会使用您的实时聊天，因为缺乏数据安全/隐私责任。
• 因此，您可能需要使聊天短暂。例如，在客户的域（website.com）下使用客户端存储，以便聊天日志永远不会存储/持久化在您自己的服务器上。您的服务器只是将访问者连接到代理并来回传输数据，而不存储它。
• 如果客户想保存聊天记录，可以为他们提供一些选项，让他们将聊天记录流式传输到自己服务器上的文件中，这样你就不会碰他们。或者提供一个他们可以自己托管的自托管附加组件，为他们提供数据保留和报告功能（在他们的控制下不是你的，所以更容易销售）。如果它变得足够大，你围绕这个成立一家公司...你总是可以做合规性的事情来提供一个包含数据的SaaS托管应用程序。
• 理想情况下，为欧盟访问者使用欧盟的服务器，以避免在未经同意的情况下无意中将数据传输到国外（即使是短暂的）。
• 不要在您的www.example.com服务器上记录任何个人身份信息，用户ID等service.com。只需记录聊天ID，开始/结束时间，代理ID，主题和其他您需要计费的统计信息......但不要记录访问者的信息。如果您想记录IP地址，请截断最后一个八位字节（或将其设置为0）以半匿名化IP。
• 制作一个隐私解释器“一张纸”，从技术上解释你如何避免接触（或保留）任何潜在的敏感数据（“设计隐私”），并将其包含在你的营销材料中，因为它将有助于缩短潜在客户法律的团队的任何询问。

第三题

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

大多数大公司都在使用实现TCF框架的合法cookie同意横幅。（政策和技术规格）。所有的技术规格都在那个网站上公开（对于供应商的CMP，等）。实现TCF支持的相同cookie同意供应商通常也添加了对CCPA规则的支持。加拿大现在也采用了欧盟的TCF，以简化操作。但是，您也可以手动添加到大多数cookie弹出窗口。
你不能只通过回调函数集成到TCF中。不是这样的。你需要注册以供应商的身份参与框架。然后你可以调用CMP提供的特定API函数来检查访问者是否已经提供了同意，以及你（作为第三方供应商）是否已经收到了任何特定目的的同意以及哪些。
Cookie同意提供商通常为网站提供手动（或通过爬虫自动）添加和声明TCF框架（以广告为重点）范围之外的其他供应商/Cookie的能力。如果需要，这将适用于您。
一些cookie同意提供商会复制/删除/解析页面，以阻止第三方脚本的触发，然后重新注入修改的页面。我不是一个球迷，因为这可能会导致奇怪的行为。一些提供商还使用MutationObserver来监视第三方加载的东西。常见的/手动的情况是手动修改第三方iframe/javascript/image/etc html标签使用数据属性，以便标记此cookie同意...并防止加载（即将src移动到不同的属性，因此标签不会加载）。如果同意，则这些元素可以由cookie同意库更新以加载。
然而，正如我在问题2的回答中提到的，如果你小心的话，你可能不需要担心这一点。
一些网站已经推出了自己的cookie同意小部件，因为它们太小，无法处理复杂的许可证的完整CMP，因为他们往往有非常有限的第三方供应商，他们需要披露（也许只是谷歌分析和谷歌广告和Facebook再营销像素）。这些如果他们是良好的建设应该防止任何第三方的javascript（或其他http调用）被加载直到已经给出（或拒绝）同意。
我几年前建的一个使用谷歌标签管理器（post consent）来管理使用GTM触发器加载的内容。在收到用户的信号之前，我们不会加载GTM。在触发GTM之前，我们将同意信号添加到数据层，以指示哪些目的（功能/分析/营销）用户已同意如果用户以前访问过该网站，则从cookie加载以前的同意，以便小部件不会再次弹出。如果同意披露详细信息（供应商、目的）发生了变化，所有用户再次获得弹出窗口。他们也会在一年后获得弹出窗口。无论如何，在GTM中，我们设置触发器，以便只有在给予适当的同意时才会触发标签。功能性/必需的cookie总是在GTM之外加载。如果我们不这样做，我们将在GTM中设置触发器。t有任何分析或营销同意，那么我们从来没有加载GTM在所有加快网站的“没有”游客。
TCF的工作方式正好相反大多数供应商将始终加载，但他们应该“自我管理”自己，并检查来自CMP的信号，无论他们是否同意......这意味着他们的代码必须广泛修改，以支持在他们不同意设置/读取cookie的情况下如何处理请求（例如）。供应商可能会为一个目的而不是另一个目的获得同意......因此他们的代码必须尊重这一点。如果供应商有许多不同的cookie和目的，就会很快变得复杂。遵循政策是供应商在加入TCF框架时同意的一部分。TCF目前也面临着一些巨大的挑战，因为关于TCF实施隐私立法的有效性的Belgian Data Protection Authority's ruling。但这是另一个蠕虫。要点是：点击“不”cookie并不一定意味着更少的网络请求或在TCF世界中运行的javascript。
如果您对存储（不存储）哪些数据并将存储的内容保存在客户的域中，那么您可能不需要担心cookie弹出窗口作为功能性cookie。
如果你决定建立一个基于聊天数据的商业模式（例如disqus风格），那么你需要做的还有很多，以符合法律规定，并让你的大客户的法律/隐私团队放心。

其他一些cookie弹出窗口是纯粹的光学。旧网站有很多手动添加的脚本标签和没有标签管理。噩梦他们在技术上得到兼容。所以他们添加一个小部件，使它看起来像他们是兼容的，但没有改变幕后。这些通常是小网站，几乎没有收入，所以他们认为欧洲DPA永远不会打扰他们...然而，这只是一个时间问题，直到专业律师事务所有机器人和信件生成自动化的大规模骚扰长尾网站。目前的主要问题是这些律师事务所如何获得报酬，但如果他们设法谈判的DPA罚款的百分比提供执法作为一种服务......那么它将成为一件大事。

第一个问题这取决于cookie的创建和存储方式。如果cookie存储的是用户特定的、网站特定的会话ID，并且只会在该网站上使用，则可以使用由您提供给前端的JavaScript设置的第一方cookie来存储。如果要在其他网站上使用（例如广告技术公司的唯一用户ID），则将是第三方cookie。
第2个问题这不是您的责任。作为“数据控制者”（网站所有者），网站提供商有责任向用户声明其“数据提供者”（您），并给予他们选择是否希望存储和（可能）处理他们的数据。

但是，您可以遵守浏览器提供的DoNotTrack设置，并且您还可以实现一个工作流，允许您的代码具有某种await权限。我的意思是，您可以确保您的代码在调用cookiePermissionProvided()等函数之前不会执行。这将允许网站的开发人员有效地将您的代码实现到其网站的cookie同意回调中。

第三个问题你可能会或可能不会感到惊讶，但他们中的一些人绝对diddly蹲。

然而，那些 * 实际 * 工作的通常使用某种承诺或回调功能，例如...

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时运行哪些代码的责任在于网站所有者，而不是您。您的责任是确保您的代码遵守必须等待被告知才能运行/存储用户特定数据的原则。
希望这个有用。
我在为我们的电子商务平台（在数百家零售商的网站上运行）实施此功能时遇到了非常类似的问题。最终，我们选择了一个基于承诺的系统，该系统在运行任何存储用户敏感数据的代码之前都要等待许可。一些cookie无法避免，例如ASP.net会话（这些在立法中有说明）。
总之，我认为你不必担心你认为你可能需要担心的一半。只要确保你的代码在被告知之前不会执行。如果可以的话，提供一个替代的回调，这样您的功能就可以运行而不存储个人数据。例如，聊天功能将无法在浏览器会话或页面重新加载时工作-你应该在你的UI中说明这一点，让用户在他们开始聊天之前就知道（解释为什么会这样，甚至允许他们在事实发生后选择加入[你必须解释存储了什么和为什么] -这也是允许的）。