Pular para o conteúdo principal

What Your AI Chat Leaks to Ad Trackers

Intermediário
What you'll learn
  • Name the artifact class that is unique to conversational AI — conversation URLs, titles, prompts and screenshots — and why it is far worse than ordinary web tracking
  • Recognise the three mechanisms (server-side tag managers, first-party-proxied analytics, mobile WebViews) that make an ad blocker irrelevant here
  • Read the consent numbers honestly: what rejecting non-essential cookies actually removes, and what it does not
  • Understand why a conversation permalink is not an access control, and what the canary-token experiment proved
  • Run a 20-minute self-audit of any assistant you use, and apply the handful of settings changes that measurably matter

The study, in one paragraph​

Nine researchers, mostly at IMDEA Networks in Madrid, took the nine most-used conversational AI services and instrumented them the way the mobile-tracking research community instruments any app: Chrome v148 driven through the Chrome DevTools Protocol with full HAR capture for the web clients, and a Google Pixel 3a running an instrumented Android 12 AOSP build with mitmproxy and Frida for the eight that ship an Android app — plus static decompilation with Androguard to enumerate embedded SDKs. Every session was driven by hand with a fixed, deliberately sensitive persona script (a user asking about a medical condition), repeated across guest / free / paid tiers and across three consent states: ignore the banner, reject non-essential cookies, accept everything. Measurements were taken in Spain in May 2026. The paper was accepted at PoPETs — the peer-reviewed venue for privacy technology — and the authors ran a responsible-disclosure process with the providers and with European data protection authorities before publishing.

That methodology matters because it is the difference between "someone found a Meta pixel on a page" and a defensible claim about what is transmitted, under which consent state, on which tier, to whom.

ServiceProviderWeb domainAndroid packageTranco rankPlay installs
ChatGPTOpenAIchatgpt.comcom.openai.chatgpt48over 1B
ClaudeAnthropicclaude.aicom.anthropic.claude617over 10M
GrokxAIgrok.comai.x.grok956over 100M
DeepSeekDeepSeekchat.deepseek.comcom.deepseek.chat1,196over 50M
PerplexityPerplexity AIperplexity.aiai.perplexity.app.android1,249over 100M
GeminiGooglegemini.google.comcom.google.android.apps.bard6,045over 1B
MS CopilotMicrosoftcopilot.comcom.microsoft.copilot11,011over 50M
Le ChatMistral AIchat.mistral.aiai.mistral.chat12,039over 1M
Meta AIMetameta.aicom.facebook.stella13,701over 50M

The headline numbers​

What you'll learn
  • Every one of the nine services contacts at least one third-party advertising or tracking service. There is no clean provider in the set.
  • 124 distinct third-party domains, attributed to 44 organisations, 34 of which are advertising or tracking services.
  • 6 of 9 web clients and 3 of 8 Android clients leak conversation-derived artifacts — URLs, titles, prompts, screenshots — to 11 and 2 tracking organisations respectively.
  • 5 web clients disclose conversation permalinks (or the identifiers needed to rebuild them) to 9 tracking organisations. Three of those five do it by default, with no consent needed.
  • 3 of 9 web clients leak the auto-generated conversation title to 9 third parties including Meta, TikTok and DoubleClick.
  • Rejecting non-essential cookies leaves 80.8% of third-party trackers still active.

Third-party integration is not the same set on web and on mobile: 11 tracking organisations appear on both client types, 15 are web-only (including Google Tag Manager, TikTok and the consent-management platform OneTrust), and 8 are mobile-only (including Braze). Auditing the website therefore tells you very little about the app, and vice versa.

Why conversation artifacts are a different problem​

Ordinary web tracking observes behaviour: which page you loaded, how long you stayed, what you clicked. Conversational AI generates a new class of object — the provider itself manufactures a short, human-readable summary of what you are thinking about, and then that object travels through the same pipes.

The paper's Appendix A shows exactly what that summary looks like. Same prompt, three providers:

Prompt typed by the userTitle generated by ChatGPTby Claudeby Grok
"What are the symptoms of early-stage Parkinson's disease?"Early-stage Parkinson's SymptomsEarly-stage Parkinson's disease symptomsEarly Parkinson's Disease Symptoms
"My salary is $85k. How much mortgage can I afford in NYC?"Mortgage Affordability in NYCMortgage affordability on $85k salary in NYC$85k NYC Salary: $280k-$350k Mortgage

Look at the bottom-right cell. Grok's title does not merely record the topic — it encodes the answer, including a salary figure and a mortgage range, into a short string. When that string is transmitted to an ad network alongside a stable identifier, the ad network has learned a health condition or a financial profile from a single field. No inference, no modelling, no clickstream reconstruction. The provider did the summarisation for them.

Here is what the paper counted leaking, and to how many distinct tracking organisations:

Artifact leakedProviders (web)Providers (Android)Trackers (web)Trackers (Android)
Conversation URL5090
Conversation ID2211
User prompt1121
Conversation title3090
Conversation screenshot1010
Shared conversation URL5090
Shared conversation ID0101

The asymmetry is worth internalising: the web clients leak the user-facing artifacts (titles, URLs, screenshots) because web trackers execute inside the page's JavaScript context and can simply read the DOM. Mobile SDKs run outside the WebView's document, so they mostly get the conversation ID — but in exchange they get a much richer identifier set, because a third-party SDK inherits the host app's permissions.

Three mechanisms that make your ad blocker irrelevant​

This is the part most coverage misses, and it is the most transferable lesson on the page. Blocking doubleclick.net in your browser does nothing against any of the following.

Guided walkthrough1 of 3
  1. Grok's web client loads a Google Tag Manager container configured to route events through a server-side GTM instance (sGTM). A custom event forwards the conversation URL and the chat topic server-to-server to Meta's Conversions API and TikTok's Events API. Because the hop from Grok's infrastructure to Meta and TikTok never touches your browser, no extension can see it, let alone block it. The same payload carries both Meta's _fbp cookie and TikTok's _ttp cookie, which means the two ad platforms can be joined into a single identity for that event.
Watch out
  • The generalisable rule: once a provider moves tracking server-side or proxies it through its own domain, client-side blocking is a measurement of the provider's laziness, not of your privacy. The only client-side controls that still bite are the consent signal itself and not generating the artifact in the first place.

A fourth mechanism shows up in the CSP headers rather than in live traffic. Content-Security-Policy response headers enumerate the origins a page is authorised to contact, including ones that stayed dormant during the test — a useful lower bound on future behaviour. Across the nine services:

OrganisationDomains in CSPNumber of providers
Google Tag Managergoogletagmanager.com6
Google Analyticsgoogle-analytics.com5
Google Adsgoogleadservices.com4
Meta Pixel / Conversions APIconnect.facebook.net, facebook.net4
Google DoubleClickdoubleclick.net3
TikTok Analyticsanalytics.tiktok.com2
Reddit Ads / Analyticspixel-config.reddit.com, redditstatic.com2
Microsoft Bingbat.bing.com, bing.com2
Intercomintercom.io, intercomcdn.com2

Per-service findings worth knowing​

These are the specific, verifiable behaviours the paper documents. Each is a May 2026 observation, not a permanent property.

Nine assistants, nine findings
Pressione Enter ou Espaço para virar o cartão. Use as setas esquerda e direita para navegar entre os cartões.Termo exibido.
1 / 9

This is where the study is most useful and most depressing, because it quantifies something everyone suspects.

What you'll learn
  • 77.3% of observed transmissions of web identifiers to third parties occur only after the user accepts non-essential cookies. Your choice does something.
  • But 80.8% of third-party trackers remain active even when non-essential cookies are rejected. What your choice removes is the minority.
  • Across all analysed free-tier services, third-party trackers still collect data in 44.4% (4 of 9) of them under a reject-all configuration.
  • Of the three web clients that leak conversation titles, 88.9% of those disclosures happen only on accept — titles are among the artifacts consent actually gates.
  • Ignoring the banner entirely produced no connections beyond those observed under explicit rejection. Clicking the X is, on these nine services, equivalent to rejecting.
  • Subscription tier barely matters. Free and premium accounts contacted largely identical third parties; Claude's mobile free tier was the single clear exception.

Two structural observations follow, and they are the ones to remember:

The strongest controls are least available to the users most exposed. Persistent consent preferences on the web exist only on ChatGPT's paid tier, while roughly 95% of ChatGPT users sit on free tiers — and OpenAI has announced advertising for free and low-cost users. On mobile, most apps present no cookie-consent equivalent at launch at all, despite exposing similar tracking infrastructure. You cannot reject what you were never asked about.

Presence is not proof of purpose. The paper is careful here and so should you be: a third party appearing in traffic does not by itself mean data is being used for advertising. Some SDKs do crash reporting, session replay or in-app payments. Sentry, Datadog and Intercom have obvious operational justifications. The authors also note their methodology cannot separate a provider's own first-party server-side tracking from functional traffic. Read the tables as "these entities receive this data", not "this data is definitely sold".

Every one of the nine services lets you share a conversation, and every one of them serves the shared conversation without requiring the recipient to authenticate. The security model is the unguessability of a UUID in the URL. Table 6 in the paper measures the default posture per provider and tier; the two outliers are Grok, where free and premium conversation permalinks are public by default with an opt-out, and Perplexity, where guest-tier conversations are always public with no opt-out at all. Perplexity is also the only provider that offers a whitelist control on top.

The authors then did the thing that turns a theoretical exposure into a measured one. They deployed canary tokens — from canarytokens.org and from a self-hosted canary infrastructure with a generic domain, because some assistants recognise and refuse known canary domains — both pasted directly into prompts and embedded inside uploaded .docx and .pdf files. Then they waited to see who fetched them.

Watch out
  • For DeepSeek, Copilot, Mistral and Claude, some canary URLs fired once at submission time, from AWS or GCP addresses — consistent with the provider's own link-preview or retrieval infrastructure.
  • For Grok, they recorded 70 distinct canary activations over hours to days after submission, from 70 IP addresses spanning 48 autonomous systems in 14 countries across 4 continents, with 65.7% of connections originating in the United States.
  • Perplexity repeatedly fetched canary URLs even when the prompt explicitly instructed it not to, from IP ranges belonging to its Perplexity-User crawler on AWS infrastructure in the US.

Seventy retrievals from forty-eight different networks, days later, is not link-preview behaviour. It is the signature of a URL that escaped into a pipeline and got crawled. The authors are appropriately cautious — absence of observed access elsewhere is not evidence of absence, since they only see what their own instrumentation catches — but the positive result stands on its own.

Grok was also the only service where the authors identified something they classified as a security concern exploitable by an external party, rather than an intentional product decision. That is why xAI got a vulnerability-disclosure email on 2026-04-17 rather than an ordinary research notification. As of 2026-09-10 the paper reports that Grok still uses publicly accessible permalinks and that no official response had been received.

Run the audit yourself​

None of this requires research infrastructure. You can reproduce the shape of the finding on any assistant in about twenty minutes, and you should, because the stacks change constantly and the paper is explicitly a point-in-time lower bound.

Guided walkthrough1 of 6
  1. New browser profile, no extensions, no prior cookies. Prior consent state, auth tokens and telemetry artifacts from an earlier session will silently change what fires. This is the step people skip and it invalidates everything downstream.

Extract every third-party host and hunt for your own identifiers in a HAR

# Every distinct host the page contacted, by request count
jq -r '.log.entries[].request.url' capture.har \
| awk -F/ '{print $3}' | sort | uniq -c | sort -rn

# Any request whose URL or POST body contains the conversation UUID
CONV_ID="paste-the-uuid-from-the-address-bar"
jq -r --arg id "$CONV_ID" '
.log.entries[]
| select((.request.url | contains($id))
      or ((.request.postData.text // "") | contains($id)))
| "\(.request.method) \(.request.url)"' capture.har

# Your email, in clear and in the three hashes trackers actually use
EMAIL="you@example.com"
for h in "$EMAIL" \
       "$(printf %s "$EMAIL" | md5)" \
       "$(printf %s "$EMAIL" | shasum -a 1   | cut -d' ' -f1)" \
       "$(printf %s "$EMAIL" | shasum -a 256 | cut -d' ' -f1)"; do
printf '%s -> ' "$h"
grep -c -- "$h" capture.har
done

What actually reduces exposure​

Ordered by how much they move the needle, per the paper's own mitigation discussion.

Guided walkthrough1 of 6
  1. The worst transmissions in the study happen in the sharing code path, and every provider lets you revoke previously shared links. Go through your existing share list now. A permalink you created in 2024 and forgot about is still public on Grok and Perplexity's guest tier, and the canary result shows shared URLs do get fetched.

If you build on these APIs, this is your problem too​

The paper's scope note is easy to skim past and it is the part that should worry engineers: the leakage vectors observed here "stem from embedding standard web and mobile tracking directly into conversational interfaces". Nothing about them is specific to a frontier lab. If you have shipped an LLM-powered support chatbot, a custom assistant or a third-party AI wrapper, and your marketing team has installed the usual analytics on the same pages, you have almost certainly reproduced this architecture by accident.

Three concrete things to check in your own product:

  • Do you generate conversation titles or summaries client-side? If so, they are in the DOM, and any tag manager on that page can read them. The fix is to keep generated summaries out of the document title, out of <meta> tags, and out of any analytics event payload.
  • Are conversation IDs in the URL path? Then they are in the Referer header of every third-party request the page makes, and in document.location for every script. The study found two providers shipping the global conversation ID to Datadog as an independent parameter, which is enough to reconstruct a permalink.
  • Is your share page publicly readable? Under the ePrivacy Directive's Article 5(3) and the EDPB's Guidelines 2/2023 on its technical scope, URL and pixel tracking, persistent identifiers, and instructing the browser to forward data to a server-side API all require prior informed consent. The CJEU's Fashion ID judgment (C-40/17, paragraph 78) goes further: enabling third-party access is itself a processing decision that triggers your obligations, whether or not the third party ever reads the data.

The disclosure timeline​

Useful as a model for how this kind of research lands, and as a record of who moved.

DateEvent
2026-03-23Authors first notice tracker activity while analysing Perplexity and Grok
2026-04-06Testing expanded to all major platforms across consent states, tiers and privacy modes
2026-04-13Findings notified to data protection authorities in the EU and UK
2026-04-17xAI notified via vulnerability disclosure, specifically about Grok's conversation access controls
2026-05-27The Spanish DPA (AEPD) cites the work, requesting escalation to an EDPB plenary meeting held 2026-06-06
2026-08-15OpenAI updates ChatGPT's privacy policy to explicitly mention third-party trackers (causal link unconfirmed by the authors)
2026-09-10Grok still exposes publicly accessible permalinks; no official response received

Check yourself

0/6
  1. You reject non-essential cookies on every AI assistant you use. Roughly what fraction of third-party trackers does that remove?
  2. Why does blocking doubleclick.net in your browser fail to stop Grok's conversation URLs from reaching Meta and TikTok?
  3. Which artifact makes conversational AI tracking qualitatively worse than ordinary web tracking?
  4. The canary-token experiment produced 70 activations from 48 autonomous systems in 14 countries, days after submission. Which service, and what does it demonstrate?
  5. You are auditing your own LLM-powered support chatbot. Which of these is the highest-risk pattern the study identifies?
  6. Why might the mobile app be the worse choice for sensitive conversations, even though the web client leaks more conversation content?
Key takeaways
  • All nine major conversational AI services contact at least one advertising or tracking organisation: 124 third-party domains, 44 organisations, 34 of them ATSes. There is no clean option in the mainstream set.
  • Conversational AI creates an artifact class that ordinary web tracking does not have — the provider's own generated title, a compressed natural-language summary of user intent — and 3 of 9 web clients ship it to 9 third parties including Meta, TikTok and DoubleClick.
  • Client-side blocking is structurally defeated three ways: server-side tag managers (Grok to Meta Conversions API and TikTok Events API), first-party-proxied analytics (Claude's Segment via a-cdn.anthropic.com, forwarding to eleven trackers), and mobile WebViews carrying 71% of all mobile endpoints.
  • Consent removes the minority: 80.8% of trackers survive rejecting non-essential cookies, and the strongest control — persistent consent preferences — exists only on ChatGPT's paid tier while roughly 95% of users are on free tiers.
  • A conversation permalink is an unguessable URL, not an access control. Canary tokens proved shared Grok conversations are fetched 70 times from 48 autonomous systems in 14 countries, days after the chat ended.
  • The cheapest real mitigations: revoke old share links, use temporary/incognito chat, delete rather than reset your Android advertising ID, and move genuinely sensitive work to a raw API call or a local model where no tag manager exists.
  • If you ship an LLM feature, you probably inherited this architecture by accident — check for generated summaries in the DOM, conversation IDs in URL paths, and publicly readable share pages.

Sources & further reading​

Next​