How Nesora protects your memories
In short: everything Nesora analyses — faces, text in documents, ages — is worked out on your phone, and face data stays there. Encrypted backup and sharing are optional. When you turn them on, photos are encrypted on your phone before they are uploaded, with keys that only you and the people you invite hold. Our server stores encrypted bytes it cannot open, plus the small amount of metadata it needs to decide who may download what. There is no email or password: your account is an anonymous key.
1. How the pieces fit
Nothing in the middle box is needed to analyse your photos: Nesora works fully on your phone without it. The server only comes into play if you turn on Encrypted backup or private sharing. Without them, the app does not connect to Nesora’s server at all.
2. What our server can and cannot see
| Information | Can the server read it? |
|---|---|
| Your photos (backup, circles, web links) | No. Encrypted on your phone before upload. |
| Dates, captions, notes, people’s names and birthdays, album and circle names, member display names, comments, guestbook messages | No. Encrypted the same way as photos. |
| Face vectors, facial landmarks, your personal recognition model, text read from documents (OCR) | Never uploaded. After a restore they are recalculated on the new phone. |
| Your master key, recovery code, circle keys, link keys, link passcodes, pack passwords | Never sent. |
| Photo locations (GPS) | No. Not shared in circles or links. Added to your encrypted backup only if you turn on “Include photo locations”. |
| Your anonymous account ID and public keys | Yes — derived from your key; not linked to an email, phone number or name. |
| Which anonymous accounts belong to which circle, and their roles | Yes — needed to decide who may upload, download or delete. |
| Number, size and upload time of encrypted items; random IDs; which member uploaded, viewed, commented on or reacted to which item, the type of reaction, and when | Yes — needed for permissions, storage limits, unread badges and notifications. It does not reveal what a photo shows or what a comment says. |
| Web links: expiry date, whether a passcode is set, whether downloads, hearts and the guestbook are on, and view and heart counts per link and per photo | Yes — counts, not identities. To count each visitor once a day, the server keeps a salted hash that changes daily and is deleted the next day; it does not store visitors’ IP addresses. |
| Notification token, platform and language, and which kinds of notifications or circles you muted (if you allow notifications) | Yes — used only to deliver a generic alert to your phone (see section 9). |
| Your cloud plan: plan, product ID, expiry date, storage quota, store, and the store’s original transaction ID or purchase token | Yes — checked with Apple or Google to confirm the plan. No name, email or card details. |
| IP address | Processed by Cloudflare to deliver each connection; not stored in Nesora’s database (only short-lived hashes for rate limiting and visitor counts). |
3. The cryptography, in plain words
Nesora uses well-studied, standard building blocks — no home-made ciphers. On phones, encryption uses the operating system’s native implementations.
- AES-256-GCM encrypts every photo, index and message. GCM also detects any change: a tampered file fails to open instead of showing something wrong. Large files are split into 256 KiB chunks, each sealed separately and numbered, so chunks cannot be reordered, dropped or cut short without detection.
- X25519 lets one phone hand a key to another phone securely: a circle key is “wrapped” separately for each member, using that member’s public key.
- Ed25519 signatures prove each request comes from your key. Requests are time-stamped and cover the exact bytes sent, and the server rejects a request it has already seen, so requests cannot be replayed or altered on the way. Your public keys are published as a bundle signed by you, so the server cannot quietly replace them.
- HKDF-SHA256 derives separate keys for separate jobs from one master key, so a key is never reused for two purposes.
- Argon2id turns a password (for example on a memory pack) into a key in a way that is deliberately slow and memory-hungry to guess. In web browsers, link passcodes use PBKDF2-SHA256 with 600,000 rounds, because that is what browsers provide.
All connections also use HTTPS. End-to-end encryption means the content would stay unreadable even if that outer layer were removed.
4. Key hierarchy
- Master key — 256 random bits, created on your phone when you first turn on backup or sharing. It is stored in the iOS Keychain or Android Keystore and, only if you choose, in iCloud Keychain.
- Keys derived from it (HKDF-SHA256):
- a signing key (Ed25519) — your anonymous account is simply a fingerprint of its public half;
- an identity key (X25519) — for receiving circle keys from other members;
- backup keys — one to encrypt backup objects and one to give them names that reveal nothing about their content.
- Circle keys — each circle has its own random 256-bit key, wrapped for every member’s identity key. When a member is removed, the owner’s phone creates a new circle key (a new “epoch”) for the people who remain.
- Link keys — each web link has its own random 256-bit key, which lives only in the part of the link after
#. Browsers do not send that part to servers. An optional passcode is mixed into the key, so the link alone is not enough.
5. Recovery: code and Emergency Kit
Because only you hold the master key, we cannot reset it. When you turn on backup or sharing, Nesora shows a 55-character recovery code (the master key plus a short checksum) and offers an Emergency Kit PDF with the code and a QR code, to print and keep somewhere safe. On iPhone you can also keep the key in iCloud Keychain, which Apple protects end-to-end, so a new iPhone on the same Apple Account can unlock the backup without typing the code.
To restore, enter or scan the code on a new phone. Nesora downloads and decrypts the encrypted index and your photos, then recalculates faces and document text on the new phone and puts people back on the photos they were tagged in.
The trade-off is real: if you lose your phone and your recovery code (and did not use iCloud Keychain), nobody — including Nesora — can open your backup. Anyone who has your recovery code can open your backup and your circles, so keep it as carefully as a house key.
6. Sharing circles and removing members
- A circle (family, friends, partner, community or your own) has three roles: owner (manages members and invites, can remove any photo), contributor (adds and removes their own photos and albums, comments) and viewer (browses, comments and saves photos). The server enforces these roles for every request.
- Invites are QR codes or links containing a one-time secret. The server stores only a check value for it, so it can confirm an invite without being able to use it. Invites can expire and be limited in number of uses.
- Each new circle key is signed by the owner, and members only accept keys with a valid signature, so the server cannot slip in a key of its own. When the owner removes someone, a new circle key is created for everyone else and outstanding invites are cancelled. The removed person cannot read anything shared afterwards. Current members — including people who join later — can still read older photos through a chain of previous keys.
- Limit: photos a member already saw or saved before being removed cannot be taken back.
7. Verifying family members
To send someone a circle key, your phone needs that person’s public key, which it gets through our server. A dishonest or compromised server could, in principle, hand over a different key. To rule this out, Nesora shows a safety number for each pair of members — 60 digits computed on both phones from both people’s public keys. Scan each other’s QR code in person, or read the digits over a call you trust: if they match, no one has swapped the keys, and Nesora remembers that you verified. If a member’s keys change later, the number changes too. If you choose not to compare, you are trusting the server to deliver the right keys.
8. Private web links
- A web link lets relatives without the app view an album in a browser at
nesora.app/s/. The page downloads encrypted bytes and decrypts them in the browser with the key after#. - Options: an expiry date, a passcode (send it separately, for example by phone; Nesora does not store it), and whether to show download buttons. You can revoke a link at any time — it stops working immediately and its encrypted photos are deleted from the server.
- If you allow it, visitors can tap a heart on photos and leave a message in a guestbook. Messages are encrypted with the link’s key, so the server stores only scrambled text and anonymous counts.
- Limits: anyone who has the link (and passcode, if set) can view it — including anyone it is forwarded to — until it expires or you revoke it. Hiding download buttons does not stop screenshots. A short passcode can be guessed by someone who has both the link and the encrypted data, so choose a long one for sensitive albums. The viewer page itself is served by nesora.app, so you rely on that site delivering the genuine viewer code.
9. Notifications
If you allow notifications, your phone registers a delivery token with Firebase Cloud Messaging (Google) — used on both iPhone and Android to deliver alerts — and Nesora’s server stores that token with your anonymous account ID. Alerts carry only a translated message type such as “New photos” plus random IDs so the app can open the right screen; similar events are grouped into one alert. You choose which kinds you get and can mute a circle. They never contain photos, names, captions or comment text, because the server cannot read those. You can turn notifications off at any time in your phone’s settings.
10. On your phone
- Nesora’s database, previews and keys live in the app’s private storage, which the operating system keeps away from other apps. Keys are kept in the Keychain or Keystore.
- App lock and locked profiles use Face ID, fingerprint or your device passcode. Nesora only receives a yes/no answer from the system — never biometric data. Showing your recovery code also asks you to confirm it’s you.
- Nesora never edits your original photos. If you choose to delete a photo from your library (for example when cleaning up blurry shots), the system asks you to confirm and keeps it in Recently Deleted / Trash for a while.
- The app has no analytics or tracking SDKs. The free version includes Google’s ad SDK for non-personalized ads; Nesora never passes it your photos, faces, names, notes or keys, and shows no ads on shared-content, privacy or security screens. Paid plans have no ads.
11. Threat model
Designed to protect against
- A breach of Nesora’s servers or storage, or a curious insider at Nesora or our infrastructure provider: they would find encrypted bytes and the metadata listed in section 2, not your photos.
- Someone listening on the network, or a server that alters data: content is end-to-end encrypted and authenticated, and requests are signed.
- A removed circle member trying to read new photos.
- Someone guessing a web link: link IDs and keys are long random values.
Not designed to protect against
- Someone who has your unlocked phone, or your recovery code.
- People you chose to share with: they can screenshot, save or forward what they can see.
- Malware on your phone or on a recipient’s phone or computer.
- Third-party code inside the app (such as Google ML Kit on Android or the ad SDK in the free version) misbehaving: like any SDK it runs within the app. We only give it what is described in our Privacy Policy.
- The metadata the server needs (section 2), such as how many items a circle has and when they were added.
- Key substitution by a malicious server if members never compare safety numbers.
- Losing both your phone and your recovery code — the backup then cannot be opened by anyone.
No system is perfectly secure. We describe what Nesora is built to resist so you can decide what to share, and with whom.
12. Reporting a vulnerability
If you believe you have found a security problem in the Nesora app, the nesora.app website or Nesora’s server, please email lienhe@nesora.app with “Security” in the subject. Include enough detail to reproduce it. Please give us reasonable time to fix it before sharing it publicly, and do not access, change or delete other people’s data while testing. We will acknowledge your report, keep you updated, and credit you if you wish. We do not run a paid bug bounty at the moment.
See also our Privacy Policy and how to delete your data.