我正在一个非常注重隐私的环境中设置 discourse 论坛。我目前遇到的障碍是 persistent sessions（持久化会话）设置，即登录时的“记住我”功能。据我所知，GDPR 要求用户明确同意存储功能性/偏好性 cookie，其中包括持久化会话（因为用于处理持久化会话的 cookie，或者说它在浏览器会话之外的生命周期，并非严格必需）。
这导致了两个非常不吸引人的选择：
-
禁用 persistent sessions，迫使用户每次访问论坛时都必须登录，或者建议/强制他们使用浏览器内置的凭据存储功能，以避免每次手动登录。然而，由于我们将使用 SSO 进行论坛访问，并且通过该 SSO 登录可以访问许多不同的服务，因此让用户仅为访问论坛而存储 SSO 凭据并非好的策略。这可能会弊大于利。
-
启用 persistent sessions。但在这里，我找不到一种可行的方法将 cookie 横幅集成到 Discourse 中，该横幅能够处理持久化会话标志的每个用户配置值。后者至关重要，因为用户必须给予同意，包括能够撤销该同意，这需要某种形式的 cookie 横幅/管理解决方案。
我活跃在许多启用了 persistent sessions 但未提供 cookie 同意选项的 Discourse 论坛上（包括这个元论坛）。在我看来，它们似乎违反了 GDPR？
我的上述理解是否错误（因为我不是律师）？并且真的没有好的解决方案可以集成一个 cookie 同意横幅到 Discourse 中，允许配置每个用户的持久化 cookie 设置？
编辑：我确实阅读了 Cookie Consent, GDPR, and Discourse 以及诸如 Session Timeout - #56 by sam 等帖子，但在发帖之前，它们并没有真正触及持久化会话的核心问题。
Jagster
(Jakke Lehtonen)
2
这里现在有两件不同的事情。
根据 GDPR/数据隐私法律，您不需要获得持续会话的同意。它是用户的技术 cookie，不用于收集个人数据。当然，您必须告知它的存在，但如果用户想避免被记住，他们每次都应该注销。您仍然可以提供它。
还有这个：
那完全是另一回事了。在北欧国家，所有涉及银行、医疗保健、政府/地方机构等领域的网站都会在一段时间后或在不活动期间自动注销（希望在全球都是如此），并且无法使用持久性 cookie。同样，对于出于自身原因非常注重隐私的网站也是如此。
如果您的案例也是如此，我不知道有现成的解决方案，但这里有很多专家可能/将会知道。
但总的来说，您不需要用户的同意。但有时您甚至不能提供它。
重点不是它不收集个人数据，而是 _t cookie 将您识别为个人，因为它直接与 Discourse 服务器上的用户帐户会话相关联。因此，当您使用浏览器访问设置它的网站时，浏览器中设置的身份验证 cookie 意味着您可以被服务器识别（因此您不是匿名的）。根据欧洲委员会的数据保护工作组 WP 29 关于 Cookie 同意豁免的意见 04/2012 - 00879/12/EN WP 194：
存储跨浏览器会话的身份验证令牌的持久登录 cookie 不在 B 标准下豁免。这是一个重要的区别，因为用户可能没有立即意识到关闭浏览器不会清除其身份验证设置。他们可能会在假设自己是匿名的同时返回网站，而实际上他们仍然登录到该服务。在提交表单旁边使用复选框和简单的信息注释（例如“记住我（使用 cookie）”）的常用方法是获得同意的适当方式，因此无需在此情况下应用豁免。
请注意，他们建议网站可以实现一个简单的解决方案，即在登录表单中添加一个“记住我”复选框，这在如今几乎随处可见（但在 Discourse 中没有）。这是 2012 年的决定，当时 GDPR 尚未生效，但我没有看到任何信息表明它已被取代（例如，Cookie Consent Exemptions: Strictly Necessary Cookies - CookieYes 于 2023 年 8 月更新，仍然提到持久身份验证 cookie 需要同意）。但可能存在我不知道的法律后续或发展。
Jagster
(Jakke Lehtonen)
4
错了。这才是唯一的重点。
这并不是收集和存储可以或将会用于识别用户的个人数据。论坛无论如何都知道您是谁。
如果你使用没有设置该 cookie 的浏览器访问论坛，论坛又怎么会知道你是谁呢？而且，你应该能够使用论坛而不被隐式跟踪，除非你已明确同意，在这种情况下，你允许 _t cookie 在浏览器会话结束后继续存在。
RGJ
(Richard - Communiteq)
6
为了记录在案，以上信息不正确。
@paulmelis 我认为你是正确的，这是一个很好的发现。
持久化 cookie 确实需要明确的许可，即使它为用户提供了特定的功能：用户必须明确请求该功能。
更糟糕的是，目前可用于 Discourse 的各种现有“Cookie 同意横幅”解决方案，包括官方主题组件，均不符合 GDPR 标准。它们只会告知用户正在设置这些 Cookie，但如果用户不单击“我明白”按钮，Discourse 仍会愉快地设置这些 Cookie。换句话说，这些解决方案并没有请求某事发生的许可，它们只是告知用户某事正在发生（或者更糟：已经发生了）。
因此，即使您的论坛上有 Cookie 同意横幅，如果您启用了持久化会话，您仍然违反了 GDPR。
话虽如此，我怀疑这在实践中不会是一个大问题，但对于我们这些寻求 100% 合规的人来说，这确实是一个问题。
目前，您唯一的选择是禁用 persistent sessions 设置。
乍一看，这在插件中看起来非常可行，但如果将其包含在 Discourse 核心中会更好。
1 个赞
Jagster
(Jakke Lehtonen)
8
并非如此。这已经通过欧盟法律在大型企业中多次推广，而且从未改变。
仍然需要记住 GDPR 及其后续法规的目标和目的。以及为什么我们可以使用技术 cookie 而无需征得同意。
RGJ
(Richard - Communiteq)
9
@paulmelis 提供了来自欧盟官方文件的引用，其中明确说明它们不被 GDPR 允许。
如果您有不同的信息，我很乐意倾听，但请引用您的来源并提供原始文件的链接。
Jagster
(Jakke Lehtonen)
10
它没有那么说。
无意冒犯，但这就像提供公开立法作为信息来源一样困难且毫无意义，就像指引我了解 swap 的秘密并提供 man swapon 一样毫无意义。存在对某些知识的需求，我可以阅读那些 man pages，但我无法理解我所读的内容。
我每天都在处理这些问题，这些问题对我来说都不是新的。这就是为什么我给出两个建议：
- 购买所需的软件并询问所有事项所需的同意（但这没有帮助，因为最终重要的是数据的用途，而不是同意本身）
- 如果一个企业足够大（例如 CDCK），存在被罚款的实际风险，那么必须使用公司的法律部门或专业第三方
paulmelis
(Paul Melis)
11
是的，我（不幸地）现在就是这么做的。
我真的很想知道你是如何阅读那份文件的。我的意思是，3.2 身份验证 Cookie 说得很清楚：
身份验证 Cookie 用于在用户登录后（例如：在网上银行网站上）识别用户。这些 Cookie 对于允许用户在 successive visits 到网站上进行身份验证并访问授权内容（例如查看其账户余额、交易等）是必需的。身份验证 Cookie 通常是会话 Cookie。也可以使用持久 Cookie，但它们不应被视为相同，如下文所述。
承认了身份验证 Cookie（注意，不是技术 Cookie）的必要性。明确指出这些 Cookie 的生命周期，即会话 Cookie 与持久 Cookie，意味着它们需要被区别对待。
当用户登录时，他明确请求访问他已授权的内容或功能。如果没有使用存储在 Cookie 中的身份验证令牌，用户将在每次页面请求时都必须提供用户名/密码。因此，此身份验证功能是他明确请求的信息社会服务的关键组成部分。因此，这些 Cookie 在 CRITERION B 下被豁免。
然而，需要注意的是，用户仅请求访问网站和执行其所需任务的特定功能。身份验证行为不应被视为在未经同意的情况下利用 Cookie 进行其他次要目的（如行为监控或广告）的机会。
登录意味着用户同意登录，而不是通过任何身份验证 Cookie 进行其他类型的数据使用。
存储跨浏览器会话的身份验证令牌的持久登录 Cookie 不在 CRITERION B 的豁免范围内。 这是一个重要的区别，因为用户可能没有立即意识到关闭浏览器不会清除其身份验证设置的事实。他们可能会在假设自己是匿名的情况下返回网站，而实际上他们仍然登录到该服务。使用复选框和简单的信息提示（例如“记住我（使用 Cookie）”）与提交表单并列，是获得同意的适当方式，从而无需在此情况下应用豁免。
CRITERION B 是：
Cookie 是“信息社会服务提供商为用户明确请求的服务所必需的”。
因此，在设置持久身份验证 Cookie 之前，用户需要提供同意。原因：您不能期望用户默认了解持久身份验证的含义。
是的，这项立法是模糊而复杂的，近二十年来有许多不同的更新。即使是我查看过的欧盟官方网站，在处理 Cookie 和他们声明的政策方面似乎也非常混乱。
3 个赞