This is written plainly on purpose. Where a thing is technically possible but we do not do it, this page says so rather than implying it is impossible. If anything below is unclear, write to hello@albient.com and we will fix the wording.
The rule the rest of this page rests on
Nobody at Albient reads your mail, your files, your repositories or your messages. Not to improve a service, not to train anything, not out of curiosity.
Administrative access to the machines is limited to the people who run them, and every such session is logged. That access is used for three things only: dealing with abuse coming from an account, a lawful order we are compelled to obey, and a fault you have asked us to look into. If we ever look at your content for that third reason we will say so first, and we will look at as little as the problem requires.
That is a policy, not a law of physics. The point of the rest of this page is to be clear about which is which.
This website
albient.com sets no cookies, runs no analytics, and makes no request to any third party. The fonts, the images and the one script on the front page are all served from this domain. Your light or dark choice is stored in your own browser and never sent to us.
Post: mail, calendar and contacts
This is the service where the honest answer is the longest one, so here it is in order.
Mail arrives in the clear. A message sent to you crosses the internet as the sender wrote it. The connection between their server and ours is normally encrypted in transit, but the message itself is readable at the point it reaches us, unless the sender encrypted it to your key themselves.
It is scanned before it is stored. On arrival every message goes through spam and virus checks. That scanning reads the message. It happens automatically, on our machines, and nothing about it leaves them.
Then it is encrypted at rest. If you have given us a PGP public key, the message is encrypted with it before it is written to disk. After that nobody at Albient can read it, and nor can anyone who walks off with a disk. We cannot recover it for you either: if you lose your private key, that mail is gone.
So there is a window, between the message arriving and being written to disk, in which the system holds it in the clear and in which a person with administrative access to that machine could in principle read it. We do not. But we will not tell you the window does not exist, because it does, and no mail provider can remove it. The only way round it is for the sender to encrypt the message to your key before they send it, in which case we never see anything but ciphertext.
Outgoing mail leaves in the clear in the same sense. We use TLS to the receiving server wherever that server supports it, which is most of the time now, but we cannot make the other end do anything. Once a message has left us it is subject to whatever the recipient’s provider does.
Without a PGP key your mail is stored on encrypted disks but not encrypted per-account, so it is readable to the system in the same way most mail is. The policy above is what protects it.
Headers and delivery records. We keep the ordinary mail logs a server needs to deliver mail and to fight spam: who connected, when, the envelope sender and recipient, the result. They are kept short-term, for weeks rather than years. We do not keep a record of what you read, when you read it, or what you searched your mailbox for.
Calendar and contacts are stored as you enter them and are not encrypted with your key, because the protocols your devices use cannot work that way.
Ward: your account
Ward holds your username, the e-mail address we write to, a recovery address if you give one, your passkeys and public keys, your live sessions, and the groups you belong to. That is the list. There is no profile, no marketing record, and no third party involved in signing you in.
Passwords, where you use one instead of a passkey, are stored hashed; we cannot read them. Sessions record the time, a device description and an IP address, so that you can recognise and revoke them. You can see all of this yourself, export it, and delete the account.
Hord: code hosting
Public repositories are public: that is the point of them.
Private repositories are visible to you and to whoever you share them with. They are stored on our disks unencrypted, because a forge has to read your code in order to serve it, index it and run pipelines on it. An administrator could therefore read a private repository. We do not, under the rule above.
Pipelines run on our own runners, in London. Secrets you set on a repository are encrypted at rest and decrypted only inside the job that uses them, and they are masked in logs, though a job you write yourself can of course print anything it is given.
Moot: chat
Rooms that are end-to-end encrypted, which is the default for private rooms, are unreadable to us. We hold the ciphertext and the metadata the protocol needs: who is in a room, when messages were sent, room names and membership changes.
Rooms that are not encrypted, which includes most large public rooms, are stored in the clear and are readable to an administrator in principle. If a conversation matters, keep it in an encrypted room.
Matrix is a federated network. Anything you send into a room with people from other servers is copied to those servers, and what happens to it there is their business, not ours.
Leaf: sites
Everything you publish on Leaf is public by nature: that is what publishing means. Do not put anything in a site repository that you do not want the world to have.
We serve your pages and keep short-lived access logs for the same reasons any web server does. Nothing is injected into your pages, no visitor is tracked, and no script of ours runs on your site.
Watch: status
Watch holds no personal data at all. If you subscribe to incident notices we keep the address you gave us and nothing else, and you can remove it yourself.
Keep: passwords, when it arrives
Keep will be a vault encrypted in your own client before anything reaches us. We will hold an encrypted blob we cannot open, and we will never have the key that opens it. If you forget your master password we cannot help you, and that is the correct trade.
Chest: files, when it arrives
Chest will store your files server-side, on encrypted disks, with our keys rather than yours. That is what makes sync, sharing, previews and collaborative editing work. It also means an administrator could in principle read a file you have stored. We do not, under the rule above; but Chest will not be the place for something you need to be cryptographically certain nobody can open.
Logs, everywhere
Our servers keep short-lived operational logs: connection times, IP addresses and error records, which are what a mail or web server needs in order to stop abuse and to work out why something broke. They are kept for as long as that takes and no longer, and they are not used to build any picture of you.
Where it lives
The machines are in London and the service is run from Wessex, under the law of the United Kingdom. A second copy is taken to Falkenstein in Germany every night so that one provider’s bad day is not also yours. Both copies are ours, and the backups are encrypted.
Your rights
Under UK data protection law you can ask what we hold about you, ask for it to be corrected, ask for it to be deleted, and take a copy away with you. Ward lets you export and delete your account yourself, without asking anyone. For anything Ward does not cover, write to hello@albient.com.
If the law comes asking
If we are compelled to hand something over we will comply with a valid order, and we will tell you it happened unless we are forbidden from doing so.
Changes
If this notice changes we will publish the new version here before it takes effect, and the change will be visible in the history of this site’s repository on Hord.