Privacy Tools Guide

For activist organizations, Matrix with Synapse (self-hosted) provides the best balance of security, privacy, and coordination features—it’s decentralized, supports end-to-end encryption, offers strong access controls, and gives you complete infrastructure control. Alternative: use Signal’s Group Messaging if preferring managed simplicity over self-hosting, though Signal doesn’t allow self-hosting. Configure your chosen platform with mandatory end-to-end encryption, strong access controls, and regular security audits.

Threat Modeling for Group Communications

Before selecting tools, define your threat model. Consider these attack vectors:

  1. Metadata collection — Who knows you communicated, when, and with whom
  2. Content interception — Reading message contents without decryption keys
  3. Device compromise — Physical or software-based device takeovers
  4. Social engineering — SIM swapping, phishing, or coerced key disclosure
  5. Server-side attacks — Homeserver breaches or subpoenas

Different tools address these threats differently. No single solution provides perfect security, but layered approaches reduce your attack surface significantly.

Threat modeling is not a one-time activity. As your organization grows and as the political environment changes, revisit your model. A group facing low-level online harassment has different requirements than one operating in a country with active surveillance of civil society. Start with a realistic assessment of who your likely adversaries are and what capabilities they have, then choose tools accordingly.

Self-Hosted Option: Matrix with Synapse

Matrix provides the most flexible option for organizations wanting infrastructure control. The protocol supports end-to-end encryption (E2EE) via the Olm and Megolm encryption protocols.

Deploying Synapse with Docker

# docker-compose.yml for Synapse homeserver
version: '3'
services:
  synapse:
    image: matrixdotorg/synapse:latest
    container_name: synapse
    volumes:
      - ./synapse:/data
    ports:
      - "8008:8008"
      - "8448:8448"
    environment:
      - SYNAPSE_SERVER_NAME=chat.yourorg.org
      - SYNAPSE_REPORT_STATS=no
    restart: unless-stopped

Generate your configuration:

docker run -it --rm -v ./synapse:/data -e SYNAPSE_SERVER_NAME=chat.yourorg.org matrixdotorg/synapse:latest generate

Hardening Synapse for Activist Use

The default Synapse configuration is suitable for general deployments but needs hardening for sensitive activist work. Edit the generated homeserver.yaml:

# Disable public registration — invite-only
enable_registration: false
registration_requires_token: true

# Restrict room directory visibility
enable_room_list_search: false

# Limit federation to trusted servers only
federation_domain_whitelist:
  - yourorg.org

# Require users to be verified before sending messages
require_auth_for_profile_requests: true

Disabling open federation is particularly important. By default, Matrix rooms can federate across servers, meaning users from other homeservers can join your rooms if invited. For internal activist communication, limit federation to your own server or a small set of trusted partner servers.

Creating Encrypted Rooms

Once Element (the Matrix client) connects to your homeserver, create rooms with proper encryption settings:

  1. Create a new room in Element
  2. Access Room Settings → Security & Privacy
  3. Enable “End-to-end encryption” for this room
  4. Set “Who can read history” to “Members only (since joining)”
  5. Disable “Allow guests” entirely

For sensitive rooms, implement the following room configuration:

# Advanced: Set via Admin API
POST /_matrix/client/r0/admin/rooms/{room_id}/state/m.room.encryption
{
  "algorithm": "m.megolm.v1.aes-sha2",
  "rotation_period_ms": 604800000,
  "rotation_period_msgs": 100
}

This configuration rotates encryption keys weekly or after 100 messages, limiting the exposure if keys are compromised.

Backing Up Your Homeserver

A self-hosted server that goes down takes your communication history with it. Implement regular backups of both the database and media store:

# Backup PostgreSQL database
pg_dump -U synapse synapse > synapse_backup_$(date +%Y%m%d).sql

# Backup media store
tar -czf synapse_media_$(date +%Y%m%d).tar.gz /path/to/synapse/media_store/

# Encrypt backup before storing offsite
gpg --symmetric --cipher-algo AES256 synapse_backup_$(date +%Y%m%d).sql

Store encrypted backups at a location independent of your primary server. If the server is seized or goes offline, having recent backups means you can restore to a new instance quickly.

Signal Group Chats

For organizations preferring managed solutions, Signal provides group encryption. Each group uses Sender Keys, allowing efficient many-to-many communication without the overhead of pairwise encryption.

Signal Group Security Features

Configure disappearing messages via the UI or for organizations managing multiple devices, use the Signal API:

# Signal API: Update disappearing messages timer
import signal_api

client = signal_api.Client("+1234567890", "your-registration-id")
group_id = "group-id-from-signal"
duration_seconds = 3600  # 1 hour

client.update_group_timer(group_id, duration_seconds)

Signal’s limitation for organizations is that it requires a phone number for registration, which creates a link between your communications identity and your phone account. In jurisdictions where carriers cooperate with authorities, this can be a meaningful risk factor.

Session Messenger: Decentralized Alternative

Session operates on the Signal protocol but routes traffic through onion nodes, providing metadata resistance without requiring phone numbers.

Session Group Setup

  1. Install Session (available on iOS, Android, and desktop)
  2. Create an account (no phone number required)
  3. Generate a recovery phrase — store this securely offline
  4. Create a new group and share the invite link

Session’s routing through Lokinet provides anonymity properties unavailable in traditional messaging apps. The trade-off is slightly higher latency and no phone-number-based contact discovery. For new members joining your organization, this means you need an out-of-band way to share your Session ID — a meeting in person or through a separate secure channel.

Briar: Offline-First Encrypted Messaging

For organizations operating in connectivity-restricted environments, Briar provides mesh networking via Bluetooth and Wi-Fi Direct.

Briar Deployment Considerations

Briar differs fundamentally from server-based solutions:

To maximize Briar’s utility in activist contexts:

  1. Pre-install on devices before operations
  2. Establish regular “sync meetups” at safe locations
  3. Use Bluetooth range limits (typically 10-30 meters) as a security feature
  4. Enable “delete account” as a panic option

Briar is best understood as a complement to your primary secure messaging tool rather than a replacement. Use it for situations where internet access is unavailable, unreliable, or unsafe to use — protests, remote field operations, or during active network disruptions.

Key Management Best Practices

Regardless of tool selection, key management determines overall security.

Key Rotation Schedule

Implement regular key rotation:

# Matrix: Manual key export/rotate via Admin API
curl -X POST "https://chat.yourorg.org/_matrix/client/r0/room/{room_id}/send/m.room.key_request" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -d '{"action": "request", "room_id": "{room_id}"}'

Device Hygiene

If a member leaves the organization, immediately remove their devices from all shared rooms. In Matrix, this means verifying that cross-signing no longer includes their devices. In Signal, it means they should be removed from all groups by an admin. Failing to do this means departed members may still have access to the encryption keys for messages sent during their membership.

Recovery Planning

Critical: Establish account recovery procedures before they’re needed.

For Matrix:

  1. Note the 4S (Secure Secret Storage) recovery key
  2. Print and store offline in secure location
  3. Designate trusted contacts for cross-signing

For Signal:

  1. Enable registration lock with a strong PIN
  2. Print backup code and store securely
  3. Verify safety numbers with all group members regularly

Onboarding New Members Securely

The weakest point in most organization’s communication security is the onboarding process. New members need to receive credentials over a channel that is already secure, which creates a bootstrapping problem.

A practical approach: conduct initial onboarding in person when possible. Exchange device verification codes face-to-face, verify safety numbers together, and establish shared secrets that can be used to authenticate future communications. If in-person onboarding is not possible, use multiple independent channels to verify identity before granting access to sensitive rooms.

Infrastructure and Hosting Decisions

Where you host your Synapse server matters as much as how you configure it. Consider these factors when selecting a hosting provider:

Jurisdiction: Servers hosted in jurisdictions with strong privacy laws are harder for foreign governments to compel through legal process. However, no jurisdiction is immune — data retained on your server can always be sought through legal channels by the hosting country’s authorities.

Payment anonymity: If your threat model includes hiding the existence of your organization’s communications infrastructure, paying for hosting anonymously matters. Cryptocurrency payments through privacy-focused exchanges, combined with hosting in privacy-friendly jurisdictions, reduce the paper trail linking you to the server.

Physical security: Colocated servers you physically own are harder to access without your knowledge than virtual machines running on shared infrastructure. For most activist organizations, a reputable VPS provider with a strong privacy track record is a reasonable compromise.

Incident response: Before you need it, know what you will do if your server is seized or compromised. Have a documented procedure for alerting members, migrating to a new server, and rotating all credentials. Test this procedure at least once per year.

For most organizations, a VPS from a provider with a no-logs policy, encrypted storage, and a history of resisting government requests is sufficient. Run your Synapse instance with full-disk encryption enabled at the OS level, and ensure the decryption key is not stored on the server itself — this prevents offline analysis of seized disks.

Comparing Communication Needs Across Org Types

Different activist contexts require different communication infrastructure:

Local protest coordination: Needs fast, ephemeral, peer-to-peer communication. Signal groups or Briar work better than self-hosted infrastructure. Assume phones may be seized, so minimize message history. Enable disappearing messages on 1-hour timers.

International human rights documentation: Requires reliable, archivable communication with long history. Matrix self-hosted with persistent storage makes sense. Coordinate with international partners who may use less secure systems—focus on preventing internal compromise rather than protecting against foreign governments.

Decentralized autonomous networks: Participants separated geographically with minimal trust between subgroups. Briar’s peer-to-peer mesh becomes attractive since no single server represents a single point of failure or legal jurisdiction problem.

Advocacy organization with public-facing work: Mix of public (website, social media) and private (board communications, sensitive campaigns) channels. Use Matrix for internal communications, separate Signal groups for time-sensitive operational coordination.

Disaster Recovery: When Infrastructure Fails

Your communications system will eventually fail. Be prepared:

Scenario 1: Server seized

Scenario 2: Hosting provider terminates service

Scenario 3: Ransomware infection

Scenario 4: Losing admin credentials

Run at least one disaster recovery drill annually. Test server migration to a backup provider. Test member communication during service downtime. Each drill reveals gaps in your documented procedures.

Advanced: Using Matrix for Sensitive Operations

For organizations coordinating across multiple locations or time zones with high-security needs:

Room-level access control: Create separate Matrix rooms by operational need:

# Advanced room config for secure operations room
m.room.encryption:
  algorithm: m.megolm.v1.aes-sha2
  rotation_period_ms: 604800000  # Weekly rotation
  rotation_period_msgs: 100

# Visibility settings
m.room.visibility:
  type: private

# Access control
join_rule: invite
history_visibility: members

# Audit trail
audit_log: enabled  # Track who accessed room
audit_retention: 90  # Keep audit logs 90 days

Time-limited operations rooms: Create rooms for specific operations that self-delete after the operation concludes. This prevents the room becoming a permanent archive of sensitive tactical information if the server is later compromised.

# Create ephemeral operation room
import requests

def create_operation_room(matrix_server, access_token, operation_name, duration_days=7):
    room_body = {
        "name": f"OP_{operation_name}_{date_today}",
        "visibility": "private",
        "join_rule": "invite",
        "encryption": "enabled",
        "retention": {
            "max_lifetime_ms": duration_days * 24 * 60 * 60 * 1000
        }
    }

    response = requests.post(
        f"{matrix_server}/_matrix/client/r0/createRoom",
        json=room_body,
        headers={"Authorization": f"Bearer {access_token}"}
    )
    return response.json()

# Room automatically deletes after 7 days

Monitoring for Compromise Indicators

Even encrypted infrastructure can be compromised. Watch for these warning signs:

If compromise is suspected, treat it as urgent. Initiate immediate credential rotation, alert all members, consider server migration. Document the incident for post-action analysis.

Scaling: Beyond 50 People

As your organization grows, communication becomes more complex. Some guidance:

Split into geographic or functional subgroups: Don’t have all 200 members in single chat room. Create subgroups, use higher-level coordination rooms sparingly.

Implement role-based access: Not everyone needs access to everything. Coordinating committee has different room access than general members.

Introduce formal quorum/decision procedures: With 200 asynchronous voices, clear decision-making procedures prevent endless discussion.

Separate operational and strategic communication: Real-time tactical coordination uses one system, strategic planning uses different channel with asynchronous discussion.

Regular audit of access: As org grows, review who has access to what rooms. Remove departed members immediately.

Built by theluckystrike — More at zovo.one

Explore Our Developer Guides

© 2026 theluckystrike Developer Guides