Messaging & Analytics Without Surveillance

Privacy-first software is often defined by what it refuses to collect. In messaging products, that refusal can be explicit: no phone numbers, no identifiers, and no collection of user data or metadata. Built as a decentralized, onion-routed messaging network, Session represents one of the clearest attempts to carry that logic through in practice. But this creates a harder product question. If a system is designed not to observe its users, how does it still learn enough to improve?

The collaboration between Session and the Interfold explores whether useful analytics can be generated without rebuilding the surveillance model privacy-first systems are meant to avoid.

As part of the Multiplayer Privacy X Space series, Auryn Macmillan of the Interfold and Chris McCabe of Session discussed an active area of collaboration between the two teams: whether useful product analytics can be generated without rebuilding the surveillance model privacy-first systems are meant to avoid.

The conversation began with messaging, but its central question was broader: if a privacy-first app refuses to collect user data, how does it still learn enough to improve?

“We do not want your data at all.”

Privacy-first messaging starts by refusing the usual data model

Chris described Session’s approach in direct terms. The goal was not to collect user data and promise to handle it responsibly, but to avoid holding it in the first place.

That includes metadata, not just message contents. As Chris explained, a service may not read what you say, but it can still learn a great deal from the surrounding pattern: who you message, when, how often, from where, and under what habits.

A recurring point in the conversation was that metadata is not separate from privacy. It is part of the exposure.

The tradeoff is real: better privacy can mean worse visibility

Neither side treated this as free. Auryn pointed to the product cost directly. Once a team gives up the normal stream of user analytics, it also gives up much of the visibility that other products rely on to iterate.

Chris described the consequence in simple terms:

“We’re really blind… we only get what’s reported to us.”

Session hears from users who stay, care, and report problems. What it sees less clearly are the users who hit friction, encounter a bug, or leave quietly. That creates a real product gap.

Auryn added a useful frame for why this is easy to underestimate: privacy often behaves like a threshold feature. People do not reward it as long as it works. They notice it when its absence produces a bad outcome.

“People only care about these features once something has gone wrong.”

Can analytics exist without surveillance?

That is where the Session–Interfold collaboration came into focus.

Auryn described the pilot as an attempt to let users opt into analytics in a way that preserves strong privacy guarantees while still producing useful aggregate insight.

The premise is straightforward: product teams usually do not need each individual data point. They need the result that emerges in aggregate.

“You don’t care about the individual data points themselves. You care about the insight that comes out of the computation.”

The examples discussed were ordinary product questions: how often users open the app, how long it takes from install to first message, where friction appears, and what might be causing silent drop-off.

The underlying question was whether a product can recover a feedback loop without exposing the people who produce it.

Rebuilding the feedback loop

Privacy-first products do not just reject surveillance. They also give up many of the tools other products use to improve. The Session–Interfold collaboration gave that tension a concrete form: whether a product can rebuild a useful feedback loop without returning to the surveillance model it was designed to avoid.