Field notes

What a relay that can’t read still sees

Our relay passes ciphertext it can’t open. That isn’t the same as seeing nothing. An inventory of what it does see, and why.

Between your browser and Tinfoil sits a small server of ours: the relay. It exists to check who is asking, to swap in our Tinfoil key and to charge the allowance. It can’t read your messages, because they’re encrypted to the enclave’s key before they reach it. “Can’t read” is still not “sees nothing”, and it’s worth being exact about the difference.

What it sees

  • Who is asking: your account or key, which it checks before passing anything on.
  • When, and how much: each request’s time and size, and the size of the answer.
  • Which enclave answered: Tinfoil names the model enclave in a response header, which the relay reads to price the request.
  • Your IP address, through our host.
  • Two hints the workspace adds for pricing: that a request used web search, and how many images it carries and how large they are.

What it doesn’t see

The words you write, the files you attach and the answers you get. It also can’t see which model you asked for, only which enclave answered, and it can’t count tokens, since they’re inside the ciphertext.

Charging for what it can’t read

So the relay charges from sizes. At the time of writing it counts 3 request bytes and 130 answer bytes as a token, both chosen to err high, at the price of the model that answered, or the priciest model when it can’t tell. Images would be overstated about a hundredfold by size, so the workspace declares them, and each is charged as 3,000 input tokens.

The relay can’t confirm the workspace’s hints. A modified client could leave off the search hint, or claim more of a request is images than it is, to pay less. Per-person and total daily budgets bound what that can cost, and the check before each request bounds any single overrun. We chose that over reading requests to price them exactly.

What it forwards, and what it keeps

  • It forwards only to Tinfoil’s own hosts, and only bodies that carry an encryption header, so it can’t be pointed somewhere else or pass plain text.
  • It returns three headers from Tinfoil and drops the rest.
  • Its logs hold route names, status codes and timings only: never prompts, answers, account IDs or keys. Tests check this.
  • For the transparency page it counts requests and failures as totals by day, with nothing per person.

Why say all this

Metadata is where privacy promises usually go soft: timing, size and identity can say a lot on their own. A relay that can’t read is a real improvement on one that can, and it still knows when you work, how much and from where. If that matters for what you do, the threat model sets out who could see each part, and the privacy page says how long each is kept.

More field notes

  1. What an attestation proves, and what it doesn’t

    Your browser checks Tinfoil’s enclave before it sends a word. What that check establishes, where it stops, and what can’t be checked in a browser yet.

  2. A key after the #: how shared links keep the server out

    A shared conversation is stored on our server, and we can’t open it. How that works, where the password comes in, and what a link can’t protect.