End-to-end encryption
Shares the server stores but cannot read. Off by default
An encrypted share is sealed on the uploader's machine before it leaves, so the instance stores and hands out bytes it holds no key for. Opening it happens on the recipient's machine.
Off by default. Turn on features.encryption to accept them. Turning it off again refuses new ones and leaves existing ones retrievable.
Who it protects against
The operator, and anyone who gets what the operator has. A database dump, a copy of the bucket, a storage provider reading its customers' objects: all of them see sealed bytes.
That makes it worth having on an instance run for people the operator does not know. On an instance you run for yourself, the only person it keeps out is you.
Not against a page that lies
In a browser, the code doing the sealing is JavaScript this same server sent. An operator who wanted the keys could serve a page that sends them home, and no web application can rule that out from inside itself. What it does rule out is stored data being read later. The command line does not have this gap, because its code did not come from the server it talks to.
Two ways to hold the key
In the link. The key is written after # in the share's address. Browsers never send that part to a server, so whoever has the whole link can open the share and whoever has only the retrieval code cannot.
From a password. The key is derived from a password, so the code and the password are enough and both can be read out over the phone.
A password-derived key has two costs
Whoever has the stored bytes can guess passwords offline, so the password must be at least 12 characters and the client refuses anything shorter before uploading. And because the key comes from it, the password of such a share can never be changed or removed.
What is hidden, and what is not
| Hidden | Not hidden |
|---|---|
| The content | How large each file is |
| File names and types | How many files there are |
| The title | When it was made and when it expires |
| A text share's language | How often it is fetched, and from where |
The second column is what the instance needs to enforce quotas, expiry and limits.
What works differently
- Several files arrive one at a time, never as an archive. An archive would have to be built from content the server cannot read.
- The link preview says only that the share is end-to-end encrypted, and its size.
- Virus scanning skips it. There is nothing a scanner could read. See virus scanning.
- Text cannot be opened as plain text from the raw link; it has to be decrypted by a client first.
From the command line
tess sends and fetches encrypted shares too.
tess send --encrypt holiday/
tess send --encrypt --password report.pdf
tess get 'https://files.example.com/s/0ZPQ4M7K#…'--encrypt alone puts the key in the link, after #. With --password the key comes from the password instead, which has to be at least 12 characters, and the recipient needs both the link and the password. tess get asks for the password, or reads TESSERA_PASSWORD.