1.What this page is#
This page explains how the UK GDPR and the Data Protection Act 2018 apply to the hosted service at notchr.app, run by an individual trading as “Notchr”. Where you are in the EU or EEA, the EU GDPR applies to our processing of your data and we treat the two regimes as one standard rather than choosing the weaker.
It is written to be read alongside the Privacy Policy, which contains the field-by-field inventory of what we hold. This page is about responsibility and rights.
2.Who controls what#
Notchr splits neatly into two kinds of data, with two different answers, and most confusion about a service like this comes from running them together.
| The data | Who determines what happens to it | Our role |
|---|---|---|
| Account and technical data — your account reference, passkey records, sessions, timestamps, IP addresses at the edge, and the subscription record if you have ever subscribed | We do. We decide what is collected and why | Controller |
| The ledger — the encrypted names, notes, photos, places and everything else in clause 3 of the Privacy Policy | You do, entirely. You decide what to record, about whom, in what detail, and when it goes. We decide nothing and can see nothing | Not applicable, or processor — see clauses 3 and 9 |
| The structural columns — ratings, ordinal numbers, date timestamps, heights, catalogue names | You enter them; we hold them readable because the ledger cannot sort or count without them | Controller, for the narrow purpose of operating the service |
3.Your own records, and the household exemption#
Data protection law does not reach into a private life. Article 2(2)(c) of the UK GDPR — and the same provision of the EU GDPR — takes processing “by a natural person in the course of a purely personal or household activity” outside the scope of the legislation altogether. A diary is the classic example, and a private ledger of your own dating life, kept for yourself and shown to nobody, sits squarely inside that exemption.
So, for the ordinary user:
- your own record-keeping in Notchr is not regulated processing, and you are not a data controller for it;
- the people in your ledger do not have GDPR rights against you in respect of it, because the legislation does not apply to what you are doing;
- other law still does apply to you — for example the law on intimate images, harassment, confidence and defamation, wherever you are. The exemption is from data protection law, not from decency or from the rest of the statute book.
If you use Notchr for anything beyond your own private purposes — recording people in a professional capacity, keeping a ledger on behalf of someone else, sharing it, publishing from it, or using it in connection with a business — the exemption falls away and you become the data controller for everything in it, with the full set of obligations that follow. At that point we act as your processor on the terms in clause 9, and the special-category rules in clause 5 apply to you directly. This is a real threshold, and it is yours to stay the right side of.
4.Our legal bases#
For the data we control, our bases are performance of our contract with you (Article 6(1)(b)), our legitimate interests in keeping the service available and defending it from abuse (Article 6(1)(f)), and compliance with legal obligations (Article 6(1)(c)). The Privacy Policy sets this out purpose by purpose.
We rely on consent for nothing, so there is no consent to withdraw. We send no marketing, run no analytics and set no non-essential cookies, which is why the site has never asked your permission for anything.
On the legitimate-interests basis we have weighed our interest in an available, un-abused service against your interests, and the balance is comfortable: the data involved is network metadata and traffic shape, the processing is minimal and short-lived, and no content is readable to us in the first place.
5.Special category data#
A ledger of this kind holds, in substance, data about sex life and sexual orientation, and often about racial or ethnic origin and health. Under Article 9 that is special category data and the most strongly protected kind there is.
Our answer to that is architectural rather than contractual:
- every field capable of carrying it — names, notes, highlights, ethnicity, nationality, dates of birth, places, photos — is encrypted on your device before it reaches us;
- we therefore process no special category data in any intelligible form, and have no ability to profile, disclose, sell or analyse it;
- the readable structural columns are deliberately kept to what sorting and counting require. We will not add a readable field that carries this kind of content.
Where the household exemption applies to you, Article 9 does not bind your own record-keeping. Where it does not (see clause 3), you need an Article 9 condition for holding special category data about identifiable people — and “I wanted to remember” is not one of them. Think about that before you use this tool for anything other than your own private life.
6.Your rights, and what we can actually do#
Every right below is real. What varies is how much of it lands on us, because most of the data is beyond our reach. No right is charged for, and none requires a reason; clause 7 explains how to make one without telling us who you are.
| Right | What we can do |
|---|---|
| Access — Art. 15 | Fully. We will give you everything we hold: the readable structural rows, your passkey and session records, and the ciphertext of your ledger, in a machine-readable file. Only you can decrypt the last part — which is the point |
| Rectification — Art. 16 | You already hold it. Edit anything in the app and it is re-encrypted and replaced. We cannot correct content we cannot read; we will correct readable structural data that is wrong |
| Erasure — Art. 17 | Fully. On request we delete the account and every row attached to it — partners, dates, activities, photos, passkeys, sessions — within 30 days and usually the same week. Deletion is not reversible and not recoverable |
| Restriction — Art. 18 | Fully. We can suspend an account so that nothing happens to it but storage, while a dispute or an accuracy question is resolved |
| Portability — Art. 20 | Partly, and honestly so. We can export everything the server holds — structural rows as JSON plus your ciphertext. We cannot produce a readable export, because we cannot decrypt. There is no one-click readable export inside the app yet; until there is, the plaintext exists only in your browser |
| Objection — Art. 21 | Yes. You may object to the processing we do on legitimate interests. We will stop unless we have compelling grounds; in practice the security processing is inseparable from running the service, so the honest outcome may be that you close the account |
| Withdraw consent — Art. 7 | Not applicable. We rely on consent for nothing |
| Automated decisions — Art. 22 | Nothing to exercise. There are none. See the AI policy |
| Complain — Art. 77 | Always. To us, and to a supervisory authority — see clause 15 |
7.How to make a request, and the identity problem#
Write to [email protected] and say what you want. We will answer within one month, and tell you if a complex request needs up to two months more.
Then the difficulty, which we would rather explain than hide behind: an account has no email address, no name and no phone number. There is nothing on file to match your message against. Anyone could email us claiming to be the holder of an account we cannot name.
So every account carries one thing that names it: an account reference, three random words —
something in the shape of randy-love-monkey — shown at the top of Settings, and the
handle we use to find an account. Quote it in your message and we know which ledger your request concerns.
What it is, precisely:
- Random, and about nothing. The words are drawn at random when the account is created. They are not derived from you, your ledger or anything you have typed, which is why they can sit in plain text while everything personal is ciphertext.
- Not a credential. It cannot sign in, unlock a ledger or decrypt a single field; only a passkey does that. Knowing a reference lets its holder point us at an account, and nothing more.
- The link between you and the account is yours to make. We hold no email address for you, so we learn one only because you chose to write to us from it. You may write from an address that says nothing about who you are — an alias, a forwarding address, one you made for this — and your request is no weaker for it. We need to identify the ledger, not the person holding it.
- So keep it to yourself. Quote it to us and to nobody else: it is the one string that names your account to whoever holds it, and someone who has it could write to us about your ledger. We will not tell anybody else what an account's reference is, and we will not confirm or deny to a third party that a reference they have matches an account.
A reference names an account; it is not proof that the account is yours. So before we do anything we cannot undo, we also verify by what only the account holder can know or do:
- best: send the request while signed in from a device that holds one of your passkeys, and tell us so, so we can match the session;
- otherwise: include details we can check against the readable columns — roughly when you created the ledger, how many passkeys are registered and when each was added, what kinds of authenticator they are, roughly how many entries you have and when the most recent one was made.
If that does not identify the account with confidence, we will say so and decline rather than act on the wrong one. Article 11 of the UK GDPR is explicit that a controller unable to identify a data subject is not obliged to acquire more information simply to make itself able to — and we will not start collecting identity documents, email addresses or phone numbers in order to serve rights requests. The account reference exists so that we do not have to. Deleting the wrong ledger would be unrecoverable, so on balance we err towards refusing.
There is one route that needs nothing from us at all: remove your passkeys and delete the entries yourself. The content becomes permanently unreadable at that moment, by anyone.
8.If you think you are in someone's ledger#
Some people reading this will not be Notchr users. They will be wondering whether somebody has written about them here. The straight answer, in order:
- We cannot look. Names, notes, photos and places exist only as ciphertext. There is no search we can run, and no way for us to tell whether any named person appears in any account. This is not a policy we could relax; the capability does not exist.
- Where the household exemption applies to the account holder (clause 3), data protection law does not govern their record and there is no GDPR right for us to serve against it.
- Where an account holder is a controller and you can identify them, your rights lie against them. If you tell us who they are and what you are asking, and we can identify the account, we will pass the request on and tell you we have — we cannot answer it for them, since we cannot read the data it concerns. In practice we can seldom identify an account from outside it: the reference that names one is the holder's to give, and not something we will confirm, deny or hand to anyone else.
- Unlawful content is different. If you believe intimate images of you are being stored without your agreement, or that content breaches clause 7 of the Terms, write to [email protected]. We can act on the account — suspend it, and delete its rows — even though we cannot inspect what is in it. We will also act on a valid order from a court or competent authority, to the extent it asks for something we are able to do.
We would rather say this plainly than imply a takedown capability we do not have. The same design that protects a user's private record is what prevents us from reaching into it, for anyone.
9.Where we act as your processor#
If you fall outside the household exemption and are a controller for what is in your ledger, these are the terms on which we process it for you. They are our Article 28 commitments, and you do not need to sign anything to have them.
- Subject matter and duration: storing and serving back the encrypted personal data you upload, for as long as your account exists.
- Nature and purpose: storage, transmission, deletion, and the structural sorting and counting described in the Privacy Policy. Nothing else is technically possible.
- On your instructions only. We process it as the application does at your direction, and not for any purpose of our own. We will tell you if we believe an instruction breaks the law.
- Confidentiality: access to production systems is limited to the operator, and the content is unreadable even to that person.
- Security: the measures in clause 12, appropriate under Article 32.
- Sub-processors: as listed in clause 10. We will update that list before adding one, and you may object by closing the account.
- Assistance with rights and breaches: we will help as far as we technically can, which for encrypted content means producing ciphertext, deleting rows, and telling you what happened — not reading or extracting content.
- Deletion at the end: on termination we delete your rows. Nothing readable can persist in any event.
- Audit: we will answer reasonable written questions about these measures. The encryption design is in the source code, which is the most useful audit available.
10.Sub-processors and other recipients#
| Party | Role | Where | Status |
|---|---|---|---|
| Cloudflare, Inc. | Network front door, tunnel and DNS for notchr.app, and the Cloudflare R2 bucket that stores every photo as ciphertext | United States, global network; the photo bucket carries no jurisdictional restriction | Sub-processor |
| Our own infrastructure | Kubernetes cluster and PostgreSQL database, holding every row but not the photo bytes | the United Kingdom | Us, directly — not a third party |
| Google (Google Fonts) | Serves two typefaces, requested by your browser | United States, global network | Independent controller of that request; receives no data from our servers |
| OpenStreetMap Foundation | Map tiles, and geocoding when you open the Map page | United Kingdom and Europe | Independent controller of that request; see Privacy Policy clause 8 |
| Stripe, Inc. | Merchant of record for the subscription: checkout, card processing, invoicing and VAT | United States | Independent controller of the checkout and payment data you give it directly; sends us the subscription record and nothing else |
| Anthropic PBC | AI model for backfill from notes | United States | Not used by the hosted service — see the AI policy |
We have no other processors: no analytics, no error tracking, no email marketing platform, no CRM, no support desk. The only payment company is Stripe, and you meet it only if you choose to subscribe.
11.International transfers#
The application and database sit in the United Kingdom. The photo objects sit in a Cloudflare R2 bucket with no jurisdictional restriction, so they may rest outside the UK and the EEA on Cloudflare’s global network. Some of the parties above operate globally, so network metadata is processed outside the UK and the EEA.
Those transfers rely on the safeguards Chapter V provides: the UK Addendum to the EU Standard Contractual Clauses, the EU Standard Contractual Clauses themselves, or an applicable adequacy decision, depending on the recipient. The material point is what is capable of crossing a border: IP addresses and request metadata, and ciphertext we cannot read. No readable ledger content is transferred anywhere, because none exists outside your own device.
12.Security measures (Article 32)#
- End-to-end encryption of all personal fields and photos with AES-256-GCM, keyed per account.
- Key wrapping derived from WebAuthn passkey secrets with HKDF-SHA-256: the account's data key exists on the server only as a wrapped blob, and no secret held server-side can open it.
- Passkey-only authentication: no passwords to phish, reuse or leak, and phishing-resistant by construction.
- Server-side rejection of plaintext in encrypted columns, so client-side failures cannot leak content.
- Photo objects written only as ciphertext, under random keys, to a private bucket with no public access and credentials scoped to it alone. An upload that fails deletes the object it had begun to write.
- Per-request ownership checks on every row read or written.
- TLS in transit; database access restricted to the application's own role; secrets held outside the codebase.
- Containers that run as a non-root user, rebuilt and redeployed from source on every change.
- Data minimisation as a design rule: the readable column list in the Privacy Policy is the whole of it, and it only grows if a feature cannot work otherwise.
The Privacy Policy is equally specific about where these measures stop: your own device, and the trust any browser-delivered encryption requires on each page load.
13.If there is a breach#
We will report a personal data breach to the ICO within 72 hours of becoming aware of it where Article 33 requires it, and tell affected users where Article 34 requires it. Because we hold no email address, notification means a prominent notice in the app and on this site — and we will publish what happened rather than wait to be asked.
What an attacker with our whole database would actually get, stated so you can judge the risk yourself:
- Readable: the structural columns — timestamps, ratings, ordinal numbers, heights, custom activity and event-type names, photo sizes, types and storage keys, account and passkey metadata, session records.
- Unreadable: every name, note, highlight, venue, city, country, nationality, ethnicity, occupation, date of birth and map coordinate. Each is AES-256-GCM ciphertext whose key is not in the database.
- Not there at all: the photographs. The database holds only their storage keys, so the same attacker would also need the Cloudflare R2 bucket — and then would hold ciphertext keyed to a passkey they still do not have.
- Useless: the wrapped key on each passkey row, which can only be unwrapped by that physical authenticator, the passkey public keys, which cannot be used to sign in, and the account reference, which names a ledger to us but opens nothing and describes nothing.
That is the whole point of the architecture: our worst day should not be your worst day.
14.Data protection officer and representatives#
Notchr is a one-person operation whose processing of readable personal data is small in volume and narrow in scope, so we are not required to appoint a data protection officer under Article 37 and have not appointed one. Everything in this document is handled by the operator, at [email protected].
We have not appointed an EU representative under Article 27 of the EU GDPR: our processing of EU residents' data is occasional, involves no large-scale special category data in any readable form, and is unlikely to result in risk to rights and freedoms — the conditions of the exemption in Article 27(2)(a). If the service grows past that, we will appoint one and name them on this page.
15.Complaints and the regulator#
Tell us first: [email protected]. We would much rather fix something than be reported for it.
You can complain to the Information Commissioner’s Office (ICO), the UK supervisory authority, at https://ico.org.uk/make-a-complaint/, or by post to Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF. If you are in the EU or EEA you may instead complain to the supervisory authority of the country where you live or work. Complaining to a regulator does not cost you anything and does not affect any other remedy.
16.Changes to this page#
The revision number and effective date at the top of the page tell you which version is current. A material change — a new sub-processor, a new readable field, a change to how requests are handled — will be announced in the app and here at least 30 days before it takes effect, unless the law requires it sooner.