OpenAI is running a cross-site tracking cookie that ties your ChatGPT account to what you do on advertiser websites, and its own cookie policy files that cookie under analytics rather than marketing. That is the finding of a post published September 20 by the security researcher behind Buchodi's Threat Intel, who spent several months capturing traffic from an Android phone and then confirmed the results a second way. The post hit the top of Hacker News within hours.
The mechanism is ordinary adtech. I've watched Meta and Google run the same play for fifteen years. What has no precedent is bolting it onto a product people use to describe their health problems and their debts.
How the cookie gets set
The flow has three steps. When you use ChatGPT on the web, the client posts to a sync token endpoint and gets back a signed JWT that binds a random identifier to your account. The token expires in 60 seconds and carries a subject type of either account_user or anonymous. Your browser then sends that token to bzr.openai.com, and the server answers by setting a cookie named __obi on the .openai.com domain.
The cookie attributes tell you what it's for. SameSite=None, Secure, HttpOnly, Max-Age of 31536000 seconds. That is one year, and SameSite=None exists for exactly one reason: so the cookie rides along on requests made from other people's websites.
Step three happens on those other websites. Any company buying ads in ChatGPT can install OpenAI's measurement pixel, a script loaded from bzrcdn.openai.com. When you land on a page carrying that pixel, it posts events to bzr.openai.com, and the browser attaches __obi. OpenAI now has your ChatGPT identity next to the URL you're on and whatever the pixel picked up from the page.
On the researcher's own device, a single __obi value went back to OpenAI from 12 commercial sites under 13 pixel IDs. The named ones include Chewy, Wayfair, ThriftBooks, Eventbrite, HelloFresh, Coursera, and SeatGeek. Across the wider dataset, the researcher counted 936 distinct advertiser pixels on 1,029 hostnames and 23,929 URL events.
What the pixel scrapes without being asked
OpenAI's pixel documentation describes a feature called automatic advanced matching. The script reads customer information off the page it's embedded in. The researcher saw it pull from four places: values the advertiser passed in on purpose, form fields, rendered page text, and the Google Tag Manager dataLayer.
Scraped identity outnumbered identity the advertiser supplied on purpose, 685 events to 255. Email addresses, phone numbers, names, and external IDs are hashed with SHA-256 in the browser before they leave. Country, region, city, and postal code go in cleartext. Postal code was the most harvested field, 100 events across 28 sites.
The hashing is weaker protection than it sounds. A SHA-256 of a lowercased email is a stable identifier that any party holding the same email can match. That is the point of the feature. It is how the pixel joins a purchase on Wayfair to an ad view in ChatGPT, and it is why the same design at Meta drew years of regulatory attention.
The observed URL events included pages about medical conditions and litigation. The pixel does not know or care what a page is about. It reports the URL.
Analytics consent is enough
OpenAI's cookie banner offers two separate choices, one for analytics and one for marketing. You can refuse marketing and accept analytics, which is what a lot of people do when they think analytics means page view counts. The sync tokens the researcher decoded carried consent_decision: analytics_allowed, and the __obi cookie was set regardless of the marketing refusal.
That lines up with OpenAI's cookie policy, which lists __obi under analytics cookies that help OpenAI "understand how its services perform and are used." An identifier that lives for a year, is tied to your account, and is sent from other companies' sites to an ad collector is not analytics in any sense a consent management platform recognizes. Under the GDPR and the ePrivacy rules, the category on the banner is supposed to match what the cookie does. Here it doesn't.
Users who aren't logged in are covered too. Of 932 decoded sync tokens, 196 used the anonymous subject type, with an anonymous identifier persisting at least 27 days. If you later log in from that browser, the two IDs can be joined on the server. The researcher notes the cookie's scope was narrowed on August 27, and OpenAI updated its cookie policy on September 10, so somebody at OpenAI was already tending this.
The researcher wrote to OpenAI on September 14 with two questions: why is __obi an analytics cookie, and why does it persist when marketing consent is refused. The reply came from OpenAI Support, not the privacy team, and answered neither.
OpenAI announced ads on January 16 and started showing them to US Free and Go users on February 9. The pitch at launch was that advertisers get only aggregate performance numbers and never see your chats. That commitment may still hold. But it was always about the flow from ChatGPT to advertisers. The pixel is the flow in the other direction, from advertisers' sites into OpenAI, and the launch post said nothing about that.
Ads went live in the UK on June 6 and in 31 European markets on August 24. The researcher found the sync happens in roughly one ChatGPT web session in five. On iOS, Safari's Intelligent Tracking Prevention blocks the cookie, so the mechanism doesn't work there. The mobile web client shows ads without syncing at all, which tells you the ads work fine without the cookie. The cookie is for attribution, and attribution is what advertisers pay a premium for.
What to do if you run a site or use ChatGPT
If you've installed the ChatGPT measurement pixel on a site you operate, you are now a party to this. The pixel's docs initialize consent to true by default. If your consent banner doesn't call oaiq("consent", false) before the pixel loads, the pixel fires for every visitor, including the ones who refused marketing. Wire that up or pull the script.
Look at the automatic advanced matching setting. It scrapes form fields, and it will grab a postal code off a checkout page whether or not you intended to hand that to OpenAI. If you run a site where the URL path itself is sensitive, a clinic or a debt counselor, the pixel is reporting those paths. Don't install it on those pages.
Your Content Security Policy is the backstop. OpenAI's own docs list the hosts the pixel needs: script-src for bzrcdn.openai.com, connect-src and img-src for bzr.openai.com. If those hosts aren't in your policy, the pixel can't phone home. That cuts both ways. A CSP that allows them is a decision, and it should be a deliberate one.
As a user, you have four options. Block third-party cookies in your browser, which kills SameSite=None cookies outright and is what Safari does by default. Refuse analytics consent on ChatGPT as well as marketing consent. Clear cookies for openai.com, knowing a fresh identifier is issued on the next visit. Or add bzr.openai.com to a blocklist; there is already an issue open on the StevenBlack hosts list.
My read is that the technical design is nothing new and the policy design is the problem. Meta's pixel does the same scraping, hashes the same fields, and has for a decade. What changed is the identity on the other end of the join. A Facebook profile is a face you curate for the public. A ChatGPT account is a running log of what people ask when they think nobody is listening. OpenAI now holds both that log and a browsing trail across other sites keyed to the same account, and it labeled the mechanism analytics.
I expect a European data protection authority to open a file on this by year end. I don't expect the cookie to go away. I expect it to move to the marketing category, with the default flipped to on for anyone who hasn't touched the banner, and the ad business will keep growing.
