What our server
can see.
This is the list we are building to. When gotin opens it will be generated from our database schema on every release, so it can't quietly fall out of date.
What we can see
- The sealed file, which is unreadable to us
- Its size, rounded up so exact sizes don't leak
- How many files are in a request
- When a file was uploaded and downloaded
- The link's expiry date
- Your account email
- A hash of your IP address that changes daily, used only to slow down guessing
What we can't see
- What's inside your client's files
- File names or file types
- The exact size of a file
- Any note your client adds
- Your passphrase, or any key that opens the files
Sealed in between. Readable only at each end.
The file is encrypted on your client's device and decrypted on yours. What sits on our server in between is a sealed copy.
Readable
Your client picks the file. It is encrypted before it leaves their device.
Sealed
We store a copy we cannot open. No file name, no file type, no key.
Readable again
Your team's key opens it on your device. Nobody else has that key.
Who holds what.
Your passphrase
It never leaves your device. We can't see it and we can't reset it.
Your team's key
Unlocked on your device by your passphrase. We never hold a key that opens your files.
Your recovery key
Shown at setup for you to save. It is the only way back in without the passphrase.
The sealed files
Stored until the request expires, then deleted. Unreadable to us the whole time.
Three bad days, and what each one gets.
These hold because of how files are sealed. They do not depend on our servers behaving correctly.
Someone gets into our servers.
They get sealed files and locked keys. Nothing stored there opens a file. The keys that do are unlocked only on your team's devices.
Someone copies a request link.
They can see what you asked for and add files to it. They cannot open anything that was uploaded, because the link holds no key that opens files.
Someone records the traffic and waits.
The key exchange uses two methods, and one is built to resist a quantum computer. A file recorded today stays sealed unless both are broken.
Enforced by our servers, not by cryptography.
These protect you, but they depend on our servers behaving correctly. We label them so you can weigh them accordingly.
Expiry
Links stop working on schedule.
Delete after download
We delete the file. A recipient could still keep a copy.
Limits and rate limits
Caps on size, count and guessing.
Three public methods, and what each one does.
No cryptography of our own. Each method is published, and the specification says exactly how it is used.
Two methods together, one of them built to resist a quantum computer. A sealed file stays sealed unless both are broken.
Each file is sealed in pieces. A piece that is changed, missing or out of order is refused, and the file does not open.
Slow and heavy on memory by design, so every guess at a passphrase costs an attacker time.
Check our work.
The specification
How files are sealed and opened, written to be checked.
Read the specificationAudit report
Not available yet. It will be linked here when there is one.
Buying for a regulated team?
Ask how the keys, the records and the deletion work. Your message goes to the people building gotin.