跟著你離開 ChatGPT 的 Cookie：OpenAI __obi 廣告像素深度解析

2026 年 9 月 20 日，一位獨立安全研究人員發布了對 OpenAI 廣告基礎設施的深度逆向工程分析，隨即在 Hacker News 上衝上 321 點、161 則留言。核心發現一句話就能說完，卻讓人坐立難安：OpenAI 經營的廣告衡量系統，能夠把你的一般網站瀏覽行為——零售商、線上課程平台、售票網站——連結到你的 ChatGPT 帳號，靠的是一個多數使用者從未聽過的 Cookie。

這個 Cookie 叫做 __obi，由 bzr.openai.com 上的收集器設定——“bzr” 是 “bazaar”（市集）的縮寫，是 OpenAI 內部對其廣告平台的稱呼——作用域涵蓋整個 .openai.com 網域，效期長達一年。真正不寻常的是它的設定：SameSite=None，代表它被刻意設計成會在跨站請求中被傳送。這位研究人員用自己的手機、以兩種獨立的封包擷取方法驗證整個機制，並比對橫跨數個月、涵蓋 936 個不同廣告像素與 1,029 個主機名稱的觀測流量，發現它是 OpenAI 唯一被這樣設定的 Cookie。在同樣的跨站請求上，OpenAI 的其他識別碼全數被瀏覽器阻擋。

機制如何運作

整條鏈始於 ChatGPT 本身。在 chatgpt.com 上，客戶端會產生 16 個隨機位元組，呼叫一個後端端點並取得一枚 RS256 簽章的 JWT。這個 Token 綁定了你的帳號主體（sub）、一組 22 字元的 obi 識別碼、60 秒的效期，以及——特別值得注意的——一個寫著 analytics_allowed 的 consent_decision 欄位。接著客戶端把 Token 跨站 POST 到 bzr.openai.com/v1/obi/sync，回應便設下了 __obi Cookie：Domain=.openai.com; HttpOnly; Max-Age=31536000; SameSite=None; Secure。Cookie 值與 JWT 中的 obi 值完全相同。從那一刻起，這個識別碼就跟著你走了。

接收端位於廣告主的網站上。任何在 ChatGPT 上投放廣告的公司，都可以安裝一小段 OpenAI 程式碼——由 bzrcdn.openai.com 提供的 oaiq.min.js SDK——就像零售商長年安裝 Meta 與 Google 追蹤程式碼那樣。研究人員在此記錄了一個擊碎某種合理抗辯的細節：SDK 本身的程式碼路徑確實會在請求中省略憑證，但這沒有用。瀏覽器會在 OpenAI 的任何程式碼執行之前，就把 Cookie 附加到載入 SDK 的 <script src> 請求上。載入標籤本身就是揭露。在研究人員的裝置上，同一個 __obi 值從十二個商業網站、十三個不同的像素 ID 傳送到 OpenAI——包括 Chewy、Wayfair、ThriftBooks、Eventbrite、HelloFresh、Coursera 與 SeatGeek。每個請求都以 202 狀態碼被接受。

隨之傳送的是什麼

這個 SDK 不只是帶著識別碼回報家鄉，它還會從廣告主頁面上蒐集身分素材，並依 OpenAI 自己的欄位標籤分成四個來源：in 是廣告主刻意傳入的值，fm、ht、js 則是 SDK 從表單欄位、頁面渲染文字與標籤管理器匯流排（tag-manager bus）爬取的值。在觀測流量中，爬取而來的身分資料以 685 比 255 的差距，超過了廣告主主動提供者。

標籤管理器匯流排是最大的電子郵件來源。SDK 會用自己的函式取代 window.dataLayer.push，讀取 adobeDataLayer，甚至透過解析 gtm.js 標籤上的 l= 參數，找出被改名的 Google Tag Manager 層。目前版本會從中擷取電子郵件與電話；0.1.31 版還會蒐集姓名與地理位置，直到 8 月 27 日範圍才被收窄。電子郵件、電話與姓名在傳輸前會經過 SHA-256 雜湊——但國家、地區、城市與郵遞區號是明文傳送。郵遞區號是被蒐集最多的表單欄位：28 個網站、100 次事件。

URL 在傳送前會被化約為 origin 加路徑，觀測到的 23,929 個 URL 都沒有帶查詢字串。但路徑保留下來了，而抵達收集器的路徑中，包括一個醫療狀況頁面、一個債務解決方案的轉換漏斗，以及一份訴訟受理表單。自動比對（automatic matching）由 OpenAI 的 Ads Manager 控制，在 881 個已知設定的像素中有 638 個啟用，包括觀測到的每一家信貸與放款廣告主。OpenAI 的拒絕清單確實排除了密碼、一次性驗證碼、卡號、社會安全號碼、出生日期、病史、診斷與法院欄位。

核心的同意權問題

故事到此從技術議題變成治理問題。OpenAI 的 Cookie 政策把 __obi 列在「Analytics cookies」之下，效期一年，而且是該分類中唯一的條目。政策將 analytics cookies 描述為協助 OpenAI 了解其服務的表現與使用方式。與此同時，OpenAI 把 analytics 與 marketing 經營成兩個分開的同意選項（oai_consent_analytics 對 oai_consent_marketing），而研究人員解碼的每一個同步 Token 都帶著 consent_decision: analytics_allowed。換言之：一個允許 analytics、拒絕 marketing 的使用者，仍然會拿到一個餵養廣告平台的跨站識別碼。

研究人員在 9 月 14 日把整個機制連同兩個尖銳的問題寄給 OpenAI 的媒體與隱私信箱——為什麼 __obi 被歸類為 analytics cookie，以及允許 analytics、拒絕 marketing 的使用者是否仍會收到它。OpenAI Support 承認收到詢問，表示觀測結果會在內部分享檢視，但兩個問題都沒有回答。

有幾個明確的限制必須講清楚。機制是在 Android 版 Chrome 上觀測到的。Safari 的 Intelligent Tracking Prevention 會阻擋所有第三方 Cookie，而 iOS 上所有瀏覽器都跑在 WebKit 上，因此這個機制在 iOS 上完全無法運作。大約每五次 ChatGPT 工作階段只有一次會產生同步 Token。最後的關聯——OpenAI 在伺服器端把 Cookie 解析回你的帳號——是設計上的必然，但並未直接被觀測到。可以確定的是，伺服器確實接受了每個帶著 Cookie 的事件。

為什麼這件事超越廣告技術

這裡的任何一塊積木都不新鮮。Meta 多年前就蓋好了結構上等價的東西：一個登入帳號、像素觸發時的第三方 Cookie、被解析到某個使用者檔案的站外轉換。正如研究人員所言，這套機制是標準廣告技術。真正沒有前例的，是把它跑在一個 AI 對話產品上。人們會告訴這些產品一些他們絕不會發在社群網路上的事——症狀、法律焦慮、財務壓力——而這些產品還越來越常代他們行事。安裝像素的廣告主看不到這一切；__obi 存在於他們的程式碼讀不到的網域上，他們也無從得知自己的訪客正被解析成某個 ChatGPT 身分。

隨著 ChatGPT 的廣告業務持續擴張，__obi 事件把一個將定義 AI 平台隱私未來多年的問題逼到眼前：當你的對話助理與你的廣告網路屬於同一家公司時，你同意的到底是什麼——而誰有權檢查？