OpenAI 部署了跟踪 Cookie？解构 __obi 的实际关联机制

OpenAI 是否部署了 Cookie 跟踪系统？独立安全研究员 Buchodi 在 2026 年 9 月 20 日发布的技术调查表明，当 OpenAI 在第三方商业网站中部署跟踪 Cookie 机制时，Web 客户端会自动触发识别程序，将外部浏览行为传输回平台的广告收集端。该基础设施的核心是一个名为 __obi 的持久化标识符，它被配置为具有跨站权限，并在官方文档中被分类为“分析型 Cookie”而非营销组件。虽然该协议架构在技术上为将商业交互与账户绑定或持久化的匿名标识符进行关联提供了前提，但外部流量捕获证实了这些数据会传输至边缘接收端，目前尚无法从外部观察验证最终的服务器端数据库合并逻辑。

行业核心重塑与新闻解析

随着 Buchodi 关于跨站广告收集技术披露的发布，生成式人工智能与商业变现的结合点引发了广泛关注。这项独立调查研究了客户端在与 ChatGPT 交互时，如何与其在外部商业域名的后续 Web 活动相关联。这些交互并非完全局限于封闭接口，而是通过客户端交互触发后台识别程序，将浏览元数据传输至广告接收基础设施。

核心概览

跨站标识符签发：访问 chatgpt.com 的 Web 客户端会获取一个短效的 OBI 同步 JSON Web Token，随后在 .openai.com 域名下交换为一个有效期长达一年的持久化 Cookie，即 __obi。
Chrome Android 测试中的预执行 Cookie 传输：当从 bzrcdn.openai.com 获取外部广告测量脚本时，浏览器网络堆栈会在客户端 JavaScript 执行前自动附加 __obi。
像素级 DOM 与表单收集：部署的广告测量标签会解析表单输入、渲染的 HTML 元素及标签管理器总线，并将地理指标和 URL 路径字符串传输至 OpenAI 端点。

该实证分析在长达数月的测试框架中监控了实时网络交换。数据集评估了在 1,029 个唯一主机名托管的 936 个广告像素上生成的 23,929 个独立 HTTP 请求。研究发现，外部商业活动（包括产品目录交互、商品搜索和结账流程）在伴随持久化客户端令牌的情况下，会频繁向 OpenAI 接收端点传输数据。

网络流量捕获显示 __obi Cookie 附加在零售域名的 OpenAI 商业跟踪请求中

在研究员的测试设备上，来自 13 个独立像素配置的 12 个不同商业网站（包括 Chewy、Wayfair、ThriftBooks、Eventbrite、HelloFresh、Coursera 和 SeatGeek 等门户）传输了相同的 __obi 值。在更广泛的流量样本中，30 个不同的 __obi 值中有 12 个出现在多个广告上下文中，其中一个值在 10 个不同的商业域名中被观察到。

跨站身份解析时间线

事件阶段	协议动作	技术范围与隔离边界
会话初始化	`POST /sync-token`	RS256 JWT 将账户或匿名主体标识符绑定至 60 秒令牌
Cookie 持久化	`Set-Cookie: __obi`	`SameSite=None` 标记使 Cookie 符合跨站传输条件
商家归因	`GET /sdk/oaiq.min.js`	浏览器网络堆栈在初始脚本检索时附加 Cookie

OpenAI Cookie 政策中的官方定义将 __obi 归类为分析型 Cookie，并赋予其 365 天的有效期。由于 OpenAI 的许可架构通过分析许可而非专门的营销控制来管理 __obi，在观察测试中，仅拒绝营销许可并不能阻止 Cookie 的部署。

HTTP 数据包拦截显示移动浏览器与 OpenAI 广告端点之间的跨站数据交换

技术架构解构

管理 __obi 的操作机制依赖于连接客户端浏览器会话、广告收集端点和第三方商业门户的三阶段交换流水线。网络追踪演示了一个临时的加密断言是如何转化为持久化客户端标识符的。

该过程源于 chatgpt.com。客户端浏览器生成 16 字节的熵并向平台内部后端发送 HTTP 请求：

POST /backend-api/bazaar/obi/sync-token

未经身份验证的会话会调用 /backend-anon/bazaar/obi/sync-token。由 JWT iss 声明标识为 chatgpt-wadi 的内部签发服务，会返回一个经过 RS256 签名的 JSON Web Token，其中包含将随机熵映射到内部账户元数据的身份声明。

{
  "iss": "chatgpt-wadi",
  "aud": "bzr.openai.com",
  "purpose": "obi_sync",
  "operation": "set",
  "consent_decision": "analytics_allowed",
  "consent_policy_version": "user_granular_consent_v1",
  "sub": "«已脱敏: 64位十六进制账户主体»",
  "subject_type": "account_user",
  "obi": "«已脱敏: 22字符标识符»",
  "exp": "«iat + 60s»"
}

签名的有效载荷强制执行 60 秒的过期时间 (exp)。客户端浏览器随后通过异步 POST 请求立即将此令牌转发给 OpenAI 的程序化广告域名：

POST https://bzr.openai.com/v1/obi/sync

OpenAI 的边缘服务器处理该令牌并返回 HTTP 标头，指示浏览器存储该持久化 Cookie。

HTTP/2 200 OK
Set-Cookie: __obi=«已脱敏»; Domain=.openai.com; HttpOnly; Max-Age=31536000; Path=/; SameSite=None; Secure

在 Secure 标志旁分配 SameSite=None 将该 Cookie 标记为在宿主浏览器允许第三方 Cookie 的情况下具备跨站传输资格。与范围限定为 SameSite=Lax 或仅限于直接原始子域的标准应用 Cookie 不同，__obi 会附加到发往 *.openai.com 的出站跨站请求中。

+-------------------------------------------------------------------------+
|     [ 协议流概念图: OBI 令牌交换与广告像素 ]       |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ 用户浏览器会话 (chatgpt.com) ]                                 |
|          |                                                              |
|          +---> 请求同步令牌: POST /backend-api/.../sync-token     |
|          |     响应: 60s RS256 JWT (账户或匿名主体)   |
|          |                                                              |
|          +---> 交换令牌: POST bzr.openai.com/v1/obi/sync          |
|                响应: Set-Cookie: __obi (SameSite=None; 1年有效期)      |
|                                                                         |
+-------------------------------------------------------------------------+
|  [ 商家门户 (嵌入 OpenAI 像素的零售商网站) ]     |
|          |                                                              |
|          +---> 浏览器获取: <script src="bzrcdn.../oaiq.min.js">    |
|          |     * 浏览器网络堆栈在获取脚本时附加 __obi * |
|          |                                                              |
|          +---> 像素收集 DOM 文本、标签管理器总线和输入    |
|          |                                                              |
|          v                                                              |
|  [ OpenAI 接收端点 (bzr.openai.com/v1/sdk/events) ]          |
|  传输内容: 邮政编码 + 哈希值 + 清理后的 URI 路径          |
|                                                                         |
+-------------------------------------------------------------------------+

合作商家门户完成了通信闭环。通过 ChatGPT 进行广告投放的零售商嵌入了 OpenAI 的转化测量脚本 (oaiq.min.js)。当用户导航至集成商家时，浏览器会解析脚本标签：

GET https://bzrcdn.openai.com/sdk/oaiq.min.js

由于该请求符合 .openai.com 通配符范围，浏览器网络堆栈会在初始脚本检索时附加 __obi。此传输发生在像素的 JavaScript 执行之前，这意味着像素内的客户端逻辑无法绕过该凭据请求。不过，网络级内容拦截器、DNS 陷阱或直接阻止请求域名的浏览器扩展可以完全阻止此连接。

网络捕获显示，测量 SDK 在四个标记渠道中提取了页面级属性：

像素接收数据分类

来源渠道	收集机制	技术范围与字段暴露
`in` (显式输入)	商家 API 参数	交易价值、产品标识符、货币符号
`fm` (表单获取)	DOM 输入拦截	表单输入值、结账元素、联系信息条目
`ht` (DOM 遍历)	渲染 HTML 解析	内容标题、确认字符串、文本元素
`js` (标签管理器钩子)	数据层拦截	挂载至 `window.dataLayer.push` 及 Adobe 标签数组

观察到的流量记录了 685 次跨 DOM 和标签源 (fm、ht 和 js) 的自动收集事件，而商家提供的参数 (in) 为 255 次。SDK 会检查标准标签架构，解析传递至 Google 标签管理器和 Adobe Analytics 流水线的数据。电子邮件地址、电话号码和全名等个人标识符在传输前会经过 SHA-256 哈希处理。相比之下，地理指标（包括国家、地区、城市和邮政编码）以明文形式传输。在 28 个主机名的 100 次离散捕获中出现了邮政编码属性。

URL 结构也会传输至接收端点。虽然去除了查询参数，但来源和路径组件保持不变。观察到的记录证实，代表医疗参考查询、金融债务管理工作流以及法律诉讼登记表单的路径已抵达收集端点。

安全审计可视化映射广告像素分布与敏感 URL 路径收集

解耦系统与浏览器防护

跨站 Cookie 传输机制反映了现代 Web 引擎架构的基本差异。不同浏览器执行不同的状态分区默认设置，决定了第三方标识符能否跨越源边界进行传输。

浏览器 Cookie 隔离架构

浏览器环境	存储隔离模型	`SameSite=None` 跨站处理	已观察到的路径处理
Chrome for Android	共享配置文件 Cookie 存储	在允许第三方 Cookie 时支持跨站传输	测试中证实已传输；受用户及企业第三方 Cookie 配置影响
Apple Safari (WebKit)	智能跟踪预防 (ITP)	默认拦截第三方存储	在此观察的跨站路径中默认被拦截
Chrome on iOS	强制 WebKit 运行环境	受 WebKit 存储限制约束	在此观察的跨站路径中默认被拦截
Mozilla Firefox	全方位 Cookie 保护	按顶级站点分区 Cookie 存储	第三方状态默认被分区；未对 `__obi` 交互进行独立测试
Brave Browser	Shields 存储分区	分区并拦截跨站状态	第三方状态默认被分区/拦截；未对 `__obi` 交互进行独立测试

正如 WebKit 跟踪预防概览中的文档所述，WebKit 环境默认限制跨站存储。智能跟踪预防 (ITP) 会抑制外部网络调用中的第三方 Cookie，从而阻止 iOS Safari 和 iOS Chrome 上的商家门户传输 __obi。同样，Mozilla 关于全方位 Cookie 保护和源状态分区的架构规范详细说明了 Cookie 存储如何按顶级源进行分区，从而将 openai.com 下创建的 Cookie 与外部商家页面隔离开来。

本次调查特别在 Chrome for Android 上重现了整个机制。正如 Google Chrome Cookie 管理政策中所记录，除非用户或设备管理员启用了第三方 Cookie 拦截，否则配置为 SameSite=None; Secure 的第三方 Cookie 允许在跨站网络请求中使用，这为商家门户与 OpenAI 广告端点之间的通信提供了便利。

许可分类与观察到的行为对比

评估属性	既定 Cookie 政策范围	观察到的运行时部署
分类指派	归类为分析型 Cookie	配置为 `SameSite=None; Secure` 以进行跨站交付
评估的许可声明	区别于 `oai_consent_marketing` 设置	仅由解码令牌中的 `analytics_allowed` 管理
拒绝营销的结果	旨在规范广告与促销用途	在仅拒绝营销许可的情况下，商家请求中仍处于激活状态
数据收集配置文件	描述为评估服务使用情况与性能	携带结账表单数据、明文邮政编码及 URI 路径

OpenAI 法律政策中对 __obi 的分类引出了重要的治理问题。OpenAI 为分析 (oai_consent_analytics) 和营销 (oai_consent_marketing) 提供了独立的许可选择。在技术测试期间解码的每个同步令牌都包含 consent_decision: analytics_allowed 属性。

由于底层令牌签发服务将生成与分析偏好挂钩，在观察到的测试流程中，仅拒绝营销 Cookie 并不影响 __obi 的签发或传输。这种结构在国际数据治理标准下引发了疑问：多站点广告转化测量是应等同于基础功能分析，还是应归类为营销遥测。

工程评估必须在观察到的网络传输与后端数据处理之间保持严格区分。流量日志证实，商家门户将 __obi 与订单指标、表单属性和 URL 路径一同传输至 bzr.openai.com，并收到 HTTP 202 Accepted 状态码。虽然在初始授权令牌中加入账户级主体标识符使得账户解析在设计上成为可能，但外部网络观察无法独立证实 OpenAI 的后端系统是否将这些入站事件与用户的对话历史进行了关联。

工程清单与验证计划

管理 Web 门户和端点集群的企业工程团队应评估第三方标签配置，以确保外部脚本符合企业隐私和数据处理标准。

企业级网站标签治理清单

脚本摄入与标签审计

[ ] 审计应用模板以定位从 bzrcdn.openai.com 加载资源的依赖项。
[ ] 评估子资源完整性 (SRI) 或版本锁定托管是否符合供应商部署模型。
[ ] 审查标签管理器配置，以验证营销标签是否访问了内部交易总线。

数据层审查与字段处理

[ ] 评估 window.dataLayer 和 adobeDataLayer 结构上的访问边界。
[ ] 审查邮政编码和地址字段在发送至外部标签前是否需要脱敏。
[ ] 审查 OpenAI 广告管理器中的“自动匹配”设置，以评估 DOM 解析是否适用于结账工作流。

内容安全策略 (CSP) 验证

[ ] 审查 connect-src 指令，以定义出站遥测信标的授权目的地。
[ ] 评估 script-src 策略，以防止执行未经审查的外部脚本。
[ ] 验证结账和客户登记渠道，以确保敏感路径受到保护，不受第三方信标影响。

端点配置与存储卫生

移动设备集群配置

[ ] 在托管企业设备中评估 Chrome for Android 的配置简档。
[ ] 评估在托管端点上启用第三方 Cookie 限制的操作影响。
[ ] 在业务需求允许的情况下，审查以隐私为导向的浏览器配置部署。

身份与会话卫生审计

[ ] 监控企业网络出口流量，查看是否有指向 bzr.openai.com 的重复调用。
[ ] 在非托管浏览器会话中建立定期的简档维护程序。
[ ] 确认企业表单设计避免将用户的明文输入暴露给环境脚本上下文。

实施结构化的内容安全策略并审查标签摄入边界，可以帮助工程团队在商业交易过程中减少非预期的第三方数据暴露。

常见问题解答 (FAQ)

仅拒绝营销许可是否会停止 __obi Cookie 的运行？

在研究员的观察测试中，仅拒绝营销许可并不能阻止 `__obi` 的签发或传输。由于 OpenAI 在其已发布政策中将 `__obi` 分类为分析型 Cookie，令牌签发端点会评估是否授予了分析权限 (`analytics_allowed`)。目前的测试尚未确定完全拒绝分析型 Cookie 是否会抑制该同步机制。

为何 iOS 上的 Safari 拦截了此类跟踪，而 Android 上的 Chrome 却允许？

差异源于底层浏览器引擎实现的默认存储分区模型。Safari 和当前的 iOS 版 Chrome 使用 WebKit，其中智能跟踪预防 (ITP) 默认在外部请求中拦截第三方 Cookie 传输。在 Android 版 Chrome 上，除非用户或设备管理员在设置中启用了第三方 Cookie 拦截，否则配置为 `SameSite=None; Secure` 的第三方 Cookie 允许在跨站网络获取中使用。

第三方商家网站可以直接读取 __obi Cookie 吗？

第三方商家脚本无法通过客户端 JavaScript 直接读取 `__obi` Cookie。该 Cookie 的作用域被限定在 `.openai.com` 域名，并带有 `HttpOnly` 安全属性，防止外部 DOM 脚本访问其内容。相反，当商家页面引用外部测量脚本时，浏览器网络堆栈会自动将已存储的 Cookie 附加到指向 OpenAI 端点 (`bzr.openai.com`) 的出站网络请求中。

实践意义与未来展望

对 __obi Cookie 框架的技术审查揭示了对话式 AI 平台与在线广告架构之间不断演变的关系。多年来，数字广告系统一直利用浏览器状态机制来连接跨独立网站的用户参与度。将这些测量模式应用于对话接口引发了新的思考。用户在假设这些环境与更广泛的广告网络隔离的情况下，经常在对话平台中输入敏感的专业、技术和个人信息。

如果商家遥测最终被解析为协议设计所允许的账户级身份，这种结合将产生极其丰富的行为画像。随着 AI 代理日益承担起调度、旅行预订和产品采购等实际任务，直接对话效用与商业画像之间的操作边界将需要明确的定义。

应对这一转变需要工程团队在 Web 资产中应用严谨的治理。管理客户交互站点的组织必须审计第三方脚本集成，审查标签管理器的数据暴露情况，并执行精确的内容安全策略。与此同时，不断演进的浏览器存储标准持续限制跨平台的非预期数据共享。现代 Web 环境中的长期隐私保护，将依赖于稳健的客户端技术边界，而非仅仅依靠政策声明。