What we do, what we don't, and why.

The encryption model in two paragraphs

Each Shoal family has a single AES-256-GCM key. Every message in that family is encrypted with that key on the sending device, before it leaves. The key is wrapped (encrypted under) each member device's ECDH P-256 public key, so that only authorised devices can unwrap it. Decryption happens locally on each recipient's device.

On top of this, almost everything we store on our servers — message ciphertext, your display name, your profile picture, device labels, public keys, encrypted copies of device decryption keys, and routing metadata — is additionally encrypted at rest under a server-side environment secret. The only personal data we hold in plaintext is your email address, because we need it to send you sign-in emails.

What this means today

What we hold in plaintext

• Your email address — used for magic-link sign-in.

What we hold encrypted at rest

• Message ciphertext.
• Voice note audio, and any transcripts produced on-device by a recipient.
• Your display name and profile picture.
• Device labels.
• Device public keys.
• Encrypted copies of device decryption keys.
• Routing metadata: who sent what to which conversation, and when.

What we cannot read in normal operation

• Anything in the encrypted-at-rest list above. The infrastructure to decrypt that data does not exist; no Shoal employee has direct access to the environment secret in the course of normal work.

The architectural caveat we want to be upfront about

Encrypted backups of your device decryption keys are stored on our servers, protected by the environment secret. We currently have no code path that unwraps those copies, and no plans to write one. But it would be technically possible for us to do so in the future — for example, if we were ordered to comply with a lawful disclosure request that we could not refuse, or if we built a feature for users to recover messages after losing all of their devices.

In short: the protection on user data we hold encrypted at rest is operationally enforced rather than cryptographically separated from us. If we ever build a capability to read data we cannot read today, we will say so publicly on this page and in our privacy policy, and notify users in advance.

Admin oversight, explained honestly

Shoal exists partly to give parents oversight of their children's conversations. Pure end-to-end encryption (the Signal model) is the gold standard for confidentiality, but it isn't compatible with the oversight that Shoal exists to provide.

So we do something different. When a child is in a conversation, the conversation key is wrapped for every family admin's device at the moment the conversation is created. That makes the admin a cryptographic recipient, alongside the child. Admins can read the conversation because they hold a key.

Admin oversight does not require the environment secret or any server-side decryption. It works in the client, between cryptographic recipients, exactly the way the rest of the messaging system does.

Specific cryptography

• Symmetric encryption: AES-256-GCM, with a fresh 96-bit IV per message.
• Asymmetric key wrapping: ECDH P-256 to derive a wrapping key, with HKDF-SHA-256 for key derivation.
• Authentication of message integrity: AES-GCM authentication tag.
• Transport: TLS 1.3 to Cloudflare's edge. Messages are double-encrypted in transit (TLS plus payload).
• At rest: Cloudflare D1 with disk encryption, plus application-level encryption under a server-side environment secret.

Threat model

What we defend against

• Database compromise. An attacker who exfiltrates the database, but does not also compromise our deployment environment, sees encrypted bytes (and a list of email addresses). Application-level encryption stops them from reading any of the user data.
• Network observers. TLS 1.3 plus payload encryption means a network attacker sees only encrypted bytes.
• Insider risk in normal operation. No Shoal employee can read user messages, display names, profile pictures, or routing metadata without writing new infrastructure to do so. The environment secret is not exposed to staff workflows.
• Malicious push services. Push notification payloads are encrypted to your device's public key — Apple, Google, and Mozilla push services see metadata only.
• Email link prefetching. Magic links are protected with an intent-confirmation step that prevents email scanners from silently consuming the token.

What we don't fully defend against

• Compromise of your device. If an attacker gets unlocked access to your device, they get the keys cached there. Use a screen lock.
• Coerced disclosure on a device. If someone forces you to read your messages aloud, no encryption helps.
• Compromise of an admin device in your family. If an admin device is compromised, the conversations that admin can read are at risk. Rotate keys after such an incident.
• Compromise of our deployment environment combined with new code. An attacker who obtained the environment secret and could deploy decryption code to our infrastructure could decrypt the at-rest device key backups and decrypt user data. The attack surface is our ops/CI footprint; this is the same surface that any future compelled-decryption scenario would also flow through.

Data retention

Messages are retained until you delete them. Deleting a message removes the ciphertext from our database. Account deletion removes your user record and revokes all device keys; messages you've sent in conversations remain readable to other participants unless they also delete them.

Compliance

Shoal is built to be compatible with UK GDPR, EU GDPR, the UK Children's Code (Age-appropriate Design Code), and equivalent regimes elsewhere. Our database is in EU jurisdiction. Data subject requests can be made to [email protected].

Frequently asked questions

Is Shoal end-to-end encrypted?

Messages are encrypted on the sending device, decrypted on recipient devices, and never seen in plaintext by our servers in transit. In that sense, yes. There is one nuance worth being explicit about: encrypted copies of device decryption keys are stored on our servers under an environment secret for resilience, so a future Shoal team could in principle build code to decrypt at-rest data. The strict architecture of pure E2EE — where only the participating devices ever hold the keys — is not quite Shoal's architecture, and we'd rather say so than over-claim.

How does admin oversight work without breaking encryption?

The conversation key is wrapped for every family admin's device at conversation creation. They can read the conversation because they hold a key. There is no separate decryption pathway and no server-side decryption involved.

How does voice note transcription work? Do you process the audio on your servers?

No. Voice note audio is encrypted on the sending device with the same conversation key that wraps text messages. If a recipient turns on transcription for a conversation, their device runs its operating system's on-device speech recogniser locally — the audio is decrypted on the device, transcribed in place, and the resulting text is re-encrypted with the conversation key before being stored alongside the audio. Our servers never see decrypted audio or transcript text, and we don't call any cloud speech service on your behalf. See the voice notes feature page for more.

What happens if I lose my device?

Revoke the device from any other logged-in device, or contact us for account recovery. Revocation removes future access. The family key can be rotated.

Where is Shoal's data stored?

On Cloudflare's edge platform, in EU jurisdiction. Almost all data is encrypted at rest; only email addresses are held in plaintext.

Can law enforcement access my messages?

Today, no. We have not built code that decrypts user data, and have no plans to. We could in principle be ordered to build such a capability in the future. We will respond to any such situation when it arises, and will update this page and notify users before changing what we can disclose.

Reporting a vulnerability

If you've found a security issue in Shoal, please email [email protected]. We respond within 72 hours and will acknowledge the report on our security page once it's resolved.