Should encrypted messengers hide the small signals by default?

End-to-end encryption protects message contents, but typing indicators, read receipts, and precise timestamps still expose a surprising amount of behavioral metadata: when someone is awake, who answers quickly, and whether an exchange feels urgent. I’ve caught myself checking the gap between “read” and a reply and assigning meaning to it, even when I knew that was probably unfair.

Signal at least makes typing indicators and read receipts optional, with both sides involved, and shows timing details locally. I wonder whether the safer default is coarser time buckets, local-only indicators, configurable disclosure delays, or privacy-preserving batching. Real-time presence can still matter for accessibility and coordination, so disabling everything universally seems too blunt. Should metadata controls be granular user settings, privacy-safe defaults, or both? I’d like to hear about implementations and strong counterarguments.

The distinction between “can reveal” and “does reveal” matters here. Timing may support inferences about availability or importance, but the inference is context-dependent. I’d support safer defaults, provided the interface explains what changes rather than presenting privacy as a binary switch.

I’d avoid pretending coarse buckets are free. They add state, synchronization rules, edge cases, and probably confusing behavior when clients reconnect. A local-only composing indicator is cleaner: useful to the sender, not broadcast to the recipient. That seems like the best first experiment.

The product problem is that these cues became social promises. Remove them and users may assume the app is unreliable, not private. A per-contact setting plus a simple “quiet mode” might be more adoptable than a universal privacy-safe default that nobody understands.

Exactly. Once a cue exists, people build etiquette around it. “Seen” becomes an obligation, and typing becomes a tiny performance of availability. Defaults matter because most people will never revisit the settings, but the escape hatch needs to be obvious and reversible.

The accessibility point deserves careful wording. There is good general evidence that people use different input methods and may need extra time, but that does not establish that typing indicators themselves are necessary. I’d frame them as potentially useful coordination aids, not accessibility requirements.

Threat-model question: who are we hiding this from? A casual contact, a stalker, an employer, or a network observer? These controls mainly reduce recipient-visible signals; they do not magically erase all timing information from every system involved. Still worthwhile, just narrower than “metadata privacy.”

Local-only indicators fit the local-first principle nicely. The composer can show “you are typing” without publishing that state. For shared coordination, users could explicitly send a presence update that expires, rather than leaking presence continuously as a side effect of writing.

In support and incident work, real-time cues can prevent duplicate effort: someone knows another person has seen the handoff. But we usually need a deliberate acknowledgement, not a permanent trail of micro-events. An expiring “I’m handling this” status might be more honest than read receipts.

I’m not convinced defaults should optimize for the most privacy-sensitive interpretation. Some people genuinely use response timing to coordinate childcare, transport, or urgent work. Make the controls granular, explain the tradeoff, and let users choose per conversation. Privacy-safe defaults can become socially costly defaults.

A configurable delay seems practical: show typing only after, say, a user-selected interval, or batch several state changes into one update. I’d want the delay to be randomized enough that it doesn’t simply become another precise signal. Not elegant, but probably shippable.

The old answer was simple: send the message when it is ready. We added a live telemetry feed for ordinary conversation and then act surprised that it became etiquette. Defaults should stop broadcasting by default; exceptions can be turned on by people who need them.

For organizations, configurability is unavoidable. Different teams have different coordination and retention expectations, and accessibility review will ask different questions from a security review. I’d want documented policy controls plus user-level overrides where appropriate, not one global answer.

Precise timestamps are the easiest thing to fix because they’re mostly a display choice. Store or transmit less precision where possible, then let the client render a bucket. Typing and read state are harder because they’re live protocol events, so I’d tackle them separately.

Customers often interpret missing receipts as a bug, especially when coordinating appointments. I’d keep an explicit “available now” mode for people who want it, but make ordinary chats quiet by default. The key is making the difference visible without shaming either choice.