Privacy

This is the inventory of what sudo knows about you, what it doesn't, what it stores, how long, and what you control.

For the protocol-level threat model, see TRUST_MODEL.md. For the audit findings, SECURITY_AUDIT.md.

The shape of it

Most messaging apps know who you talk to and when, even when they can't read what you say. sudo is in this category. We can't pretend that's not true. What we can do is be specific about it.

What's encrypted:

What is not encrypted, because the server has to do something with it:

What the server stores

Every piece of data the server keeps has a purpose, a retention bound, and a deletion rule. This section lists all of it.

Your identity

Stored until you delete the account.

Pending messages

Deleted when your device confirms receipt. Auto-expires after 72 hours if your device never picks it up.

Encrypted device-sync events

Each event stays in the log until every paired device has acknowledged it, plus a short grace period. Long-term retention is bounded by a watermark: once all your devices say "I've seen up to seq N," anything below N is purged.

Device list

Stored until you revoke. Revoked devices stay in the list (marked revoked) so you can see your own history.

Feed posts you've published

Stored until you delete the post. Public posts may be cached by visitors' browsers.

Subscriptions and connections

Stored until you remove them.

Push subscription endpoints

Stored until you remove it or the provider says the endpoint is gone (HTTP 410).

Rate-limit counters

Not persisted across server restarts.

What's NOT stored

What you control

You can:

What you do NOT have on this version:

Notifications

When a message arrives for you and you have a push subscription registered, the server tells your OS push provider (FCM, Apple, Mozilla, Microsoft) to wake your phone with a small payload. That payload contains:

It does not contain the message body. The body is encrypted in the queue; only your phone, after waking up, can decrypt it.

The push providers (Google/Apple/Mozilla/Microsoft) see the encrypted payload they're carrying. They see who it's going to, when, and how often. Their privacy policies apply to that visibility. Choosing not to install the PWA, or disabling notifications, removes them from the loop.

Connections to other services

sudo on its own does not call out to any third-party service. No analytics. No tracking pixels. No external fonts. No CDN. The HTTP requests your browser makes go to:

That's it. If you load the page over Tor, even those connections happen over Tor.

Tor

sudo can be served over a .onion address. When you connect that way:

See TOR_DEPLOY.md for the operator side and SECURITY_AUDIT.md for what was checked.

Children / age

sudo has no age gate. The cryptographic protections do not change with the user's age. If you are responsible for a child's account, you are responsible for the device, the backup, and the people they message — the same way you'd be responsible for any other end-to-end-encrypted tool they use.

Government requests

If a sudo node operator receives a lawful request for user data, they can hand over what's in their database. Specifically:

They cannot hand over message contents, private keys, passwords, or sync log payloads — they don't have those.

If you run your own node, you'll receive any such requests directly. If you use a node someone else operates, you're trusting them with the metadata above. There is no centralized sudo authority; each node is a separate trust domain.

Things we want to do but haven't yet

Each of these is a tradeoff. They're not on the current version's path but they're on the project's list.

How to verify any of this

Run a node yourself. The whole codebase is open. Open the SQLite file. Run the smoke suite. Read the route handlers. Inspect a network trace.

The opposite of "trust us" is "check us." We've tried to make checking easy.