Account Privacy Notice v5

Version: 5
Effective date: 2026-09-20
Privacy and account contact: [email protected]

Scope and purpose

This notice covers invitation, public registration when enabled, sign-in, account, access-gated product downloads, free Core account claims, Stripe Checkout, licence, activation, and installation-management data handled through account.crathesaudio.com. We use that data only to register or admit a person under the active account policy, authenticate the account, provide the requested product release, complete and prove licence ownership, operate activation and installation limits, prevent abuse, and maintain the security and recoverability of the service.

Account messages are transactional only. We do not use the account email address for advertising, marketing mail, behavioural profiling, an updater, or plug-in telemetry.

Data handled by the account service

The service keeps the normalized email address, opaque account identifier, verification and status timestamps, invitation and product-access state, hashed credential verifiers, Checkout Session and Customer identifiers and outcomes, licence-grant state, and installation activation state. Installation records include bounded client version, plug-in format, operating-system family, processor architecture, and activation/deactivation timestamps. Passwords are not used. Raw invitation, magic-link, session, and CSRF credentials are not stored in PostgreSQL.

Stripe email, Customer, and Checkout fields never establish Crathes Audio account ownership. Account identity comes from the verified email address. Product access and grants are recorded locally with immutable invitation, free Core account-claim, or fulfilled Stripe Checkout provenance.

Service providers

Cloudflare provides the public network edge and processes network addresses, HTTP headers, requested URLs, and proxied request traffic for transport, TLS, security, and abuse prevention. When public registration is enabled, Cloudflare Turnstile also processes the browser challenge token and associated network and browser signals to help prevent automated account creation. Supported account routes are query-free. Invitation and magic values initially stay in the browser URL fragment, which is never part of an HTTP request. After the HTML and same-origin script load at the fragment-free URL, the script removes the fragment before sending the bearer in a bounded POST body; bearer values and request bodies are forbidden from application logs and metric labels.

Hetzner hosts the application, PostgreSQL database, immutable release artifacts and evidence, automatic server backups, and the encrypted Borg backup repository on a Storage Box. Resend receives the destination email address and the plain-text and self-contained HTML alternatives of transactional invitation and magic-link messages. Those messages contain the applicable one-time bearer link. Resend click and open tracking must remain disabled, and messages contain no remote assets. Stripe receives an opaque local Checkout reference, product and price references, return URL, and expiry; it creates the Checkout Session and Customer and separately handles any information entered directly into Stripe Checkout. The local service retains bounded Stripe identifiers and terminal outcomes, not payment-card details. Google Workspace processes support correspondence and replies to transactional account messages.

Retention

Initial invitation delivery is retried for no more than one hour. An unused delivered invitation lasts no more than seven days. Invitation email and token verifier are scrubbed when the invitation is consumed, revoked, or expires. A magic link lasts 15 minutes. Account sessions have a 30-day idle and 90-day absolute limit. Expired or terminal authentication and delivery rows are removed by bounded cleanup after a 30-day transient audit window. An unverified public-registration account with no remaining dependent state is also deleted after that window.

The email address remains while the account is active. Opaque account, product-access, Checkout, grant, installation, release, and security-audit records are durable licensing and operational evidence. Revocation or deactivation changes their state; it does not claim that their opaque history is erased.

Production recovery uses automatic Hetzner backups of the protected application server and client-side encrypted Borg archives of PostgreSQL on a Hetzner Storage Box. Borg retains 14 daily, 8 weekly, and 6 monthly generations. Existing server backups and immutable Borg generations are not rewritten when live data is scrubbed; they age out under their configured retention. Before an erasure is confirmed, a pseudonymous authenticated tombstone must be durably recorded and its exact ledger head must be verified in both an encrypted Borg archive and a genuinely independent encrypted immutable copy. The second-copy provider is an operator selection and is not selected by this source code; erasure completion must not be represented as available until that provider, its retention, and successful copy evidence are configured and named in the deployed notice.

A restore remains account- and network-fenced before exposure. It migrates the isolated database, requires the latest ledger sequence, digest, and receipt identifiers obtained independently from both copies, and replays every qualifying tombstone before account mode can be re-enabled. If either copy, the dedicated reconciliation key, the latest-head evidence, or the zero-PII/zero-active-access proof is unavailable, the restore remains fenced. A selected older database archive never supplies or limits the ledger.

Diagnostics are separate

Optional diagnostic reports use the cookieless https://api.crathesaudio.com/diagnostics page and its separate Diagnostic Privacy Notice v1. Diagnostic rows have no account, Checkout, grant, or installation link, expire exactly 14 days after acceptance, and are excluded from the production database backup data. Account cookies are host-only and are not sent to the API host.

Erasure and revocation

To request account erasure, email [email protected]. The operator must verify the request. The account service must first be deployed in disabled mode. A root-owned durable operation fence then stops it and prevents restart throughout preparation, ledger copying, and commit. Preparation records the tombstone before disabling the account and invalidating live authentication; the request is still incomplete while its two encrypted ledger copies are unproved. Only after both exact copy receipts are recorded may the operator scrub the live email address, revoke product access, terminate or scrub outstanding local authentication and mail state, revoke account grants, and deactivate installations. A failed or interrupted gate keeps the service fenced and is not an erasure-completion claim. Opaque identifiers, timestamps, licensing provenance, Stripe references, and bounded security-audit evidence remain where needed to prove those actions. Every pending or created Stripe Checkout Session must first be expired or reconciled, every active mail lease must end, and provider-held records may require separate manual handling under the provider's retention rules.

Deactivation or erasure stops entitlement refresh immediately. An offline entitlement already issued to the plug-in may continue to work until its signed expiry, for up to 45 days.