Privacy Model

Understanding how Bastion protects privacy and what information the server can and cannot see.

This page explains how Bastion is designed to protect user privacy, what information the server cannot access, and what limited metadata the server may still observe when operating the service.

Overview

Bastion is designed to allow people to coordinate in private groups without relying on a global account or a central identity provider.

Instead of creating a server-side user account, Bastion generates a cryptographic identity directly in your browser. That identity signs actions such as creating posts, joining circles, or managing membership.

Because identities are client-side and circle identifiers are derived differently for each circle, the server is intentionally designed so it cannot easily link your activity across circles.

The goal is simple:

• Bastion should not need to know who you are
• Bastion should not have access to your private keys
• Bastion should not be able to link your participation across circles

Identity and Keys

When you first set up Bastion, your browser generates a cryptographic identity locally.

This identity consists of a private key and a corresponding public key.

Important properties:

• The private key never leaves your device.
• The server only sees signatures produced by the key.
• Bastion does not maintain a global user database.

Because identities are generated locally, Bastion does not have an "account recovery" mechanism. If your identity is lost and you do not have a backup, it cannot be recovered.

Circles and Unlinkability

Each Bastion circle operates independently.

Even if the same identity participates in multiple circles, Bastion is designed so that:

• circle membership records are separate
• circle-specific identifiers are derived independently
• the server does not have a single global identity table

This reduces the ability of the server to link participation across circles.

In practice, this means the server processes requests like:

• "a member of this circle posted something"
• "a member of this circle joined"

without needing to know whether that same identity exists in any other circle.

What the Server Cannot See

Because key operations happen in the client, the server cannot access several important pieces of information.

The server cannot see:

• your identity private key
• encrypted identity backups
• the contents of encrypted sync payloads
• your device PIN
• the list of circles stored inside encrypted registry data

The server stores and processes only the data required to operate each circle.

What the Server Can Still See

Like any web service, Bastion still exposes some limited metadata to the server.

Examples include:

• IP addresses during requests
• timestamps of API calls
• approximate size of encrypted payloads
• when encrypted registry records are updated

This metadata is unavoidable for most web applications. Bastion's design attempts to minimize how much of it can be used to infer relationships between users or circles.

Circle Sync

Bastion allows an optional feature called Circle Sync.

When enabled, Bastion stores an encrypted record of your circle list. This allows your devices to stay up to date when circles are created or joined.

Important properties:

• The sync payload is encrypted client-side.
• The server cannot read which circles are inside the payload.
• The server can observe when the encrypted record changes.

Without sync, restoring from a backup will only include the circles present at the time the backup was created.

Backups and Recovery

Bastion identities exist only on your device.

To recover your identity if a device is lost, Bastion allows you to export an encrypted backup file.

Backups include your identity and a snapshot of your circles at the time of export.

Your identity is stored locally in your browser. If it is cleared or reset, it cannot be recovered without a backup.

Important distinctions:

• Backups store your identity.
• Sync stores only circle metadata.

Enabling Circle Sync does not replace backups. If all devices are lost and no backup exists, the identity cannot be recovered.

Threat Model and Limitations

Bastion reduces the amount of information a server can observe, but it does not eliminate all possible metadata.

Examples of remaining risks include:

• network-level observation of traffic
• correlation based on timing of events
• device compromise
• malicious circle administrators

Bastion's goal is not perfect anonymity, but rather to make privacy the default and reduce the amount of information centralized systems typically collect.

Summary

Bastion is designed around a simple principle:

The server should only know what it needs to operate a circle — and as little else as possible.

By generating identities locally, separating circles, and encrypting sensitive data before it leaves the device, Bastion minimizes the amount of information that must be trusted to the server.