Privacy
How privacy works.
Every chat in the private lane is sealed on your device and opened only inside sealed hardware that your device checks first. Below, the whole architecture in diagrams, each in plain words, in how it works, and in full detail.
Read it your way
In plain words
For everyone: what happens, without the jargon.
How it works
For engineers: the parts, and how they talk.
The details
For specialists: the chips, the standards, and the checks.
The idea
Locked until the vault.
One picture first. Every diagram below adds detail to it.
In plain words
Your device locks each message in a box that only the vault can open. Thinkr carries the box but has no key. The vault opens it, writes the answer, locks it again, and sends it back.
How it works
The vault is a hardware enclave. Before your device sends a word, it checks a report signed by the enclave's chip, then encrypts the message to a key that exists only inside the enclave.
The details
- Encryption
- HPKE, RFC 9180
- CPU
- AMD SEV-SNP · Intel TDX
- GPU
- NVIDIA, confidential mode
- If a check fails
- Nothing is sent
Architecture
Every part, and every link.
Your device, Thinkr's relay, and the enclaves, with the proof that ties them together.
In plain words
Three places handle your chat: your device, Thinkr's relay, and the enclaves. Only the enclaves ever see your words, and your device checks them before it trusts them.
How it works
The app verifies the attestation of the router enclave and seals to it. The relay forwards ciphertext and meters usage. The router verifies each model enclave, weights included, before it forwards.
The details
- Device to relay
- TLS 1.3, HPKE inside
- Router
- AMD SEV-SNP
- Models
- Intel TDX or AMD SEV-SNP
- GPUs
- NVIDIA, confidential mode
- Releases
- Signed, in a public log
Encryption
Two locks on every message.
One lock for the trip, and one for the words.
In plain words
The first lock protects the trip. The companies on the way can open it, and inside they find only the second lock, which opens only in the enclave.
How it works
TLS 1.3 ends at the edge of Cloudflare and at the relay. The body inside is an HPKE ciphertext sealed to the attested key of the enclave, so neither of them can read it.
The details
- Lock 1
- TLS 1.3
- Lock 2
- HPKE, RFC 9180
- Key exchange
- X25519
- Cipher
- AES-256-GCM
- Key of lock 2
- Made inside the enclave
Step by step
What happens when you press send.
Eight steps, from the first question to the last word of the answer.
In plain words
Before your words leave, your device asks the vault for its papers, checks them with the chip maker and a public record, and only then locks the message for that vault.
How it works
Attestation, then verification, then HPKE key encapsulation, then sealed transport. The router repeats the verification for each model enclave it sends to.
The details
- Report
- AMD SEV-SNP attestation
- Root of trust
- The chip maker
- Code check
- Signed release, public log
- Key
- HPKE · X25519
- Body
- AES-256-GCM
Inside the hardware
Sealed, even from the server.
What the chip keeps out, and what runs inside.
In plain words
The chip encrypts the enclave's memory with keys it never shows. The people and the software that run the server see only scrambled data.
How it works
SEV-SNP and TDX encrypt and protect the memory of the guest and lock the hypervisor out. The GPU takes only encrypted transfers from the guest, and must pass the attestation of NVIDIA before the server starts.
The details
- Memory
- Encrypted by the CPU
- Hypervisor
- Locked out
- CPU to GPU
- Encrypted transfers
- GPU check
- At boot, or no boot
- Disk
- Nothing written
The proof
A chain anyone can check.
From the key of the chip maker to the key your words are sealed to.
In plain words
Each link vouches for the next, from the company that made the chip to the key your message is locked to.
How it works
The device verifies the chain of certificates from the root of the chip maker to the attestation key of the chip, the signature of the report, and its measurement against the signed release in a transparency log.
The details
- Root
- Certificates of the chip maker
- Measured
- Code and model weights
- Releases
- Sigstore transparency log
- Pinned
- The expected release
- On failure
- Nothing is sent
Who sees what
Every party, every piece.
What each party on the path can see, and what stays sealed from it.
| Party | Your words | The answers | When and how much | Your IP address |
|---|---|---|---|---|
| Your network and ISP | Sealed | Sealed | Sees | Sees |
| Cloudflare, at the edge | Sealed | Sealed | Sees | Sees |
| Thinkr relay | Sealed | Sealed | Sees | Sees |
| The enclave provider | Sealed | Sealed | Sees | No |
| The data center | Sealed | Sealed | Sees | No |
| The enclave | Reads | Reads | Sees | No |
In plain words
Everyone on the way can tell that you sent something, and when. Only the enclave sees what you said.
How it works
The content is sealed from your device to the enclave. The metadata, the timing, the size, the model, and the address, stays visible on the path, and your IP address stops at the relay.
The details
- Content
- Device to enclave only
- Metadata
- Visible on the path
- IP address
- Stops at the relay
- Answers
- Padded in the stream
At rest
Where your data lives.
What is stored, where, and what is never stored.
In plain words
Your history stays with you. Thinkr keeps your account, not your chats. The enclave keeps nothing on disk.
How it works
The private lane is stateless on the server side: the relay meters, the enclave computes in memory, and the history lives on the device, sealed under a key that only you unlock.
The details
- History
- On your device
- Thinkr
- Account and usage
- Enclave disk
- Nothing written
- Open lane
- Zero data retention
Two lanes
Every model says who can read it.
The private lane is the default. The open lane serves the frontier models, with a label on each.
In plain words
The private lane is sealed and checkable. The open lane trusts a contract instead, and every model says which lane it is in.
How it works
Private-lane requests are sealed to attested enclaves. Open-lane requests go over TLS to the provider with zero data retention and data collection denied.
The details
- Private lane
- Sealed, attested
- Open lane
- TLS, zero retention
- Default
- Private lane
| Private lane | Open lane | |
|---|---|---|
| Models | Open-weight models | Claude, GPT, Gemini, Grok |
| Runs in | Hardware enclaves | The cloud of the provider |
| Who can read a chat | Only the enclave | The provider, and the relay in transit |
| Written to disk | Nothing | Nothing, by zero data retention |
| Proof | Remote attestation | A contract |
| Used for training | Never | Never |
Limits
What this does not protect.
Confidential computing lowers the risk. It does not remove it.
Physical attacks
Someone with physical access to a server and lab tools can attack the chip itself. The enclaves run in data centers that Thinkr does not own.
Side channels
Researchers keep finding ways to infer data from the timing or the power of these chips. The makers patch them, and the report names the firmware a chip runs.
Metadata
The network, the relay, and the provider see when you send, how much, and which model. The relay also sees your IP address.
The code of this web app
Your browser runs the code that thinkr.sh serves, so you trust that code as well as the enclave. Apps for desktop and phone come later.
Web search
With web search on, the search query leaves the enclave for a search provider. The rest of the chat stays sealed.
The keys of the chip makers
The proof rests on the keys of AMD, Intel, and NVIDIA. If a maker's key leaked, a fake report could pass.
Glossary
The words, in plain words.
Eight terms that this page uses.
- 01
Enclave
A sealed part of a server. The chip encrypts its memory, so the people and the software that run the server cannot look inside. Also called a trusted execution environment, or TEE.
- 02
Confidential computing
Running code inside enclaves, so that data stays encrypted even while it is in use.
- 03
Remote attestation
A report, signed by the chip, of exactly what an enclave runs. Anyone can check it against the keys of the chip maker.
- 04
Measurement
A hash of the code and the data that an enclave started with. Change one byte and the hash changes.
- 05
Transparency log
A public record of signed releases that can only grow. Anyone can audit it, so a secret release would stand out.
- 06
HPKE
Hybrid Public Key Encryption, RFC 9180: it seals a message to a public key with a fresh key for each message.
- 07
Metadata
Data about a message rather than in it: when it was sent, how large it is, and where it came from.
- 08
Zero data retention
A term of a contract: the provider keeps no prompt and no answer after it replies.
Questions
Asked often.
Can Thinkr read my chats?
Not in the private lane: your words are sealed on your device and opened only inside the enclave. In the open lane the provider of the model can read the chat, and the label of the model says so.
Who runs the hardware?
A confidential-computing provider runs the enclaves on servers in data centers. Neither it nor Thinkr can read a chat, and your device checks the proof before it sends a word.
What happens if the check fails?
Your device sends nothing, and the app shows that the check failed.
How can I check the proof myself?
Each private chat in the app shows a badge, Verified, that opens the proof: the chip, the hash of the code, and the open-source release it matched.
Does the enclave keep my prompt?
It writes nothing to disk. Your prompt and its answer exist only in the encrypted memory of the enclave while it works on them.
Why trust the chip makers?
Their keys are public, every report is checked before your message leaves, and the code inside is open source. You check a signature instead of trusting a promise.
Are my chats used for training?
No. The private lane keeps nothing, and the open lane sends every request with data collection denied.
Is Thinkr anonymous?
No. Thinkr keeps an account for your plan and sees the metadata of each request. It never reads the content of a private chat.