[$ ] legal: privacy

1. Who is the data controller

The data controller (in [GDPR Article 4(7)] sense) for personal data processed via the XMRHost brand surface is the operator legal entity disclosed on /legal under the operator-disclosure block. Until counsel filing is complete, both the entity name and the registered address render TBD. The contactable representative for data-protection enquiries is reachable via the privacy mailbox listed under /legal DISPATCH.

Iceland is a member of the European Economic Area; the EEA Joint Committee Decision 154/2018 incorporates the GDPR (Regulation (EU) 2016/679) into the EEA Agreement; Iceland’s Lög nr. 90/2018 is the national implementing statute. Romania is an EU member state; Legea nr. 190/2018 is the national implementing statute alongside the directly-applicable Regulation. The operator’s processing of personal data of customers whose Service is hosted in either jurisdiction is therefore subject to the GDPR.

For users outside the EEA / EU, the operator extends the same procedural rights as those granted to EEA / EU users under §4 below, as a matter of operator-side policy rather than statutory obligation.

2. What is collected

2.1. At sign-up

• Email address. Required. Used as the binding-notice channel (TOS §3) and as the password-reset destination. Pseudonymous email addresses are permitted; the operator does not validate the identity of the natural person behind the address.
• Password. Stored as an Argon2id hash with per-account salt. Never logged in cleartext. Not recoverable by the operator — the password-reset flow issues a new password via the registered email address; there is no out-of-band recovery path.
• Optional public-key. A PGP public key may be uploaded at sign-up; if present, all subsequent operator-to-customer email is encrypted to that key.

2.2. At order time

• The Service order. Type, location, billing cycle, add-ons. Linked to the Account.
• The XMR subaddress assigned to the order, and the inbound XMR transactions to that subaddress (visible to the operator via the operator’s view-key per Monero’s view-key semantics; see /payments).
• No payment-instrument data. The operator does not collect a card number, a bank account number, a fiat-rail counterparty identifier, or any KYC document.

2.3. During Service operation

• Inbound HTTPS request logs for the brand surface (/, /node/..., /docs/..., /legal/... etc.): truncated source IP (last octet zeroed for IPv4, last 80 bits zeroed for IPv6), timestamp (5-minute resolution), URL path, response status. Used for operational debugging and aggregate self-hosted Plausible analytics. Retention: 14 days, then irreversibly deleted.
• Service-side network metadata for the customer’s VPS / dedicated / GPU instance: aggregate bytes-per-five-minute on the customer-facing interface, used for invoice computation and SLA accounting. No per-flow source / destination retention. Retention: 90 days, then aggregated to monthly totals and the per-flow data deleted.
• Customer-uploaded SSH keys. Stored in the cloud-init metadata for the instance. Not logged elsewhere.
• Support-ticket content. Whatever the customer writes into a ticket. Retention: 12 months from the ticket-resolved date, then irreversibly deleted unless the ticket is associated with an active legal hold.

2.4. NOT collected

The operator runs no third-party tracking or analytics scripts on the brand surface. The following are explicitly absent:

• Google Analytics (any property ID, GA4 / UA / GTM).
• Facebook Pixel.
• Hotjar, FullStory, LogRocket, Mixpanel, Amplitude, Heap.
• Stripe / Braintree / Adyen / Shopify payment scripts (the brand does not use these processors).
• Sentry / Datadog / New Relic cloud-hosted telemetry SDKs.
• Cloudflare as a CDN (no Cloudflare proxy in front of the brand surface — direct origin under the operator’s Caddy issuance).
• Cookies for advertising or cross-site tracking. See §3 below.

The only first-party analytics surface is a self-hosted Plausible instance — this brand’s instance is distinct from the operator’s other-brand instances, runs on operator-controlled infrastructure in an Operating Jurisdiction, and emits no third-party requests. Plausible’s data model is documented at [Plausible Data Policy]; the operator’s instance is configured to anonymise visitor IPs at the daemon level (no IPs persisted to disk).

3. Cookies

The operator’s cookie surface is minimal and entirely first-party. The only cookies set are:

• A session cookie issued by the /console authentication flow. Lifetime: session. Purpose: authenticated session continuity. Strict same-site, HttpOnly, Secure flags set per [RFC 6265] §4.
• A CSRF-protection cookie for the /console mutation endpoints. Lifetime: session. Purpose: cross-site-request-forgery protection per the OWASP recommended pattern.

There are no advertising cookies, no analytics cookies (Plausible operates without cookies), no third-party cookies, and no consent banner — because no consent is required for the strictly-necessary functional cookies above per Article 5(3) of Directive 2002/58/EC (the ePrivacy Directive) as transposed in Iceland (Lög nr. 81/2003) and Romania (Legea nr. 506/2004).

4. Data-subject rights

Where the GDPR applies (per §1 above), the data subject has the following rights, exercisable via the privacy mailbox listed under /legal DISPATCH. The operator’s response timeline is up to 30 calendar days from receipt of a substantively-complete request, extendable by a further 60 days per [GDPR Article 12(3)] for complex or numerous requests.

• Article 15 — Access. The data subject may request a copy of the personal data the operator holds about them, together with the §1 / §2 disclosures (purposes, categories, recipients, retention periods, etc.). The operator’s response is the personal-data export in a machine-readable format (JSON-Lines), accompanied by the disclosure metadata.
• Article 16 — Rectification. The data subject may correct inaccurate or incomplete personal data. The operator’s /console profile surface allows direct rectification of email, public-key, and ticket content; rectification of derived data (e.g. an audit-log entry) is operator-mediated.
• Article 17 — Erasure. The data subject may request erasure of personal data where the GDPR Article 17(1) grounds are met. The operator’s response: closure of the Account, irreversible deletion of the Service-instance data per TOS §5.4 wipe semantics, and irreversible deletion of the Account record from the operator’s database. Some categories may be retained for the operator’s defence of legal claims under Article 17(3)(e) — invoice records for the local-law statutory retention period (Iceland: 7 years per Bókhaldslög nr. 145/1994; Romania: 10 years per Legea contabilităţii nr. 82/1991), pseudonymised so the natural person is no longer identifiable.
• Article 18 — Restriction. The data subject may request restriction of processing while a rectification request is being processed or while the lawfulness of processing is contested. The operator implements restriction by flagging the Account record as restricted-only-storage and suspending all non-storage processing.
• Article 20 — Portability. The data subject may receive a copy of personal data they provided to the operator, in a structured, commonly-used, machine-readable format. The operator’s response is the same export as Article 15, in JSON-Lines + a flat-file archive of any uploaded artefacts (SSH keys, support-ticket attachments).
• Article 21 — Objection. The data subject may object to processing of their personal data on the basis of public-interest or legitimate-interest grounds. The operator’s processing is principally on the basis of the contractual-necessity grounds of GDPR Article 6(1)(b) (necessary for the performance of the Service contract); legitimate-interest processing is limited to the abuse-mitigation surface in §2.3 above and is reviewed against the data subject’s objection.
• Article 22 — Automated decision-making. The operator does not engage in solely-automated decision-making producing legal effects on the data subject. The §6 emergency-trigger surface in /legal/aup is operator-reviewed before suspension is finalised; the only fully-automated suspension surfaces are the §5.4 non-payment timer (which produces a suspension that the data subject can immediately reverse by paying the invoice).

5. International transfers

Personal data processed in connection with the Service is stored within the Operating Jurisdiction (Iceland or Romania, per the data subject’s order selection). The operator does not transfer personal data outside the EEA / EU absent (a) the data subject’s explicit instruction (e.g. opening a support ticket in which they paste personal data of a third party located outside the EEA), or (b) compliance with a binding court order from an Operating Jurisdiction’s competent authority.

The operator’s upstream provider, the operator’s mail provider, and the operator’s payment-watcher infrastructure are all located within the EEA / EU. The operator does not use any U.S.-based cloud provider, U.S.-based analytics provider, or U.S.-based mail relay.

6. Government access

The operator processes lawful requests from competent authorities of the Operating Jurisdictions. The operator’s procedural posture:

1. The operator does not voluntarily disclose personal data to any authority absent a binding written request signed by an authorised official.
2. The operator scrutinises the legal basis of every request: a court order from a court of competent jurisdiction in an Operating Jurisdiction is honoured; a subpoena from a foreign jurisdiction is processed only via the relevant mutual-legal-assistance treaty (MLAT) channel of the Operating Jurisdiction.
3. The operator notifies the affected data subject of the request as soon as reasonably practicable, except where the request prohibits notification under a non-disclosure provision binding on the operator.
4. The operator does not maintain a “back door”, an undocumented telemetry channel, or any other voluntary-cooperation infrastructure.

The operator publishes a quarterly transparency report (forthcoming under /transparency; the page does not exist at MVP) summarising the count of requests received per Operating Jurisdiction, the count of requests honoured, the count of requests refused as defective, and the count of data subjects affected. Per-request detail is not published.

7. Retention summary

Category	Retention
Email address (active Account)	for the lifetime of the Account
Argon2id password hash (active Account)	for the lifetime of the Account
SSH public keys uploaded to instances	for the lifetime of the instance
Inbound HTTPS request logs (brand surface)	14 days
Service-instance network metadata (per-flow)	90 days
Service-instance network metadata (monthly aggregates)	24 months
Support-ticket content	12 months from resolution
Invoice records	7 years (Iceland) / 10 years (Romania) — pseudonymised after Account erasure
Plausible analytics events	24 months (Plausible default; data anonymised at ingest)

After the retention period the data is irreversibly deleted from operator systems. No third-party processor retains a copy.

8. Security

The operator follows industry-standard practice for the protection of customer data. The brand surface and /console are served over TLS 1.3 only with HSTS preload. The customer database is encrypted at rest with operator-controlled keys. The operator’s incident-response posture is documented at /docs/incident-response (forthcoming).

The operator does not warrant the absolute security of any data; the GDPR Article 32 obligation is one of appropriate technical and organisational measures, not absolute prevention. Data subjects are notified of personal-data breaches affecting them within 72 hours of operator awareness per [GDPR Article 33-34] where the breach meets the notification threshold.

9. Updates

This Privacy Policy is updated from time to time to reflect (a) changes in the operator’s processing surface, (b) changes in the underlying law, or (c) procedural refinements. Material updates are effective on the effectiveFrom date in the document front-matter, with at least 30 days’ notice to active data subjects via the registered email channel for changes that materially expand the operator’s processing surface. Non-material clarifications (e.g. tightening retention, adding a new data-subject right, reducing an existing collection) take effect immediately on publication.