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. Calls go through a LiveKit SFU that requires E2EE Insertable Streams, so it relays opaque RTP frames and never decodes your 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 "verified — vendor-scoped" 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

Calls run on LiveKit, and every room requires end-to-end encryption: the room refuses a participant without E2EE Insertable Streams, your app checks for it when it joins 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

Your audio is encrypted on your device and decrypted only inside an attested enclave, which transcribes and analyses it. When that path is unreachable, the audio waits on your phone, encrypted, and uploads once the path returns; audio still waiting after 24 hours is deleted. There is 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 used.

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. Sever the grant and the server stops handing over the wrap on your next read — that's access control, not a promise. What it can't do is reach backwards: anything they already opened and kept, they keep.

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.
• 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 new-sign-in notice names the device, its IP address and the time)
• 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.