Trust

Privacy Policy

Last updated: 2026-05-27

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

ClassWhereEncrypted to us?
Account identity (email / phone, OAuth ID)Cloudflare D1No
Subscription / billing stateCloudflare D1 + providerNo
Conversation content, transcripts, recapsCloudflare R2 (ciphertext)Yes — we cannot decrypt
Ecomap, goals, relationship detailsCloudflare R2 (ciphertext)Yes — we cannot decrypt
Audio recordings (when attached)Cloudflare R2 (ciphertext)Yes — we cannot decrypt
Operational metadata (when, which routes)Cloudflare logsNo (90-day retention)
Audit log of privacy-bearing actionsCloudflare D1 (hash-chained)No (readable to you, the user)

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. Mediated by a LiveKit SFU we've configured to require E2EE Insertable Streams. The SFU 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 enclave's signed attestation against a policy we publish at /.well-known/attestation-policy.json. 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 itself is open-weight (currently gpt-oss-20b, running inside the enclave — not a hosted 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, but the model's own attestation behind that gateway is accepted on the vendor's published catalogue. 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 (when you use it)

LiveKit mediates real-time voice. The room is required to have E2EE Insertable Streams enabled; your client probes for it at connect time and refuses to start the call if the API isn't available. On top of that, we run an application-layer cipher — 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

Your audio is encrypted on your device and decrypted only inside the same attested enclave that runs the AI. The enclave is the only thing that hears you; we see ciphertext only. When the attested path is unreachable (offline, attestation failure), audio buffers locally on your phone — encrypted at rest — and uploads to the enclave the moment connectivity returns; the transcript appears on the recap once the upload completes. There is no on-device transcription path, no cloud STT vendor path, and no opt-in to bypass the enclave. The privacy-status pill during recording shows which mode is in use. Closed audio-understanding vendors (Deepgram Nova-3, GPT-4o-audio, Gemini, ElevenLabs) are not in our audio path at all — they cannot run in a customer-verifiable enclave.

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. When you sever the grant, their device loses the key — we don't ask politely; the cryptography enforces it.

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, you have 180 days to claim it back — after that, hard delete is irreversible. You can export everything you hold with us first as an encrypted .ttbk file, readable by a standalone offline tool — the format does not depend on us still being here.

10 Subprocessors

  • Cloudflare — Workers (gateway), D1 (metadata), R2 (ciphertext bodies)
  • Phala Network — confidential inference (TEE)
  • LiveKit — voice SFU (encrypted frames only)
  • RevenueCat — Apple IAP / Google Billing routing
  • Polar — web subscriptions
  • Twilio / Messagebird / Sinch — OTP delivery (phone + timing only)
  • 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.
  • 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.