Account Privacy Notice v1

Account Privacy Notice v1

Version: 1
Effective date: 2026-08-17
Privacy and account contact: [email protected]

Scope and purpose

This notice covers invitation, sign-in, account, Octavium Core download, Stripe Checkout, licence, activation, and installation-management data handled through account.crathesaudio.com. We use that data only to admit an invited person, authenticate the account, provide the requested free Core 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. Ownership comes only from the verified email-bound invitation and the local account/product record.

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. 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, and the encrypted Borg backup repository on a Storage Box. Resend receives the destination email address and the text-only transactional magic-link message. 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/Gmail processes only correspondence that you send to, or receive from, [email protected].

Retention

An unused 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.

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 PostgreSQL archives use encrypted Borg retention of 14 daily, 8 weekly, and 6 monthly generations. The Hetzner Storage Box also keeps a daily 06:00 UTC provider-snapshot plan with at most 7 snapshots. Existing immutable backup generations are not rewritten when live data is scrubbed; they age out under those policies. 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.