I’m not using EncroGram because I like clean UI or new apps. I’m using it because I assume that sooner or later, anything I touch might be examined — devices, servers, logs, timelines.
Most messaging apps focus on encrypting content. That’s table stakes now. What matters in practice is everything around the content: identifiers, metadata, backups, correlations, and the quiet assumptions built into the system.
EncroGram caught my attention because it seems to start from a different premise: reduce what exists in the first place. No accounts tied to phone numbers or emails. No analytics. No long-term server-side message storage by design. Fewer moving parts, fewer promises, fewer things to trust.
I’m not under the illusion that this makes communication safe or anonymous. Devices get seized. Networks get monitored. People make mistakes. Nothing here changes that. What it changes, at least in theory, is how much residual data is created by default, and how much of that data lives outside the endpoint.
From my point of view, that’s the real question: not “is it secure?”, but “what’s left behind when things go wrong?”
This doesn’t feel like a mainstream product, and it probably shouldn’t be. It feels more like an experiment in being explicit about trade-offs and threat models instead of hiding them behind UX polish and legal language.
I’m posting this because I’m interested in technical criticism and discussion. Where does a low-retention or stateless approach actually help, and where does it fail? What assumptions does it still rely on that users like me might underestimate?
Not here to promote it — just interested in informed perspectives on the design choices.
0 comments
—
Show HN: EncroGram – Messaging When You Assume Everything Will Be Looked At · HackerTrans
I’m not using EncroGram because I like clean UI or new apps. I’m using it because I assume that sooner or later, anything I touch might be examined — devices, servers, logs, timelines.
Most messaging apps focus on encrypting content. That’s table stakes now. What matters in practice is everything around the content: identifiers, metadata, backups, correlations, and the quiet assumptions built into the system.
EncroGram caught my attention because it seems to start from a different premise: reduce what exists in the first place. No accounts tied to phone numbers or emails. No analytics. No long-term server-side message storage by design. Fewer moving parts, fewer promises, fewer things to trust.
I’m not under the illusion that this makes communication safe or anonymous. Devices get seized. Networks get monitored. People make mistakes. Nothing here changes that. What it changes, at least in theory, is how much residual data is created by default, and how much of that data lives outside the endpoint.
From my point of view, that’s the real question: not “is it secure?”, but “what’s left behind when things go wrong?”
This doesn’t feel like a mainstream product, and it probably shouldn’t be. It feels more like an experiment in being explicit about trade-offs and threat models instead of hiding them behind UX polish and legal language.
I’m posting this because I’m interested in technical criticism and discussion. Where does a low-retention or stateless approach actually help, and where does it fail? What assumptions does it still rely on that users like me might underestimate?
Not here to promote it — just interested in informed perspectives on the design choices.