Security

Security is job #1. Mikipage exists so you can write down the things you haven't shown anyone yet — so keeping them safe is not one feature among many, it is the job. We will never trade it for convenience, growth, or a deadline. When protecting your data and shipping something faster pull in different directions, protecting your data wins.

This page says what that means in practice, specifically rather than reassuringly. For the promises behind it — who at Mikipage may ever look at your data, and what happens when you leave — see [1].

Where your data lives

On AWS. Mikipage runs on Amazon Web Services in the US (us-east-1): the app, the database that holds your notes and pages, and the storage for your files. The search index that powers meaning-based search runs on Qdrant Cloud, hosted in the same AWS region.

Encrypted in transit

Every connection goes over HTTPS (TLS). Nothing travels in the clear.

Your browser to Mikipage. The website, and the APIs behind it and the [2] at api.mikipage.com, are served only over HTTPS. The APIs accept TLS 1.2 or newer and refuse anything older.
Signing in. Signing in on the website uses the Secure Remote Password protocol (SRP), so your password itself is never sent — not even encrypted; only a proof that you know it is. Connecting the API or an AI assistant signs you in on auth.mikipage.com, AWS's sign-in page, over HTTPS.
Our servers to each other. The app reaches the database, file storage, the search index and the AI model providers over TLS as well. The file storage rejects any request that isn't encrypted.

Encrypted at rest

Everything we store is encrypted on disk with AES-256:

What	Where	How
Notes, pages, groups, account data	Amazon DynamoDB	AES-256, keys managed by AWS
Files and pictures	Amazon S3	AES-256 (S3 server-side encryption)
The search index	Qdrant Cloud	AES-256 encrypted storage volumes
Database backups	Amazon DynamoDB	Encrypted the same way as the tables

On your own device

To stay fast and work offline, the web app keeps a copy of your recent notes in your browser's storage for this site. That copy is protected the way your browser protects any site's data, but it isn't encrypted by Mikipage, so use Mikipage on devices you trust. A protected note is the exception: only its encrypted form is ever kept there.

Who can read your notes

Your Personal notes are yours. No other user can see them.
A note you share to a group is readable by that group's members. They can't edit it.
Nothing is public unless you make it so — by putting it in a group and deliberately making that group public. Then anyone can read it on the website, no account needed. See [3]. The API and MCP still serve it only to you and the group's members. Any signed-in user can comment on it.
Your files follow your notes. A file you upload is readable by you, and by anyone who can read one of your notes that references it. Someone else pasting its reference into their own note doesn't let their readers open it.
AI reads your notes when it runs. Building pages, AI Polish and chat send note text to the AI model providers that do the work. That is how the AI features work at all, and it is exactly what a protected note opts out of.

Encryption at rest protects your data from someone who gets hold of a disk. It does not stop Mikipage's own servers from reading your notes — they have to, to search and organize them. For the handful of things you want nobody but yourself to be able to read, use a protected note.

Protected notes

A protected note is encrypted in your browser, with a password you choose, before it is saved. The password never leaves your browser and is never stored anywhere — not on our servers, not in your browser's storage. What reaches Mikipage is ciphertext: a block of scrambled text that nobody at Mikipage, and nothing in Mikipage, can turn back into your words.

That makes it a note the product deliberately cannot help with — no search inside it, no AI, no version history. Keep it for the things that are worth that trade.

Protecting a note

Open the note, and choose Protect from its ⋮ menu. Pick a password (at least 4 characters) and type it twice.

The note's text moves into the encrypted part, and the note's visible text is replaced with a short description — "Protected note. Add a description here." — which you can edit. The note stays unlocked, so you can carry on.

You don't have to save first. On a new note, Protect is there as soon as you start typing, and whatever is in the editor — saved or not — is what gets encrypted. Protecting before the first save means the text never reaches our servers as anything but ciphertext.

Protecting cannot be undone. A protected note stays protected. If you ever want an ordinary note back, unlock it, copy the text into a new note, and delete the protected one.

Locked and unlocked

A protected note is either Locked or Unlocked; the badge on the left of the note's action bar shows which, and clicking it switches.

Locked, you see the description and the encrypted text exactly as it is stored — the same block of letters and numbers our servers hold. It can't be edited.
Unlocked, you see the text, and Edit opens two fields: the description and the protected text. Save writes both.

Unlocking lasts only while the note stays open in that tab. Moving to another note, reloading the page or closing the browser locks it again. The unlocked text lives in the page's memory only — it is never written to your browser's storage, and there is no draft recovery for it, so save before you leave. Locking a note you are editing saves your changes first.

Changing the password

Unlock a note, then choose Change password from its ⋮ menu. Only the note's owner can do this, and it needs an internet connection. The current description and protected text are saved together under the new password; people you shared the note with will need that new password too. The note stays unlocked in the mode you were using.

Changing the password creates a new random salt and encryption key. It is not password recovery — you must unlock the note first, and a forgotten password still cannot be reset. It is not access revocation either: somebody who kept an older ciphertext copy can still open that copy with the old password.

The description

The description is not encrypted. It is what you see in your notes list and in search, what tells one protected note from another, and what AI can read like any other note. Write something that reminds you what's inside — "bank logins", "safe combination" — without giving the secret away.

Files

Files are not encrypted, so on the website a protected note can't have any: there is no attach or insert-picture option while editing one, and a note that already references files must have them removed before it can be protected. Through the API, a protected note's visible description can still reference a file — that file is stored like any other, unencrypted. A file referenced only from inside the encrypted text doesn't count as used, since Mikipage can't read that text, so it is deleted like any other unused file. For a sensitive file, encrypt it yourself before uploading it anywhere.

You can share a protected note to a group. Members see the description and the encrypted text — in the app, through the API and through MCP — and can unlock it only with a password you give them yourself, outside Mikipage.

In a public group, the public page shows only the description. The encrypted text is never on the public page, and it never reaches anyone who isn't a member through the API or MCP.

Anyone who holds the encrypted text — and that includes every member of the group — can try passwords against it on their own computer, as fast as their hardware allows, with no limit we can enforce. A short password falls quickly. For a note shared with many people, use a long passphrase: several random words, not a word and a number.

If you forget the password

The protected text is gone. There is no reset and no recovery, by you or by us — a reset would mean we held the key, and the whole point is that we don't. Choose a password you will remember, or keep it in a password manager.

What happens to the note's history

Protected notes keep no version history, and protecting a note deletes the history it already had, so earlier copies of the text don't linger. The note's AI-generated title and summary are cleared too.

Protecting a note can't reach back into things that were made from it before you protected it: a page already built from it, a chat or AI run log that quoted it, a comment, or a notification email. Those keep what they said until they are refreshed, edited or deleted. If the note was published with a public web address, that address may contain words from its first line; you can change it in the note's details. For something truly sensitive, protect the note before sharing it or building pages from it.

Under the hood

For the technically curious: the key is derived from your password with PBKDF2-SHA256 (600,000 iterations) and a random salt, and the text is encrypted with AES-256-GCM, using the Web Crypto API built into your browser. The stored value is a Base64 string holding a version byte, the salt, a fresh random IV for every save, and the ciphertext with its authentication tag. The API documents the same format, so a program holding the password can decrypt a protected note without us. Ordinary saves retain the salt; changing the password deliberately creates a new one.