周三下午，你正准备登录某个网站，点击"我不是机器人"——然后噩梦开始。9宫格模糊照片，找红绿灯。点错了？再来一轮，这次是斑马线。三轮下来，你忘了自己本来要干什么。
这是看得见的折磨。看不见的是背后：一整个Cookie和追踪器军团正在判断你"够不够像人类"。这些Cookie不只是限制验证码频率，它们构建了一张画像网络，覆盖你访问过的每一个使用同一家服务商的网站。
这篇文章记录了我如何搭建一个不需要Cookie的验证码系统captchaapi.eu，以及为此付出的代价。这不是隐私宣言，而是一个工程问题：验证码真的需要Cookie吗？还是说，我们只是沿用了最早解决问题时最方便的工具，而GDPR改变成本结构后，没人回头质疑这个假设？
答案是不需要Cookie。以下是实现路径。
先看看reCAPTCHA的数据流——这是大多数欧盟开发者的默认选择。用户进入页面后：首先设置一个_GRECAPTCHA的跨站Cookie；如果用户登录了Google账号，还会读取SID、HSID、SSID、APISID、SAPISID等会话Cookie；同时收集浏览器元数据：用户代理、屏幕分辨率、插件、字体列表、时区、语言设置；最后基于用户在Google搜索、Gmail、YouTube及所有reCAPTCHA保护站点的近期活动，计算风险评分。
最后这点对GDPR至关重要。风险模型不是本地运行的——它是一个跨站图谱，横跨Google全系产品和无数第三方站点。Google称之为"高级风险分析"；从GDPR第4条第4款看，这就是典型的画像分析（profiling）。
数据还会流出欧盟。Google的处理器遍布全球，以美国为锚点。2020年Schrems II裁决废止Privacy Shield后，欧盟数据向Google传输需要标准合同条款或DPF认证，且传输影响评估必须承认CJEU明确标记的监控风险。
对一家欧盟SaaS来说，让用户"点击所有含红绿灯的方块"意味着合规负担。技术上并非不可行——Google公布了DPF认证，你签DPA、打勾即可。但这会带来下游摩擦：Cookie横幅、CMP集成、DPO审批，以及对下一次Schrems判决的担忧。
热门跟贴