Privacy Policy

1 What this policy describes

How Tongue Tamer handles your data. Our architecture is the load-bearing answer — this policy describes what the architecture 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 inside sealed memory; we have no key path into either side.
• 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 "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.

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 SFU is in the metadata path only.

We've built an automated check that watches every frame the SFU receives during a test call and confirms none of them decode as audio. Independent verification of the opacity claim — the call goes through, the SFU sees only opaque bytes.

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. 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. 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

You pick a recovery method when you sign up: passphrase, paired device, or both. There is no "send me a magic link" path that would let an attacker who breaches our email get back into your account.

If you delete your account 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. If you delete it from 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 from their Account, your data is kept for 180 days so you can claim it. Once a hard delete has run, it is irreversible. 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.

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. The threat model + design records are written and kept current, and pending publication; the security review is in progress; the audit log is the load-bearing tamper-evident primitive that makes a discovered bug investigable after the fact.

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 and an entry in the public changelog. Amended copy is itself audited.