Maitland

How Maitland’s Encryption Works

Last updated: October 10, 2026

This page describes how Maitland protects what you write, what our server can see, and what the protection does not cover. The technical details are at the end.

This page is a description of a design. It is not a guarantee. No system is perfectly secure. The Maitland Terms of Use, including Sections 10 and 11, apply to everything here.

The short version

Your device encrypts what you write before sending it to our server. The key that does the encrypting is made on your device and is never sent to us in a form we can use. Our server stores your files but cannot read what they say. If someone copied everything on our server, they would get files they could not read without your key or your password.

The same protection works the other way too. Your phone and your browser accept only files locked with your own key, and refuse anything else, telling you so. That means our server cannot forge a file or change what one says without your device noticing. It can still withhold, delete or send back an older version of a file, and your device takes our server’s word for who sent you a task.

The protection covers your files while they travel and while they sit on our server. It does not cover your own phone or computer. Nothing you write is sent to an AI company.

Your key

The first time you use Maitland, your device creates a random encryption key of 32 bytes. Every file is encrypted with that key on your device before it is uploaded.

The key is kept in up to three places. All of them are yours.

  1. On your devices. On an iPhone or iPad the key is stored in the iCloud Keychain, which Apple syncs to your other Apple devices. In a web browser the key is stored in that browser’s local storage for maitland.app. Clearing the browser’s site data erases it from that browser, and that browser only.
  2. In your 24-word recovery phrase. The phrase is the same key written as 24 English words, using the published BIP-39 word list of 2,048 words — 256 bits of key and 8 bits of checksum, so a mistyped word is caught rather than silently opening nothing. You can see it under Settings → Account. Anyone who has the phrase has your key.
  3. In a locked copy on our server, if you signed up with an email address and a password. Your device uses your password to lock a copy of the key, and sends us the locked copy. We store it but cannot unlock it, because we never receive your password. When you sign in on a new device, the device downloads the locked copy and your password unlocks it there. If you use Sign in with Apple, there is no password and no locked copy; the iCloud Keychain is that account’s answer.

Your password

Your password never leaves your device. Your device turns it into two separate values. It runs the password through PBKDF2-HMAC-SHA256 for 600,000 rounds, salted with the SHA-256 of your email address, and then splits the result into two 32-byte values with HKDF-SHA256. One value is sent to us as your sign-in credential, and we store only a salted hash of it. The other value stays on your device and locks the copy of your key described above. Six hundred thousand rounds is deliberately slow; it makes each guess expensive, not impossible.

Accounts made before September 7, 2026 sent the password itself. We no longer accept it: signing in to one of those accounts asks you to reset your password first, which moves it onto the design above. Until the reset, our server still holds a scrambled form of the old password.

If you reset your password, the old locked copy is useless and we discard it. After a reset you need your 24-word phrase, or a device that still holds the key, to open your files. A reset also signs out every other phone and browser; each asks you to sign in again with the new password.

What our server can see

  • Your email address, and your Apple sign-in identifier if you use Sign in with Apple. With Sign in with Apple, the address is whichever one Apple gives us: your own, or a private relay address that forwards to it.
  • The salted hash of your sign-in value, the locked copy of your key, your sign-in sessions, and your sync tokens and when each was last used.
  • The token Apple gives us for sending your iPhone a silent sync notice.
  • For each encrypted file: its name, its size, when it last changed, and a fingerprint of its encrypted bytes. For a task or a page, the name is an ID the app made up, which includes the day it was made, and the file’s header also carries the time it last changed, in the clear. A page written with an Apple Pencil has handwriting files named after the page, so we can see that the page has handwriting, though not what it says. When you correct one of the app’s sorting guesses by hand, the correction is a file named for the moment you made it, so we can see when, and how often, you corrected a guess by hand, though not what you changed. A web page you keep is named after its title. For a document, a letter or a request, the name is the file’s own name — so a document you added as lease-2026.pdf has a readable name on our server, even though nothing inside it is readable. The number of files is visible for the same reason: they are files in a folder.
  • Which items you have deleted, by ID. A deleted item stays in your account’s trash, encrypted, for 30 days, and copies of changed and deleted files are kept for 14 days.
  • Your settings, list names, labels and contacts are inside one encrypted file like any other, so we can see that the file exists and nothing else.
  • When you send a task to another user: which account sent it, which account it is for, and when, until 30 days after it is collected.
  • The accounts you have blocked from sending you tasks, by account ID.
  • Which versions of the Terms of Use and the Privacy Policy you accepted, and when.
  • Your subscription, as Apple reports it: your plan and when it ends, which subscription you bought, whether it came through Family Sharing, Apple’s numbers for the original purchase, and when we last asked Apple. Also when your account was made, and the random code the app gives Apple with a purchase so that the purchase can be matched to your account. We never see your payment details or your Apple ID.
  • The IP address and time of requests. The web server in front of our application writes one line per request — address, result, and the browser or app identifier — with credentials, account IDs and file names removed, and keeps it 30 days. Our application writes errors and account events to the system log, sometimes with an account ID, for 30 days, and holds recent IP addresses in memory to limit abuse.
  • Daily counts of error reports, which say nothing about who sent them. They are described under “Error reports” below.
  • After an account is deleted: its account ID and the date it was deleted, with no email address, for two years, so that a device still signed in to it learns that it is gone.

What our server cannot see

  • Anything you have written: tasks, pages, notebooks, documents, labels, contacts and settings.
  • Your password.
  • Your key or your recovery phrase.
  • The contents of a task sent between users. The sender’s device encrypts it to a public key that belongs to the recipient, using an ephemeral P-256 ECDH key agreement and AES-256-GCM, and only the recipient’s devices hold the matching private key. This holds as long as the recipient’s public key that our server hands out is genuine. Our server erases the encrypted task 30 days after the recipient’s app collects it.

Signing in a web browser from your phone

A browser needs your key before it can read your files. The sign-in page makes a one-time key pair and shows its public half as a QR code. When you scan it with Maitland on your phone — Settings, then Account, then Sign in a browser — and approve, your phone agrees a shared secret with that browser’s public half and encrypts your key so that only that browser can open it, and sends it through our server. We relay it but cannot open it. The code is good for two minutes and one use.

Approve a code only on a screen that is in front of you. Anyone whose browser you approve gets your key.

What this does not protect

Dictation on older iPhones. On an iPhone that cannot turn speech into text itself, a dictated recording goes to Apple’s speech service, under Apple’s terms. It never passes through our server. Where the iPhone can do it itself, dictation stays on the phone.

Your own devices. On your phone your files are stored as plain text in the app’s own folder, so that the app can show them to you and so that you can open them in the Files app and in other apps. They are protected by your device’s own lock and built-in storage encryption, not by Maitland’s. Anyone who can unlock your device can read them. In a browser, your files are decrypted in the tab while you are using it, and that browser’s local storage also holds your key, anything you captured while offline, and any version of a page that lost a sync conflict. A reminder you ask for shows the words of that task in a notification, which can appear on your lock screen. Your iPhone’s notification settings decide whether it does.

Files you export. An export is plain text. Once you export a file, protecting it is up to you.

A weak or reused password. Someone who obtained the locked copy of your key from our server could try to guess your password. We make each guess slow, but a short or common password can still be guessed. A long, unique password is the defense.

Your iCloud account and backups. On Apple devices your key lives in the iCloud Keychain, and your phone’s backups to iCloud or a computer include the app’s plain-text files. Their security depends on your Apple ID and on Apple; unless Advanced Data Protection is on, Apple holds the keys to iCloud backups.

The web app’s code. Your browser downloads the web app from our server each time you visit, and that code is what handles your key. You are trusting that the code has not been tampered with, by us or by someone who broke into our server. This is true of every web app that encrypts in the browser. The iPhone app’s code arrives through the App Store instead.

Anyone you give your password, phrase or unlocked device to.

Mistakes. The software may have bugs, and the design may have flaws we do not know about. It has not been reviewed by an outside security firm.

If you lose everything

If you lose every device that holds your key, and your password (or you reset it), and your 24-word phrase, your files cannot be opened by anyone. We cannot help, because we never had the key.

Error reports

When the app shows you a failure, it sends our server a short error report: the kind of failure, chosen from a fixed list; the platform (iPhone or web); the app’s version and build number; and the date. It never contains your words, the name of a file or item, your account, your email address, a device identifier, the time of day or the text of the error, and it is sent without a sign-in cookie or sync key. Our server keeps no reports. It adds each one to a count, and keeps only the counts, in one file per day that holds how many times each kind of failure was reported that day for each platform and version, and nothing else. Nothing in that file links a count to a person or an account. To limit how many reports one source can send, our application uses a scrambled form of the sender’s IP address, held in memory and never written down. The web server in front of our application does not log reports.

Backups

We back up the server every night and keep the newest fourteen backups. Backups contain the same encrypted files and account records as the server. When you delete your account, it is gone from the backups within fourteen days.

Technical details

  • File encryption: AES-256-GCM, through Apple’s CryptoKit on the iPhone and the browser’s own WebCrypto on the web. A fresh 12-byte nonce for every write. The file’s ID is passed as additional authenticated data, so an encrypted file cannot be moved to another name.
  • Key generation: 32 bytes. SymmetricKey(size: .bits256) on the iPhone, crypto.getRandomValues in the browser.
  • Recovery phrase: BIP-39, English word list, 2,048 words. 256 bits of key plus an 8-bit checksum taken from the SHA-256 of the key, written as 24 words of 11 bits.
  • Password derivation: master = PBKDF2-HMAC-SHA256(password, SHA-256(“maitland-account:” + email), 600,000 rounds, 32 bytes); then auth = HKDF-SHA256(master, salt “maitland-account”, info “auth”, 32 bytes) and wrap = HKDF-SHA256(master, salt “maitland-account”, info “wrap”, 32 bytes). The email address is lowercased and trimmed first. auth is what we receive; wrap never leaves the device.
  • Server-side credential storage: scrypt with N=16384, r=8, p=1, over a fresh random 16-byte salt, 32 bytes out, compared in constant time. Where a server build has no scrypt, PBKDF2-HMAC-SHA256 at 600,000 rounds, recorded alongside the hash.
  • Key locking (“wrapping”): AES-256-GCM under wrap, 12-byte nonce, with the account identifier — the word email, a colon, and your address — as additional authenticated data, so a locked copy lifted onto another account will not open. We store the nonce and the box, check their shape, and read neither.
  • User-to-user tasks: an ephemeral P-256 ECDH key agreement to the recipient’s published public key, HKDF-SHA256 (salt maitland-handoff, the envelope’s ID as info), AES-256-GCM. The recipient’s key pair is derived from their own encryption key, so nothing extra is stored.
  • Browser pairing: a P-256 ECDH key pair made for that sign-in, HKDF-SHA256 (salt maitland-pair, the pairing ID as info), AES-256-GCM. The pairing is discarded after two minutes or one use.
  • Session tokens: 32 random bytes from the operating system, base64url. We store the SHA-256 of the token, never the token. If “Keep this browser signed in” is left unticked, the cookie ends when the browser closes, and our record of the session lasts 30 days from its last use; ticked, the sign-in lasts 90 days, counted again from each time you open the web app.
  • Transport: HTTPS, with certificates obtained automatically by Caddy, the web server in front of our application. The TLS versions and ciphers are Caddy’s defaults.
  • What is authenticated but not encrypted in each file: the file’s ID, which is both readable and bound into the encryption, and the time the file last changed, which is readable and not bound in. Everything else — every word, every facet, every attachment — is inside the encrypted body.

Reporting a problem

If you find a security problem, write to support@maitland.app.