Privacy

Every search on this site is written to a log. That log has three things in it: the search text after it is trimmed and lowercased, how many results came back, and the moment it happened.

There is no user id, no IP address, no session key and no device identifier in it — not blank, not hashed, but absent from the table. Nothing in the database can attach a search to a person, and that stays true whether you are signed in or not.

It exists for one reason: a search that returns zero results is usually a gap in the synonym table — a trade name or an abbreviation the codex does not know yet. Reading the misses is how the reference gets better at answering the names perfumers actually use.

Reading the codex needs no account and collects nothing that identifies you. Everything below is either the search log above, or something you get only by choosing to sign up.

• Your email address, if you make an account. It is your sign-in and the address confirmation and password-reset mail goes to.
• If you sign in with Google: your name, email address, profile picture address and Google account id, which Google passes to Supabase when you choose “Continue with Google”. The site asks Google for nothing else — no contacts, no calendar, no Drive, no access to your Google account after you have signed in.
• Your password. It is passed straight through to Supabase Auth, which stores it. This project’s own database has no password column — sign-in is not something I built, and it is not something I want to hold.
• Sign-in records. Supabase Auth, the sign-in service, keeps a record of each signed-in session (the IP address and browser it came from, and when) and a log of sign-in events such as signing in, changing a password or deleting the account (your email address, the IP address and the time). This is the one place your IP address is stored, and only if you have an account. It exists to keep accounts secure: to spot someone else signing in as you, and to investigate abuse.
• Saved materials. Your account id, the material’s id, and when you saved it. That is the whole row.
• Private notes. Your account id, the material’s id, the text you wrote, and when you wrote and last changed it.
• Page views, in aggregate. The site uses Vercel Web Analytics, which is cookieless and stores no IP addresses. It counts visits to pages; it does not follow you between them or across other sites.

Your notes and saved materials are yours. The database enforces that with row-level security: every read and write is scoped to the row’s owner, so no other reader — signed in or not — can reach them, and the site has no screen anywhere that shows one person’s notes to another.

I should be straight about the limit of that. I administer the database, so I can read what is in it. I don’t, and I have no reason to, but a policy that told you it was technically impossible would be a promise the software does not enforce. Write notes accordingly.

• No tracking cookies, and no advertising of any kind.
• No selling, renting or sharing of anything here. There is no business model that would want it.
• Reading the site records no IP address — not in the search log, not anywhere else. The only stored IP addresses are the sign-in records above, and only for people with an account. (Every visitor’s address still reaches the host that serves the page; see below.)
• No profile, no behavioural scoring, no cross-site tracking, no data broker, no third-party analytics beyond the cookieless one named above.
• No third-party fonts, images or embeds. The typeface is served from this site, and structure diagrams are drawn by this site from the molecule’s SMILES string rather than fetched from somewhere else, so reading a material page does not quietly announce you to another company. The one exception is the bot check on the sign-in forms, described below.

Two, both strictly necessary, both named here because a policy that says “we use cookies” without saying which ones is telling you nothing. There is no consent banner because there is nothing to consent to — none of them tracks you.

• The Supabase authentication cookie — set when you sign in, so that you stay signed in. It carries your session token. Signing out removes it.
• The Google sign-in verifier — set for the few seconds between pressing “Continue with Google” and coming back, so the sign-in can only be finished in the browser that started it. It holds a random one-time value and is replaced by the authentication cookie when you return.

Two small conveniences live in your browser’s local storage. Neither is sent to the server, and clearing your browser’s site data removes both.

• theme — whether you chose light, dark, or to follow your system.
• perfumers-codex:recent-searches — your last five searches, so the search palette can offer them back to you. This list stays on your device; the server never receives it.

Two companies always, and Google only if you choose it. Each has its own privacy policy, and Supabase and Vercel process this data on my behalf under their data processing terms.

• Supabase — the database and the authentication service. Accounts, saved materials, notes and the search log all sit there.
• Vercel — hosting and the analytics described above. Every page is served from Vercel, and a request cannot reach any server without carrying the address it came from, so Vercel sees network-level details of your visit that this application never records or stores.
• Google — only if you choose “Continue with Google”. Google then knows you used your Google account to sign in here, and sends Supabase the four things listed above. The site uses them only to create and sign in to your account, never for advertising, and never passes them to anyone else. Its use of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. You can cut the link from your Google account’s third-party connections page at any time; deleting your account here removes what Google sent.
• Cloudflare Turnstile checks that the sign-up, sign-in, password-reset and change-password forms are filled in by a person rather than a script. Only those forms load it. It runs in your browser and sends Cloudflare signals about the browser and your IP address; the site then asks Cloudflare whether the check passed, sending your IP address with that question. It sets no cookies, and the site keeps nothing from it beyond the answer for that one request. Cloudflare describes what it collects in its Turnstile privacy addendum.

• Your account, saved materials and notes exist because you asked for them: holding them is how the site provides the account you signed up for under the terms. Giving an email address is required only for an account; reading the codex needs nothing.
• Sign-in records are kept because keeping accounts secure is a legitimate interest of yours and mine, and the records hold no more than that needs.
• The search log and analytics hold nothing that identifies you, so there is no personal data to have a basis for.
• Nothing here makes automated decisions about you, and nothing is used for advertising or sold.

Supabase stores the database and the sign-in service in [ maker: the Supabase project's region (Project Settings → General), e.g. "the United States (AWS us-east-1)" ]. Vercel serves pages from its network worldwide. If you are in the UK or the European Economic Area, using an account therefore means your data is handled outside it; both companies cover that transfer in their data processing terms with the European Commission’s standard contractual clauses (and the UK addendum).

• Search entries are kept indefinitely today. I intend to delete them after about 90 days, but the scheduled job that would do it does not exist yet, and I am not going to describe a retention period the database does not enforce. When that job is running, this sentence will say so.
• Your account, saved materials and notes are kept for as long as your account exists, and go when it goes.
• Sign-in records. Session records go when you sign out, when the session expires, or when you delete the account. The sign-in event log is kept for [ maker: the retention period once item 12 in docs/maker-todo.md is done ]. It is not tied to your account row, so deleting your account does not remove its past entries straight away; they are removed when that period runs out.
• Backups. Once a day the whole database, accounts and notes included, is copied into an encrypted backup that only I hold the key to. One copy stays on my own computer and one is kept off-site, both encrypted, and each backup is deleted after 30 days. So for up to 30 days after you delete your account, it can still exist inside those backups. If I ever have to restore one, I will delete again any account that was deleted after the backup was taken, before the site goes back up.
• Analytics are counts held by Vercel under its own retention. Nothing in them identifies you.

• See or change your email address, or set a new password on the account page.
• Delete everything, yourself, at any time. The same account page has a delete button. It removes your sign-in, your saved materials and your private notes immediately. It is a real deletion, not a flag on a row that stays behind: the application keeps no copy and offers no undo. The two exceptions are described under how long any of it is kept: the sign-in event log, whose past entries age out rather than going at once, and the encrypted daily backups, which drop your account within 30 days. The codex itself is unaffected — it stays public and free to read without an account.
• Can’t sign in any more? A forgotten password is fixed by resetting it from the sign-in page. If you still can’t get in, email the address under contact from the address the account was made with, and I will delete the account within 30 days. Writing from that address is how I know the request is yours.
• Take a copy with you. The account page has a “Download your data” button: one file with your account details, how you sign in (including what Google sent, if you use it), your saved materials and your notes, in a format any program can read. For a copy of your sign-in records, email me.
• Anything else the law where you live gives you — access, correction, portability, restriction, objection. Write to me and I will answer within a month, without making you argue about it. If you are in the UK or the EEA you can also complain to your data protection regulator (in the UK, the Information Commissioner’s Office), though I would like the chance to put it right first.

Passwords are stored only as one-way hashes by Supabase. Every person’s notes and saved materials are walled off from everyone else’s by the database itself, and that wall is tested automatically, with real test accounts, on every proposed change to the code.

If a breach ever exposes account data, I will email the people affected without undue delay, say what was exposed and what to do, and notify the regulators the law requires me to tell.

Accounts are for people aged 16 and over. The codex is a working reference for perfumers and is not aimed at children; if you believe a child has made an account, tell me and I will delete it.

The site is run by Davis Kim, who decides what happens to the data described here (in data protection terms, the controller). One person maintains it, and email reaches him directly: [ maker: contact email — hello@perfumerscodex.com is planned but not live yet ]

The date at the top of this page changes with it, and anything that alters what is collected or who sees it will be described here rather than folded in quietly.

18 October 2026: added the encrypted daily backups and how long they keep a deleted account (30 days).

18 October 2026: added Cloudflare Turnstile, the bot check on the sign-in forms, and noted that the site now passes your IP address to Supabase when you sign in, so its limits on repeated attempts apply to you alone rather than to every reader at once.

17 October 2026: removed the pc_gate cookie, which existed only while the site was behind a construction password.

12 October 2026: added the sign-in records Supabase keeps (the earlier version wrongly said no IP address was stored anywhere), what Google sends if you sign in with it, the reasons and legal basis for each kind of data, where it is stored, the new “Download your data” button and password reset, and the sections on breaches and children.

This page is a file in the project’s source repository. Once that repository is public, the full history of every word on it is public with it — which is the point of writing the policy from the code instead of from a template.