Version 1.0 · effective from the date of the first public release. Earlier revisions in the git history of `chimera-storefront`.

This document describes the actual data behaviour of CHIMERA. It is intentionally short — when a service collects only what is necessary to function, there is nothing to describe.

1. What we don't collect

• Client IP address. Neither when visiting the storefront (nginx access logs are off), nor when connecting to the VPN nodes (where `RemoteAddr` is not logged — verifiable via reproducible builds).
• Email, phone number, name. We never ask for these fields. The core mechanism of our anonymity is that there is simply nowhere to enter them.
• User traffic. Neither DNS queries, nor visited domains, nor payload content are recorded.
• Per-user metadata. Session start, duration, transferred bytes — not stored.
• Payment details. CryptoCloud (the payment provider) sees the sender's crypto address; we do not. We only get the fact "invoice paid" through an HMAC-signed webhook.

2. What we collect (aggregated, no personal binding)

• Prometheus counters on the VPN nodes: total active connections, handshake error rate, node CPU/memory. No per-user breakdown.
• ML telemetry of the protocol selector — only if you explicitly enabled it in the client settings. Hour-bucketed events (precision down to an hour, not a second), provider_hash via HMAC with a client-side key, RTT in power-of-2 buckets. See `chimera-core/src/telemetry.rs` — documented line by line.
• Billing webhook events — the fact and status of payment processing (`paid` / `failed` / `expired`), with `order_id = sha256(salt || token || serial)`. The 16-word key itself is stored as its SHA-256 hash.

3. Retention

4. Cookies

This site does not use cookies. Neither analytical nor session ones. The dashboard login keeps the key in form memory, not in localStorage/sessionStorage/cookie.

5. Third-party

• Google Fonts — self-hosted on our server through `next/font`; no requests are sent to fonts.googleapis.com.
• CryptoCloud / BTCPay — they see the fact of payment and the sender's crypto address. Our storefront does not share any client identifier with them other than order_id.
• No Google Analytics, Meta Pixel, Hotjar, Sentry, CloudFlare front-end JS or any other third-party script. Verifiable via `view-source` or via Tor Browser's NoScript.

6. Compelled disclosure

We cannot hand over what we do not have. Law-enforcement bodies that obtain a legally valid request will receive:

• Aggregated Prometheus counters (useless for deanonymization)
• The `orders` table (SHA-256 key hashes and order_ids, no IPs)
• Webhook events (linked to CryptoCloud order_ids, no IPs)
• Confirmation that there are no IP logs on the VPN nodes (verified by the reproducible build of `chimera-node`)

The fact that any such request was received is recorded in the warrant canary (`/canary`). If the canary is not refreshed for over 35 days — assume that a request was received and act accordingly.

7. User rights (GDPR / CCPA equivalent)

Even though we do not hold data linkable to you for GDPR "right to access / delete" purposes, we still recognize these rights. If you need us to delete anything tied to your key_hash — write to the SimpleX contact in `/legal/security`.

The request does not require proof of identity (the irony — we will simply verify that you own the key, no other attributes exist).

8. Privacy contact

Only through SimpleX Chat or GPG-encrypted email; details on /legal/security. Plain unencrypted email is not read — it goes to /dev/null.

9. Jurisdiction

CHIMERA is operated by a solo operator with no legal entity (see the project OPSEC model). You cannot send an MLAT request against us to a specific country, because no such country exists for us. You can, against an individual VPN node — and in practice there is nothing there beyond timing metrics.