Transparency

We believe in honest communication about what Freedom Messenger does and does not protect against. No security marketing — just facts.

What We Protect Against

  • Mass surveillance — your messages are on your server, not on a third-party cloud. No company can scan, sell, or hand over your data in bulk.
  • Network monitoring — all transport modes use TLS encryption. VLESS mode makes your traffic indistinguishable from visits to microsoft.com, even to DPI systems.
  • Brute-force attacks — rate limiting, account lockout, Argon2id hashing, and mandatory 2FA.
  • Credential theft — TOTP-based 2FA means a stolen passphrase alone is not enough to access an account.
  • Metadata leakage from photos — EXIF data is stripped automatically from uploaded images.
  • Domain blocking — Cloudflare mode hides your server behind a CDN. VLESS mode makes your server invisible to censors.

What We Do NOT Protect Against

Honesty matters. Here are the current limitations:

Server Admin Access

The server administrator can access message content. Messages are encrypted at rest with the server's key, but the server decrypts them to deliver them. If you are the admin, this means you have access to all messages. If someone else is the admin, they have access to your messages.

Mitigation: E2E encryption is planned for v2.0 using the Signal Protocol, which will encrypt messages with user keys so not even the server admin can read them.

Server Compromise (Disk Access)

If an attacker gains root access to your server, they can read the master secret from config.toml and decrypt all messages in the database. They can also intercept new messages in real time.

Server Compromise (Live Memory)

Even without disk access, an attacker (or VPS provider, or law enforcement) who can take a live memory snapshot (RAM dump) of a running server can extract the encryption keys from process memory. At-rest encryption does not protect against this attack — the keys must be in memory while the server is running to decrypt messages for delivery.

This is an inherent limitation of any server-side encryption system. It applies equally to all messaging servers that decrypt on the server (including Matrix/Synapse, Mattermost, Rocket.Chat, and any system without E2E encryption).

Mitigation for both: Use strong server passwords, keep the OS updated, restrict SSH access to key-based authentication, and use a reputable VPS provider outside jurisdictions with compelled access. E2E encryption (v2.0) will eliminate both risks — messages will be encrypted with user keys that never exist on the server.

Device Compromise

If an attacker gains access to a user's device, they can read all messages visible to that user. Freedom Messenger does not currently have disappearing messages or screen capture prevention.

Mitigation: Use device encryption, strong device passwords, and biometric locks. Disappearing messages are planned for a future release.

Traffic Analysis

While VLESS mode hides the content of your traffic, an observer can still see that you are sending data to a specific IP address. The timing and volume of traffic could theoretically reveal that you are having a conversation, even if the content is hidden.

Legal Compulsion

If the server is in a jurisdiction where law enforcement can compel you to hand over data, the server admin may be forced to provide access to the master secret and database. Freedom Messenger does not have a "dead man's switch" or warrant canary.

Mitigation: Host in a jurisdiction with strong privacy laws. E2E encryption (v2.0) will make the server content unreadable even if seized.

Our Commitment

  • We will always be honest about limitations
  • We will not use marketing language like "military-grade encryption" or "unhackable"
  • We will clearly mark features that are planned but not yet built
  • We will document our security architecture in detail so it can be audited
  • The codebase is open for review