Privacy Policy

This covers the Thalorin marketing website: these pages, the contact form, and the careers form.

It does not cover the Thalorin product. If your organisation is a customer, the data you put into the product is governed by the agreement between your organisation and Thalorin. Tenant data, evidence and control records are handled under that contract, not under this page, and nothing here grants or limits rights over them.

The two are separate systems. A visitor to this website is not a product user, and reading this page tells you nothing about how your tenant is handled.

Visiting this site reports your visit to HubSpot, our customer-relationship platform, and sets cookies on this domain to do it. That happens on the first page you load, before you interact with anything, and there is no banner in front of it.

Beyond that, our own code collects nothing as you browse. It sets no cookies of its own, writes nothing to your browser's storage, reads nothing from your device, and runs no analytics of its own.

We receive information you type only when you submit one of two forms. Both are described below, field by field.

The contact form asks for your name, your email address, your company (optional) and your message. Nothing is transmitted while you are typing and no draft is saved anywhere.

Alongside those fields, the server records the IP address of the connection that submitted the form, a Cloudflare Turnstile token, and the time the form was loaded in your browser. The last two are anti-bot signals and are discarded once evaluated.

Fields that become email headers have newlines, tabs and control characters removed before use, and the email address is rejected outright if it contains header-injection patterns. This stops a submitted string rewriting the headers of the message we receive.

The submission is assembled into one plaintext email — name, email address, company, IP address, message, timestamp — and sent to our contact mailbox. Reply-to is set to your address, so our reply goes to you. We read it and answer it.

The careers form is the more sensitive of the two, because an application is employment information about a named person. It asks for your name, your email address, your LinkedIn URL and your message, and it records the same IP address and anti-bot signals.

There is no file upload anywhere on this site. There is no mechanism to send us a document and none is stored.

The application becomes a plaintext email to the careers mailbox, with reply-to set to you.

Be aware that HubSpot's form-capture component loads on this page. See the section on HubSpot below.

Both forms capture the IP address of the submitting connection. It is read from a header set by our host at the edge, not from anything your browser can choose to send.

It is put to four uses. It is the key that rate-limits submissions. It is sent to Cloudflare to verify the anti-bot token. It is recorded as an identifier in the rate limiter's analytics. And it is written into the body of the email we receive.

That last use is worth stating flatly rather than leaving buried. Your IP address does not stay inside an abuse-prevention system. It is copied into ordinary email and persists wherever that email persists, which is longer than the anti-abuse purpose requires.

Both forms use Cloudflare Turnstile. The Turnstile script loads from Cloudflare, so on those pages Cloudflare receives your IP address and user-agent as a function of the connection itself, before any challenge is decided. It also evaluates browser and interaction signals internal to Cloudflare that we cannot see.

On submission our server sends Cloudflare the token, our secret key and your IP address. The check fails closed: if Cloudflare is unreachable or verification does not succeed, the submission is rejected rather than let through.

Two quieter checks run alongside it. The form records when it was loaded and the server compares that to submission time; anything faster than about two seconds is treated as automated. And each form carries a hidden field a person never sees. If either check fires, the submission is discarded and you are still shown the normal success message. That is deliberate, so automated clients cannot detect the trap — but it means a false positive looks exactly like success. If you send something important and hear nothing, email us.

To stop the forms being used to flood our inbox, submissions are rate-limited through Upstash, a hosted Redis service, keyed on both your IP address and your email address.

The counting keys expire roughly two hours after the window they belong to. That is the only automatic deletion anywhere on this site.

The limiter also keeps per-identifier analytics counters, and nothing in the code expires those. Your IP address and the email address you used therefore persist in Upstash beyond the counting window.

Both forms send mail through Resend, which receives the full content of your submission in order to deliver it, and which retains delivery records according to its own terms.

From there the message sits in an ordinary mailbox and is subject to whatever that mailbox does — retention, search, backup, and forwarding by the people who read it.

A HubSpot tracking script loads in the site's root layout, so it is present on every page. It is not behind a consent gate. There is currently no cookie banner on this site and nothing for you to accept or decline.

On a single page load it reports the visit to our HubSpot portal, sets the cookies described in the next section, and requests a tracking pixel. On pages carrying a form, it additionally loads HubSpot's form-capture component and fetches that component's configuration.

Form capture is a HubSpot feature that can record submissions from forms it did not create, including the careers form. Whether it is switched on, and what it does with what it captures, is a setting in the HubSpot portal rather than something visible in this site's code. We are not going to claim a configuration we cannot show you from here.

Our content-security policy additionally permits HubSpot to load analytics, banner, chat and advertising-pixel components. Permitting is not the same as using, but it means HubSpot can begin using them without any change to this site.

You can block this entirely. Blocking the HubSpot hosts in your browser, or using an extension that does, stops all of it and does not break the site.

This distinction is easy to get wrong, so here it is in full.

Our own code sets no cookies. It writes nothing to localStorage, sessionStorage or IndexedDB, reads nothing from your device, and does no fingerprinting or device enumeration.

Cookies are nevertheless set when you visit. HubSpot's script sets them, scoped to this domain — so to your browser, and to a regulator, they are first-party cookies on thalorin.ai. Four are set on first load, before any interaction: a persistent visitor identifier and a page-view tracker, each lasting about six months, plus a session cookie and a half-hour session-window cookie.

So "Thalorin does not set cookies" is true of our code and false about this website. The accurate statement is that every cookie here is set by the HubSpot tracker described above.

You can delete them at any time and prevent them by blocking those hosts.

The site is hosted on Vercel. A host necessarily processes the IP address, URL and user-agent of every request it serves, and keeps request logs to operate the platform.

Fonts are served from this domain rather than fetched from a font provider, so a page load sends nothing to Google.

Our own application logging records error conditions, and its log statements do not interpolate your name, email address or message. One exception is worth naming: if the rate limiter itself fails, the underlying error object is logged, and that object can carry the command that failed.

Beyond the people at Thalorin who read the mailbox, your information reaches the providers that operate this site:

We are not going to publish a retention schedule we do not operate.

Nothing in this site's code expires anything, with the single exception of the rate limiter's counting keys. Form submissions become email and last as long as that mailbox keeps them. Data held by HubSpot is retained according to that portal's settings, and host request logs according to the platform's.

Published retention periods for each of those are an open item. Until they are set, the practical position is that you can ask us what we hold about you and we will tell you and delete it. That is a working answer, not a substitute for the schedule.

Depending on where you live, you may have the right to ask what personal information we hold about you, to have it corrected or deleted, to object to particular processing, and to receive a copy. Ask through the contact form and we will act on it.

To find your records we will generally need the email address you used. For anything to do with the tracking, the identifier is the cookie in your browser rather than your name — so deleting those cookies before asking removes our ability to locate the record.

Two honest limits. A deletion covering the HubSpot record requires us to act inside HubSpot. And a message already delivered as email cannot be recalled from a recipient's mailbox by us; we can delete our copies.

You do not need us in order to stop the tracking. Blocking the HubSpot hosts or deleting the cookies does it, and you do not have to tell us.

This site is aimed at organisations, not children. We do not knowingly collect personal information from children, and neither form asks for an age or is designed to attract a child's use.

If you believe a child has sent us information through one of these forms, tell us and we will delete it.

What is actually in place, and no more: the site is served over HTTPS with strict transport security; a content-security policy restricts which origins the page may load from or talk to; framing and plugin content are blocked; form input is sanitised against header injection and length-bounded; bot protection fails closed; and submissions are rate-limited.

None of that eliminates risk and we are not going to claim it does. If you find a vulnerability, our disclosure contact is published at /.well-known/security.txt. Reports are read by people and answered.

When this policy changes, the date at the top changes with it. We keep no mailing list for policy notifications and will not create one for this purpose, so the date is the mechanism.

If a change materially widens what we collect or who receives it, we will say what changed rather than quietly reissuing the text.

Questions, requests and corrections go through the contact form. Security vulnerabilities go to the contact published in /.well-known/security.txt.