本週公布的OpenAI廣告像素拆解報告中，真正的爭點並不是有一個Cookie在網路上跟著使用者跑，而是這個Cookie被歸在哪一個同意選項底下。以Buchodi's Threat Intel名義發表的研究者於9月20日指出，OpenAI把綁定已登入ChatGPT帳號的識別碼__obi歸類為分析用Cookie，但從實測來看，這組識別碼的實際工作是把該帳號帶往廣告主的網站。也就是說，只同意分析、拒絕行銷的使用者，照樣會被種下這個Cookie。
重點摘要
- __obi是OpenAI所有Cookie中唯一設定SameSite=None的一個，這是瀏覽器願意把Cookie附加到跨站請求上的必要旗標，並在.openai.com網域保留一年。
- 研究者解碼的932組同步權杖，無一例外都帶有consent_decision: analytics_allowed這項宣告，其中736組更直接載明了帳號主體。
- 隨Cookie一併送出的個人資料，多數並非廣告主刻意提供，而是從廣告主自家網頁上抓取而來，比例為685筆對255筆。
為何問題出在標籤而不是機制
跨站追蹤像素本身很常見。Meta幾年前就把三項材料湊齊了：已登入的帳號、隨像素觸發而傳遞的第三方Cookie，以及回推到個人檔案上的站外轉換。純就工程面而言，OpenAI這套收集器只是再普通不過的廣告技術。
真正讓分類變成關鍵的，是OpenAI同時運作oai_consent_analytics與oai_consent_marketing兩個彼此獨立的同意開關，而在其Cookie政策中，分析項目底下只列了__obi這一個。在參照ePrivacy規範建立的同意制度裡，決定Cookie需要哪種授權的是它實際執行的用途，而不是業者把它寫在哪個標題底下。如果一個Cookie經實測的功能是把廣告身分接上第三方網頁的瀏覽紀錄，那就很難辯稱它是用來了解服務運作狀況的工具。
三個步驟完成的交握
ChatGPT用戶端會產生16位元組的隨機值，在/backend-api/bazaar/obi/sync-token換取一組效期60秒的RS256 JSON Web Token，其宣告把64字元的帳號主體與22字元的識別碼綁在一起。用戶端接著把這組權杖跨站送往bzr.openai.com/v1/obi/sync，回應則以HttpOnly、Secure、SameSite=None屬性與一年效期寫入__obi，而Cookie的值與JWT中的識別碼是同一個字串。此後只要網頁掛有OpenAI的像素，這個值就會被回傳。在OpenAI的內部命名中，bzr是bazaar的縮寫，指的就是廣告平台本身。
其中一項發現，直接抵銷了SDK自己設下的防線。這個像素有一條不帶憑證發出請求的程式路徑，但瀏覽器在抓取SDK的<script src>請求階段就已經把Cookie附上去了，此時OpenAI的程式碼一行都還沒執行。換句話說，光是載入這段標籤就足以洩漏識別碼，而廣告主無論怎麼選擇串接方式，都關不掉這個洩漏。
像素的第二項任務：讀取所在網頁
OpenAI的資料酬載把身分資料的來源分成四種標記：廣告主刻意傳入的是in，SDK自行從表單欄位、已渲染的網頁文字與代碼管理工具匯流排取得的則分別是fm、ht與js。最後一條管道最具侵略性。SDK會把window.dataLayer.push換成自己的函式，讀取adobeDataLayer，還會解析gtm.js標籤的l=參數，藉此找出被改名的Google代碼管理工具容器。目前的版本以此方式取走電子郵件與電話號碼；0.1.31版甚至連姓名與地理位置一併抓取，直到8月27日範圍才收斂。
雜湊處理則做了一半。電子郵件、電話與姓名經過SHA-256雜湊，但國家、地區、城市與郵遞區號全是明文傳送，而郵遞區號正是被抓取最多的單一表單欄位，橫跨28個網站共100筆。雜湊過的識別碼一旦配上明文郵遞區號，隱私防線遠比只看雜湊時脆弱。完整網址會被縮減為來源加路徑，2萬3929筆觀測中沒有任何一筆挾帶查詢字串，但路徑本身往往已經足夠說明內容：抵達收集器的路徑中，包含了某項疾病名稱、債務處理流程，以及訴訟受理表單。在881個能看到設定的像素當中，有638個開啟了自動比對，信貸與借貸類廣告主無一例外都在其中。
廣告主幾乎無從稽核這一切。__obi落在廣告主腳本讀不到的網域上，掛了這段標籤的商家根本無法檢視自家訪客究竟揭露了哪些身分資料。既然網路爬取管道以將近三比一壓過刻意傳遞的管道，那麼法律上該向訪客揭露同意事項的一方，經常並不是決定要收集什麼的那一方。
證據到此為止
報告對自身的上限交代得很清楚。HTTP 202只說明收集器接受了一筆附帶Cookie的事件，並不能證明OpenAI在自家系統內把該事件解析回某個帳號。研究者也表明，伺服器端的比對是從設計架構推導而來，而非直接觀測到的結果。
觸及範圍同樣不平均。這項行為是在Android版Chrome上捕捉到的；Safari完全封鎖第三方Cookie，iOS上的Chrome又跑在WebKit之上，因此沒有任何一款iOS瀏覽器會觸發這套機制，桌面版Chrome則未經測試。而每五次ChatGPT工作階段，大約只有一次真的產生同步權杖。實際效果是風險集中在Android使用者身上，而非平均分布，且實測到的普及程度應視為下限而非全貌。
流量確實證實的是持續性。在研究者自己的手機上，同一組__obi值透過13個像素ID、自12個商業網站傳回OpenAI，其中包括Chewy、Wayfair、ThriftBooks、Eventbrite、HelloFresh、Coursera與SeatGeek。在更大範圍的擷取中，30組不同的值裡有12組出現在一個以上的廣告主，其中一組更橫跨十家。登出也躲不掉：有196組權杖帶著匿名主體，而這個值在同一台裝置上至少固定了27天。
接下來會怎麼走
研究者直接問過OpenAI。他在9月14日寫信給press@openai.com與privacy@openai.com，提出兩個問題：為什麼這個Cookie被歸類為分析？拒絕行銷同意能不能讓它停下來？得到的回覆是OpenAI客服的一封確認信，表示會把這些觀察轉達給內部，兩個問題則一個也沒有回答。
把這份沉默，擺在OpenAI正以多快的速度擴張這個像素所支撐的事業旁邊，就更顯得尷尬。從在ChatGPT內部直接進行銷售對話的贊助代理，到設有自動比對開關的Ads Manager主控台，全是同一門生意。真正令人不安的是，人們對AI助理說的話，和他們公開發表的內容根本是兩回事。這篇拆解在一天內於Hacker News取得379分與188則留言，顯示開發者立刻就抓到了這個差別。最先被扯開的線頭，很可能就是同意分類，因為那是企業說法與實測結果正面牴觸的唯一一處。
常見問題
ChatGPT使用者可以關閉__obi這個Cookie嗎
報告沒有找到任何能停用它的設定，而拒絕行銷同意也沒有用，因為OpenAI把它當成分析用途。它會在.openai.com存活一年。清除Cookie可以移除，但下一次同步就會回來；至於封鎖第三方Cookie的瀏覽器，也就是Safari以及iOS上的所有瀏覽器，則直接讓跨站這一步無法成立。
廣告主看得到附在自家訪客身上的ChatGPT身分嗎
看不到，而這正是問題的一部分。__obi位在廣告主腳本無法讀取的網域，因此掛上標籤的商家也無從稽核。這個像素的另一個Cookie __obref則寫在廣告主自己的網域上，且各站維持獨立：觀測到的2860組值中，有2828組只出現在單一廣告主底下。
這是否證明OpenAI把瀏覽紀錄連結到具名帳號
還不能下定論。帳號綁定在JWT的宣告中清楚可見，識別碼確實會傳到OpenAI並被接受，這些都有實測。但最後的比對這一步發生在OpenAI的伺服器上，研究者無法觀測，因此那部分屬於從架構推論，而非量測所得。
