The contested detail in this week's teardown of OpenAI's advertising pixel is not that a cookie follows people around the web β it is which consent box that cookie sits behind. A researcher publishing as Buchodi's Threat Intel reported on 20 September that OpenAI files __obi, an identifier bound to a signed-in ChatGPT account, under analytics cookies, while the identifier's observable job is to carry that account onto advertisers' websites. Someone who allows analytics and declines marketing gets it anyway.
Key takeaways
- __obi is the only OpenAI cookie set with SameSite=None, the flag a browser requires before it will attach a cookie to a cross-site request, and it lasts a year on .openai.com.
- Every one of the 932 sync tokens the researcher decoded carried the claim consent_decision: analytics_allowed, and 736 of them named an account subject.
- Most of the personal data travelling alongside the cookie was scraped from the advertiser's own page rather than deliberately supplied by the advertiser, by 685 events to 255.
Why the label, not the mechanism, is the story
Cross-site pixels are ordinary. Meta assembled the same three ingredients years ago: a logged-in account, a third-party cookie riding on pixel fires, and off-site conversions resolved back to a profile. Judged as engineering, OpenAI's collector is unremarkable adtech.
What makes the classification load-bearing is that OpenAI runs two independent consent switches, oai_consent_analytics and oai_consent_marketing, and publishes a cookie policy in which __obi is the sole entry under analytics. Under consent regimes modelled on ePrivacy rules, the purpose a cookie actually serves governs the permission it needs β not the heading a vendor files it under. A cookie whose measured function is to attach an advertising identity to third-party page views is difficult to defend as a tool for understanding how a service performs.
The handshake, in three steps
ChatGPT's client generates 16 random bytes and exchanges them at /backend-api/bazaar/obi/sync-token for a 60-second RS256 JSON Web Token whose claims bind a 64-character account subject to a 22-character identifier. The client posts that token cross-site to bzr.openai.com/v1/obi/sync, and the response writes __obi with HttpOnly, Secure, SameSite=None and a one-year lifetime β the cookie value and the JWT's identifier being the same string. Thereafter any page carrying OpenAI's pixel returns it. In OpenAI's internal naming, bzr is short for bazaar, the ads platform itself.
One finding undercuts the SDK's own safeguard. The pixel has a code path that omits credentials, but the browser has already attached cookies to the <script src> request that fetches the SDK, before a line of OpenAI's code runs. Loading the tag is sufficient to disclose the identifier, which means the disclosure is not something an advertiser's integration choices can switch off.
The pixel's second job: reading the host page
OpenAI's payload labels four identity sources β in for what an advertiser passes on purpose, and fm, ht and js for what the SDK takes from form fields, rendered page text and the tag-manager bus. That last channel is the most aggressive: the SDK swaps out window.dataLayer.push, reads adobeDataLayer, and locates renamed Google Tag Manager containers by parsing the l= parameter from the gtm.js tag. Current builds lift email and phone this way; version 0.1.31 also took names and geography until the scope narrowed on 27 August.
The hashing story is partial. Email, phone and names are SHA-256 hashed, but country, region, city and postal code travel in the clear β and postal code was the single most-harvested form field, in 100 events across 28 sites. Hashed identifiers combined with a clear-text postal code are a weaker privacy boundary than hashing alone suggests. Full URLs are reduced to origin plus path, with none of 23,929 observations carrying a query string, yet paths are often descriptive enough on their own: those reaching the collector included a medical condition, a debt-solutions funnel and a litigation intake form. Automatic matching was enabled on 638 of the 881 pixels whose setting was visible, every credit and lending advertiser among them.
Advertisers are not well placed to audit any of this. __obi lives on a domain their scripts cannot read, so a merchant running the tag has no way to inspect what identity its own visitors are disclosing. Since the web scraping channel dominates the deliberate one by nearly three to one, the party that legally owes visitors a consent notice is frequently not the party deciding what gets collected.
Where the evidence stops
The report is explicit about its ceiling. An HTTP 202 shows the collector accepted an event with the cookie attached; it does not show OpenAI resolving that event to an account in its own systems. The researcher describes the server-side join as following from the design rather than as something observed.
Reach is uneven, too. The behaviour was captured on Chrome for Android; Safari blocks third-party cookies outright and Chrome on iOS runs on WebKit, so no iOS browser exercises the mechanism, and desktop Chrome went untested. Roughly one ChatGPT session in five produced a sync token at all. The practical effect is that exposure is concentrated on Android users rather than spread evenly, and that the measured prevalence reads as a floor rather than a full accounting.
What the traffic does establish is persistence. On the researcher's own handset one __obi value reached OpenAI from 12 commercial sites under 13 pixel IDs β Chewy, Wayfair, ThriftBooks, Eventbrite, HelloFresh, Coursera and SeatGeek among them β and in the broader capture 12 of 30 distinct values surfaced under more than one advertiser, one under ten. Signing out is no escape: 196 tokens carried an anonymous subject that stayed fixed to a device for at least 27 days.
What happens next
OpenAI was asked directly. The researcher wrote to press@openai.com and privacy@openai.com on 14 September with two questions β why the cookie is classified as analytics, and whether refusing marketing consent stops it β and received an acknowledgement from OpenAI Support saying the observations would be shared internally, with neither question answered.
That silence sits awkwardly against how fast OpenAI is building the business the pixel serves, from sponsored agents that hold sales conversations inside ChatGPT to the Ads Manager console where the automatic-matching switch lives. The uncomfortable part is what people tell an AI assistant versus what they post publicly, and the teardown's 379 points and 188 comments on Hacker News within a day suggest developers grasped that distinction immediately. The consent classification is the thread most likely to be pulled first, because it is the one place where a company statement and a measurement plainly disagree.
FAQ
Can ChatGPT users turn off the __obi cookie?
The report identified no setting that disables it, and refusing marketing consent does not, because OpenAI treats it as analytics. It survives for a year on .openai.com. Clearing cookies removes it until the next sync, and browsers that block third-party cookies β Safari and every browser on iOS β prevent the cross-site step entirely.
Can advertisers see the ChatGPT identity attached to their visitors?
No, and that is part of the problem. __obi sits on a domain an advertiser's scripts cannot read, so merchants running the tag cannot audit it. The pixel's other cookie, __obref, is written on the advertiser's own domain and stays unique per site: 2,828 of 2,860 observed values appeared under exactly one advertiser.
Does this prove OpenAI links browsing history to named accounts?
Not conclusively. The account binding is visible inside the JWT claims, and the identifier demonstrably travels to OpenAI and is accepted. The final resolution step happens on OpenAI's servers, where the researcher could not observe it, so that part is inferred from the architecture rather than measured.
