过去几周 AI 隐私领域最扎眼的一篇独立披露,既不是漏洞利用,也不是 P0 级别的安全事件,而是一个被白纸黑字写在 OpenAI 自家 cookie 策略里的、配置成「跨站可携带」的 cookie:__obi。
9 月 20 日的披露
独立安全研究者 Jamie Larson 9 月 20 日在 Buchodi Threat Intel 公开了一篇长文,描述 OpenAI 在 bzr.openai.com 上的广告收集器会写入一个名为 __obi 的 cookie,作用域为 .openai.com,有效期 1 年,配置为 SameSite=None;Secure。这正是浏览器允许跨站请求带出 cookie 的唯一组合,而 OpenAI 自己的 cookie 策略里所有其他标识都配置了 SameSite=Lax 或受域限制,被浏览器默认阻断。
研究者在自己手机上复现了完整链路,并用两种独立抓包方法交叉验证,样本覆盖 936 个广告像素、1029 个域名、共 23929 次请求。当用户随后访问安装了 OpenAI 广告 SDK 的商家网站时,这个 cookie 会随像素请求一起被发回 OpenAI 的广告基础设施。OpenAI 可将用户在这些网站上的浏览行为——搜索的产品、阅读的文章、购买的动作——映射回 ChatGPT 账户。
三个步骤拆解
第一步,客户端在 chatgpt.com 上生成 16 字节随机数,调用 /backend-api/bazaar/obi/sync-token,后端返回 RS256 JWT,内含账号 sub 字段和 obi 字段,有效期 60 秒。iss 为 chatgpt-wadi,aud 为 bzr.openai.com,bzr 是 OpenAI 内部对广告平台的代号。第二步,这个 JWT 被跨站 POST 到 bzr.openai.com/v1/obi/sync,响应通过 Set-Cookie 把 __obi 写入 .openai.com,1 年有效期,SameSite=None;Secure。第三步,广告主网站随后通过 OpenAI 的广告像素 SDK 发出的任何请求——包括单纯加载 SDK 脚本本身——浏览器都会自动附上这个 cookie,请求被 bzr.openai.com 返回 202 Accepted 接收。
研究者在 932 个解码出的 sync token 中发现,736 个是登录态(主体类型为 account_user),196 个是匿名态(主体类型为 anonymous),匿名标识同样稳定,一台设备一份,持续至少 27 天。
数据负载与同意绕开
随 cookie 一起被回传的还包括从广告主页面抓取的身份信号,SDK 自己把数据来源分成四类:in(广告主显式传入)、fm(表单字段抓取)、js(从 GTM/Adobe dataLayer 拦截)、ht(渲染页面文本)。研究者在流量样本中观察到,被 SDK 抓取的来源(685 次)几乎是广告主主动提供的(255 次)的 3 倍。邮箱、电话、姓名 SHA-256 哈希后传输,而国家、地区、城市、邮编明文发送——邮编是被抓取最频繁的字段,在 28 个站点共观察到 100 次。
研究者 9 月 14 日向 OpenAI 的 press 与 privacy 邮箱分别发信,提出了两个直接问题:第一,为什么 __obi 被归类为分析 cookie 而不是营销 cookie;第二,如果用户拒绝营销同意但接受分析同意,是否仍会收到这个 cookie。OpenAI Support 确认收到问题并表示会内部评审,截至披露日两个问题都未得到实质性答复。
这件事真正的分量
这并不是一次新的攻击,而是 OpenAI 自身广告产品线的标配基础设施,设计上完全合规、配置上完全公开。但它的配置细节暴露了三个值得讨论的问题。第一,SameSite=None 是 cookie 跨站可携带的唯一必要条件,而 OpenAI 策略中只有 __obi 这一个 cookie 走这条路,这是有意为之的产品决策,不是技术疏漏。第二,OpenAI 把 __obi 归类为「分析 cookie」而非「营销 cookie」,绕开了用户只授权分析而拒绝营销这一常见设置——cookie 同意弹窗里那个看似无害的分析开关,实际上足以让广告标识被写入。第三,把广告 SDK 集成进商家网站,与 Meta Pixel、Google Ads Tag 在结构上没有区别;真正不同的是承载它的产品——人们向一个对话式 AI 倾诉的内容,和向搜索引擎/社交网络暴露的内容,在隐私直觉上从来不在同一个量级。
研究者的复现明确指出几个边界:第一,这个机制在 Safari 和任何 iOS 浏览器上被 ITP 默认拦截;Firefox 的 Total Cookie Protection 和 Brave 也同样默认阻断;只有 Chrome for Android 被验证复现成功,桌面 Chrome 未测试。第二,大约每 5 次 ChatGPT 会话中只有 1 次会触发 sync token;移动 Web 版有时根本不触发。第三,OpenAI 服务端把 __obi 与账户的对应 join 在设计上必然存在(否则没必要在 JWT 里带 sub),但研究者没能在流量层直接观测到服务端 join。
实操层如何自检
对用户而言,排查路径相对清晰。Safari 用户(包括所有 iOS 浏览器)无需操作,ITP 默认拦截所有第三方 cookie,机制直接失效;Firefox 默认开启 Total Cookie Protection、Brave 默认开启站点隔离,效果相同。Chrome 用户需要在设置里手动开启第三方 cookie 阻断并搭配 uBlock Origin。最稳妥的做法是周期性清理 .openai.com / chatgpt.com 下的 cookie,虽然下次 ChatGPT 会话可能再次写入。
对开发者与广告主而言,这件事提出了一个尴尬的现实:你安装了 OpenAI 的转化标签,你看不到自己的访客正在被打成 ChatGPT 账户标识,__obi 的域不可读,你没法审计,也无法拒绝。这是广告 SDK 黑盒化带来的新一阶风险——你卖的流量你看不到,但卖你流量的平台看得到。OpenAI 在披露日的沉默,让这个机制暂时停留在「合法但未充分告知」的位置。对 ChatGPT 用户而言,这件事真正的提示是:在「同意分析」和「同意营销」两个看似并行的开关背后,可能藏着第三层跨产品关联,而你点下的那个看似无害的按钮,是这一切的开端。