Privacy notice

What this notice covers

It covers this public site, the two enquiry forms it carries at /contact and /enterprise, and the account and sign-in system behind them. No reading history is collected, and nothing here describes one.

It describes the behaviour that is implemented today and deliberately stops where a settled answer would need qualified legal review.

What the forms store

Both forms ask for a name, an email address, and a message, and both require a consent checkbox that must be ticked before a submission is accepted. The enterprise form also asks for an organization and a role. A submission missing any of those is refused before anything is stored.

An accepted enquiry becomes one database row holding exactly those fields, the email address trimmed and lower-cased, the moment consent was given, and a status that starts at new. Nothing else about you is recorded with it: no network address, no browser fingerprint, no referring page, no marketing source.

Why we hold it

To read the enquiry, to answer it if an answer is needed, and to send one automated acknowledgement that it arrived. That is the entire purpose.

There is no marketing list, no profiling, and no advertising. Enquiry content is not sold, and it is not shared outside the two processors named below. The public pages load no analytics. The only cookie they can set is the colour-theme preference described below, and only if you choose a theme.

The acknowledgement email

Each accepted enquiry queues exactly one acknowledgement to the address given. Both forms produce the same short message: it confirms the enquiry arrived, links back to the contact form, and asks you not to reply to the sending mailbox. It does not quote your message, name your organization or role, reveal which form you used, or promise a reply time.

In production it is sent through Resend from [email protected]. In local development and in tests it goes to an in-memory driver or a local mail catcher, never to a real inbox.

The queued job carries only the identifier of the delivery record. The recipient address is resolved inside the database at the moment of sending, under a short-lived lease, and the message text never leaves the enquiry row.

What an account stores

An account holds a name, an email address, and whether that address has been confirmed. A password is never stored: only a one-way credential hash derived from it, which cannot be turned back into the password. A passkey stores its public credential metadata, the public key, an identifier, a counter, and the kind of device it lives on, and never a private key.

A sign-in creates a session record. Alongside the session itself, that record keeps security metadata about the sign-in: the connecting network address and the browser user-agent string, so an unfamiliar session can be recognized and revoked.

Signing in sets one cookie, __Host-salient.session. It holds a session identifier and nothing else: no name, no address, and no reading history. It is marked HttpOnly so no script on the page can read it, Secure so it travels only over HTTPS, and SameSite=Lax so another site cannot make your browser send it. It is scoped to this site alone, it is replaced rather than added to each time you sign in, and signing out expires it and deletes the session record behind it.

Registering or using a passkey sets one further cookie, __Host-salient.passkey_challenge, and only while a passkey ceremony is in progress. It holds a random challenge so the reply your device produces can be matched to the request that asked for it. It identifies nobody: no account, no address, no device name, and no reading history. It carries the same HttpOnly, Secure, and SameSite=Lax protections, and it is expired as soon as the ceremony it belongs to finishes.

Choosing a colour theme sets one further cookie, salient-theme. It holds a single word, light or dark, for one year, and nothing else: no identifier, no account, and no reading history. It is sent to the server so a page can be built in the theme you chose rather than arriving in the wrong one and correcting itself, and it is the one cookie here that a script on the page can read, because the control that sets it runs in your browser. It is scoped to this site, marked SameSite=Lax, and marked Secure wherever the site is served over HTTPS. Leaving the theme on Auto sets nothing at all, and returning it to Auto deletes it.

Those three are the only cookies this site issues, and none of them is used for analytics or advertising. Reading the public pages sets none of them unless you choose a colour theme.

A password reset or an account-recovery hold stores when the hold expires, and nothing about why beyond that. A privileged recovery request stores a sanitized reason written by an operator and the non-secret record of who approved it.

A verification or reset email stores an encrypted intent: the token that opens the link is sealed with authenticated encryption and stored only in that form, so it exists in readable form solely inside the message that carries it. A security-change notice stores delivery metadata for the mail, never the change itself.

Your network address is not stored for enquiries

The two forms share one allowance: five enquiries an hour from the same connecting address, counted across contact and enterprise together. A sixth is refused with the time to wait, and no enquiry is stored for it.

The counter is keyed by a keyed one-way digest of the address, computed before anything is written. The address itself is never stored against an enquiry, and the digest cannot be reversed into an address without the key. The address used is the one the hosting platform reports for the connection; forwarding headers sent by a browser are ignored, and a connection the platform does not report cleanly is counted in a single shared bucket instead.

Signing in is different, and deliberately so. As described under what an account stores above, a session record keeps the connecting address and the browser user-agent as security metadata, so an unfamiliar session can be recognized and revoked. That session record is the only place your address is kept in readable form, and it is removed with the session by the bounded cleanup described below.

What logs and audit records contain

Enquiry content is never written to a log. When a submission is accepted, the service records identifiers only, the enquiry id and the request id, and writes one audit row of the same shape that names which of the two forms it came from.

That audit row is the durable record that a submission was accepted. It holds no name, address, or message text, and it is not one of the tables the deletion windows below cover.

Who else handles it

Hosting and database, DigitalOcean. The site, its API, and its managed PostgreSQL database run on DigitalOcean App Platform in the New York region, and enquiry rows live in that database.

Email delivery, Resend. Resend is the production email processor: it transmits the acknowledgement, every verification and reset link, and every account-security notice, so it handles the recipient address and the fixed text of those messages. It receives no message text, no organization, and no role.

Nobody else. Enquiry content reaches no analytics service, no advertising network, no customer-relationship tool, and no payment processor, and no public page loads a third-party resource.

How long it is kept

Deletion is a scheduled job rather than an intention. One sweep runs daily at 03:30 UTC and deletes in bounded pages, so a row is removed on or after the day its window ends rather than at the instant it expires.

Enquiries: 180 days. An enquiry that is still new, or that has been closed, is deleted 180 days after it was submitted, and the name, address, and message go with it. An enquiry in an active conversation, marked contacted or qualified, is kept while that conversation is open.

Delivery records: 90 days. The record of an acknowledgement, its template, state, attempt count, and the recipient digest but never the address, is deleted 90 days after it was created, once the send has finished and nothing else refers to it.

Provider event records: one year. If the email provider ever reports back on a message, that report is stored in normalized form, an event id, a type, a digest of the payload, and a status, and deleted one year after it arrived. No such reporting is switched on today: no webhook is registered, so nothing is written here in practice.

Rate-limit counters: deleted once expired. Each counter carries the expiry of its one-hour window, and the next daily sweep deletes every counter already past it. A counter holds the name of the limit, a digest, a window, and a number.

Background job receipts: 30 days. The worker records that it finished a job so that a redelivery cannot repeat the work. A receipt holds a queue name, a job id, and an outcome code, and is deleted 30 days after it was recorded.

Expired sessions, verifications, encrypted link intents, and expired recovery holds: removed or cleared once they have been expired for more than seven days. An intent survives its own expiry only while a delivery is still trying to send it.

Privileged recovery requests: a resolved request keeps its sanitized reason text for 90 days after it resolved, and the request and its approval detail are removed one year after that same moment. A request that has not resolved is preserved and nothing about it is removed.

Account, profile, and passkey records have no automatic deletion window in this release, and neither do the identifier-only audit records described above, which are kept for at least a year.

Those windows are the only automatic deletion this system performs. Anything else is kept until someone deletes it deliberately.

Asking for an enquiry or an account to be deleted

Ask through the contact form and say which address you used. Deleting an enquiry or an account before its window ends is a manual step performed by the operator, and there is no self-service control for it yet.

The address you used is the only thing that identifies your enquiry, and nothing else is used to identify you.

Reporting a security problem

Report a suspected vulnerability through the contact form, with enough detail to reproduce it. There is no separate security mailbox and no bug-bounty programme yet, so that form is the only intake and reports reach the same desk.

Please do not include anyone else's personal data in a report, and please do not test in a way that degrades the site for other readers.

What this draft does not say

It has not been read by a qualified lawyer. It names no company details, no supervisory authority, and no privacy contact beyond the form above; it states no statutory rights and does not say which country's law applies. None of that has been settled, and inventing it would be worse than leaving it out.

It will be replaced once it has been through review. Until then, treat it as an accurate description of the system rather than as legal advice.