Privacy-first X audience analysis: why Revealed processes data in your browser

The answer in full

Privacy-first audience analysis starts with a specific question: where does the information go after an extension reads it? Revealed is designed to collect the public X profiles you choose to scan, store the audience in Chrome extension storage and derive insights locally. Its semantic model, tokenizer and WebAssembly runtime are bundled with the extension, so profile text is not sent to an external AI service for classification. This design avoids creating a server-side copy of raw audience rows in Revealed's account service. It does not mean the product never communicates with a server: account access, plan checks, billing and support have their own online workflows. It also does not make every later action local. If you export a CSV and upload it elsewhere, that destination receives the file. If you connect an assistant, consider where that assistant processes the summaries it receives. The useful privacy promise is a defined data boundary, rather than a blanket claim that nothing can ever leave your computer.

At a glance

What the Poper Blocker reporting illustrates

In its 28 September 2026 investigation, Bay Area Labs reported that Poper Blocker collected browsing URLs and AI conversation data using instructions delivered from a remote server. Dark Reading covered those findings on the same date. Gridinsoft's 30 September article discusses the collection model and its limits. Links to all three sources are below.

These are reports about a particular extension and the behaviour examined by the researchers. They do not establish that every installation exposed every conversation. The researchers also distinguish commands the interpreter could execute from commands observed in the captured programs.

For someone choosing an audience research extension, the relevant question is whether the information needed for the feature is also being sent to another service. A store badge, review count or useful feature does not explain that data flow. This is why we explain Revealed's processing boundary rather than asking you to rely on a privacy label.

Why we chose local audience processing

Follower research can reveal a team's target market, creator shortlist or competitive research direction. Even when the underlying profiles are public, the collected audience and the questions you ask about it can be useful business information.

Keeping collection, storage and classification on the device lets Revealed provide audience insights without uploading raw profile rows to its account service. It also means the local analysis does not need to send each bio to an external AI classifier.

This is an architectural choice about audience analysis. It is not a claim that Revealed is immune to security bugs, that every server-connected extension is unsafe or that a browser store has independently certified our design.

What stays local and what still goes online

Scanned public profiles, bios, saved audience snapshots, locally derived classifications and aggregates remain in extension storage unless you choose to export, copy or share them. The existing privacy notice describes this boundary and the account workflows in more detail.

Account infrastructure handles information needed for sign-in, plan access and security. Stripe handles payment processing; support messages and abuse protection have separate service roles. Those workflows do not require raw follower rows to be uploaded for audience analysis.

Revealed still reads the audience response available to your signed-in X session. Local processing means the analysis occurs on your device; it does not mean scanning X works without accessing X.

AI assistance needs its own privacy decision

Revealed's local classification and a user-chosen assistant are different workflows. You can export a file and share it with an assistant, but the provider then receives what you upload and its policies apply.

The optional Pro MCP connection runs a bridge on the same computer and returns bounded, computed audience summaries rather than raw profile rows. A local bridge does not make a cloud-hosted assistant local: summaries can still enter the assistant's processing environment. Review the assistant configuration and share only what suits your research task.

Questions to ask before trusting an analytics extension

Ask what it reads, why that access is needed, whether raw data is uploaded, where analysis runs, how long data is retained and what changes when you enable integrations. Look for answers that name the data and destination rather than relying on broad promises.

For Revealed, start with the data boundaries above and our privacy notice. Consider exported files and assistant connections as explicit sharing choices, and remember that data stored locally still needs care on a shared or compromised device.

What to keep in mind

• This page summarises reported research; we have not independently reproduced the Poper Blocker investigation.
• Local processing reduces the need for server-side audience copies; it is not a guarantee against every security or privacy risk.
• User-chosen exports and assistant integrations can share information beyond the extension.

Sources and further reading

• ↗

  Bay Area Labs: Poper Blocker investigation

  Primary research by James Arnott, 28 September 2026. Documents observed collection, interpreter capabilities and configuration limits.

• ↗

  Dark Reading: Chrome Store hosts Poper Blocker spyware

  Reporting by Nate Nelson, 28 September 2026, covering Bay Area Labs' findings.

• ↗

  Gridinsoft: Poper Blocker collects AI chats and browser history

  Analysis updated 30 September 2026. Explains the findings and distinguishes demonstrated capabilities from observed collection.

• ↗

  Revealed Privacy Notice

  Our description of local audience processing, account services, retention and optional integrations.