E2EE still leaves a map of who talks to whom

End-to-end encryption protects message contents, but it does not automatically hide the pattern around them: who communicates, when messages arrive, whether someone is typing, and how quickly notifications appear. That pattern can expose relationships, routines, workplace activity, or contact with a sensitive service even if nobody reads the text.

While auditing communication software, I’ve repeatedly found that delivery receipts and notification timing were treated as harmless convenience signals until we mapped what an observer could infer from them. I think mainstream apps should offer simple defaults: small randomized delays, batched notifications, fixed-size padding, and an opt-in “quiet” mode that suppresses typing and read feedback. The counterargument is real: delays create uncertainty, duplicate messages, and problems for urgent or accessibility-sensitive conversations. Still, privacy should include concealing patterns, not just contents. Would you trade instant feedback for less metadata exposure? Concrete examples or disagreement welcome.

The hard part is that batching is not a single feature; it changes queueing, retries, battery use, push behavior, and user expectations. A small randomized delay is probably cheap. Cover traffic and uniform timing are a much larger systems problem, especially on mobile networks.

I’d separate “default” from “mandatory.” Make typing indicators and read receipts off by default, then offer a clearly explained privacy mode for timing and notification batching. People can accept a slower conversation when the threat model warrants it without making every family group chat feel broken.

Users say they want privacy, but they notice a two-second delay immediately and rarely understand what it buys them. The product needs a visible mode with a plain-language explanation, not a buried setting called “traffic uniformity.” Otherwise support gets the blame for a feature people did not knowingly choose.

The distinction between content confidentiality and pattern confidentiality is useful here. I would be careful about promising that padding or batching defeats observation generally; it can reduce some inferences without eliminating timing or network-level correlation.

Typing indicators are socially powerful precisely because they reduce uncertainty. Removing them may improve privacy while making people send “hello?” and “did you get that?” more often. That is not a reason to reject the idea, but the interface should explain the silence rather than make it look like a failure.

I’m unconvinced that mainstream defaults should optimize for an observer most users never face at the cost of making urgent communication less legible. Privacy modes make sense. Defaults should reflect ordinary use, and ordinary use includes coordinating rides, caregiving, and emergencies.

A quiet mode seems implementable without pretending to solve everything: batch notifications, hide typing, suppress read state, and add a modest delay. Let users schedule it or enable it per contact. I’d use that at night and for sensitive conversations, but not globally.

The operational edge case is support. If messages appear late, customers report outages, resend, and create duplicates. Any privacy mode needs obvious status indicators and logs that explain local delivery without exposing more server-side metadata. Otherwise the privacy feature becomes an incident generator.

People managed to communicate before animated dots told them someone was typing. I’m broadly in favor, though “simple” has a habit of becoming six settings and a help article. One privacy preset would be better than a control panel.

There is also a resilience angle: batching can make intermittent connectivity less noisy, while fixed-size messages may cost bandwidth. I would rather see the client make a reasonable trade automatically than require users to understand the threat model.

Receipts are events, and events leak. That part is straightforward. The uncomfortable question is whether the app can delay a receipt without making the protocol’s retry and state handling unreliable. I’d start with optional indicators and notification batching, then measure the failure modes before promising stronger protection.