Privacy and trust

The defining property of Cremind Connect is restraint: it is engineered to relay events without holding your tokens or your content. This page is the trust model — what the relay can momentarily see, what it provably never keeps, and how you can verify all of it yourself.

What the relay never holds

• No OAuth access or refresh tokens. For Google, the relay is never in the token path. For Atlassian, the relay performs the confidential exchange and hands the tokens straight back to your app — it stores none of them.
• No email, calendar, or issue content. The relay forwards content-free "resync" nudges. Your app always fetches the actual changes itself, locally, with its own token.
• No durable user data or account mapping. Routing keys are derived from each event's payload, not stored. There is no user table to leak.

What the relay can momentarily see (and immediately discards)

Being honest about the threat model matters more than claiming the relay sees nothing. Here is what passes through it and how each item is handled:

The account email is observed only long enough to hash it into a routing key, and the routing key is itself a hash. Logging uses a field allowlist, so logs contain only the derived (already hashed) routing key and counts — never email addresses, cursor hints, tokens, or JWTs.

Stateless at rest

Cremind Connect is stateless at rest. Subscriber WebSocket connections live only in memory for the lifetime of the connection, and routing keys are derived per event rather than persisted.

The only persistent storage the relay uses is a small key-value store for:

• Google's public JWKS cache — the public keys used to verify Google's signed pushes. This is public data, not user data.
• A single-use nonce store — used to prevent replay of the bootstrap ID token during subscription. Nonces are consumed and expire.

There are no tokens, no user records, and no content anywhere in the relay's storage.

How subscriptions stay private

Because routing keys come from a hash of the account, the relay enforces proof of control before letting an app join an account's hub. Your app presents a Google ID token; the relay verifies its signature, audience, expiry, the email_verified claim, and a single-use nonce, then confirms the derived key matches the requested account. An ID token proves who you are but grants no API access — so even at the moment of subscription, the relay sees only a verifiable identity assertion, never a usable token. A subscriber can only ever join the hub whose key matches its own verified account, so one account's nudges can't leak to another.

Why you can trust it: open and auditable

Cremind Connect is MIT-licensed and fully open source, running on Cloudflare's platform. It is intentionally small, so you don't have to take these claims on faith — you can read the entire service, including its infrastructure definitions, and confirm exactly what it does and does not do.