How we keep your family's chats private

In plain English

When someone in your family sends a message on Orbit, their phone scrambles it before it leaves. The only phones that can unscramble it are the ones belonging to the family — the people in the conversation and the trusted adults on both sides, when there are children involved. Our servers move the scrambled message between those phones like a post office that can see the envelope but never open the letter inside.

This is called end-to-end encryption. It's the same idea behind apps like Signal and iMessage. The difference with Orbit is the trust circle: when a child is in the chat, the grown-ups looking after them are cryptographic participants too. You get to see what's being said, and the server doesn't.

When we say "we can't read your messages," we mean it structurally — not as a promise. The keys that unscramble messages never leave your family's phones. If someone broke into our servers, or served us a subpoena, or if we wanted to (we don't), the thing we'd be looking at is still scrambled.

The technical bits

For curious or technical readers. Skip this section if you don't want to go into the weeds.

The protocol: X3DH + Double Ratchet

Orbit uses the Signal Protocol — the same end-to-end encryption protocol behind Signal, WhatsApp, and Facebook Messenger's secret conversations. It's open, well-audited, and widely peer-reviewed. We didn't invent our own crypto.

X3DH (Extended Triple Diffie-Hellman) is how two phones that have never met establish a shared secret the very first time they talk — even if one of them is offline. Double Ratchet is how they keep rotating keys forward as they chat, so that if any one key is ever compromised, it doesn't unlock earlier or later messages. This property is called forward secrecy and post-compromise security.

The keys: Curve25519

Every device has three kinds of keys, all generated on the device itself:

• Identity key — a long-lived Curve25519 key pair that identifies the device. The private half never leaves the phone.
• Signed prekey — a medium-lived key, signed by the identity key, that starts new conversations.
• One-time prekeys — a batch of single-use keys that get consumed as new conversations begin, giving extra forward secrecy for the opening handshake.

Our server stores the public halves of these so your friends' phones can look them up to start a conversation. The private halves never leave the device where they were generated.

Per-device sessions

If a user has multiple devices (an iPhone and an iPad, say), each device has its own independent identity key and its own encryption session with every peer. A message sent to Emma isn't encrypted "to Emma" — it's encrypted separately for each of Emma's devices. If one device gets compromised, the others aren't.

What our server handles

The server is responsible for routing, not reading. It:

• Holds public key bundles so phones can find each other and start conversations.
• Stores encrypted message blobs until the recipient's phone is online to fetch them.
• Manages accounts, the family graph (who's in which family, who's approved to talk to whom), and Mack's moderation settings, which are pushed to the sending device so Mack can run locally.
• Broadcasts delivery notifications (metadata only — "a message arrived for you") so phones know when to sync.

It does not — and structurally cannot — decrypt the message contents.

Sign-out wipes local state

When someone signs out of Orbit, every piece of crypto state on that device is wiped: identity key, session state, message cache. A re-login generates a fresh identity and starts new sessions. If a phone is lost, a remote sign-out via the parent account achieves the same thing.

Mack and end-to-end encryption

A common question: if Orbit can't read messages, how does the AI moderation work?

The answer is Mack — our on-device AI safety agent. Mack runs on the sending device, never on our servers, and never in the cloud. The child's phone is the sender; it sees the plaintext of the outgoing message in the moment before it is encrypted. We use that window to give Mack a look — locally, on the device — before the message is locked and sent. The server receives only ciphertext and, when Mack fires, a small alert payload (model version, which labels were triggered). No message text ever reaches our servers as part of moderation. End-to-end encryption is not weakened.

Contrast this with server-side scanning products, which require either decrypting messages on the server or gaining access to a copy of the plaintext via the messaging provider. Orbit does neither. Mack is on the phone, not in the cloud.

What the server sees from a Mack event

When Mack fires an alert on the device, the only data the server receives is:

• Which labels were triggered (e.g. bullying, self_harm).
• The model version of Mack that produced the result.
• The timestamp and the parent-child link identifier (so the alert can be routed to the right parent).

No message text. No ciphertext. The alert is metadata about the classification, not about the content.

Feedback loop — if a parent opts in

Parents can flag a Mack alert as inaccurate. There is an additional, separate opt-in to share the message text to help train the next version of Mack; this is off by default and requires an explicit per-message decision. If a parent opts in, the child's device encrypts the message text to the parent's identity key at classification time. Only the parent's own device can decrypt it. When the corpus row is written on our server, it is stripped of all identifiers — no parent ID, no child ID, no conversation ID. There is no way to trace a corpus row back to the family that contributed it.

What we store (and what we don't)

What parents can actually see

Orbit treats the family as the unit of privacy. When someone sends a message, their phone encrypts one copy per device in the family trust circle — the others in the conversation, plus the trusted adults on both sides whenever a child is involved. The server relays ciphertext; each family device decrypts locally.

What grown-ups in the family can see and control (when a child is part of the chat):

• The messages themselves. Every message sent or received is decryptable on a parent's device. You see the conversation in your own Orbit app.
• Who the children are talking to. The list of active conversations and the grown-up on the other end.
• Approval for new contacts. A child can't add a new friend without the grown-ups on both sides agreeing.
• Mack alerts. When Mack flags a message on the child's device, the parent receives an alert showing which labels fired. The underlying message text is readable on the parent's own device (they are a cryptographic participant in the conversation), but the alert itself contains only metadata.
• Approval requests. In "Hold for approval" mode, flagged messages are held on the child's device pending your sign-off. The message text reaches you via your own decryption, not via the server.
• Watchlist notifications. A notification when a watchlisted word appears in your child's messages — notification only, no blocking.
• Metadata. When conversations happen, how often, with whom.

What Orbit cannot do: read those messages on your behalf server-side, hand them to anyone outside your family, or show them to another family's parent. The encryption is scoped to your family — no one else.

Transparency & current state

We believe you should be able to check what we claim. Honest status as of today:

• Orbit is currently in pre-launch / early beta. The security design described here is in place; polish and audits are ongoing.
• We plan to commission a third-party security review before a broad public launch and publish the report.
• Found a security issue? Use the form below. We take responsible disclosure seriously and will credit researchers who report issues privately first.

Technical FAQ