We only set cookies that are strictly necessary to keep you signed in and protect your account. Our usage analytics are self-hosted in the EU, cookieless, and honor Do Not Track — no analytics cookies, no third parties, no cross-site tracking. Learn more.

Skip to content

Security & Privacy Design

Last updated: 2026-08-20

This page describes how Dissidence actually works: what is encrypted, what we hold, what we could be compelled to produce, and how to report a problem. It is written to be checkable, not reassuring — where a protection has a limit, the limit is stated.

1. End-to-end encryption, for every account

Direct messages, group chats, server chat rooms, voice and video calls, shared media in conversations, and personal notes are end-to-end encrypted for every account. There is no opt-in, no plaintext fallback, and no “not set up yet” state — encryption is provisioned automatically when an account is created, and anything that cannot be encrypted is refused rather than sent unprotected. A call that cannot establish an encryption key does not connect.

  • Post-quantum hybrid cryptography: key agreement combines X25519 with ML-KEM-768, and identities are signed with Ed25519 plus ML-DSA-44 (FIPS 203/204). Both layers must be broken to read a message.
  • Single-use message keys in multi-device conversations, and ratcheting group keys that rotate when a member leaves, is removed, or a device is revoked — a removed member or device cannot read what is sent afterwards.
  • Device authenticity: every device key is signed by your account's master identity, verification is fail-closed, and signatures bind the post-quantum keys so they cannot be silently substituted or stripped.
  • Safety numbers let two people verify each other's identities in person; they cover the classical and post-quantum identity keys together.

Community forum posts and comments are public or community-scoped content and are not end-to-end encrypted — that is what makes server-side moderation, search, and feeds possible for them.

2. What we can and cannot read

We cannot read:

  • the content of your messages, calls, conversation media, or personal notes;
  • your encryption keys — the master key is wrapped by a recovery code or passkey that only you hold, and your encrypted history backup is readable only by your own devices.

We do hold, and could be compelled to produce:

  • your account record: email address, username, profile, hashed password;
  • your public and community content (posts, comments, reactions);
  • message ciphertext and its transport metadata: which account sent a message to which conversation, and when;
  • your device list and session records;
  • the IP address and browser of your sign-ins, devices, sessions and uploads, encrypted, for 30 days, after which they are erased automatically. We do not record your location;
  • where content has been reported to the National Center for Missing & Exploited Children, or an account is under a legal hold: the related records, kept for one year from the report as US law requires, or for as long as the hold lasts.

We do not claim metadata privacy we do not have: for ordinary (named) messages the server necessarily knows who is talking to whom, even though it cannot know what is said.

3. Anonymity features, stated honestly

Posting, direct messages, and group participation can be anonymous. The claim these features make is “not recorded”, not “unknowable”:

  • Anonymous group messages are stored with no author at all, delivered under rotating chain labels that name no member.
  • Anonymous 1:1 conversations run through a mediator: for the first 30 days the server holds the link between the conversation and the sender (so abuse can be acted on), then attribution is severed — including from uploaded media and stored IP fields.
  • A server operating live can still observe connection timing and IP addresses; the protection targets stored records, not a real-time observer. The interface warns you when a group's anonymity set is small.
  • An automated audit runs in our test pipeline that fails if any database table links a person to an anonymous message — every new table carrying that shape must be reviewed before it can ship.

4. Moderation without breaking encryption

We cannot scan encrypted content, and we do not. Moderation of encrypted conversations is report-on-discovery: a participant who can already read a message may report it, and their report carries the decrypted evidence from their own device — including the earlier version of a message that was edited after the fact. The accused account is derived server-side from the stored message, so a report cannot frame someone the message did not come from.

5. Infrastructure and jurisdiction

  • Tor onion service: Dissidence is reachable at http://upa6slux3oc3keyhwggxq6joncc52g5dt6knna5hyr42xl4ij5iimeqd.onion — a first-party mirror for people whose network blocks our domain or who prefer not to reveal they are connecting at all. Tor Browser offers it automatically when you visit the regular site. Two honest limits: passkey login and Google sign-in are pinned to the clearnet origin and only work there, and the mirror is served by the same infrastructure — it defeats network blocking and observation, not a seizure of our servers.
  • Application, database, and media servers run in the European Union (Germany), with EU-based providers. We deliberately do not host on US-jurisdiction infrastructure providers.
  • Backups are encrypted before leaving the server (modern public-key file encryption); the decryption identity is kept offline. The off-site media mirror is append-only, so a compromise of the live system cannot silently destroy it. Restores are exercised on a schedule, not assumed.
  • Third-party services we do use, and what they see: Apple and Google push delivery (notification payloads cannot contain message content — the server does not have it), Stripe for payments, the app stores for distribution, an EU CDN for media delivery of encrypted blobs, and Scaleway (France) to deliver the security and account-recovery email described above — it sees your email address and the contents of those messages, which never include message content.
  • The bot check at sign-up, and at sign-in after repeated failures, is a short proof of work that your device solves. Our own servers issue and verify it; nothing about it is sent to anyone else.
  • Usage analytics are self-hosted, cookieless, EU-based, anonymize IP addresses, and honor Do Not Track. Error reporting is self-hosted. Nothing about your usage is sent to a third-party analytics company.

6. Account security

  • Passkeys and two-factor authentication are supported; the recovery code that protects your encryption keys is never stored by us in a recoverable form.
  • Repeated failed logins trigger an adaptive challenge rather than a lockout, and authentication endpoints are rate-limited.
  • You can review and revoke devices and sessions in Settings; revoking a device also rotates the group keys it could read.
  • Email is used for security and account recovery only — we do not send engagement or marketing email.

7. Reporting a vulnerability

Report security issues to security@dissidence.net. We commit to a good-faith response: acting on reports promptly, not pursuing researchers who test in good faith against their own accounts and data, and crediting findings if you want credit. We are an independent project and do not currently run a paid bounty program — we say so here rather than imply otherwise. A machine-readable version of this policy is at /.well-known/security.txt.

Please do not test against other people's accounts or data; use accounts you created for the purpose.

8. Requests from authorities

If we receive legally binding demands, we can only produce what we hold — the list in section 2. We cannot decrypt message content for anyone, including ourselves, and we have designed the anonymity features so that the most sensitive links are not in our records at all. We will challenge or narrow requests where the law allows, and notify affected users where we are legally permitted to do so.

9. Transparency

As of 2026-08-20, Dissidence has received:

  • zero subpoenas, court orders, or warrants for user data;
  • zero government demands of any kind, from any jurisdiction;
  • zero demands accompanied by a gag or secrecy order.

This statement is re-affirmed and re-dated with our releases. If it goes stale or a line above disappears, treat that as meaningful.

Questions about this page: security@dissidence.net. See also our Privacy Policy and Imprint.