Audit Finds GenAI Browsers Transmit Sensitive Data: Privacy Risks & Mitigations

Popular generative‑AI browser assistants can and do sweep up deeply personal data from ordinary web sessions — including health records, bank details and even social‑security numbers — and forward that content to remote servers where it can be tracked, profiled and reused in ways most users would neither expect nor accept.

Background / Overview​

Last quarter, a multi‑institution research team published a large, systematic audit of generative AI browser assistants that lays out how widely deployed extensions and integrations collect, transmit, and use browsing data for tracking and personalization. The paper, titled Big Help or Big Brother? Auditing Tracking, Profiling, and Personalization in Generative AI Assistants, was posted to the public preprint archive and presented at a major security forum. The authors — researchers from UC Davis, University College London and Mediterranea University of Reggio Calabria — combined a novel prompting framework with live network traffic analysis to test ten of the most popular GenAI browser assistants and extensions. (arxiv.org) (usenix.org)
Independent reporting from mainstream outlets has since confirmed the paper’s headline: most of the tested assistants transmit more browsing context than users expect, and several leave users exposed to cross‑site tracking and sensitive data leakage. These follow‑on reports reproduce key findings such as full‑page DOM uploads, form input capture, profiling across sessions, and sharing of prompts or identifiers with third‑party analytics platforms. (euronews.com) (techxplore.com)
This feature unpacks the technical findings, evaluates the practical risks for Windows users and browser administrators, and lays out defensible mitigation strategies — both immediate and strategic — that vendors, regulators and privacy‑minded users need to adopt.

---

What the researchers did — the audit in plain terms​

The research team designed a repeatable, two‑pronged audit:

• They built a prompting framework that simulates realistic user queries and follow‑ups, including tests to see whether an assistant retains and uses leaked personal attributes. This allowed the researchers to test profiling and personalization behaviour across browsing actions.
• They performed network traffic analysis by intercepting and decrypting the communications between the browser assistants, their servers, and third‑party trackers while exercising a set of real‑world browsing scenarios. This revealed exactly what data left the browser and where it went. (arxiv.org)

The team ran their test persona through 20 representative online spaces: ten public (news, shopping, social video) and ten private or authenticated (university health portals, banking pages, tax portals, dating sites, and learning management systems). By asking targeted follow‑ups — for example, “what was the purpose of the current medical visit?” after visiting a health portal — researchers probed whether the assistants had captured and retained sensitive page content. (arxiv.org)
The audit focused on the ten most popular generative‑AI browser extensions at the time, including well‑known offerings such as ChatGPT integrations, Merlin, Copilot variants, Perplexity, and a set of smaller but widely adopted assistants. The evaluation covered architecture (local vs server‑side inference), implicit and explicit data collection, sharing with third parties, and profiling/personalization behaviors. (arxiv.org)

---

Key findings — distilled, technical and practical​

1) Server‑side models dominate; local inference is rare​

Nearly all tested assistants rely on server‑side API calls for inference rather than performing model work locally. That architecture makes it necessary — and routine — for page content or derived context to be transmitted off‑device whenever the assistant is invoked. Only one assistant in the study operated without obvious server‑side profiling in the researchers’ tests. (arxiv.org)

2) Full page content and form inputs are being transmitted​

Several assistants uploaded full webpage content (HTML DOMs) or large extracts of visible content to their first‑party servers, even from authenticated pages. In at least one case — the Merlin extension — the audit recorded the assistant capturing form input values, including entries such as social‑security numbers on a U.S. tax portal and details from banking and health forms. That is a practical and alarming vector for exfiltration of protected data. (arxiv.org)

3) Third‑party analytics and cross‑site linkage​

The audit found multiple assistants sharing user prompts, identifiers (chat IDs, conversation IDs), and even IP addresses with third‑party trackers and analytics platforms like Google Analytics and Mixpanel. When an assistant attaches stable identifiers or chat tokens to analytics calls, that creates the technical possibility of cross‑site tracking and retargeting that far exceeds a single extension’s telemetry. Assistants named in the study for these behaviours include Sider, TinaMind and others. (arxiv.org)

4) Persistent profiling and personalization​

Some assistants inferred demographic attributes — age, gender, income, interests — and used those inferred attributes to personalize responses across sessions and browsing contexts. A subset of tested tools preserved context across navigations, enabling profiles to persist even when users moved to new sites or private pages. Perplexity’s assistant stood out as comparatively privacy‑friendly in the audit; other mainstream integrations showed extensive profiling traces. (arxiv.org)

5) Private spaces are not reliably protected​

Assistants that were expected to limit data collection in private, authenticated spaces sometimes continued recording or sent collected content upstream. The study shows that users’ expectation of privacy while interacting with health portals, university systems or banking pages can be violated simply by having an assistant active in their browser. These kinds of leaks raise possible compliance issues under sectoral laws. (arxiv.org)

---

Why this is legally and operationally significant​

• Health and education records—if transmitted without appropriate safeguards—may implicate laws such as HIPAA and FERPA in the U.S. The researchers caution that, depending on context and contractual arrangements, those data flows could constitute unlawful disclosures. Regulatory determinations require formal investigations and vendor logs; the paper frames legal exposure as an urgent risk rather than a definitive finding of illegality. (arxiv.org)
• In the European and UK contexts, the behaviour described (profiling without clear lawful basis, cross‑border transfers, lack of transparency) likely triggers GDPR concerns around data minimization, purpose limitation and automated profiling. The auditors explicitly flagged potential GDPR non‑compliance in several scenarios. (euronews.com)
• Operationally, the combination of server‑side inference + third‑party analytics + persistent identifiers increases the attack surface: a breach of a vendor or analytics partner could expose vast swathes of browsed content that users assumed remained private. The researchers highlight the poor visibility users have into what happens to browsing data after it leaves the device. (arxiv.org)

---

How these assistants technically leak data (short technical breakdown)​

• Content scripts and DOM access: Browser assistants often inject content scripts into pages. Those scripts have access to the page DOM and visible text. If the extension forwards DOM text or serialised HTML upstream for server processing, everything visible on the page can be exfiltrated. (arxiv.org)
• Background service workers and auto‑invocation: Some assistants use background workers that can auto‑trigger on navigation or search events. Auto‑invocation enables context retention but also means data can be sent without an obvious user action. The audit observed auto‑triggered calls in multiple assistants. (arxiv.org)
• Server‑side vs local inference trade‑off: Running models server‑side simplifies engineering and reduces client resource needs, but requires transmitting user content. Local inference is privacy‑preserving by design, but is still rare among the assistants tested. (arxiv.org)

---

Immediate steps for Windows users and IT administrators​

The risk is not theoretical: if you run these assistants as browser extensions or enable similar in‑browser AI features, sensitive data may leave the endpoint. Practical, immediate steps follow.

• Audit installed extensions and operators
• Remove or disable any generative AI browser assistant you don’t actively use.
• For those you keep, check extension permissions and disable “read and change all data on the websites you visit” unless strictly necessary.
• Block assistants on high‑risk domains
• Treat banking, tax, health portals, student systems, and other authenticated services as sensitive. Disable AI assistants when visiting these sites or run them in a separate browser profile that does not hold extensions.
• Use strict extension‑permission policies in enterprise environments
• Enforce policies via group‑policy or endpoint management to restrict installation of unsanctioned extensions and require review for any assistant that needs full‑page access.
• Prefer assistants with local or explicit consent models
• Where possible, use tools that only operate locally or that explicitly fetch pages server‑side only after explicit user consent for each site and action.
• Monitor network traffic and telemetry
• For security teams: instrument outbound filtering and inspect calls from extension processes to detect uploads of page DOMs or form posts to unknown endpoints.
• Principle of least exposure
• Log out of non‑essential accounts when not needed, run sensitive tasks in a hardened browser or VM, and avoid entering sensitive data on a machine where untrusted assistants are installed.

These immediate mitigations align with the researchers’ recommendations and mirror pragmatic IT hygiene for extension management.

---

How vendors and browser platforms should respond​

The audit doesn’t just call out the assistants — it provides a blueprint for safer design. Practical, prioritized engineering and policy changes include:

• Privacy‑by‑Design: Move privacy‑sensitive features to local processing where feasible; offer a clear “local‑only” mode as default for sensitive actions.
• Explicit, machine‑readable disclosures: When a feature will transmit page content, show a one‑click banner that explains exactly what will be sent, where it will be stored, and for how long. Make consent granular and revocable.
• Opt‑in profiling & deletion controls: Profiling should be opt‑in, paired with an easy deletion API that erases profiles and associated logs on demand.
• Segregate analytics from content flows: Avoid wiring raw prompts, chat IDs, or page content into general analytics pipelines that enable cross‑site tracking. Use anonymized, aggregated telemetry if analytics are necessary. (arxiv.org)
• Independent audits and certifications: Commission third‑party audits, publish methodologies and logs (redacted as necessary), and subject assistants to recognized privacy certifications to rebuild public trust.

These are not mere policy platitudes; they are technically achievable changes that materially reduce regulatory and reputational risk while preserving product value.

---

Broader threats and emerging attack vectors​

The privacy risk of browser assistants sits beside a parallel security problem: agents with broad data access are novel attack surfaces for prompt‑injection and agent‑hijacking exploits. Recent security research has demonstrated “zero‑click” exploit chains that can subvert agents, extract secrets, and implant persistent malicious instructions without direct user interaction. The combination of privileged extension access plus server‑side processing magnifies that threat. Security teams should treat assistants as first‑class attack surfaces and apply the same threat model used for connectors, bots and API‑enabled services. (menlosecurity.com)

---

Critical analysis — strengths, weaknesses, and open questions​

Strengths of browser assistants (why people use them)​

• Productivity gains: Summaries, cross‑tab reasoning and on‑page Q&A speed up research and repetitive tasks.
• Accessibility: For users with visual or cognitive impairments, instant summaries and conversational navigation can be transformative.
• Low friction: Extensions and side‑panel assistants provide an integrated workflow that reduces context switching.

Weaknesses and systemic risks​

• Design trade‑offs that favor convenience over privacy: Server‑side processing simplifies development but concentrates sensitive data in vendor clouds and analytics stacks.
• Opaque consent models: Privacy notices often bury the real implications in legal text; many users never see or understand that an assistant may capture authenticated page content. (arxiv.org)
• Regulatory gray area: Determining whether a given upload violates specific statutes (HIPAA, FERPA, GDPR) requires context, vendor cooperation, and regulator investigation. Until those adjudications happen, claims of legal violations should be treated as plausible but provisional. (arxiv.org)

What remains unverified or needs further scrutiny​

• The audit was performed in controlled lab conditions that simulated realistic browsing — excellent for reproducibility — but real‑world variance (different extension settings, versions, and server‑side configurations) might alter precise behaviour. Vendors may point to configuration options or enterprise settings that mitigate observed behaviour; those claims should be evaluated against telemetry and code audits.
• The study shows data transmissions and plausible policy/legal exposure, but regulatory findings require formal enforcement actions. The audit’s legal claims should therefore be understood as substantiated concerns requiring regulator and vendor follow‑up, not as final legal judgments. (arxiv.org)

---

Practical recommendations for WindowsForum readers (checklist)​

• Disable AI browser assistants before visiting any medical, banking, tax, or education portals.
• Use a second browser profile or a dedicated "research" browser for any assistant workflows; keep your primary profile minimal and extension‑free.
• Check extension permissions and audit background processes; remove assistants that require “read all data” permission unless you explicitly consent to the trade‑off.
• Prefer vendors that offer explicit per‑site consent or local‑model options. Perplexity, in this audit, showed the least evidence of profiling behavior — but vendors change quickly; prefer architectural guarantees (local inference, per‑site consent) over vendor reputations alone. (arxiv.org)
• For enterprise IT: implement extension whitelisting, monitor outbound traffic from extension subprocesses, and include generative‑AI assistants in threat modelling and incident response plans.

---

The road ahead — regulation, transparency and engineering​

This audit should be a clarifying moment for the industry. The convenience of integrated, context‑aware AI is real and compelling, but the deployment model must change if the technology is to scale without undermining user privacy and legal obligations.
Regulators in the EU, UK and U.S. are increasingly scrutinizing AI systems and data processing practices. The researchers explicitly call for regulatory oversight and stronger vendor accountability; mainstream coverage and security research have amplified that call. Policymakers and platform owners should require clearer disclosures, enforceable consent mechanisms, and technical controls that minimize the data surface sent to third parties. (arxiv.org) (euronews.com)
From an engineering perspective, the priorities are straightforward:

• shift sensitive processing to the client where possible,
• adopt machine‑readable, user‑facing consent flows,
• decouple analytics pipelines from raw prompt and content flows, and
• provide programmatic data‑deletion endpoints and audit logs for users to exercise their rights.

---

Conclusion​

Generative‑AI browser assistants deliver real productivity value, but the current dominant architectures create a predictable and preventable privacy problem: assistants routinely have the technical ability to see everything a user does in a tab, and many suppliers forward that content — sometimes including form inputs from authenticated pages — to remote servers and analytics pipelines. The researchers’ audit demonstrates this at scale and provides a prescriptive roadmap for mitigation. (arxiv.org) (arxiv.org)
For Windows users and administrators, the responsible posture is immediate and precautionary: audit and limit extension use, treat assistants as potentially privileged software with the same operational scrutiny as any connector or enterprise bot, and press vendors for transparent, privacy‑first designs. For vendors and regulators, the study is a prompt to act: privacy‑by‑design, visible consent, and independent audits are no longer optional if users’ medical, financial and educational data are to remain private in the age of in‑browser AI. (theregister.com)

---

---

Source: Mirage News AI Browser Assistants Spark Major Privacy Concerns