[$ ] legal: aup

1. Scope and posture

This AUP applies to every Customer account, every Service, and every workload run on operator-supplied infrastructure under the XMRHost brand. It is incorporated into the Terms of Service (/legal/tos) by reference; a breach of this AUP is a breach of the Terms.

The operator’s enforcement posture is narrow-by-design. The hard-prohibition list in §3 below is short, specific, and exhaustive — there is no residual “anything we find objectionable” clause, and there is no class of workload prohibited solely on the basis that an upstream provider, payment processor, or trade body objects to it. Workloads not enumerated in §3 are presumptively permitted, subject to (a) the legality requirement in §2 below and (b) the operational constraints in §4.

The operator does not pre-screen Customer workloads. The operator does not run deep-packet inspection on Customer egress, does not enumerate processes inside Customer VPS instances, and does not maintain a workload-classification database. Enforcement is reactive and complaint-driven, except for the specifically-enumerated emergency triggers in §6.

2. Legality requirement

The Customer’s use of the Service must comply with the law of the Operating Jurisdiction in which the Service is hosted (Iceland or Romania) and with the law of any jurisdiction in which the Customer is domiciled or in which the Customer directs activity. The Customer is responsible for understanding the relevant law; the operator does not provide legal advice and does not warrant that any particular workload is legal in any particular jurisdiction.

The operator notes for the avoidance of doubt that the substantive law of an Operating Jurisdiction governs disputes about workloads hosted there — specifically Iceland’s [Höfundalög nr. 73/1972] for Iceland-hosted workloads and Romania’s [Legea nr. 8/1996] for Romania-hosted workloads, in each case as amended. The operator does not apply the substantive copyright law of any other jurisdiction to any workload absent a binding court order from an Operating Jurisdiction’s court.

3. Hard prohibitions

The following workloads are categorically prohibited and trigger immediate suspension under TOS §7.2 without prior notice or opportunity to cure. The list is exhaustive.

3.1. Child sexual abuse material (CSAM)

Storage, hosting, generation, distribution, transit, or any other technical handling of child sexual abuse material as defined under the Operating Jurisdiction’s law. The operator’s response to a credible CSAM report is:

1. immediate suspension of the Service;
2. preservation of the underlying storage in operator custody for a minimum of 90 days;
3. notification of the appropriate national hotline (Iceland: [Barnaheill — Save the Children Iceland hotline]; Romania: [Romanian Safer Internet Centre / Sigur.info]) for further reporting under the relevant statutory framework;
4. cooperation with any subsequent court order from the Operating Jurisdiction’s competent authority.

The operator does not pursue extra-statutory reporting paths, but the §6 emergency-trigger logic does not require prior complaint for this category.

3.2. Terrorism and mass-violence facilitation

Operational planning, recruitment, financing, or material-support workloads for organisations designated as terrorist by the Operating Jurisdiction or under Article 26 of the EU Counter-Terrorism Directive (Directive (EU) 2017/541, as transposed in Romania; analogous Icelandic provisions). Includes hosting of explicitly-incitatory mass-violence content as adjudicated under the Operating Jurisdiction’s law.

3.3. Active malware command-and-control infrastructure

Operation of botnet C2 servers, ransomware staging infrastructure, info-stealer dead-drop endpoints, or analogous active-attack infrastructure. The “active” qualifier is load-bearing: a malware research lab analysing samples in an isolated VPS is not in scope; a VPS issuing live commands to a deployed botnet is.

3.4. Phishing infrastructure

Operation of credential-harvesting pages impersonating a third-party brand, banking institution, or government service. The phishing-kit hosting trade is a known abuse pattern; the operator’s response is immediate suspension on receipt of a credible report from the impersonated party or from a CERT (CERT-IS for Iceland, CERT-RO for Romania) or from the operator’s own automated phishing-feed correlation (APWG, OpenPhish — see §6 emergency triggers).

3.5. Fraud, credential markets, financial-crime infrastructure

Operation of credit-card-dump marketplaces, stolen-credential exchanges, fake-document-as-a-service shops, or analogous financial-crime infrastructure. Cryptocurrency tumbler / mixer infrastructure is not in scope per se (see §5 below for the operator’s posture on overlapping cases).

3.6. Non-consensual intimate imagery (NCII)

Storage, hosting, or distribution of intimate imagery without the depicted person’s consent, including imagery generated by AI to depict an identifiable person without that person’s consent. Reports may be filed via the abuse mailbox at the foot of /legal/aup; the operator follows the immediate-suspension + storage-preservation response in §3.1.

4. Operational constraints

4.1. Network egress

The Customer must not knowingly transmit traffic that violates the Operating Jurisdiction’s network-abuse statutes (e.g. Iceland Lög nr. 30/2002 on electronic communications, Romania Legea nr. 506/2004 on personal-data processing in the electronic-communications sector). Volumetric DoS / DDoS attacks originating from a Service trigger an emergency throttle and a §7 complaint procedure.

4.2. Open relays / open resolvers

The Customer must not operate an unauthenticated SMTP relay accepting third-party mail, an open recursive DNS resolver, or an open NTP / SSDP / chargen reflector. These configurations are exploited for amplification attacks and trigger an emergency throttle on detection. See [BCP 38] on ingress filtering and [RFC 5358] on amplification-attack mitigation.

4.3. Outbound port-scanning

Outbound port-scanning at scale (thousands of distinct destinations per minute, sustained) is operationally constrained — the upstream provider may issue a complaint. Targeted authorised security testing (penetration testing of an asset the Customer is contractually authorised to test) is permitted; the Customer should notify the support mailbox before commencing a sustained scanning campaign to avoid an automated throttle.

4.4. Cryptocurrency mining

Cryptocurrency mining on shared-tenancy VPS instances is permitted but operationally discouraged (CPU-saturation impact on neighbours triggers the operator’s noisy-neighbour throttle). Mining on dedicated and GPU instances is fully permitted. Tor hidden service and I2P node tiers may not be used for mining (the workloads are mutually contradictory on bandwidth profile).

5. Tor / I2P / Lokinet relay-operator carve-out

Operation of a Tor relay (middle, exit, bridge), an I2P router (regular or floodfill), or a Lokinet exit on the dedicated tor-hidden-service, i2p-node, and lokinet-exit Service tiers is not only permitted but actively supported. Per /docs/run-non-exit-tor-relay, /docs/setup-i2p-floodfill, and the forthcoming Lokinet-exit doc, the operator’s procedural posture for abuse complaints originating from such relays is:

1. The operator will identify the workload as a privacy-network relay in the response to the complainant.
2. The operator will not unilaterally suspend the Service for activity that is solely the result of the relay’s normal operation (i.e. exit-relay traffic patterns that look like abuse to a naive complainant but are anonymised third-party traffic).
3. The operator will engage the relay operator (the Customer) in the complaint-resolution path under §7 if the activity persists or if the complaint is escalated by an Operating Jurisdiction authority.
4. The operator will comply with a binding court order from an Operating Jurisdiction court, in which case the relay operator is informed (subject to any non-disclosure provision in the order) and given the opportunity to seek their own legal counsel.

6. Emergency triggers (operator-initiated suspension)

The operator may suspend a Service without prior complaint where the operator has direct, credible, near-real-time evidence that the Service is engaged in a §3 hard-prohibition workload OR in a §4.1 / §4.2 emergency operational pattern. Emergency triggers include:

• inbound abuse feed from a CERT (CERT-IS, CERT-RO) flagging the Service IP for active C2 / phishing / CSAM hosting;
• automated correlation against APWG / OpenPhish / SURBL feeds for §3.4 phishing reports;
• volumetric DoS egress detection by the upstream provider’s flow-analytics, exceeding the per-tier egress envelope;
• operator-internal honeypot or traffic-analysis pipeline flagging a §3.1 / §3.3 pattern with high confidence.

Emergency suspension is followed within 24 hours by a written notice to the Customer per TOS §3 contact-email channel, with the basis of the suspension and the §7 cure path (where available).

7. Third-party complaint posture (non-emergency)

The operator does NOT operate a third-party abuse-report intake. Informal complaints — DMCA-format notices, brand-monitoring claims, “trust & safety” alerts, private-investigator requests, civil-litigation discovery letters sent without court process, marketing-side reputation services, automated copyright-bot mailings — receive no action and no acknowledgement. The operator does not run an abuse mailbox on the public surface, does not publish a designated-agent contact, and does not maintain a notice-and-takedown form.

This is not an oversight. The operator’s view is that operating a private third-party takedown procedure on the basis of unverified complaints would amount to a privatised censorship channel that bypasses the substantive-law adjudication step. Tenants pay for hosting under a published AUP; enforcement against a tenant is operator-discretion based on the operator’s own observations of an actual §3 / §4 / §6 violation, not on third-party allegations.

8. Intellectual-property complaints

The operator does not process notices in the format prescribed by the U.S. Digital Millennium Copyright Act (17 U.S.C. § 512). The operator’s stance is that the Operating Jurisdiction’s substantive copyright law applies — Iceland’s Höfundalög nr. 73/1972 for Iceland-hosted workloads and Romania’s Legea nr. 8/1996 for Romania-hosted workloads — and the operator processes intellectual-property matters ONLY when served with a court order from a court of competent jurisdiction in the relevant Operating Jurisdiction, and only after counsel review.

A rightsholder with a substantive copyright claim under Operating Jurisdiction law may pursue the matter through the Operating Jurisdiction’s courts; the operator will respond to a properly-served court order, processed by counsel. The operator declines to operate a privatised takedown procedure that bypasses the substantive-law adjudication step, and declines to apply U.S. statutory standards extra-territorially absent a treaty obligation to do so.

The operator does not maintain a separate DMCA-process page on this surface. There is no DMCA designated-agent registration; there is no notice-and-takedown form; there is no counter-notice procedure. Rightsholders sending DMCA-format notices to any operator-published address will receive no response.

8.1 Other inbound legal channels

The same posture applies to non-IP requests:

• Civil discovery without court process — declined.
• Law-enforcement informal requests (“preservation requests”, “voluntary cooperation” enquiries, “national security letters” outside the operator’s jurisdiction) — declined.
• Trust & safety / brand-monitoring services acting on behalf of a third party — declined.
• Court orders from a competent tribunal — processed by counsel, on their substantive merits, with the tenant notified to the extent permitted by the order.

9. Enforcement transparency

Where the operator suspends or terminates a Service under this AUP, the operator records the basis (the §3 / §4 / §6 trigger, the date, and a reference to the underlying complaint or detection event). Aggregate suspension statistics — counts per trigger category per quarter — are published in the operator’s transparency report (forthcoming under /transparency; the page does not exist at MVP).

The operator does not publish per-Customer suspension records and does not respond to third-party requests to confirm or deny that any particular Service has been suspended absent a Customer waiver.

10. Updates

This AUP may be updated to reflect (a) changes in the underlying Operating Jurisdiction’s law, (b) new abuse patterns that warrant inclusion in §3 or §4, or (c) procedural refinements to §7. Material updates are effective on the effectiveFrom date listed in the front-matter of the revised document, with at least 30 days’ notice to active Customers per the TOS §2 notification protocol. Non-material clarifications take effect immediately on publication.