encrypt.to

Privacy Policy

Effective [date — TO BE SET] · Operated by [legal entity — TO BE SET]

Draft — not in force. The operating entity, address, governing law and effective date are not yet set, and this text has not been reviewed by a lawyer. It describes how the service actually behaves, which is the useful half, but it is not a binding agreement and must not be presented as one.

Encrypt.to stores documents you encrypt in your own browser and delivers them to people you name if you stop checking in. This page describes what we hold, what we can read, and what we could hand over if compelled.

What we cannot read

Your documents are encrypted on your device before upload, with a key derived from your password. We never receive your password. What reaches us is a value derived from it that can verify a login but cannot unwrap anything.

For recipients you set up as Sealed or Public Key, we store ciphertext and wrapped keys and nothing that opens them. A full compromise of our cloud account, an insider with root access, or a subpoena served on us yields ciphertext. We could not decrypt those documents for a court if ordered to.

The exception, stated plainly. For a recipient you set up as an Open Link, we hold a key that opens the documents sent to them, because that recipient needs nothing at all to read them. Those documents are readable by us and we could be compelled to produce them. The choice is yours, per recipient, and the product marks it every time it appears. If you never create an Open Link recipient, this paragraph does not apply to your account.

What we store

  • Your account — email address, a hash of your derived login key, and your vault record: salts and your vault key wrapped by your password and by your recovery code. None of these can be unwrapped without something we do not have.
  • Your documents — as encrypted containers, plus their size and chunk layout. Filenames and file types are inside the encrypted header, so we do not know what any document is called or what kind of file it is.
  • Your recipients — the name, email address and any phone number you give us, the delivery mode, and any public key you paste in.
  • The optional line you write for a recipient to see — shown at the top of the email they receive. This is the one piece of content you give us that we can read, because it has to be plain text by the time it reaches a mail server. The product says so where you type it.
  • Your schedule — check-in interval, grace period, deadlines, and a log of check-ins, reminders and state changes.
  • Security settings — if you enable two-factor: an authenticator secret, hashed backup codes, and the public half of any security key you register.
  • Short-lived tokens — for sessions, email links and delivery links, stored hashed and deleted when they expire.
  • Rate-limit counters keyed by IP address, kept briefly to slow down guessing attacks.
  • Anything you send us through the contact form — your message, the name and email you give, and the IP it came from. Kept for a year so we can answer follow-up questions, then deleted automatically.

What we never receive

Your password. The 10-word passphrase on a Sealed recipient card. Your 15-word account recovery code. The contents or filenames of your documents, except as described in the Open Link exception above. All of these exist only in your browser.

Recipients

Adding a recipient does not contact them. They are told nothing until a delivery actually happens, or until you deliberately send them a test. That is a deliberate design decision: for many customers, the fact that an arrangement exists is itself the sensitive information.

It also means a recipient may have no idea we hold their name and email address. Where the law gives people a right to be informed that their data is held, that right is in tension with keeping the arrangement confidential. This is an open question for [the operator — TO BE SET] and its advisers, not a settled position. If you are a recipient and have received a delivery from us, you can ask what we hold about you at support@encrypt.to.

Who else processes your data

  • Amazon Web Services — hosting, encrypted document storage and key management, in the US East (Ohio) region.
  • Neon — the database holding everything listed above except the document contents.
  • Mailjet — sends reminder and delivery emails. It therefore sees the email addresses of you and your recipients, and the text of those messages, which never contains document contents or passphrases.

Cookies and tracking

There are none. No cookies, no analytics, no tracking pixels, no third-party scripts. Your session is kept in your browser’s local storage and is never sent anywhere except to our own API. We do not profile you and we have nothing to sell.

Retention

Documents and account data are kept until you delete them or close your account. Expired tokens are purged automatically. Audit events on your trigger are kept for the life of the account, because a record of what was sent and when is the only way to answer a question about a delivery afterwards.

Your rights

You can export or delete your documents at any time from your account, and you can close your account entirely. Depending on where you live you may also have rights to access, correct, or object to our processing; write to support@encrypt.to.

One honest limit: we cannot give you your documents in readable form, because we cannot read them. We can give you the encrypted containers, and you can open them with your own password using the standalone decryptor.

Contact

support@encrypt.to · [legal entity — TO BE SET], [address — TO BE SET]