Security

Security you can check. No smoke.

A public registry is only as strong as what it refuses to leak. This page explains, in plain language, exactly how The Human Behind protects the data behind it — and what we deliberately never store. Everything here matches how the system is actually built.

Your email is never public
Date and hash can never be edited
No ID documents, no biometrics
Infrastructure in the EU

The database defends itself

The protection is not a promise in the application code — it is enforced by the database, at the lowest level, for every query.

Row-level security on every table

Every table in the registry has row-level security (RLS) enabled. Anonymous visitors can read public records only — never drafts, never removed data, never internal tables. The database itself enforces these rules on each query, so even a bug in the application cannot bypass them.

Your email is never exposed

Your email lives only in the authentication system. It is not even a column in the records table — so there is nothing to leak into a public record, the directory or the API. Claim messages, which do contain an email, are locked to administrators only.

Date and hash are immutable — for everyone

Once a record is sealed, its THB number, registration date and SHA-256 fingerprint cannot be changed. A database trigger rejects any attempt, from anyone — including our own administrators. Prior date claims are only worth something if nobody can rewrite them.

One public surface, twelve public fields

The public record page, the directory and the API all read from a single public view containing exactly the twelve public fields of a record. Internal identifiers and verification references are excluded structurally — they are not filtered out, they are simply not there.

Try to rewrite history

This is not a policy document — it is a database constraint. Any update that touches the sealed fields fails with the same error, whoever runs it:

update records set registered_at = now() where slug = 'nova';
-- ERROR:  immutable_columns

What we never store

The safest data is the data that was never collected. Minimisation is a design rule of the registry, not a preference.

What the registry holds

The public fields of your record: name, type, where it operates, responsible person
Your THB number, sealed registration date and SHA-256 fingerprint
Your account email — private, used only to sign in and contact you
From September, for verified records: the result of the identity check, its date and a session reference

What it will never hold

Your ID document, or any copy, photo or scan of it
Biometric data of any kind — no face templates, no voice prints
Tracking or advertising profiles — this site sets no tracking cookies
Passwords in readable form — authentication is handled by Supabase Auth

Identity checks are carried out by Stripe Identity, on Stripe's infrastructure. The Human Behind never sees or stores your document — our database has no place to put it.

The edges are guarded too

From the network to the sign-up form, the boring parts are covered.

EU infrastructure

The site is served through Cloudflare (hosting, CDN and DDoS protection). The registry database runs on Supabase, on Postgres hosted in the European Union (eu-west region).

Cookies that scripts cannot read

This website sets no tracking cookies at all. On the registry platform, session cookies are HttpOnly — invisible to JavaScript — and scoped strictly to the platform domain.

Bots hit three walls

Sign-ups and claims are protected by a honeypot field, a minimum-time check and Cloudflare Turnstile. All three are validated on the server — client-side tricks do not help.

Removal leaves a trace, not a hole

Records are never hard-deleted. If you remove yours, it disappears from the directory but the registry keeps minimal proof that it existed and was removed — so a number can never be silently reused by someone else.

An honest note

No system is unbreakable, and we will not pretend this one is. What we can promise: a small attack surface (this website runs no backend at all), a database that enforces its own rules, and no honeypot of sensitive documents to steal. If you find a vulnerability, please tell us — write to us with “Security” in the subject and we will respond as fast as we can.

Report a security issue