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's recovery model is different from traditional account recovery. See Recovery below.

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.

Content Protection

Bastion supports encrypted circles, where post content is encrypted on the client before it is sent to the server.

• Each encrypted circle has its own content key.
• The server stores ciphertext and cannot read post content in encrypted circles.
• Access to post content is gated by membership: members can read encrypted posts created during their membership.

Key rotation

• Encrypted circles use a per-circle content key.
• When a member is removed, the circle key is rotated.
• Removed members are not granted the new key, so they cannot decrypt posts created after removal.
• Rotation does not erase or retroactively protect posts they could already read while they were a member.
• Rotation also does not protect against content copied, exported, screenshotted, or otherwise retained before removal.

Forward secrecy and post-compromise security

Bastion does not currently provide forward secrecy or post-compromise security. If a device or circle key is compromised, encrypted content available to that key may be exposed. Later key rotation can limit future access, but it does not retroactively protect content that was already accessible.

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 contents of posts in encrypted circles

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
• circle membership and post timing in encrypted circles

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.

Recovery

Bastion does not have traditional account recovery. Identities are generated and stored on your device, and the server never holds your private keys in a usable form.

Access can be restored through one of the following paths, if it was set up beforehand:

• Identity backup. An encrypted backup file you export and store yourself. Backups include your identity and a snapshot of your circles at the time of export.
• Passkey-based recovery. Available only if you previously set up a passkey for recovery.

If neither is available, your identity cannot be recovered. Without that identity, you may lose access to encrypted circle content.

Backups and Circle Sync serve different purposes:

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

Enabling Circle Sync does not replace backups.

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.