mcpField
C
cookie-consent-ab-audit

cookie-consent-ab-audit

github.com/mukul975安全32336 次安装32 周前更新
代码仓库

关于 cookie-consent-ab-audit

用于审查 Cookie 同意横幅 A/B 测试的安全技能，面向隐私与合规团队。它依据 GDPR、ePrivacy 和 CNIL 等指导，评估设计是否通过不对称手段影响同意选择。

主要功能

  1. 01检查接受与拒绝选项的视觉差异
  2. 02评估完成接受或拒绝所需步骤
  3. 03识别语言、延迟与重复提示操纵
  4. 04按类别加权计算风险分数
  5. 05对比不同变体的同意率
  6. 06整理审计发现与整改建议

适用场景

  1. 01审查 Cookie 横幅的多个 A/B 变体
  2. 02定位拒绝选项更难操作的设计
  3. 03评估同意率提升是否伴随设计不对称
  4. 04为不合规横幅制定整改计划

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/mukul975/privacy-data-protection-skills --skill cookie-consent-ab-audit

安装后在 Claude Code 中输入/cookie-consent-ab-audit确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

assets/
template.md
references/
standards.md
workflows.md
scripts/
process.py

详细介绍

审计 Cookie 同意 A/B 测试

概述

对同意横幅进行 A/B 测试是优化同意率的常见做法。然而，如果这些实验通过设计不对称、欺骗性模式，或让接受比拒绝更容易，诱导用户同意，就会违反 GDPR 第 7 条和《电子隐私指令》第 5(3) 条。CNIL 是执法最积极的机构，曾因同意横幅设计违规，分别对 Google（2022 年 1 月）处以 1.5 亿欧元罚款，对 Meta（2022 年 1 月）处以 6,000 万欧元罚款。

同意横幅设计的监管框架

同等显著性要求

CNIL 第 2020-091 号审议决定（2020 年 9 月 17 日）和 EDPB《05/2020 号指南》规定：

  1. 视觉权重相同：“接受”和“拒绝”选项必须具有相同的视觉显著性——尺寸相同、颜色处理相同、字体相同、层级位置相同。
  2. 交互成本相同：拒绝 Cookie 所需的点击次数／步骤必须与接受所需的相同。
  3. 不得预先选择：不得预先选择任何用途或供应商。
  4. 不得设置 Cookie 墙：不得以接受 Cookie 作为访问内容的条件。
  5. 语言保持中立：任何一方都不应使用带有鼓励或劝阻意味的不对称措辞。
主要执法行动
监管机构对象罚款日期主要发现
CNILGoogle LLC150,000,000 欧元2022 年 1 月 6 日google.fr：接受 Cookie 只需点击 1 次；拒绝则需要通过次级菜单多次点击
CNILMeta Platforms Ireland60,000,000 欧元2022 年 1 月 6 日facebook.com：“接受 Cookie”按钮醒目显示；“拒绝”选项则隐藏在次级界面中
CNILMicrosoft Ireland60,000,000 欧元2022 年 12 月 22 日bing.com：显示“接受”按钮，却没有同样醒目的“拒绝”选项
CNILTikTok5,000,000 欧元2022 年 12 月 29 日拒绝 Cookie 比接受更复杂；信息不足
意大利 GaranteClearview AI20,000,000 欧元2022 年 3 月 9 日没有针对生物特征数据处理的有效同意机制

暗黑模式检测方法

类别 1：视觉不对称

检查内容：

  • 接受按钮：颜色、尺寸、字体粗细、边框、阴影、位置
  • 拒绝按钮：颜色、尺寸、字体粗细、边框、阴影、位置
  • 两者的视觉效果是否相同？在灰色文字链接“管理偏好设置”旁放置亮绿色的“全部接受”按钮，不符合要求。

测量指标：

  • 按钮面积（像素宽度 × 高度）
  • 与背景的颜色对比度（按照 WCAG 计算）
  • 字号和粗细
  • 视觉层级位置（首屏以上还是以下、左侧还是右侧）
类别 2：交互不对称

检查内容：

  • 全部接受所需的点击次数：通常为 1 次（点击“全部接受”）
  • 全部拒绝所需的点击次数：应为 1 次（点击“全部拒绝”）——不应是 2 次或以上（点击“管理”，再切换选项，最后点击“保存”）
  • 首层界面上是否有“全部拒绝”按钮？

CNIL 标准：“全部拒绝”按钮必须与“全部接受”按钮位于同一界面层，且具有同等显著性。

类别 3：语言操纵

检查内容：

  • 接受文本：中立还是带有鼓励意味？（“接受并继续享受我们的网站”）
  • 拒绝文本：中立还是带有劝阻意味？（“我不想要个性化体验”）
  • 拒绝选项是否被描述成会让用户失去某些东西？

不合规措辞示例：

  • 接受：“接受并享受个性化内容”／拒绝：“继续使用受限体验”——不合规
  • 接受：“好的，我同意”／拒绝：“拒绝所有 Cookie”——合规（两者都保持中立）
类别 4：时间和延迟操纵

检查内容：

  • 接受按钮是否比拒绝按钮更早出现？
  • 拒绝路径上是否存在加载延迟？
  • 关闭横幅（X 按钮）是否会默认表示接受？
类别 5：重复提示（反复催促）

检查内容：

  • 用户拒绝后，横幅是否会在下一页重新出现？
  • 多久会再次请求用户同意？
  • CNIL 建议间隔至少 6 个月。

A/B 测试合规边界

可进行的合规测试：

允许的测试禁止的测试
横幅位置（顶部与底部）接受按钮比拒绝按钮更大
配色方案（两个按钮采用相同的视觉处理）接受按钮比拒绝按钮更醒目
文案措辞（两个选项都保持同等中立）拒绝操作需要额外点击
布局安排（保持同等醒目）在某个变体中预先选中同意目的
图标使用（两个选项采用相同的图标）任何变体中设置 Cookie 墙
动画／过渡样式首层仅显示接受选项，而将拒绝选项深藏其中
隐私信息的呈现形式使用劝阻性措辞描述拒绝选项

审计流程

步骤 1：收集所有 A/B 测试变体

对于每项正在进行的同意横幅实验：

  • 截取桌面端和移动端所有变体的屏幕截图
  • 记录接受和拒绝元素的 HTML/CSS
  • 记录每个变体中接受和拒绝的用户流程
  • 记录流量分配情况（看到各变体的用户比例）
步骤 2：进行暗黑模式评估

对每个变体，按以下 5 个类别评分：

类别权重评分（0-10）备注
视觉不对称25%0 = 平等，10 = 极度不对称
交互不对称30%0 = 点击次数相同，10 = 拒绝需要多很多次点击
语言操纵20%0 = 中立，10 = 强烈操纵
时机／延迟15%0 = 无延迟，10 = 拒绝操作有明显延迟
重复提示10%0 = 尊重用户选择，10 = 不断催促

总体风险评分： 加权总分。评分高于 3.0 时需要整改。评分高于 5.0 时必须立即移除。

步骤 3：比较各变体的同意率

如果某个变体通过设计不对称而非改进信息来显著提高同意率，这就是操纵行为的证据：

  • 基线比较：比较完全对称设计之间的同意率
  • 预警阈值：如果某个变体的同意率高出 >20%，且设计元素存在不对称，则标记以供审查
  • 统计显著性：采用标准的 A/B 测试统计方法（卡方检验或贝叶斯方法），但须结合监管视角——操纵行为在统计上显著，即构成违规证据
步骤 4：记录并报告

生成审计报告，内容包括：

  • 所有变体的屏幕截图
  • 各变体的暗黑模式评分
  • 同意率分析
  • 针对不合规变体的建议
  • 整改时间表

主要监管参考资料

  • GDPR 第 7 条——同意条件（难易程度相同、自由给予）
  • ePrivacy 指令第 5(3) 条——对 Cookie 和类似技术的同意
  • CNIL 第 2020-091 号审议——Cookie 和追踪器指南
  • CNIL 第 2022-013 号审议——Google 罚款（1.5 亿欧元）
  • CNIL 第 2022-014 号审议——Meta 罚款（6,000 万欧元）
  • EDPB 指南 05/2020——《条例 2016/679》下的同意
  • EDPB 指南 3/2022——社交媒体平台界面中的暗黑模式
  • FTC《暗黑模式报告》（2022 年 9 月）——美国对操纵性设计的观点

评论

支持 Markdown