A security researcher just showed that ChatGPT — a product hundreds of millions of people use for medical questions, legal drafts, and relationship advice they'd never type into a search bar — is running the same cross-site ad-tracking mechanism Meta and Google have run for two decades. The disclosure, published by Buchodi's Threat Intel on September 20, 2026, hit #1 on Hacker News with 592 points and 315 comments within a day.
The mechanism is a cookie called __obi. It's set on .openai.com, it's the only cookie in OpenAI's own cookie policy configured to travel to other websites, and the researcher traced it doing exactly that — showing up on Chewy, Wayfair, ThriftBooks, Eventbrite, HelloFresh, Coursera, and SeatGeek, among other ordinary e-commerce sites, wherever those sites had installed OpenAI's advertiser pixel. This is not a hypothetical: it's verified via two independent capture methods and cross-checked against 23,929 requests across 936 advertiser pixels on 1,029 hostnames.
This post explains the mechanism end to end, separates what was directly observed from what follows from the design but wasn't, and covers concrete ways to check and block it — the kind of practical mitigation explainx.ai's readers actually want, not just alarm.
TL;DR — what people are asking
| Question | Answer |
|---|---|
What is __obi? | A first-party OpenAI cookie, set on .openai.com, configured SameSite=None; Secure, 1-year expiry |
| What makes it different from other OpenAI cookies? | It's the only OpenAI cookie configured to be sent on cross-site requests — every other one (session, oai-did, etc.) is blocked cross-site by design |
| How does it reach other sites? | Advertisers install OpenAI's ad pixel SDK; the cookie rides along on requests that pixel makes back to bzr.openai.com |
| Does it work if I'm logged out? | Yes — 196 of 932 decoded tokens were "anonymous," and that identifier is just as persistent (27+ days observed) |
| Does declining ad consent stop it? | No — every token decoded carried consent_decision: analytics_allowed, and OpenAI lists __obi as an analytics cookie, not marketing |
| What data travels with it? | Hashed email/phone/name, plain-text postal code/city/region, and page path (not query string) |
| Where was it actually seen? | 12 real sites on the researcher's own device, under 13 pixel IDs; 12 of 30 broader __obi values seen under 2+ advertisers |
| Does OpenAI confirm the server-side link to your account? | Not directly observed — the researcher confirmed the mechanism up to a 202 Accepted response; the internal account match follows from the design |
| Which browsers block this? | Safari ITP (all iOS browsers), Firefox Total Cookie Protection, Brave — all by default. Only reproduced on Chrome for Android |
| Did OpenAI respond? | Support acknowledged the researcher's questions on record but hadn't answered either one as of publication |
The mechanism, step by step
Step 1 — a sync token is minted on chatgpt.com
When you use ChatGPT, the client-side app generates 16 random bytes and calls:
POST /backend-api/bazaar/obi/sync-token
(or /backend-anon/bazaar/obi/sync-token when you're signed out). OpenAI's backend responds with a signed RS256 JWT — a cryptographically signed token, not just an opaque string — containing:
- Issuer:
chatgpt-wadi(the internal service that issues it) - Audience:
bzr.openai.com - Purpose:
obi_sync - The account's
sub(subject identifier) if logged in - An
obiidentifier - A
consent_decisionfield — every token the researcher decoded readanalytics_allowed - A 60-second expiry
The naming is a small but telling detail: bzr is OpenAI's internal shorthand for "bazaar," its ads platform, and wadi is the name of the issuing service.
Step 2 — the token becomes a cookie
The client then POSTs that JWT to bzr.openai.com/v1/obi/sync, and the response sets:
Set-Cookie: __obi=<value>; Domain=.openai.com; HttpOnly; Max-Age=31536000; Path=/; SameSite=None; Secure
That Max-Age=31536000 is one year. The combination that matters most here is SameSite=None + Secure — this is the only configuration that lets a cookie ride along on requests made from a different site entirely. Every other OpenAI cookie the researcher tested (session cookies, oai-did, the consent-preference cookies themselves) is scoped with SameSite=Lax or a domain mismatch that blocks it from being sent cross-site. __obi is the sole exception in OpenAI's own published cookie policy.
Step 3 — the cookie travels to advertiser sites
This is where it stops being a chatgpt.com-only concern. Sites that sign up to advertise inside ChatGPT install OpenAI's ad pixel/SDK — structurally the same thing as installing a Meta Pixel or Google Ads tag, code a site owner adds once and mostly forgets about. When you later visit that site, the pixel fires three request types to OpenAI's ad infrastructure (bzr.openai.com, bzrcdn.openai.com), and because __obi is scoped SameSite=None; Secure, your browser attaches it automatically.
Critically, the researcher found this happens even just loading the pixel's <script src> tag — a request that fires before any of the pixel's JavaScript executes. That matters because it defeats the SDK's own "no credentials" code path: a developer reading OpenAI's SDK docs might reasonably assume that if they don't opt into sending cookies, none are sent. The initial script load doesn't give them that choice.
What data actually travels alongside the cookie
The pixel SDK collects identity signals from the advertiser's page from four labeled sources:
| Source | What it captures | Observed volume |
|---|---|---|
in | Values the advertiser deliberately passes to the pixel | 255 events |
fm | Values scraped from form fields on the page | — |
ht | Values parsed out of rendered page text (HTML) | — |
js | Values pulled from the site's tag-manager/analytics bus | — |
In the researcher's observed traffic, the three scraped sources (fm + ht + js) combined for 685 events — nearly 3:1 over deliberately-supplied identity. The js source is the most invasive of the three: it includes hijacking window.dataLayer.push calls, reading Adobe's adobeDataLayer, and even parsing renamed Google Tag Manager layers — meaning the pixel is pulling from analytics plumbing the advertiser built for entirely different tools.
Hashing and clear text, per the researcher's decoding:
- Email, phone, and name are SHA-256 hashed before transmission — a standard practice for the ad industry, though a hash is reversible against a known dictionary of common emails/phones.
- Country, region, city, and postal code are sent in the clear. Postal code was the single most-harvested field: 100 events across 28 sites.
- URLs are stripped to origin + path, with no query strings observed across all 23,929 requests. But paths alone were revealing — the researcher's traffic included a medical-condition page, a debt-consolidation funnel, and a litigation-intake form path traveling to OpenAI's ad servers.
"Automatic matching" — a broader, page-content-scraping mode — was enabled for 638 of 881 advertiser pixels with a known setting, including every credit/lending advertiser the researcher observed. That setting lives in OpenAI's own Ads Manager, and its denylist specifically excludes passwords, OTPs, card numbers, SSNs, date of birth, and medical/legal fields — a targeted exclusion list that, by implication, leaves broader fields like postal code and page paths on medical or financial funnels un-denylisted.
How wide is the reach — and how gated is it
On the researcher's own device, a single __obi value was observed traveling to OpenAI from 12 real commercial sites under 13 distinct pixel IDs — named examples include Chewy, Wayfair, ThriftBooks, Eventbrite, HelloFresh, Coursera, and SeatGeek. In the broader traffic sample, 12 of 30 distinct __obi values appeared under more than one advertiser, and one value showed up under all ten advertisers in that subset — direct evidence of a single identifier cross-linking otherwise unrelated sites.
Two caveats the researcher is careful about, and that make this a credible disclosure rather than a sensational one:
- Gating: only roughly 1 in 5 ChatGPT sessions in the researcher's testing produced a sync token at all. ChatGPT's mobile web client appears to serve ads without syncing in some cases, meaning this specific mechanism doesn't fire on every session.
- The account-level join was not directly observed. The researcher confirmed the mechanism up to OpenAI's servers returning a
202 Acceptedwhen the cookie was attached to a sync request — that OpenAI's backend actually correlates the cookie to a specific ChatGPT account internally is the logical conclusion of the design (why else mint a JWT carrying the accountsub?), but it was not observed directly in traffic.
What OpenAI's own policy says — and the unanswered question
OpenAI's cookie policy lists __obi under "Analytics cookies," with a 1-year lifetime on chatgpt.com/openai.com. It is, per the researcher, the only cookie in that entire policy section — every other analytics-labeled cookie in OpenAI's policy behaves differently.
OpenAI separates cookie consent into two independent toggles: oai_consent_analytics and oai_consent_marketing. That split exists, presumably, so a user can accept analytics (which sounds benign — "how do people use our product") while declining marketing/advertising cookies. But every sync token the researcher decoded carried consent_decision: analytics_allowed — meaning a user who explicitly refuses marketing consent, but accepts the seemingly-unrelated analytics consent, still gets __obi set and used for cross-site ad attribution.
The researcher emailed OpenAI's press and privacy teams on September 14, 2026, asking two direct questions:
- Why is
__obiclassified as an analytics cookie rather than marketing/advertising? - Do users who accept analytics consent but decline marketing consent still receive the cookie?
OpenAI Support acknowledged the inquiry and said it would be shared internally for review. As of publication, neither question has been answered.
What has precedent here, and what doesn't
It's worth being precise about what's actually novel, because the mechanism itself is not new. A pixel installed on advertiser sites, a persistent identifier that's resolved server-side to a user account, cross-site attribution built on top of that join — this is standard, decades-old adtech. Meta's Pixel and Google's advertising cookies have worked structurally the same way for years, and most people have some awareness (however vague) that Facebook and Google track them this way across the web.
The researcher's own framing, worth preserving exactly: what has no precedent is running it on an AI chat product. People routinely tell ChatGPT things they'd never type into a Google search box or post on Facebook — a diagnosis they haven't told their family, a legal problem they're embarrassed about, a relationship they're trying to work through. The expectation of privacy around a conversational AI product is meaningfully different from the expectation around a search engine or social feed, even if the underlying tracking plumbing is identical to what search and social have run for twenty years. The gap between what the mechanism does and what a typical user believes ChatGPT does with their data is the actual story here — not the technical novelty of the mechanism itself.
How to check and block this yourself
Practical steps, roughly in order of how much they cost you:
- Check your browser's cookie policy. If you're on Safari — including any browser on iOS, since all iOS browsers run on WebKit — Intelligent Tracking Prevention already blocks all third-party cookies by default, which blocks this mechanism outright regardless of
__obi'sSameSite=Nonesetting. No action needed. - Switch to (or confirm) Firefox with Total Cookie Protection, which is on by default and isolates cookie jars per site — a cross-site cookie like
__obisimply can't be read back by a second site. Brave does the same by default. - On Chrome, the researcher's reproduction was specifically Chrome for Android; desktop Chrome was untested. If you're on Chrome, install uBlock Origin and enable Chrome's own third-party cookie blocking under Settings → Privacy and security → Third-party cookies → Block third-party cookies.
- Review your OpenAI cookie/privacy settings directly — check your analytics vs. marketing consent toggles in your OpenAI account's data controls. The researcher's findings suggest this may not change whether
__obigets set, but it's worth confirming your own account's current state and re-checking after OpenAI responds to the outstanding questions. - Periodically clear cookies for openai.com/chatgpt.com if you don't want a year-long identifier persisting, keeping in mind this resets on your next ChatGPT session if the mechanism fires again.
None of this requires distrusting ChatGPT as a product to act on — it's the same hygiene a privacy-conscious reader would already apply to Facebook or Google, extended to a newer surface that most people haven't yet mentally filed under "ad tracking."
Related reading
- OpenAI Launches Ads in ChatGPT — the July 2026 Launch
- ChatGPT Ads Hits $1B Run Rate: What Changed for Advertisers
- ChatGPT Ads Self-Serve Rollout: India
- Shadow AI in the Workplace: The Privacy Risk Guide
- Claude Shared Chats and Artifacts Were Indexed by Google — What That Means for Privacy
- OpenAI's Project Lily: Human Review and ChatGPT Privacy
- Check Point Found a ChatGPT Sandbox Flaw That Leaked Gmail Across Accounts
- MCP Security Guide 2026: How to Secure AI Agent Tool Access
- Original disclosure: Buchodi's Threat Intel — "ChatGPT now knows what you do on other websites via ad collector" (independent security research, published September 20, 2026)
- Official: OpenAI's cookie policy · OpenAI ad policies
This post reflects Buchodi's Threat Intel's independently published research as of September 20, 2026, verified by the researcher via two capture methods against traffic across 936 advertiser pixels on 1,029 hostnames. Server-side account correlation of the __obi cookie follows from the token's design (it carries the account subject identifier) but was not directly observed in traffic — the researcher's confirmed observation stops at OpenAI's servers returning a 202 Accepted response. OpenAI had not answered the researcher's specific questions about consent classification as of publication; this post will be updated if that changes.