Privacy Policy

In force from 18 September 2026.

Nerchure Ltd (company number 17168853, registered office 71–75 Shelton Street, Covent Garden, London WC2H 9JQ) is the data controller for Nectenda. Write to privacy@nectenda.com about anything in this document, or support@nectenda.com about your account. We reply within three business days.

Every technical claim below is derived from docs/security-model.md, which is written to be checked against the client. If this document and that one ever disagree, that one is right and this is the bug. That is not a disclaimer — the client ships as readable JavaScript precisely so these claims can be checked rather than believed.

Nerchure Ltd, a company registered in England and Wales, operating Nectenda.

The short version

Your notes are encrypted on your device before they reach us, with a key derived from a password we never receive. We cannot read your notes, your note titles, your folder names or your attachment filenames. We can see that you have an account, who you share folders with, how much data you store, and when you were connected.

We cannot recover your notes if you lose both your password and your recovery key. That is not a policy choice; there is no mechanism by which we could.

What we hold

Identity records. Your verified email address, your display name, the opaque subject id of any sign-in provider you link (Google, Apple, Microsoft), the public half of any passkey you register, which organisations you belong to and your role in each, and a record of each device you have signed in from. Your email is used to sign you in and to reach you about the service — invitations, licences, billing, security notices — and, if you consent separately, nothing else.

Not your passphrase, in any form. On the hosted service the passphrase that encrypts your notes is never sent to us, and neither is any hash or verifier of it — nothing we could check a guess against. We store your public key, your private key sealed under a key derived from your passphrase, and your master key sealed under your recovery key. All three are opaque to us. Share links and invitations are stored as hashes only.

Sign-in providers. If you sign in with Google, Apple or Microsoft, that provider learns that you signed in to Nectenda and tells us your email address and an opaque identifier. They are involved in the sign-in step and nothing else; they never see your notes or your passphrase.

The sharing graph. Which accounts share which folders, each member's role, and when they were added. Your own folder list shows you how many people are in each folder and when it was last changed, so that two folders with the same name can be told apart; its size is shown only on folders your account pays for. We can see that two people share a folder. We cannot see what the folder is called or what is in it — including when its owner renames it, which replaces one encrypted name with another. Renaming a shared folder changes only the name shown in Nectenda's settings; it never moves anybody's folder or files, and what you called it on your own device stays whatever you called it.

Devices. A device identifier, a label, the platform string, and first- and last-seen times. A vault names itself generically — the platform and four characters of its own install identifier. It is not your vault's name and not anything you wrote.

Your vault's real name travels too, but encrypted: it is wrapped to your own account's key before it leaves, so your other vaults can show it in your device list and we hold a blob we have no key for. That is the same wrapping your folder names use. A vault that has not sent one, or one you are looking at before entering your passphrase, shows the generic label instead.

Sizes and timing. The byte length and arrival time of every update, the encrypted size of every attachment, and your account's storage total. This is enough to infer that a document is being actively edited and roughly how large it is. End-to-end encryption does not hide traffic patterns, here or anywhere.

Network information. IP addresses and connection times, as any service sees.

Payment records, if you buy something. Creem is the merchant of record and takes the payment: your card details go to Creem and never reach us, are never stored by us, and could not be. What we receive back is a record that a payment happened — the email address that paid, the plan, the number of seats, the amount, and Creem's own reference for the subscription — which is what lets us give you the thing you bought and answer you when you ask about it. Creem also receives your billing address and whatever tax identifiers your country requires, because it is the party accounting for the tax.

Understanding how the service is used, including which features are most active. We analyse the records above for this purpose too.

What we do not hold, and could not produce

Note content, note titles, folder names, attachment filenames, and your password. Document identifiers on our servers are HMACs of paths, not paths. Attachment bytes are encrypted before upload and their filenames never leave your device.

If we were compelled to hand over everything we have, that is the list. It does not include anything you have written.

Where it lives

The hosted service runs in one region, and everything is in it:

One region is a decision rather than a stage we have not reached. We measured what a second region would buy: with edits applied on your device first, only a collaborator's cursor and text are delayed by distance, and no measured delay from anywhere on earth to Germany reaches the level at which people perceive it. So we run one thing well and say plainly where it is. If that ever changes, this table changes first.

The backups are of our databases, not of your attachments. A backup provider sees less than a storage provider does: the backup is encrypted as a whole before it is uploaded, with a key that never leaves our infrastructure, so what Backblaze stores is opaque blocks with no filenames, no identifiers and no per-item sizes. It is still your data and we still account for it here.

Each storage provider receives ciphertext and opaque identifiers, and can see object sizes and access times. Email is handled on our own infrastructure, which is running today.

Error tracking — our servers. Our servers report unexpected errors to an error-tracking service we run ourselves, on our own infrastructure, not a third party. A report carries technical details of the error and account or folder identifiers so that we can act on it; it never carries note content, paths, folder or attachment names, tokens, passphrases or key material, and we test that rule rather than trust it. Reports are kept for 90 days and then deleted.

Error tracking — the plugin. When you are signed in to Nectenda Cloud, the plugin also reports its own crashes, to the same service we run ourselves. This is on unless you turn it off, and nothing is sent until you have been shown what a report contains.

A report carries the error and its message, where in our own code it happened as line numbers in the published plugin file, your plugin and Obsidian versions, whether you are on desktop or mobile, and the identifier your installation already sends with every request. It does not carry anything you have written, the name of any note, folder or attachment, any file path, your vault's name, your passphrase, your keys or any token. The report is assembled field by field from a fixed list rather than by removing things from a larger one, and the message and stack are then passed through the same filter our servers use.

The plugin file we publish is not compressed or obscured, so a line number is enough for us to find the code, and we never upload a separate debugging file.

Reports are kept for 90 days and then deleted. You can turn them off at any time under Settings → Nectenda → Troubleshooting. If you run your own server there is nothing to turn off: the address reports would go to is supplied by the server you sign in to, and your own server supplies none, so none are sent.

Service status. We publish the up-or-down state of our servers on a public status page. It shows server names and uptime, never anything about you.

Being encrypted does not remove our obligations, and it does not mean the metadata above is unimportant. It means the content is not ours to disclose.

How long

Account and sharing records are kept while the organisation exists. An organisation exists until its owner closes it; closing begins a 30-day period during which it can be reopened and its attachments downloaded, after which it is deleted from the live service.

Deleted documents are retained briefly so that other devices can learn of the deletion, then removed.

An attachment that no device has vouched for in 30 days is moved aside and its space released. Asking for it in the following 30 days brings it back. After that it is deleted. The rule is about use rather than payment: a file nobody has referred to for two months is one nobody is relying on, and no plan change or lapsed payment ever causes a deletion.

Backups are kept for 14 daily and 8 weekly snapshots and then rotated out, so a copy of deleted data can persist in them for up to a further 56 days. They are encrypted, and they hold the databases only — attachments are not backed up and exist in one place.

These periods describe what the code does today. Where a number here and the code disagree, the code is the fact and this document is the bug.

Your rights

Under UK and EU data protection law you can ask for a copy of what we hold, correct it, delete it, or object to how it is used. Write to privacy@nectenda.com.

One honest limitation. A copy of "everything we hold about you" is the metadata described above plus your encrypted blobs. We cannot provide your notes in readable form, because we cannot read them. Export your notes from Obsidian, where they are plain files on your disk.

Changes

If this changes materially we will say so by email before it takes effect.