跳到主要內容

ChatGPT 跨站追蹤疑雲:__obi Cookie 能連起帳號與站外瀏覽嗎?(2026)

最後更新: ·
ChatGPT 跨站追蹤疑雲首圖,__obi Cookie 路徑與站外足跡能否連回帳號的問號

2026 年 9 月 20 日,以 Buchodi 署名的獨立調查者發布〈ChatGPT 透過廣告收集器得知你的站外行為〉,把「ChatGPT 跨站追蹤」的焦點落在一枚名為 __obi 的 Cookie:它究竟只是分析識別碼,還是能讓 OpenAI 將站外瀏覽訊號連回 ChatGPT 帳號?

Buchodi 技術調查首頁截圖,標題質疑 ChatGPT 廣告收集器是否能看見使用者在其他網站的行為
這份單一研究者調查提出嚴重疑問;本文把可重現事實、作者自述與尚未觀察的推論分開檢驗。

先說查核結果:OpenAI 官方資料確認 __obi 存在,也確認 Ads Measurement Pixel 會從商家網站向 OpenAI 傳送事件;但目前公開證據尚不足以證明 OpenAI 已把這些事件接回特定 ChatGPT 帳號。本文先忠實還原調查,再以 OpenAI 文件、目前公開的 Pixel SDK 與瀏覽器規則逐層驗證,最後回答這套設計真正值得擔心的是什麼。

原始調查聲稱看見什麼?

依 Buchodi 的敘述,整條路徑不是「聊天內容直接流到廣告商」,而是一個識別碼接力:

  1. 登入 ChatGPT 時建立配對:瀏覽器端產生 16 bytes 隨機值 obi;ChatGPT 後端據稱簽出一枚約 60 秒有效的 token,其中同時有帳號 subject 與 obi
  2. OpenAI 網域留下 Cookie:研究者稱,該 token 被送到 bzr.openai.com 後,瀏覽器收到一年期、可用於跨站情境的 __obi Cookie。Cookie 本身是 opaque 識別碼,不是帳號 ID,也不是聊天內容。
  3. 商家網站再送事件:安裝 OpenAI Pixel 的網站會載入 OpenAI SDK 並回傳頁面或轉換事件;若瀏覽器允許第三方 Cookie,研究者稱同一枚 __obi 也會隨部分請求送回 OpenAI。
Buchodi 繪製的 __obi Cookie 機制圖,從 ChatGPT 登入、OpenAI 網域設定識別碼,到商家網站 Pixel 回傳事件
原作者繪製的機制示意圖,不是原始 HAR 或封包紀錄;圖中的伺服器端帳號 join 仍是設計推論。

作者另稱,數月樣本涵蓋 936 個不同 pixel IDs、1,029 個 hostnames,並在 12 個網站用 Android Chrome 觀察請求。不過文章沒有公開可重算的 hostname 清單、HAR、pcap、完整 headers、原始 token 或去重方法,因此這些數字只能標成作者樣本,不能改寫成 OpenAI 的全網部署量。

圖與正文還留下未解的 snapshot 差異:圖中的兩類 token 合計 682 枚,正文則寫 932 枚;兩者可能來自不同時間或子樣本,但作者沒有標日期或對帳。這進一步限制了外界對樣本規模的解讀。

“The join is not observed. That OpenAI resolves it to the account server-side follows from the design; I did not watch it happen.”

中文:資料合併本身沒有被觀察到;OpenAI 會在伺服器端解析回帳號,是從設計推得,我沒有親眼看見它發生。

Buchodi

這句話是整篇調查最重要的證據邊界:作者看見的是他所描述的 token 與網路請求,不是 OpenAI 內部資料庫的查找、保存或使用。

ChatGPT 跨站追蹤:官方確認兩端,卻沒有確認中間那條線

OpenAI Cookie Policy 確實列出 __obi:用途分類為 Analytics,適用於 chatgpt.comopenai.com,期限一年。這足以確認 Cookie 不是研究者虛構,但政策沒有公開它的值如何產生、token schema、設定端點或是否連回帳號。

另一端也是真的。OpenAI 的 Measurement Pixel 文件教廣告商把 oaiq.min.js 裝到網站,將頁面與轉換事件傳往 bzr.openai.comConversion Terms也說 conversion data 可以包含 Cookie、其他識別碼、網站造訪、App 安裝與購買事件。

證據層級目前能說什麼不能說什麼
官方已確認__obi 是一年期 Analytics Cookie;商家 Pixel 會向 OpenAI 傳送事件。截至 2026 年 9 月 21 日,本文查閱的 Cookie Policy、Measurement Pixel 文件與 Conversion Terms 均未把 __obi 說明為帳號級 join 訊號。
研究者自述觀察Android 流量中出現含 subject 與 obi 的短效 token;部分商家請求帶著同一識別碼。作者未隨文公開原始封包,第三方無法逐筆重現或重算規模。
能力推論若 token、Cookie 與 request 描述都正確,而且 OpenAI 保留 mapping,架構具備把部分站外事件關聯回登入身分的能力。不能說 OpenAI 已實際完成、保存或使用這個 join,更不能說模型讀到你的站外瀏覽。
兩端元件都可確認;爭議核心是中間的伺服器端關聯是否真的發生、用於什麼目的。

目前 SDK 還出現一個需要原始封包才能解開的矛盾

我們在 2026 年 9 月 21 日直接檢查公開的 oaiq-web v0.1.41:一般非 diagnostic 的事件路徑會選用 credentials: "include",在瀏覽器政策允許時具備攜帶 Cookie 的條件;但研究者特別描述的 credentialless diagnostic POST 路徑,程式碼卻硬編碼 credentials: "omit"。依 WHATWG Fetch Standardomit 會排除 request credentials。

可能原因包括研究時的 SDK 版本不同、請求類型被混在一起,或瀏覽器行為有尚未公開的細節;但在原始 HAR 與精確版本出現前,最穩健的結論是:一般 Pixel 請求在技術上可能攜帶 __obi,特定的 omit 請求則不能照原文直接當成已證實。

為什麼這仍是重要的隱私問題?

證據未封口,不代表問題不存在。OpenAI 的 Conversion Measurement 說明把廣告商取得的輸出描述為 campaign performance 報表,而非個別使用者活動;但這只界定商家看到什麼,不代表 OpenAI 內部只做彙總。Pixel 文件另寫明,將事件設為 opt_out: true 才會排除未來的 user-level personalization,而預設值是 false。這項一般產品能力仍不證明 __obi 已接回 ChatGPT 帳號,卻讓 mapping 是否存在、如何使用更值得追問。

  • 身分情境更敏感:登入 AI 助理的帳號,往往連著長期使用、付費與高度私密的提問;同一識別層若延伸到站外事件,風險高於單純的匿名流量統計。
  • 「分析」與使用者直覺可能錯位:官方把 __obi 分在 Analytics,但若它可參與跨站識別或廣告歸因,使用者合理地會想知道它與廣告同意、個人化開關的關係。
  • 雜湊不等於匿名:官方 Pixel 的 Advanced Matching 會先雜湊 email、電話與姓名;雜湊可降低原始值暴露,卻仍是為了匹配,不能被描述成無法關聯個人。
  • 能力、用途與證據必須分開:架構可能具備某種能力,不等於 OpenAI 已用它建立個人瀏覽檔案;反過來,截至 2026 年 9 月 21 日,本文查閱的三份官方文件都沒有交代 __obi 是否參與帳號匹配,不能靠「尚未證明濫用」取代透明度。

AlphaLab 判斷:調查抓到應解釋的架構,但標題跑在證據前面

我同意的部分:這名研究者把一個原本藏在政策表格、token 與廣告 SDK 之間的資料流問題具體化了。OpenAI 應公開說明 __obi 的產生、用途、保留、同意依據、是否參與廣告衡量,以及它能否或曾否連回 ChatGPT 帳號。對一個承接私密對話的產品,這不是可有可無的工程細節。

我存疑的部分:原始標題把「具備關聯能力」寫成「ChatGPT 已知道你在其他網站做什麼」。目前公開材料撐不起這個完成式:server-side join 沒被觀察,規模資料無法重算,desktop Chrome 未測;截至 2026 年 9 月 21 日,本文查閱的 OpenAI Cookie Policy、Measurement Pixel 文件與 Conversion Terms 也未確認 __obi 用於帳號關聯。作者稱 Support 只確認收到詢問並轉交;這不等於承認機制。

所以,對 ChatGPT 跨站追蹤爭議最精準的判決不是「闢謠」也不是「實錘」,而是可信的架構警報、尚未閉合的帳號關聯證據。下一步能讓結論升級的,不是更多轉述,而是可去識別的 HAR/pcap、token 驗證資料、版本化重現步驟、樣本清單,以及 OpenAI 對 __obi 目的與 server-side mapping 的逐項回答。

一般使用者與網站經營者現在可以做什麼?

  1. 封鎖第三方 Cookie:Android Chrome 可在 Privacy and security 的 Third-party cookies 設定中封鎖;Google 的 Chrome Cookie 說明也列出例外管理方式。這會直接切斷這類未分割第三方 Cookie 的傳送路徑,但不會阻擋所有 server-side 或指紋式衡量。
  2. 把高敏感 AI 使用與一般瀏覽分開:不同瀏覽器或 profile 能降低共用 Cookie/登入狀態的表面;它不是匿名工具,但比所有活動集中在同一個長期登入環境更容易管理。
  3. 不要把 iPhone 當成絕對免疫:WebKit Tracking Prevention預設阻擋第三方 Cookie,Safari 與目前 Chrome iOS 的預設路徑因此預期會擋下此機制;但使用者授權、Storage Access 與相容性例外,使「所有 iOS 情況都不可能」過度絕對。
  4. 網站經營者盤點同意流程:若安裝 OpenAI Pixel,應核對載入前的 consent 狀態、Advanced Matching 欄位、事件資料、保留方式與撤回流程,而不是只看後台是否收到轉換。

今天最有價值的行動很簡單:先檢查瀏覽器的第三方 Cookie 設定,再決定是否把 ChatGPT 登入工作區和日常購物/搜尋分開;同時等待可重現封包與 OpenAI 的具體說明,而不是把一張架構圖當成最終判決。

接著閱讀

左右滑動查看更多推薦

ALPHALAB 社群

有問題?來 Telegram 聊

和 Terry、編輯、其他網友一起討論這篇文章。提問、分享觀點,回覆更即時。

加入 Telegram 討論

📩 訂閱 AlphaLab 電子報

每週最多三封:一封 Weekly 週報與最多兩封關鍵 Alpha Signal。

我們不會 spam,隨時可退訂。