Privacy Policy

1 What this policy describes

How Tongue Tamer handles your data. Most of our answers come from how the system is built, not from promises. This policy says what that design enforces and what it doesn't. Every claim below is anchored to a design record; the capability-by-capability summary is on the technical details page. The records themselves are pending publication.

2 Data we hold about you

3 What we never see

• Conversation bodies, transcripts, recaps. Encrypted on your device before upload. The inference enclave decrypts them inside sealed memory; we hold no key that can decrypt them.
• Voice call audio, once calls ship. Calls are planned, not live. They will go through a LiveKit SFU configured to require E2EE Insertable Streams, which sees opaque RTP frames, never decoded audio.
• Your identity key. Generated and sealed on your device by the OS keystore. We never see it.

4 Inference (the AI side)

We run inference on Phala Cloud TDX + Confidential GPU enclaves. Before your client sends any prompt, it verifies the signed attestation of Phala's gateway enclave against a policy we publish at /.well-known/attestation-policy.json. Signed policies exist for dev, test and staging today; production’s awaits its offline signing ceremony, so that URL currently returns a placeholder the client is built to reject. If the measurement doesn't match — even a single byte off — your client refuses to send and shows a "Privacy verification unavailable" error. There is no fallback to a non-attested model. The model is an open-weight model (currently NVIDIA Nemotron 3.5 Lightning) served through Phala's confidential-inference API; we do not use closed frontier models because they cannot run in a customer-verifiable TEE.

Whose enclave it is, during the alpha. That enclave is a shared gateway operated by Phala — not hardware we run. The encryption is unchanged: we hold no key that can read your conversation, and your client still refuses to send until it has verified the enclave against the policy above. What changes is who has to run the hardware honestly — a named third party rather than us. We can verify against that risk; we cannot prevent it, and we would rather say so than let "attested enclave" imply the machine is ours.

Because of that, a verified reply is labelled "Partly verified" rather than a bare "verified": your device fully verifies the gateway enclave and binds the reply's bytes to it. Phala's gateway decrypts your request there and forwards it over a verified channel to the enclave running the model. Four things rest on the vendor's word rather than on your device's check: the model's enclave (its attestation is accepted on the vendor's published catalogue), whether anything keeps a copy of your request, where the gateway forwards it, and the physical security of the data centre. Phala's contract says its staff do not access your content and it does not train on it unless we authorise that, and we never will. This is permanent for anything processed now — we intend to move inference onto hardware we operate, and that will change things going forward, but it will not retroactively change where earlier consultations were decrypted.

Versions of the app from 2 October 2026 ask Phala not to keep a copy of your request: every request they send asks for Phala's zero-data-retention route, and Phala's documentation says a request it cannot serve that way is refused rather than sent elsewhere. That rests on Phala's contract and published policy. Neither the attestation nor the receipt can show it, so it stays on the vendor's word, as listed above.

5 Voice (planned, not live)

Calls are planned, not live: the app refuses every call today, because phones don't yet offer the encryption API a call requires. The design: LiveKit mediates real-time voice; the room must have E2EE Insertable Streams enabled, your client checks for it at connect time and refuses to start the call without it, and an application-layer cipher runs on top, as defence in depth. The voice server relays encrypted frames and sees call metadata (who joined and when, and the timing and size of each frame), never your audio.

An automated test makes a call and confirms that what reaches the voice server can't be played back as sound.

6 Audio

Planned, not live: nothing transcribes or analyses your audio today. The design: your audio will be encrypted on your device and decrypted only inside an attested enclave; while that path is unreachable, it will wait on your phone, encrypted, and upload once the path returns; audio still waiting after 24 hours will be deleted. There will be no on-device transcription path, no cloud speech-to-text vendor and no opt-in to bypass the enclave. Closed audio-understanding vendors (Deepgram Nova-3, GPT-4o-audio, Gemini, ElevenLabs) cannot run in a customer-verifiable enclave and are not part of the design.

7 Your audit log

Every action that touches your private data lands on a per-user hash-chained log. You can read it, export it, and verify its tamper-evidence on your device. If we ever altered or removed a row, your next checkpoint signature would detect it.

8 Sharing

You can share specific resources (a recap, your ecomap, a goal) with another user via a key-grant we record. Either of you can stop sharing at any time. Whoever stops chooses whether what was already shared is withdrawn; it's kept only if you both agree, and anything already opened can't be taken back.

9 Recovery + deletion

When you sign up, you choose a recovery passphrase or no backup at all; a paired second device also keeps you in. Your email address is enough to sign in, but not to read your conversations: that also takes your recovery passphrase or one of your devices.

Deleting your account works like this:

• In the app. You choose the waiting period, 30 days (recommended) or 180, and you can cancel until it ends. You can also ask for deletion with no waiting period.
• On the web dashboard. You have 30 days to sign back in and undo it; after that we delete your sign-in and keep any encrypted data you had with us for a further 180 days, then delete it.
• If an Account owner removes you. Your data is kept for 180 days so you can claim it.
• Conversations with other people. If you delete your account, you leave conversations you share with others. Your messages stay with them unless the conversation is set to delete them.
  What happens to a shared conversation

  When your account is deleted, you leave each conversation you share with someone else. It stays with them, with their own messages and a record that you joined and left: your user id, your public signing key, and your signed joining and leaving. Your messages in it stay with them, encrypted as before, unless the conversation is set to delete them. Anyone in it can set that, and it then applies to everyone's messages from then on; it covers messages written before only if everyone agrees, and going back to keeping them needs everyone to agree too. Messages already deleted with an account can't be brought back.

• Before you delete. You can make an encrypted record of your account in the app: the titles and dates of your conversations and goals, your devices and your sharing. It does not contain the content itself: what you said, the replies and your recaps are not in it. The record is kept with your account for 30 days; the app does not yet save a copy to your device.

Once a hard delete has run, it is irreversible.

10 Subprocessors

• Cloudflare — Workers (gateway), D1 (metadata), R2 (ciphertext bodies), and, where we have enabled it, Email Sending, which then handles the same emails described under Resend below
• Hashforest Technology LLC (Phala Cloud), USA — confidential inference: decrypts your request only inside its enclaves, to answer you, and sees request metadata
• LiveKit — voice SFU (encrypted frames only)
• RevenueCat — Apple IAP / Google Billing routing
• Polar — web subscriptions
• Resend — transactional email: your email address and the full content of each email we send you, including one-time sign-in codes and security notices (a notice that a device was added names the device, its IP address and the time; a notice of a sign-in from a device we don't recognise names only the device and the time, because we don't store the IP addresses you sign in from)
• Twilio / Messagebird / Sinch — text-message delivery of one-time sign-in codes: your phone number, the message itself (which contains the code), and when it was sent
• APNs / FCM — push notifications (generic envelope only)

Apple and Google see push envelopes only, not message content — today those envelopes carry no message content at all. When encrypted notification bodies ship, the decrypt will happen on your device, in a notification handler we have not built yet.

11 What we don't promise

• State-level adversaries with research-grade resources targeting the TEE hardware. Our threat model addresses published exploits. Novel research-grade attacks on the deployed TEE stack are out of scope.
• A metadata-free experience. We see when you use the app, which routes you hit, and aggregate traffic patterns. That information is necessary to run the service. Our AI vendor sees request metadata too.
• No bugs. We'll have bugs. The threat model and design records are written and kept current, but not yet published, and a security review is in progress. Because the audit log is tamper-evident, a bug can be investigated after it's found.

12 Contact

Privacy questions: privacy@tonguetamer.com.
Security disclosures: security@tonguetamer.com.

13 Changes

We'll post material changes here with a new "Last updated" date.