一个叫 __obi 的 cookie，让 OpenAI 能收到你在外部网站的浏览数据

原文来源：buchodi.com — 作者在自己手机上复现了 OpenAI 的广告归因链路，发现一个跨站 cookie 把 ChatGPT 账号和外部网站的浏览行为连了起来。

OpenAI 的广告采集端点 bzr.openai.com 会设一个叫 __obi 的 cookie，作用域是 .openai.com。它的值在你使用 ChatGPT 时生成，绑定到你的 ChatGPT 账号，然后会从你访问的普通网站上被送回 OpenAI。

机制不难理解：任何在 ChatGPT 上买广告的公司，都会在自己网站里装一小段 OpenAI 的代码，就像电商早就装了 Meta 和 Google 的追踪代码一样。这段代码一加载，就会把 __obi 连同当前页面的信息发给 OpenAI——你在搜什么商品、在读什么文章、有没有下单，都在这份数据里。结果是 OpenAI 能把你在这类网站上的行为和你的 ChatGPT 账号连起来。

作者说，他是在自己手机上把这个机制完整复现出来的，用了两种互相独立的抓包方式交叉验证，另外还比对了几个月的观察流量——覆盖 1,029 个域名下的 936 个不同的广告主像素。

三步链路

第一步，ChatGPT 生成标识符并签名。在 chatgpt.com 上，客户端生成 16 个随机字节，调用 POST /backend-api/bazaar/obi/sync-token（未登录时走 /backend-anon/）。后端返回一个 RS256 签名的 JWT，里面几个字段是关键：iss 是 chatgpt-wadi，aud 是 bzr.openai.com，purpose 是 obi_sync，consent_decision 是 analytics_allowed。sub 是账号，obi 是一个 22 字符的标识符，两者被这个 token 绑定在一起，60 秒后过期。bzr 是 bazaar 的缩写，OpenAI 内部对广告平台的叫法；wadi 是签发服务。

第二步，标识符变成 OpenAI 域名下的 cookie。客户端把 token 跨站 POST 到 bzr.openai.com/v1/obi/sync，响应里是这么一行：

Set-Cookie: __obi=«redacted»; Domain=.openai.com; HttpOnly;
Max-Age=31536000; Path=/; SameSite=none; Secure

SameSite=none 加 Secure，正是让一个 cookie 能在跨站请求里被带上的配置。有效期一年。JWT 里的 obi 值和 cookie 里的值完全一致。

第三步，广告主的网站把它送回去。作者在手机上带着这个 cookie 访问广告主页面，发现三类请求全都带上了它：加载 SDK 脚本本身的 GET bzrcdn.openai.com/sdk/oaiq.min.js、带 obref 的转化事件上报、以及 SDK 那条「不带凭证」的请求路径。作为对照，配置接口那条请求完全没有 cookie。

第一行最值得琢磨：SDK 里确实有一段代码故意不带凭证，但这没用——浏览器是在 script src 这一层就把 cookie 附上去的，那时候 OpenAI 的代码还没开始跑。换句话说，光是加载这个标签，标识符就已经暴露了。

比广告主自己给的还多

同一套 SDK 还会从广告主页面上采集身份信息。它把来源分成四类，标签是 OpenAI 自己起的：in 是广告主主动传的值，fm、ht、js 分别是从表单字段、渲染后的页面文本和标签管理器总线里扒出来的值。

在观察到的流量里，扒来的身份信息数量是广告主主动提供的 2.7 倍——685 次对 255 次。邮箱的最大来源是标签管理器总线：SDK 替换了页面上的 window.dataLayer.push，同时会读 adobeDataLayer，还会解析 gtm.js 脚本标签上的 l= 参数来找出被改过名的 GTM 层。当前版本从里面拿邮箱和电话；0.1.31 版本还拿过姓名和地域，8 月 27 日之后范围才收窄。

邮箱、电话、姓和名在发送前会做 SHA-256 哈希；国家、地区、城市和邮编则是明文发出去的。邮编是被采集最多的表单字段，28 个网站上出现了 100 次。URL 只会保留源（origin）和路径，观察到的 23,929 条请求里没有一条带查询字符串。但路径留下来了，而被采集的路径里出现过某个医疗状况、一个债务解决方案的落地页和一个诉讼登记表。

在 881 个已知设置的像素中，有 638 个开启了自动匹配，包括观察到的每一家信贷和借贷类广告主。这个开关由 OpenAI 的 Ads Manager 控制。另有一份拒绝名单，排除密码、一次性验证码、卡号、社保号、出生日期、病史、诊断和法庭相关字段。

这个 cookie 天生就是为了跨站

作者指出，在同一批广告主页面的请求里，OpenAI 的其他 cookie 都被浏览器拦下来了：oai-did 和 oaicom-stable-id 因为 SameSite=Lax 被拦，会话类 cookie 因为域名不匹配被拦。只有 __obi 被配成了 SameSite=None，所以只有它出得去。

观察到的覆盖范围是：同一个 __obi 值被从 12 个商业网站、13 个不同的像素 ID 发回 OpenAI，包括 Chewy、Wayfair、ThriftBooks、Eventbrite、HelloFresh、Coursera 和 SeatGeek。每一次请求，OpenAI 都返回 202。在更大的流量样本里，30 个不同的 __obi 值中有 12 个出现在不止一个广告主那里，其中一个出现在十个广告主下。

这个机制在未登录状态下也在跑。932 个被解出来的同步 token 里，736 个带着 subject_type: account_user，196 个是 anonymous。匿名主体和账号主体一样稳定：一台设备一个，至少能持续 27 天。

归在「分析类 cookie」下面

OpenAI 的 cookie 政策把 __obi 列在分析类 cookie 下，有效期一年，作用于 chatgpt.com 和 openai.com，而且是那一节里唯一的条目。政策对分析类 cookie 的描述是：帮助 OpenAI 了解自家服务的表现和使用情况。

OpenAI 在同意管理上把分析和营销拆成了两个独立选项：oai_consent_analytics 和 oai_consent_marketing。而作者解出来的每一个同步 token 都带着 analytics_allowed。也就是说，一个允许分析、拒绝营销的用户，照样会拿到这个 cookie。

作者 9 月 14 日把机制说明和两个问题发给了 press@openai.com 和 privacy@openai.com：为什么 __obi 被归类为分析类 cookie；以及一个只允许分析、拒绝营销的用户是否仍会收到它。回复来自 OpenAI 的支持团队，确认收到了询问、表示会内部转达，但两个问题都没答。上面那条「脚本加载本身就带 cookie」的观察，是在发出询问之后才做的。作者说如果 OpenAI 回应，他会更新这篇文章。

边界要讲清楚

浏览器方面：观察是在 Android 版 Chrome 上做的。Safari 的智能防跟踪会屏蔽所有第三方 cookie，iOS 上的 Chrome 底层也是 WebKit，所以这个机制在任何 iOS 浏览器上都不成立。桌面版 Chrome 没测。

触发条件方面：大约每五次 ChatGPT 会话才有一次产出同步 token；ChatGPT 的移动网页版直接投广告，完全不做同步。照着步骤复现的人可能看到像素触发但 cookie 没带上。

还有一点作者自己划得很清楚：归因的最后一跳没有被观察到。返回 202 只说明采集端接受了带 cookie 的事件；至于 OpenAI 在服务端把它解析到账号，是从设计上推出来的，他没有亲眼看到。

真正新鲜的到底是什么

Meta 多年前就搭过结构上等价的东西：一个登录态账号、像素触发时的第三方 cookie、站外转化回填到用户画像。这套机制本身是标准广告技术，不新鲜。

没有先例的是，它跑在一个 AI 对话产品上。人们会跟这类产品说那些不会发到社交网络上的话，而这类产品越来越多地替人做决定。

还有一个细节值得注意。像素里的另一个 cookie 叫 __obref，它设在广告主自己的域名下，每个网站拿到的值都不同，站点之间互相看不到——观察到的 2,860 个值里，2,828 个只出现在一个广告主下。也就是说，广告主完全不知道自己页面的访客正在被对上 ChatGPT 身份。__obi 设在广告主脚本读不到的那个域名下。他们装了像素做转化归因，然后呢？访客的浏览被解析到某个 ChatGPT 账号这件事，他们既不知道，也无从知道。