Gm Hackers !
In recent post, I presented to you what Operating Systems to use, Browsers and search engine. This time we're going into something that also pertains every internet user and namely the communication 📞
If you did not read my last post, do it before reading that one, by clicking above 😁
Over what channels/apps should you actually communicate anonymously ? This post will cover the essentials to start using more private tech. But before..., I have something relevant to announce
IMPORTANT ANNOUNCEMENT ⚠️
In September 2026, Google plans to officially block any app that does not belong to a developer, who do not have an account in Google Play Developer Console, haven't uploaded their ID there and paid a fee.
From someone who is kind of a normie guy, does not care about the tech, surrounding world and their only worry is about to be right on time to watch their movie in TV, it might sound as a rational argument, they want to prevent android from having malware/spyware/scam-apps on their systems, thus they require their ID and pay the fee for app deployment and demand the apps to be deployed only via Play Store.
Whereas on the other hand, Android natively with google is the biggest malware and spyware together with Microslop OS (known by Normies as Windows).
By default your Google Play Services have access to all your accessories in the phone like camera, microphone and location. So if you do not turn them off, there is more chance your data is gathered, misused and sold. In such way, you are controlled by the technology and not conversely.
Why it matters ?
The opportunity to build, launch your apps on android without needing to pay fees, load your ID to the Third-party company that is prone to frequent breaches and is has the worst products that could be ever given is exactly the normality the user and developer wants to have.
Developers can independently deploy their apps without needing to have any financial commitments or needing to identify themselves to a third-party company.
Think about programmers, youngster coders from African Countries (I have many friends from Nigeria (shout out to all my Nigerian brothers 💚, you're phenomenal hard-workers. I love you all)). Do you think they will have enough money to purchase a subscription and simultaneously keep their life at the standard they have without any external support ?
I truly doubt it, of course for some it would be feasible, but I hear personally how those people are misused and paid slavery-salaries and try to handle somehow the money for another data packages (they do not have wi-fi, you white-trash morron 😘).
Another thing is that the app might not comply with often imaginary Google Play Requirements to push the app to be visible to the Store.
For now, indie mobile app devs simply can attach an .apk to their website/webapp and let users download from there, which is actually a common solution on the internet e.g. for games.
From the other perspective, it also is a violation of freedom of users of phones with custom ROMs like GrapheneOS or LineageOS, but also the average pure android user, that should decide themselves and take the risk on their own where they want to download their apps from, and it should not be estabilished by only-profit driven company, that is seeing the competition in solutions like FDroid and wants to have a monopoly.
When it comes to custom ROM users without default Google Play Services Support, this hits hard, because it basically disables them from using any apps at all, if the update from google comes irl.
Having done this, Google not only dictates you what is the source of your apps but also what OS you should have your mobile device. This is rudiculous and I will not be silent.
Internet should remain free and this is an attack on digital freedom. And this freedom is about to be violated by an enterprise for profit.
There for I gently request you
-- Go to the KeepAndroidOpen website and perform as many action from the site there as you can do.
E.g. Install F-Droid, message your local regulators and inform about the monopoly attempt, Provide feedback directly to Google using their Android developer verification requirements survey, sign the petition.
All action matters, and even if in the end it will be implemented, you should not have any remorse to yourself, because you did something towards stopping it and were not passive.
Therefore I'm requesting you, If you have the account on Google Developer Console, the best decision would be to remove it. Do not upload any IDs if you haven't yet.
Self-confession time
Me myself unfortunately committed back October/November 2024 a failure by uploading the sensitive data to Google, only because I was in a process of building my start-up and wanted to have a greater outreach with my app. That project has been terminated and failed, but the data remained. Thus I recently decided to remove my account from Google Play Developer Console:
Candidly speaking, when I look at how much spam I got to my gmail and how much I get to my private email addresses, 1 gmail outperforms 5 private mail addresses I have.
Spam/Scam mails quantities on my email addresses in one month:
1 Gmail: 257 mails
5 Private Mail: 0 mails
Announcement Summary
That's it from the announcement. Leave a comment down below what actions have you taken and what do you think about it, and now we can head over to the main part of the article !
Messengers
Ok, until now we only discussed the Operating Systems to be used, but this is not all. You would not like your messages to be spied, misused on or be breached, right ?
Thus we need a private communicators. Me myself on a daily basis use variety of communicators, which I really do not like being completely honest. I use:
- Signal (my favorite one)
- Telegram
- SimpleX
- Matrix/Element
From those 5, only 3 are fully reliable when it comes to privacy respecting and that are:
Signal, SimpleX, Matrix
Before I discuss those 3 chat-apps, here is why I did not include Telegram and Whatsapp
Why not Telegram ?
E2EE is NOT default—standard chats are server-side encrypted, meaning Telegram can decrypt them
Custom encryption protocol (MTProto) instead of widely-audited standards like Signal Protocol
IP address leak vulnerability (MTProxy doesn't actually hide IPs as users think)
2024-2026: 200+ million records leaked via various breaches; 122GB credential archive (361M unique emails) distributed across Telegram channels in late 2023/early 2024
2024: Hackers leaked 31M+ Star Health insurance customers' medical data via Telegram bots
2025: 43.5M Telegram channels blocked for illegal activity, but actors just recreate channels within days (low cost to operate)
Why not Whatsapp ?
Meta collects metadata ruthlessly—who you message, when, how often, your contact lists
Meta monetizes this data for ad targeting
November 2025: Researchers at University of Vienna + SBA Research found 3.5 billion WhatsApp accounts via API scraping due to weak rate-limiting. They extracted profile pictures, "about" text, linked devices, OS info. One researcher: "This is a cybercriminal's dream working list."
June 2025: 16 billion credentials breach affecting Facebook/Instagram/WhatsApp (infostealer malware)
Early 2025: Graphite zero-click spyware (Paragon Solutions) targeted ~90 journalists/activists—gave attackers access to encrypted messages, microphone, location
2021: 533M Facebook accounts scraped; 58% still active on WhatsApp in 2025—leaked phone numbers have permanent value
Thus I really wish to move away from using Telegram. Unfortunately a lot of people from the crypto-industry prefer convenience and flashy effects over security and privacy.
Why the others ?
Signal 💙
Encryption: Signal Protocol (Double Ratchet)
ECDH: Curve25519
Message encryption: AES-256-GCM
HMAC: SHA-256
Perfect Forward Secrecy: Yes (every message has unique keys)
Post-Compromise Security: Yes (ratcheting)
Architecture: Centralized servers (Signal Messenger Inc.)
Minimal data collection: No message history, no contact lists stored server-side
Registration: Phone-number based
Multi-device: Supported but uses Sesame protocol
Metadata Protection: Reasonable—server doesn't see message content, but does see phone number, online status, contact discovery
End-to-end encryption is mandatory across all chats
Open-source, regularly audited, nonprofit model
Zero metadata collection unlike WhatsApp—doesn't store who you message or call logs
Post-quantum cryptography roadmap in progress.
Before I move to the next recommendation, I have to explain couple of terms that will actually repeat themselves throughout the article.
Ratcheting - A cryptographic algorithm for dynamical updates of encryption keys to ensure forward secrecy and post-compromise security. This means that even if a key is compromised, past messages remain secure, as new keys are generated for each message exchange.
Double Ratchet - It's an key-management algorithm designed by first Signal's CEO. The feature of this algorithm is that after the initial key-exchange, it handles the ongoing renewal and maintenance of short-lived session keys.
It combines a cryptographic so-called "ratchet" based on the Diffie–Hellman key exchange and a ratchet based on a key derivation function, such as a hash-function, and is therefore called a double ratchet.
Sesame Algorithm - It's an algorithm designed for message encryption sessions management in an asynchronous across multiple devices. It is however vulnerable due to the lack of cryptographic proof of ownership. Which means that if an attacker gains access or intercepts some messages of a victim, it allows the attacker to register their device and gain access to the victim's account.
Forward Secrecy - An encryption system has the property of forward secrecy if plain-text (decrypted) inspection of the data exchange that occurs during key agreement phase of session initiation does not reveal the key that was used to encrypt the remainder of the session.
All is more nicely described by researchers from University of Luebeck.
Now although there is no flaw in a protocol, meaning that it would leak some information, by falling a victim of social engineering, phishing attack or your device being compromised there are no prevention measurements to cease attacker from accessing the account.
SimpleX
Encryption: SimpleX protocol (custom, but well-designed)
Message encryption: ChaCha20-Poly1305 (AEAD)
Key encryption: XChaCha20-Poly1305 (extended nonce for random salt)
Key exchange: Curve448 ECDH
Forward Secrecy: Yes (ratcheting model similar to Signal)
Architecture: Fully decentralized—no central server required
Users run their own SMP (SimpleX Messaging Protocol) relays or use community-hosted ones
Zero-knowledge: SMP relays don't store messages; they're purely transient delivery points
No user accounts: Connections are queue-based, not identity-based—no UIDs linking users to the network
Metadata Protection: Exceptional—even relay operators can't see who's talking to whom
Tor Support: Built-in Tor integration (transport isolation per contact)
Audit: Trail of Bits security assessment (2022, 2024)
The Trade-off: SimpleX prioritizes privacy over convenience. No multi-device sync yet, no cloud backups, slower message delivery.
But this is intentional—they refuse the push-notification trap that other apps use.
Matrix/Element
Encryption: Olm + Megolm
1-to-1: Olm (Double Ratchet variant, similar to Signal Protocol)
ECDH: Curve25519
Message encryption: AES-256-CBC (non-standard; should be GCM or
ChaCha20-Poly1305)
HMAC: SHA-256
Group chats: Megolm (sender-key model)
Session key: AES-256
Ratcheting: Weaker than 1-to-1; Forward secrecy limited by key reuse
Architecture: Federated—users can run their own home-server
Protocol is open, but implementations vary in security
Default E2EE: Yes
Key Backup Vulnerability: Server-side encrypted key backups can be exploited if home-server is malicious
Metadata: Partially exposed (room names, user IDs, member lists visible to homeserver)
Other worth-mentioning messengers
There also other emerging private messengers that are worth to be paid attention to, namely NCrypt and also Sealed. Both are blockchain focused, and the messages are stored on blockchain at least in Sealed.
Here are some information about Sealed and NCrypt I could find in their privacy policy and on the internet.
Sealed
What Sealed Actually Is (The Honest Technical Take) ?
Sealed is a blockchain-based, end-to-end encrypted messaging app built on a three-tier data architecture. Unlike most messengers that centralize everything on company servers, Sealed explicitly separates data into three distinct realms, each with different controllers. This is the critical design choice that sets it apart.
The app is currently live on iOS and Android, operating on Algorand. The foundational principle is brutal: no single party—not even Sealed's operators—has full control over all your data. That's architecturally honest in a way Signal and Telegram aren't.
The Three Data Realms: How the Architecture Actually Works
Realm A: Your Device (You Alone Control This)
Everything that matters cryptographically stays on your device. Your BIP39 seed phrase, your Ed25519 wallet signing key, your X25519 encryption keypair, and all decrypted message content lives exclusively in your device's secure enclave—iOS Keychain or Android Keystore. There is no recovery mechanism. If you lose your device without a seed phrase backup, your account is gone permanently. Sealed cannot recover it, nor can any authority compel them to.
Your contact list (wallet addresses plus usernames) also stays local. The implication here is clear: Sealed has zero visibility into your social graph. They can't tell who you're talking to, how often, or in what pattern.
Realm B: The Public Blockchain (No One Controls This)
Every message you send goes onto a public blockchain as an immutable transaction. This is where the privacy model gets interesting.
Messages are stored as AES-256-GCM encrypted ciphertext—unreadable without your private key. But the blockchain stores more than just content. Each message includes an ephemeral sender public key (a one-time X25519 key per message, not your permanent identity), a 32-byte HMAC recipient tag used for "stealth addressing," the block-level timestamp, and your sender wallet public key (your pseudonymous identity).
Here's the friction: if you register a human-readable username, that gets written to the blockchain permanently. This is where anonymity breaks if you're not careful. Register as "john_crypto_banker" and link your Twitter, and the pseudonymity collapses. But if you stay wallet-address-only, the blockchain sees only a pubkey, not a name.
The critical point: blockchain data is permanent and immutable. No deletion rights apply. You cannot request removal. An observer can see that a message was sent to a particular wallet address at a particular time, and if encrypted properly, they cannot read it. But the metadata—that a message exists, when it was sent, and who the recipient pseudonymous identity is—that's forever.
Realm C: The Indexer Server (Sealed Controls This, With Guardrails)
This is where Sealed takes a calculated privacy trade-off. To deliver push notifications and enable efficient message sync, they operate an indexer server that stores limited data:
- Your wallet public address (for identity and auth)
- Your X25519 view key (this is the big one—see below)
- SHA-256 hash of your view key
- Firebase Cloud Messaging token (for push delivery)
- Device platform identifier (iOS or Android)
- Optional username
- Message metadata pointers (blockchain transaction references for sync, not content)
- Last seen timestamp
- IP address (standard server logging)
The view key is the most significant privacy tradeoff and Sealed is honest about it. Your X25519 scan/view private key is shared with their indexer server. This allows the server to detect incoming messages addressed to you on-chain and trigger push notifications. The view key does not decrypt content—that's a separate key path. The view key only reveals that a message was sent to you, not what it says.
This is crucial: if Sealed's indexer is compromised, attackers learn who's messaging you. But they don't learn what was said. Content requires your full private key, which never leaves your device.
Retention is clear: indexer data expires after 90 days of inactivity. Message metadata expires after 30 days. IP logs rotate per standard practice (7–30 days). You can manually delete your account at any time with a signed deletion request, and they'll purge the view key and FCM token within 30 days.
Authentication: No Phone Number, No Email, No Password
Sealed uses pure wallet-based authentication. When you log in, your app signs a time-limited challenge string with your Ed25519 wallet private key. The signing key never leaves your device. This means there's no email-based password reset, no SIM-swap attack surface, no centralized identity store. You are your keys.
The tradeoff: if you lose both your device and your seed phrase, you're locked out forever. There's no "I forgot my password" recovery. This is hardcore, but it's the price of true key custody.
Encryption Details: Where Sealed Gets Technical
Message content uses AES-256-GCM with per-message ephemeral keys. The key derivation path is X25519 (ECDH) + HKDF, which is industry standard. Messages are padded to a uniform 1,024 bytes before encryption to prevent length-inference attacks—a sophisticated move that prevents attackers from guessing message type based on ciphertext size.
The ephemeral key per message is the Double Ratchet-adjacent concept: each message has a unique encryption key. This gives forward secrecy—if one key is compromised, only that one message is exposed, not past or future ones.
The roadmap includes ML-KEM-512 (Kyber-512) as a hybrid post-quantum layer on top of X25519. This is planned but not yet deployed. Currently Sealed is quantum-vulnerable, like all classical asymmetric crypto.
API communication to the indexer uses Ed25519 signature-based authentication with signed time-limited nonces, enforced over HTTPS/TLS. The server implements helmet security headers and rate limiting (100 requests/minute per IP).
What Sealed Does NOT Collect (The Important Negatives)
This is where Sealed differs sharply from WhatsApp, Telegram, and especially Messenger:
- No real name
- No email address
- No phone number
- No device contacts imported
- No location data
- No advertising identifiers (IDFA/GAID)
- No biometric data
- No analytics or behavioral tracking
- No crash reports or telemetry beyond server-side operational logs
This is a stark contrast to Signal, which collects your phone number and uses it as your identity. Sealed's wallet-first model means they have no way to know who you are unless you tell them.
Third-Party Dependencies: Where Trust Matters
Sealed uses only two external services:
Google Firebase Cloud Messaging (FCM): For push notifications. Sealed sends Firebase only your FCM device token and a notification payload containing the sender's wallet address and a message reference—not the message content. This means Google sees that you received a message from a particular wallet, but not what was said. Google's privacy policy applies to this data.
AlgoNode (Algorand RPC): A third-party public Algorand node. Transactions you broadcast are globally visible by nature. No personal identifying data beyond your wallet address and encrypted message ciphertext is transmitted.
Sealed explicitly does not use advertising networks, analytics platforms, or data brokers. This is a hard line.
The Privacy Model: Honest About Tradeoffs
Sealed is architected for a specific threat model: you want encryption that no single entity can break, pseudonymity rather than anonymity, and no central server controlling your social graph.
If your threat is a government subpoena, Sealed has a clean answer: indexer data expires, blockchain data is public, and Sealed cannot hand over decrypted messages because they don't have your private key. The police would need your device or seed phrase.
If your threat is Sealed itself, you get a partial win: Sealed cannot read your messages, but they can see who's messaging you (via the view key). If you're concerned about this, you should assume the view key is compromised.
If your threat is length-based message inference, Sealed padded messages to 1,024 bytes, so attackers can't guess what you're saying based on ciphertext size.
If your threat is quantum computers, you're vulnerable until they deploy Kyber-512.
The Uncomfortable Realities
Realm B is permanent: Anything you write to the blockchain stays forever. If you message someone's wallet address, that metadata (sender, recipient, timestamp, message reference) is immutable. In a world of blockchain analysis and wallet clustering, this is a permanent link. Sealed can't delete it, and neither can you.
The view key is a vulnerability: It's the single point where Sealed can learn your incoming message graph. If the indexer is breached, attackers get a list of everyone messaging you. Sealed is transparent about this, but it's still the biggest attack surface in the architecture.
Usernames break pseudonymity: If you register a human-readable name, it's on-chain forever. Anyone can link your wallet to your identity. Sealed can't prevent this; it's a user error problem.
Firebase adds a Google dependency: FCM tokens reveal to Google that you're using Sealed, and when you receive messages. Google's privacy standards are better than most, but it's still a third party with visibility.
No audit: The privacy policy doesn't mention any independent security audit. The encryption primitives (AES-256-GCM, X25519, HKDF) are solid, but there's no third-party verification that the implementation is correct.
How This Compares to the earlier mentioned ones ?
Sealed is architecturally more honest than Signal or SimpleX about what data they hold and why. Signal doesn't explain its data architecture; they just say "we don't store messages." Sealed breaks it down into three realms and explains the controller for each.
Sealed is less mature than Signal (which has been battle-tested for a decade) and less audited than SimpleX (which had Trail of Bits assessment).
Sealed is more decentralized than Telegram (which holds all data server-side) but less decentralized than Element (which is federated) or SimpleX (which has no central relays—queues are ephemeral).
Sealed is more private than WhatsApp or Messenger because it doesn't collect phone numbers, emails, or contact graphs.
NCrypt (Gen6 Dapp)
NCrypt is a decentralized messaging app built as part of the Gen6 ecosystem. It's E2EE messaging integrated with Gen6's decentralized identity system (Gen6.Me). Messages are encrypted, transmitted through Gen6 validator nodes, and stored on the Gen6 blockchain.
The Technical Stack:
Blockchain: Gen6's own chain (Enhanced Proof-of-Authority consensus)
Validator Network: 100+ distributed validators securing the chain
Identity Layer: Gen6.Me (verified, pseudonymous, or fully private)
Encryption: Not explicitly stated, but likely AES-256 or ChaCha20-Poly1305 (industry standard)
Storage: Encrypted messages on Gen6 blockchain
Roadmap: Q4 2026 includes post-quantum security upgrade
Integration with Gen6 Ecosystem:
NCrypt isn't standalone—it's one dApp in a larger system:
RealSeal: On-chain cryptographic signing and timestamping
Gen6.Me: Verifiable identity (proof-of-attendance, credentials)
FONO: Event verification and community management
GSX Token: Utility token for transaction fees and ecosystem incentives
The Reality Check:
NCrypt is more honest but less audited than it claims:
No independent security audit — Gen6 was founded by security experts (David Pethes, Sergey Gerodes) but that's not a substitute for third-party audit.
Validator-dependent privacy — Your messages go through Gen6 validators. If a validator node is compromised, they see metadata (though not content if encryption is solid)
Identity is optional but integrated — You can be pseudonymous, but the whole ecosystem incentivizes verified identity (which is good for trust, bad for pure privacy)
Post-quantum still in roadmap — They're targeting Q4 2026; currently quantum-vulnerable like most messengers.
Smaller community — ~30,000 users vs millions for Signal. Smaller attack surface, but also less battle-testing.
Emails
Alright forwards we go ! We have now private OS, Private Browser, so we reduced successfully amount of spyware on our day-to-day activity on the internet. We keep our messages secure, by using Signal or SimpleX, but what if we want to receive mails and send mails in a more private way ? For that there is also a couple of solutions and for that I highly recommend checking out the Privacy Savvy article. I think this blog is a huge source of knowledge when it comes to privacy (So shout out to them :D):
- ProtonMail
- TutaMail
- StartMail
- MailFence
- AtomicMail
Tuta (formerly Tutanota) – Most Privacy-Focused
Server Location: Germany 🇩🇪
Founded: 2011
Business Model: Private company, no outside investors, subscription-based
Free Tier: Yes (very limited)
Privacy Tech Stack
Tuta's doing it right here. They encrypt everything – emails, subject lines, calendar events, contacts. Most providers skip subject lines (that's a metadata vector), but Tuta's like "nah." They've implemented TutaCrypt, a proprietary hybrid system using:
CRYSTALS-Kyber (post-quantum key exchange) + X25519
AES encryption for content Zero-access architecture – they literally can't read your stuff, even if they wanted to.
They don't use PGP (which has known weaknesses), so no pulling of Google Play services like ProtonMail does.
Government Interventions & Data Compliance
No major data breaches on record.
Transparency Report (Jan-Dec 2025):
Received: 389 total requests from German courts
Complied: Only ~75 cases out of ~389 (they rejected 75% of requests)
Key insight: Tuta can only be compelled by German courts under German law. No backdoors, no FISA orders ever received. They publish a warrant canary confirming this.
What they CAN release: Metadata (sender/receiver emails, timestamps, IPs), NOT encrypted content
Notable incident (2019-2021): A German court tried to force Tuta to capture unencrypted incoming emails before they encrypted them – essentially creating a backdoor.
Tuta appealed, saying this violates German law. Court still ordered it, but Tuta refused to implement system-wide monitoring, only complying for specific cases. They appealed to German Federal Court and stood firm. No data was handed over that compromised encryption.
False Accusations (2023): A former Canadian RCMP officer claimed Tuta was a "storefront" for Five Eyes intel agencies. Completely false. Tuta denied it, published their entire codebase on GitHub for peer review, and pointed out they've zero FISA orders.
Availability 📲
They support mobile apps for android and IOS, they have also proton mail desktop app but this one is paid and is available for Linux, windows and IOS.
Free Tier Details
Storage: ~1 GB
Aliases: 15-30 depending on plan
Accounts deleted after 6 months inactivity (this is intentional for privacy – they don't want ghost data)
Support: Forum-only for free users
Custom domain: No
IMAP: Not supported (design choice, not a limitation)
ProtonMail
Server Location: Switzerland 🇨🇭
Founded: 2013
Business Model: NOT a non-profit – it's a for-profit company funded by investors. This matters because pressure to monetize is real.
Free Tier: Yes (extremely limited)
Privacy Tech Stack
End-to-end encryption for user-to-user emails (between ProtonMail accounts)
Zero-access encryption – they encrypt with your public key, can't decrypt
AES encryption for storage - Supports PGP for external recipients (standard, but not as comprehensive as Tuta's approach)
Does NOT encrypt subject lines – metadata leakage
Uses Google Play Services on Android (Tuta doesn't)
Government Interventions & Data Sharing – THIS IS CRITICAL
Confirmed data breaches to law enforcement:
2021 French Climate Activist Case:
French police obtained ProtonMail user's IP address via Swiss legal channels. Activist was identified and arrested.
ProtonMail did comply – they had no "legal possibility to appeal"
2022-2023 FBI Case:
FBI obtained recovery email address and phone number from ProtonMail
User in US harassment investigation was de-anonymized
Again, ProtonMail complied
Transparency Report (2022):
5,957 data requests received
Complied with significant portion – they don't break down exact numbers clearly.
They contest requests they can legally contest (~750 in 2022), but they will hand over metadata if Swiss courts order it
The Real Talk: ProtonMail markets itself with "Swiss privacy laws" but:
They can be legally compelled to enable real-time IP logging for specific users
They will share recovery emails, phone numbers, payment info, IP addresses
Swiss courts work with other governments – their "strict Swiss law" claim is marketing BS
They have secondary offices in the US, which complicates jurisdiction
No warrant canary. They don't publish a statement saying they've never received FISA orders (unlike Tuta).
Availability 📲
They support PWAs, mobile apps for android and IOS, they have also proton mail desktop app but this one is paid and is available for Linux, windows and IOS.
Free Tier Details
Storage: 500 MB (brutally limited)
1 email address only
No folders (can't organize)
Limited sending (cap per day)
Paid plans start at $4.99/month – one of the most expensive
To me proton is like "private google", as they are the most well known company and the most visible (advertised) one, that provides private mail services and generally cloud-services as well.
MailFence
Server Location: Belgium 🇧🇪
Founded: 2013
Business Model: Subscription-based
Free Tier: Yes (limited)
Privacy Tech Stack
OpenPGP encryption (industry standard, not proprietary)
Encrypts emails, calendar, contacts
Zero-knowledge architecture
IMAP/SMTP support (unlike Tuta, easier migration)
Belgian servers under GDPR
Government Interventions
No major breaches reported.
Mailfence doesn't publish as detailed a transparency report as Tuta or ProtonMail, but they're transparent about responding to valid Belgian court orders and cannot decrypt encrypted content.
Availability 📲
They support only PWAs and mobile apps for android and IOS.
Free Tier Details
Storage: 500 MB
1 email address
Limited folders
Paid plans start at €2.75/month (cheaper than Proton)
StartMail
Server Location: Netherlands 🇳🇱
Founded: 2013
Business Model: Subscription (no free plan)
Free Tier: No (7-day trial only)
Privacy Tech Stack
OpenPGP encryption (standard)
IMAP/SMTP support (great for external clients)
Dutch servers under GDPR
Unlimited aliases even on base plans
Government Interventions
Netherlands has reasonable privacy laws, but they can be compelled by Dutch courts. No major incidents reported.
Pricing
Starts at $5-7/month (no free option, disqualifying for your "free only" requirement)
Honorable Mentions (Active but Limited Free Tiers)
Atomic Mail – The New Kid on the Block
Founded: 2024
Server Location: Germany
Free Tier: Yes (generous – unlimited storage, rare for new providers)
Availability 📲
They have only a PWA support, so you can see the icon of them and it will bring you to your mail in browser, which I find cool and I really appreciate them to implement PWA.
Very new, so limited track record
Claims to have passed 1M users in <1 year
Offers unlimited storage free (vs. competitors' 500 MB-1 GB)
No security incidents yet (new service)
Cons: In beta, unproven long-term
Atomic Mail (The Underdog 🐶)
Location: Headquarters in Estonia 🇪🇪, Servers in Germany 🇩🇪
Founded: 2024 (launched by a team of privacy advocates and cybersecurity engineers)
Company Structure: AtomicMail Systems OÜ (private company, not a non-profit)
Current Status: Beta release (actively in development, iterating fast)
Growth Rate: Hit 1 million users in <1 year (straight up aggressive expansion)
Privacy & Encryption Tech Stack
Core Encryption Primitives:
ECIES (Elliptic Curve Integrated Encryption Scheme) – Asymmetric key exchange between Atomic users. Fast, modern, not some legacy PGP garbage.
AES-256 – Symmetric content encryption (industry standard, trusted by security researchers globally)
SHA-256 – Cryptographic hashing for data integrity verification
TLS 1.3 – In-transit encryption (TLS 1.2 is dated, they went for the newest standard)
BIP39 seed phrases – THIS IS THE CRYPTO TOUCH. Users recover accounts with a 12-word seed phrase (like a blockchain wallet), NOT a phone number or backup email. That's genuinely novel for email. No five-eyes backdoor through phone carriers.
Zero-Access Architecture (The Real Deal):
Here's the trick – Atomic Mail uses a client-side encryption model:
Client encrypts before upload – Your plaintext message is encrypted on YOUR device
Server only sees ciphertext – It gets transmitted and stored as meaningless scrambled data
Only recipient decrypts – Private keys never leave your device
Atomic Mail literally can't read encrypted messages – Even if hackers breach them, or a government issues a court order, the data is mathematically useless without your private key
This is fundamentally different from ProtonMail (which CAN decrypt if forced) because the architecture prevents them from having the keys in the first place.
Data-at-Rest + Data-in-Transit Protection:
All emails encrypted at rest (AES-256)
All communication encrypted in transit (TLS 1.3)
7-day log retention for IP addresses and SMTP metadata (troubleshooting + spam/phishing detection). Logs auto-delete after 7 days.
User vault storage – All messages sit in encrypted user vaults on secure servers.
Government Compliance & Legal Requests
Atomic Mail's Policy (From Official Privacy Policy, Last Updated: March 3, 2026):
"We will only comply with requests from Estonian judicial authorities and will not honor requests from other authorities. Atomic Mail does not cooperate with voluntary surveillance programs."
So only Estonian courts can force Atomic Mail to comply
No FBI, no GCHQ, no Five Eyes – They explicitly refuse non-Estonian requests. No secret surveillance programs – No FISA, no Tempora, no bulk metadata tapping.
Real-World Application:
If a US court demands data on an Atomic Mail user, Atomic Mail's legal stance is: "Get an Estonian court order or nothing happens." Since the US and Estonia don't have an automatic data-sharing treaty that works like that, this is effectively a firewall.
Third-Party Requests:
"We will not comply with requests for user information from private third parties unless we receive a valid court order from an Estonian court."
So even if Facebook or your ex's lawyer demands user data – no way. Only Estonian courts.
Data Breach History
As of April 2026: ZERO confirmed security incidents or data breaches on record.
Why does this matter?
They're new enough (founded 2024) that they haven't had time to accumulate the baggage of older providers.
Their encryption design means even if they were breached, attackers get useless ciphertext.
They practice extreme data minimization – less data = less to leak
Comparison: Tuta (been around since 2011) has no breaches. ProtonMail has complied with government data requests multiple times and handed over metadata. Atomic Mail's track record is clean, and the architecture prevents worst-case scenarios.
Unique Features (The Tech Deep Dive)
1. Seed Phrase Recovery (Borrowed from Crypto)
Instead of:
SMS OTP (SIM swap vulnerable)
Recovery email (metadata leakage)
Secret questions (brutalizable)
Atomic Mail uses BIP39-compliant seed phrases – a 12-word mnemonic that only you hold. Even Atomic Mail's admins can't reset your password. This is inspired by blockchain wallet design (think MetaMask, hardware wallets).
Why it matters: No phone carrier backdoor, no recovery email dependency, mathematically sound.
2. Multiple Encryption Options for External Recipients
Can't encrypt to Gmail users with ECIES (they're not on Atomic).
Solutions:
Password-Protected Email – Send encrypted message, recipient enters password
Encrypted as File – Send encrypted .zip file via any channel
TLS – Standard in-transit encryption (basic, but better than plaintext)
3. AI Suite (Privacy-First)
The Plus plan includes AI tools:
Writing assistant
Grammar checker
Summarizer
Translator
Security Helper (flags sensitive content in drafts, suggests encryption)
Text-to-voice
Critical: These AI tools can only process unencrypted drafts. They can't touch your encrypted emails. Zero training data on user messages.
4. Anonymous Email Aliases
Create up to 10 free unique email addresses from one account. Use them for:
Newsletter signups (throwaway)
Financial accounts (separate identity)
Work vs. personal (compartmentalization)
If one alias gets compromised in a data breach, you know exactly which service leaked it, and you can nuke that alias without affecting your main inbox.
5. Availability 📲
They have for now available apps for IOS, Android, MacOS and Windows. What actually surprised me that they do not have a linux version yet and I really would love to have one. What is yet disappointing to me is that they do not support PWA, so I can have an icon on my screen for quicker access.
To be honest I have the account on 3 of the mails provided Tuta, Atomic Mail and Proton and atomic mail appears to become my favorite mail from them all. Their UI is slick, they have nice privacy policy. Surely it's yet quite young but I root for them to have even a billion users.
Summary
This is 2/8 of our privacy journey, I hope you enjoyed it this time and I convinced you to switch over to any of either Messengers or Mail Providers.
Let me know down in the comments. In the next post there will be more info on AI and payments. I rearranged the order with Firewalls and VPNs, because I'm almost done with full research on this part.
So stay tuned because things might get much more interesting in the future than before and I will have surprise for you.
Don't forget to leave like 💜 and follow my account for more privacy-focused content. Also please share the article with your fellows (devs) or family to spread more awareness on privacy in the internet.
That's it for today, hope you'll have a great time and until next time.
Cheerio !
Top comments (0)