Skip to main content
Tessil

Verify it yourself

Every encrypted transfer service claims it cannot read your files. Here is how to check ours, in about two minutes, with tools already in your browser.

You should not have to trust us, and these checks do not ask you to. None of them rely on something we assert. Each one relies on something your own browser reports, and you can run them against the live site right now.

You will need a transfer you sent to yourself, and your browser's developer tools: F12 on Windows and Linux, Cmd + Option + I on a Mac.

1. The key never reaches our servers

Send yourself a file from the homepage. The link you get back looks like this:

https://tessil.app/d/7f3a9c2b#kA9tR2xQ...

Everything after the # is the decryption key. Your browser generated it, and it is the only thing that turns our stored ciphertext back into your file.

  1. Copy the part of the link after the #.
  2. Open the link, then open developer tools and select Network.
  3. Reload the page and let it finish loading.
  4. Search the recorded requests for the key you copied.

What you should see: no matches. Not in a URL, not in a header, not in a request body.

Browsers do not send the fragment (the part after #) to servers. That is the HTTP standard, enforced by the browser you are already running, not a policy we promise to honour. There is no request we could quietly inspect to learn that key, because it is never transmitted.

2. What we store is unreadable

  1. With the Network tab still open, download the file.
  2. Find the request to an address ending in r2.cloudflarestorage.com. That is the stored object, byte for byte as it sits on our storage.
  3. Open its response.

What you should see: binary noise, beginning with the four characters TSL1.

That is our container format marker. Not your file, not your filename, not a thumbnail. The readable file only comes into existence after your browser applies the key from step 1. If somebody walked off with our entire storage bucket, this is what they would have.

3. Nothing else is running on the page

  1. Still in the Network tab, look at every domain the page contacted.

What you should see: tessil.app, api.tessil.app, and a storage URL. That is the entire list.

No analytics, no tag manager, no fonts pulled from someone else's CDN, no session recorder. On a page whose URL contains a decryption key, a third-party script is not a privacy nuisance, it is a key leak.

This is enforced rather than promised. Two Content-Security-Policy layers apply to every page and both have to pass. The first is a response header you can read yourself:

curl -sI https://tessil.app | grep -i content-security-policy

connect-src there limits network requests to our own origin and the storage host, so a script could not phone home even if one were added by mistake. The second layer is in the page itself: view source and you will find a content-security-policy meta tag whose script-src pins the exact SHA-256 hash of the only inline script we ship. Any other inline script, injected by anyone, fails the hash and never executes.

4. Read the code

Optional, and the slowest of the four, but it is the only check that shows you intent rather than behaviour. Tessil is AGPL-3.0 and the entire client is public. The files that matter:

  • src/lib/crypto/streaming.ts is the encryption itself
  • src/lib/crypto/key.ts generates the key that goes into the link fragment
  • src/lib/download/streamDownload.ts decrypts on the way back

github.com/tessil-app/tessil-web and tessil-api. AGPL-3.0 means anyone running a modified Tessil as a service has to publish their modifications, so a hosted fork cannot quietly remove the encryption.

What we can see

The checks above are worth little without this part. We do not need to be trusted about your file contents, because the maths handles that. We do need to be trusted about the following list, so here it is in full:

  • The size of each file and when it was uploaded
  • How many times a transfer has been downloaded
  • When a transfer expires, and when it was deleted
  • Your email address, if you chose to create an account
  • For sign-in events, the country and network operator derived from your IP address at that moment. We do not store IP addresses.

File contents, filenames, and transfer titles are not on that list, and cannot be, because they arrive encrypted. The full detail lives in the security overview and the privacy policy.

Found something that does not match?

If any check on this page comes out differently than described, that is either a bug or a broken promise, and we want to hear about it either way. Mail [email protected]. Acknowledgement within 72 hours.