Back to Paige

Encryption

How the encryption works

The short version: what you write is locked on your phone before it’s sent, and our server only ever holds a scrambled copy it can’t open. This page spells out what’s locked, the few things that aren’t, and how the locking works. There’s a way to check all of it near the bottom.

A note is encrypted on your phone, travels to the server as a sealed blob the server cannot open (it can read only the entry type and time), and is decrypted on your partner's phone. The household key exists only on the phones. Your phoneFeed · 2:02pm“20 min, right side”locked before it leaveshousehold key lives herealreadylockedOur serverfeed · 2:02pmtype and time, readableqL3vN8kZ0m4…your note, sealedno key here, can’t open itstilllockedYour partner’s phoneFeed · 2:02pm“20 min, right side”unlocked on arrivalsame key lives here tooThe key never visits the server. How it gets from one phone to the other is further down this page.

What’s locked

When you log something, the words and details you type get encrypted on your phone before they go anywhere. That covers your notes, the feed details, the nappy details, the weights, the milestones, your baby’s profile (meaning their name and date of birth), and the names household members give themselves. All of it leaves your phone already scrambled, and our server stores it that way. We don’t have the key, so we can’t turn any of it back into anything readable.

What the server can see

Not everything can be hidden. For the app to sync between phones and remind you about a feed while it’s closed, a few things have to travel in the clear. Here’s the honest list of what our server can see:

  • The type of each entry, like a feed, a nappy or a sleep.
  • When it happened.
  • The state of a running timer, so a feed you start on one phone shows up on the other.
  • An id for which person in your household logged it. It’s a random-looking string, not a name.
  • How many people are in your household.
  • A label for the kind of device, like a phone or a tablet.
  • One brief exception: when someone joins your household, the name they type travels in the clear until the pairing finishes, because their phone doesn’t hold the key yet. It’s scrubbed once the pairing is approved or denied, and their name is stored encrypted like everyone else’s.

Here’s what that looks like in practice. This is the shape of the request that logs a feed:

POST /api/events the server can read it sealed
{
"client_id": "b1f04c…",a random id so a retry on bad signal can’t create a duplicate
"category": "feed",the type of entry, in the clear, so reminders can work
"occurred_at": "2026-07-08T14:02:11Z",when it happened, in the clear, same reason
"ciphertext": "qL3vN8…",your note and every detail, locked with your household key
"iv": "9dKf2A…"the fresh random value used for this one entry
}

Why the type and time aren’t hidden

Paige can remind you when a feed’s due, and that reminder is a push notification our server sends while the app is shut on your phone. A server can’t remind you about a feed whose time it can’t see. So the type of entry and when it happened travel in the clear. That’s the trade-off: the reminders work, and in exchange the server knows a feed happened at 2pm, but not a single word you wrote about it.

How the locking works

Your household has one key. It’s made on your phone the moment you set Paige up, and it stays on your devices. You never see it or type it. When you log something, Paige takes your note and details, locks them with the key, and picks a fresh random value each time so that two identical notes never produce the same locked blob. The locked blob and that random value are what get sent. That’s the whole of it.

This runs in the page with the browser's own encryption (AES-GCM, 256-bit key), the same primitive the app uses. Nothing you type here is sent anywhere.

For the technical reader

If you’d rather see the actual algorithms, here they are.

  • Event contents (your note and the tagged details) are encrypted with AES-GCM, a 256-bit key, a fresh random 96-bit IV per message, and the default 128-bit authentication tag.
  • The household key is generated on-device with the browser’s Web Crypto and kept in IndexedDB. It never leaves in the clear.
  • Getting the key onto a second phone uses an ECDH P-256 handshake to derive a one-time wrapping key. Only the wrapped key ever crosses the wire.
  • Each device has its own ECDSA P-256 keypair for signing in. The private key is non-extractable and never leaves the device; signing in means signing a server’s one-time number, nothing more.
  • Recovery uses a 12-word BIP-39 phrase (128 bits of entropy). HKDF-SHA-256 turns it into two keys: one that unwraps your data key, and one secret the server only ever holds as a SHA-256 hash.
  • The sign-in cookie is an HMAC-SHA-256 signed token. There’s no password stored anywhere.

Getting the key onto a second phone

When your partner joins, or you add a tablet, the two phones do a short handshake so the key can move across without our server ever seeing it. The new phone shows a short code, which you type into a phone that already has the key. On its own the code does nothing. Both phones then show the same four-word phrase, and you check out loud that they match. If they do, the phone with the key wraps it up sealed so that only the new phone can open it, and our server just passes the sealed bundle along. If someone tried to sit in the middle of that handover, the four words wouldn’t match, and you’d stop.

How the household key moves to a new phone: a short code and a four-word check between the two phones, then a sealed key passed through the server, which cannot open it. New phoneServerYour phoneyou read the short code off the new phone and type it into yoursa person carries this, not the networkfern · otter · lamp · dawnfern · otter · lamp · dawnboth phones show the same four words, you check them out loudthe household key, sealed so only the new phone can open itcan’t open it, just passes it onthe same sealed blobthe new phone opens it with its half of the handshake
The four words come out of the handshake itself. If anything sat between the two phones, the words wouldn’t match, and you’d stop before the key ever moved.

If you lose your phone

When you first set up, Paige shows you twelve recovery words, once. They’re the way back if you lose every device. Our server keeps two things to make that work: a locked-up copy of your household key, and a hash of a secret those words produce. Neither is any use without the words themselves. Type the words on a new phone and it unlocks the key and pulls your log back.

There’s no softer version of this to offer. If you lose every device and you don’t have the words, the data is gone. We can’t get it back, because we never had a key to it. Keep the words somewhere safe.

Check it yourself

You don’t have to take our word for any of this. Here’s how to watch what leaves your phone:

  1. Open Paige in a desktop browser and sign in to your household.
  2. Open the browser’s developer tools and go to the Network tab. (Right-click the page, choose Inspect, then Network.)
  3. Log a feed, and put a note on it, something you’ll recognise.
  4. Find the request to /api/events and look at what it sent.

You’ll see the type (feed) and the time in plain text, and then two scrambled blobs: the ciphertext and the iv. It’s the same shape as the request pictured further up this page. Your note is inside the ciphertext, and you won’t be able to read it there. That’s the whole claim, sat in front of you. Hold this page to that standard.

What this means we can’t build

Not being able to read your data rules a couple of things out, and that’s on purpose.

  • No insights or analysis built on our side. We can’t chart your content or find patterns in it on the server, because to us it’s a sealed box. Anything like that has to happen on your own phone, where the key lives.
  • No password reset in the usual sense. There’s no account and no password to reset, and no way for us to recover your data if the words are gone. The recovery words are it.

Questions

This page is about how the locking works. For the wider picture, what we collect, cookies, website analytics, and how to export or delete your data, see the privacy page.

And if you want to poke holes in any of this, please do. Email [email protected] and a real person will reply.