Last revised — 19 September 2026
What TwoNote holds about you, what it cannot hold, and what you can ask for. This describes the service as it is actually built — every claim below corresponds to something in the source code.
TwoNote is published and operated by a private individual, acting in a non-professional capacity. The data controller can be reached at contact@twonote.ink, which is the single address for every request described here — questions, reports of illegal content, and requests about your own data.
Hosting and the identity of the publisher are set out in the Legal Notice.
Your notes live first on your own device. When they sync, they are encrypted in your browser before leaving it, with a key derived from your password by 600,000 rounds of PBKDF2-SHA256. That key never leaves your device: it is held in a dedicated worker, in a form the rest of the page cannot export. The server receives ciphertext and stores ciphertext.
This covers the content of your pages, their titles, your settings — including any AI provider keys you enter — your attachments, and your search index. It is not optional and there is no setting that turns it off.
The direct consequence: we cannot reset your password for you, we cannot recover your notes, and we cannot hand their content to anyone — including an authority that asks. This is a property of the design, not a promise we make.
One exception exists, and it is not ours. If your account belongs to an organisation, that organisation can hold a copy of your key and read your notes. It remains true that WE cannot — the key is held by the organisation, on its own machines, and never reaches us. Section 5 sets out exactly what this means, and the application tells you plainly at the moment you join.
Your username never reaches us in the clear: your browser hashes it first, and that hash is what identifies your account everywhere in our systems. The same is true of an email address, if you choose to add one — we keep only a keyed hash of it, never the address itself.
We want to be precise about what that does and does not achieve. It is pseudonymisation, not anonymisation. The hash is computed with a fixed, publicly known salt, so someone holding a copy of our database could test candidate usernames against it and find matches. Your data therefore remains personal data, and everything in this policy — legal bases, retention, your rights — applies to it in full.
There is one place where you lift this yourself, deliberately: publishing a widget to the store. A published widget carries your username in the clear, permanently attached to it, and anyone can read it — with or without an account. The application says so before you publish, and asks you to agree. Nothing else you do here reveals your name.
The table below is exhaustive for the server. Anything not listed here, we do not have.
| Data | Why | Legal basis | Kept |
|---|---|---|---|
| Hashed username | Identifying your account | Performance of the contract | Until you delete the account |
| Authentication material (hashed token, salt, wrapped keys) | Signing you in; letting you recover with your recovery code | Performance of the contract | Until you delete the account |
| Encrypted content: page bodies, titles, settings, attachments, search index | Syncing across your devices | Performance of the contract | Until you delete the account |
| Unencrypted structure: the shape of your file tree, edit timestamps, item sizes, attachment file types, which folders you keep open | Making sync work — the server must know what changed and how big it is without reading it | Performance of the contract | Until you delete the account |
| Account dates: sign-up, last sign-in, storage used and allowed | Running the account and its quota | Performance of the contract | Until you delete the account |
| Hashed email address, if you add one | Sending you a recovery link | Your consent — the field is optional | Until you remove it, or delete the account |
| Sharing records: which account shared what with whom, and when | Making sharing work and letting you revoke it | Performance of the contract | Until the share is revoked, then until account deletion |
| The IP address you were using when you published a share link | Being able to answer a lawful request about content made public through this service | Legal obligation on hosting providers | 12 months, then automatically deleted |
| Messages you send through the contact form, with your address if you give one, and the IP it came from | Answering you; recording when a report reached us and what we did about it | Legal obligation, and our legitimate interest in defending our decisions | 12 months after the matter is closed |
| A suspension, with its date and its stated reason | Enforcing the Terms and explaining the decision to you | Our legitimate interest in keeping the service lawful | Until the suspension is lifted, then 12 months |
| A widget you publish to the store: its code, name, description, icon, version, declared permissions, your username in the clear, your signing public key and your signature | Distributing it, and letting anyone verify who wrote it | Your consent — publishing is a deliberate act you are asked to confirm | Public until you withdraw it; the record stays while the account does, so you can put it back and so an installed copy can still be verified. Deleting the account erases it |
| Which widgets you starred or installed, and the permissions you granted each one | Showing you what you already have, and counting stars and installs | Performance of the contract | Until you uninstall or unstar, or delete the account |
| A report you file against a widget: the reason, your comment, and your hashed username | Reviewing the widget; the hashed name is what stops one account reporting the same widget five times | Our legitimate interest in keeping the store lawful | Deleted with your account while still open; once reviewed, the decision is kept without your name |
| Your IP address as a short-lived counter, to slow down abuse | Rate limiting | Our legitimate interest in keeping the service available | Under a minute, in memory only — never written to disk |
Note the fourth row. The server cannot read your notes, but it does know how many you have, how they are arranged, when you last touched each one, and what kind of files you attach. If that shape is itself sensitive to you, that is worth knowing before you rely on us.
Some accounts are created and administered by an organisation — an employer, a school, an association. This changes who can read your notes, and it is the one place in this document where the rest of section 2 does not apply as written.
Once a copy of your key has been deposited with it, an organisation can read everything your account contains: your pages, their titles, your attachments, your settings. Not only what you write for work — everything on that account, including anything personal you keep there. If that is not what you want, do not keep personal material on an account your organisation administers.
How it works. Your device seals a copy of your key for the organisation and deposits it with a key service that the organisation runs itself, on its own infrastructure. On an account the organisation opens for you at your first sign-in, the key is created and deposited in the same movement. On a personal account you attach to an organisation afterwards, the deposit is a separate gesture that you trigger yourself, from a settings screen that states first how far it reaches — attaching the account does not perform it. From then on, an administrator of your organisation can open your notes.
How far this reaches. Your key opens more than your own pages: it also opens the notebooks other people have shared with you, including people outside the organisation. An organisation that opens your account therefore also reads what a third party entrusted to you — and that third party never agreed to it, and is never told. Bear it in mind before accepting a share on a work account.
What does not change: the key is sealed for the organisation, never for us; the key service is theirs, not ours; and we hold no copy of your key. A request addressed to us still yields ciphertext. One reservation, and it counts: the proof of identity that makes the key service hand a key back travels through our servers for as long as we are the ones conducting the sign-in to your organisation — which is the default arrangement. We could therefore obtain one. An organisation that does not want that reservation configures the direct path, where this proof goes from your browser to its identity provider and then to the key service, without passing through us. Ask it which of the two it chose.
Each time an administrator opens someone’s notes, the key service records who did it, whose notes, when, and the written reason they had to give. The log is chained, and a second file kept beside it counts its entries: a line cannot be removed discreetly — not from the middle, where the chain stops following, nor from the end. This is not inviolability: whoever holds those two files can rewrite both. We hold neither, and cannot produce them for you — ask your organisation.
What you do not have to ask for: the openings that target you. At your next sign-in through your organisation, its key service hands back the most recent ones recorded against your own account, and we show them to you — the date, the written reason, and whatever mark that service exposes about the administrator who asked, or failing that the mere fact that it was one. This depends on no setting of your organisation’s.
The one thing an organisation key does not open: the AI provider keys you enter yourself. Those are your means of payment, not your work, so they are encrypted under a separate key sealed only under a passphrase you know. It is never derived from the key your organisation holds, and never sealed for it.
Signing in. Your organisation may require you to sign in through its own identity provider. If it has chosen automatic unlocking, you no longer type a passphrase at all: the key service hands your key back once the identity provider has vouched for you. In that arrangement there is no passphrase, therefore no personal AI key either, and your organisation serves AI from its own endpoint.
AI in an organisation. If your organisation provides the AI endpoint, its key service sits on the path of every request: the questions you put to a model, and the passages of your notes that accompany them, pass through a machine it operates. It keeps counts — how many calls, how many tokens, which model, per person and per day — and no content. It is in any case a machine that could already open your notes.
What your organisation can also do, through us: see how much space each member uses, how often they sign in and edit, and what they have shared outside the organisation; adjust quotas; suspend an account; revoke its sessions and its share links; detach an account from the organisation; and delete an account together with everything on it. Looking at those figures asks nothing of the administrator. Each of the actions, on the other hand, requires a written reason of at least twelve characters, and leaves a trace. None of them lets us read anything.
Your organisation may also govern the widget store: restrict or close access to the public catalogue, forbid you from publishing to it, and run a catalogue of its own that only its members can see. Widgets it publishes there are visible to no one else.
Your organisation may also restrict what you can share: forbid links open to anyone, forbid sharing with accounts outside it, or both. The restriction applies when you create a share and also to shares you had already created, which then stop opening. A refusal says which rule applies.
When your organisation removes you from it, your account is detached, but the copy of your key that was deposited is not retrieved for all that: only the organisation can erase it from its own key service. Ask it to. There is no departure you can trigger yourself — detaching an account is an act of the organisation, and TwoNote refuses it to the person concerned.
Four features move your content beyond the encrypted store. All four are things you switch on yourself; none of them happens quietly.
AI features. They do nothing until you enter your own API key for Google Gemini, OpenAI or Anthropic. Once you do, the calls go straight from your browser to that provider: we are not in the path, we never see your key, and we never see what you send. What is sent is more than a single block — when no region is selected, the assistant serialises the whole page and attaches a screenshot of the canvas; the notebook feature sends the full text of the pages you choose, their embedded images, and rendered PDF pages. The agent’s web search sends its query to DuckDuckGo. These providers are outside the European Union, and your agreement with them, not this policy, governs what they do with it. Entering no key keeps all of this switched off. A local model through LM Studio keeps it on your own machine. If your account belongs to an organisation that provides the AI endpoint, this paragraph does not describe your situation — see section 5.
Converting Word and PowerPoint files. This is off by default. If you turn it on, the file is sent to our server unencrypted so it can be converted, and is deleted as soon as the conversion finishes. It is the one place where our server sees your content in the clear, and the setting says so where you enable it.
Sharing. Creating a share link makes that page readable by anyone holding the link — the decryption key travels inside the link itself, in the part browsers never send to a server. We still cannot read it. But once you hand the link to someone, they can, and so can anyone they pass it to. Revoking the link cuts access immediately. If your account belongs to an organisation, it may restrict or forbid this sharing — see section 5.
Publishing a widget to the store. This is the one thing here that is public by design rather than by accident. What you publish — the code, the name, the description, the version, and your username — arrives on our server unencrypted, because a catalogue nobody can read would serve no purpose. It is stored in the clear, it is in our backups, and anyone can fetch it, signed in or not. Nothing else about your account goes with it: your notes, your files and your settings stay exactly as encrypted as they were. If your account belongs to an organisation, it may forbid this publication or direct it to a catalogue of its own — see section 5.
Withdrawing a published widget removes it from the catalogue and from download. We keep the record itself, so that you can put the widget back and so that someone who installed it can still check their copy against what you signed — but nobody can reach it any more. It does not touch the copies already installed by other people either: those live in their notes now, and we have no way to reach them. Deleting your account is what erases the record, along with your stars, your installs and any report of yours still open.
We do not sell your data, and we do not share it for advertising. The only third parties involved are the ones that run the service:
There are no analytics, no trackers, no advertising scripts, no third-party fonts, and no external scripts of any kind in the application. This is enforced by the page’s own content security policy, not merely intended.
You may ask us for access to your data, for it to be corrected, for it to be erased, for a portable copy, for processing to be restricted, and you may object to processing we carry out on the basis of our legitimate interest. Where we rely on your consent — the optional email address — you may withdraw it at any time, without affecting what was done before.
Two of these you can exercise yourself, immediately and without asking us: the application exports your notes at any time, and deleting your account from the settings erases your data from our database and our object storage in the same operation. For anything else, write to contact@twonote.ink. We answer within one month.
One limit deserves stating plainly. Because we hold only a hash of your username and never your address, we often cannot tell that a request comes from the person whose account it concerns. We may have to ask you to prove control of the account — typically by writing from the verified address attached to it, or by acting from inside the signed-in application. If you gave us neither, there may be no way for us to satisfy a request about your data. That is the price of the design, and you are entitled to know it before you need it.
If our answer does not satisfy you, you may lodge a complaint with the CNIL, the French data protection authority, at cnil.fr.
The date at the top is the date of the last revision, and it is set by hand when the text actually changes. If a change alters what we collect or why, we will say so in the application before it takes effect, not only here.