Law Enforcement Guidelines

1. Purpose of This Document

These guidelines are intended for law enforcement agencies, prosecutors, and judicial authorities seeking data from SimpleGo's SMP relay server infrastructure. This document provides: a technical explanation of our service architecture and its implications for investigations, a clear description of what data we can and cannot provide, the legal requirements we must verify before complying with any request, the process for submitting valid requests, and an honest assessment of the investigative value of data we possess.

We publish these guidelines in the interest of transparency. We believe that both the public and law enforcement benefit from a clear, honest description of our capabilities and limitations.

2. Service Description and Architecture

SimpleGo operates public SMP (SimpleX Messaging Protocol) relay servers that facilitate encrypted message exchange. Understanding our architecture is essential for setting realistic expectations about what data we can provide.

2.1 How our service works

Our servers function as temporary encrypted message storage relays. A sender's client encrypts a message with multiple layers of end-to-end encryption. The encrypted message is sent to our server and stored in a message queue. The recipient's client retrieves the encrypted message and decrypts it locally. Our server never possesses the decryption keys and processes only encrypted data.

2.2 No user accounts or registration

Our service has no user accounts, no registration process, no login credentials, no email addresses, no phone numbers, and no user profile data. Users connect anonymously over TLS or Tor. There is no concept of a "user" in our system, only cryptographic queue identifiers.

2.3 No communication metadata

The SimpleX Protocol is specifically designed to prevent the server from learning who communicates with whom. Each conversation uses multiple independent, unidirectional message queues. A single server never sees both sides of a conversation. Queue identifiers are random and cannot be correlated to real-world identities by the server operator.

2.4 Clearnet vs. Tor access

Our servers are accessible via both standard TLS connections (clearnet) and Tor onion services (.onion). For clearnet connections, the connecting client's IP address is visible to our server in volatile memory during the active connection. For Tor connections, only a Tor relay IP address is visible, not the user's real IP address.

3. What Data We Can and Cannot Provide

This section provides a comprehensive, honest assessment of data availability. We distinguish between data categories using clear status indicators.

Data Category	Available?	Explanation
Decrypted message content	Never	We do not possess decryption keys. End-to-end encryption is performed by the users' clients. This is an immutable architectural property.
User identity (name, email, phone)	Never	No user accounts exist. No registration data is collected. No identity information exists on our servers.
Communication graph (who talks to whom)	Never	The SimpleX Protocol structurally prevents the server from determining communication relationships. Queue identifiers are random and unlinkable.
Contact lists or address books	Never	These exist only on users' devices, never on our servers.
Historical IP address logs	Not by default	We do not log IP addresses to persistent storage in normal operation. No historical connection records exist unless prospective logging has been ordered (see Section 9).
Currently connected IP addresses	Partial	IP addresses of currently active connections exist in volatile server memory (RAM). This data is lost on disconnect or server restart. Useful only if a suspect is known to be connected at the moment of a lawful request.
Encrypted message blobs	Yes	Encrypted, padded 16 KB data blocks stored in message queues. Cannot be decrypted by us. Retained until delivered or 30 days maximum.
Queue existence and metadata	Yes	We can confirm whether a specific queue identifier exists, when it was created, and its current status. Queue IDs are random 32-byte values.
Server configuration and software	Yes	Our server software is open source (AGPL-3.0). We can provide server configuration details and confirm the software version in operation.
Timestamps of queue operations	Partial	Some operational timestamps (queue creation, last message delivery) may be available. Precision and retention vary.

4. Legal Requirements for Data Requests

As a German-based service provider, we are subject to German law. We comply with lawful orders issued by competent German authorities. This section details the specific legal instruments we recognize.

4.1 German domestic requests

4.1.1 Bestandsdaten (Subscriber data) per § 174 TKG

Section 174 of the Telecommunications Act (Telekommunikationsgesetz, TKG) allows authorities to request subscriber data (Bestandsdaten) such as names, addresses, and account information. Since we do not collect any subscriber data (no accounts, no registration), a § 174 TKG request will yield no results. We will confirm this in writing.

4.1.2 Verkehrsdaten (Traffic data) per § 175 TKG / § 100g StPO

Requests for traffic data (Verkehrsdaten) under § 175 TKG in conjunction with § 100g StPO require a court order (richterlicher Beschluss) issued by a competent judge. Traffic data includes IP addresses, connection timestamps, and communication patterns. Since we do not retain traffic data in normal operation (no IP logging, no connection records), a retrospective traffic data request will yield no results. Prospective collection can be ordered (see Section 9).

4.1.3 Telekommunikationsüberwachung (TKÜ) per § 100a StPO

Telecommunications surveillance orders under § 100a StPO are the primary legal instrument for lawful interception of communications in Germany. Such orders require: authorization by a judge (richterlicher Beschluss) under § 100e StPO, reasonable suspicion (zureichende tatsächliche Anhaltspunkte) of a serious criminal offense listed in § 100a Abs. 2 StPO (the "Katalogstraftat" requirement), identification of the specific target (Betroffener) and, where possible, the specific communication to be intercepted, and the order must be proportionate (verhältnismäßig) and subsidiary (letztes Mittel).

If a valid § 100a StPO order is presented, we can implement prospective IP logging for specified queue identifiers (see Section 9). We cannot provide decrypted content or intercept communications in plaintext, as we do not possess the necessary cryptographic keys.

4.1.4 Bestandsdatenauskunft per § 100j StPO

Subscriber data requests under § 100j StPO do not require a court order for basic subscriber data. However, since we hold no subscriber data, such requests will receive a null response. We will confirm in writing that we hold no data responsive to the request.

4.1.5 Eilanordnung (Emergency order) per § 100e Abs. 1 S. 2 StPO

In cases of imminent danger (Gefahr im Verzug), the public prosecutor (Staatsanwaltschaft) may issue an emergency order without prior judicial authorization. Such orders must be confirmed by a judge within three working days (§ 100e Abs. 1 S. 3 StPO). If confirmation is not obtained, the order expires and any data collected must be destroyed. We comply with valid emergency orders but require prompt judicial confirmation.

4.2 Requests under the Bundeskriminalamtgesetz (BKAG)

The BKA may issue requests under §§ 10-12 BKAG for the prevention of international terrorism or in its function as central office. These requests are subject to the same technical limitations described herein.

4.3 Requests under Landespolizeigesetze (State police laws)

Preventive measures under state police laws (e.g., PolG NRW for North Rhine-Westphalia) may authorize data requests under specific conditions. We evaluate each request individually for legal sufficiency and proportionality.

4.4 Requests we will reject

We will reject requests that: lack a valid legal basis under German law, do not include a court order where one is required, are overly broad or fail to identify specific targets or queues, request data that does not exist on our systems (e.g., decrypted messages), request the installation of backdoors or modification of our encryption implementation, originate from foreign authorities without going through proper mutual legal assistance channels, or are presented informally without proper legal documentation.

5. Request Process and Submission

5.1 Required information

Each request must include: the identity of the requesting authority and the responsible officer, the legal basis for the request (citing the specific statutory provision), a court order or other judicial authorization (where required), a specific description of the data sought, the target identifier (queue ID, IP address, or server endpoint if known), and the time period covered by the request.

5.2 Submission

Email: legal@simplego.dev (for non-classified requests)
Post: IT and More Systems, Sascha Dämgen, Am Neumarkt 22, 45663 Recklinghausen, Germany
Reference: "Law Enforcement Request" / "Behördliche Anfrage"

We accept requests in German and English.

5.3 Response time

We aim to acknowledge receipt within 2 business days and provide a substantive response within 14 business days. For emergency requests with imminent danger to life (see Section 6), we make reasonable efforts to respond within 24 hours.

6. Emergency Disclosure Requests

In situations involving imminent danger to life or physical safety (Gefahr für Leib und Leben), we may provide available data on an expedited basis, even before receiving a formal court order, provided that: the requesting authority credibly demonstrates an immediate threat to life or physical safety, the request is made by a verified law enforcement officer, and a formal legal order is submitted promptly thereafter.

This applies primarily to cases involving: imminent risk of suicide or self-harm communicated via our service (if a queue identifier is known), kidnapping with imminent danger to the victim, active threat situations where time is critical, and missing persons cases with credible risk of harm.

Even in emergencies, we can only provide data that technically exists on our systems. In most cases, this will be limited to confirming whether a specific queue is active and, if the suspect is currently connected, the connecting IP address from volatile memory.

7. International Requests (Mutual Legal Assistance)

SimpleGo is a German company subject to German law. We do not accept direct requests from foreign law enforcement agencies.

7.1 Required channels

Foreign authorities must submit requests through one of the following channels: a Mutual Legal Assistance Treaty (MLAT) request via the German Federal Ministry of Justice (Bundesministerium der Justiz, BMJ), a European Investigation Order (EIO) under Directive 2014/41/EU (for EU Member States), or a direct request to a German court via letters rogatory (Rechtshilfeersuchen).

7.2 EU Member States

Requests from EU Member State authorities under the European Investigation Order (EIO) framework are processed via the competent German judicial authority (typically the Staatsanwaltschaft or Amtsgericht with jurisdiction over Recklinghausen). We cooperate with the German executing authority, not directly with the foreign requesting authority.

7.3 Non-EU countries

Requests from non-EU countries must be submitted through MLAT or other applicable international agreements. The German BMJ will evaluate whether the request meets German legal standards before transmitting it to the competent German authority. We will comply with orders issued by German authorities as a result of this process.

7.4 US-specific note

US law enforcement agencies (FBI, DEA, HSI, state/local agencies) must route requests through the MLAT between the United States and Germany (Treaty Doc. 108-27). We do not accept US subpoenas, warrants, or court orders directly, as they have no legal effect in Germany.

8. Preservation Requests

We accept preservation requests (Sicherungsanordnung) to prevent the deletion of specific data while formal legal process is being obtained.

8.1 Scope

We can preserve: encrypted message blobs in specified queues (preventing automatic deletion after delivery or expiration), queue metadata (preventing queue deletion by the client), and server logs (if any exist at the time of the request).

8.2 Duration

We will preserve data for up to 90 days, or as specified in the preservation request. If no formal legal process is received within this period, preserved data will be released and subject to normal retention policies.

8.3 What we cannot preserve

We cannot preserve IP addresses in volatile memory (they are lost on disconnect), data that has already been deleted, or data that never existed on our systems.

9. Prospective Surveillance Orders

The most operationally useful data we can provide is prospective IP address logging for specified queue identifiers, ordered under § 100a StPO or equivalent provisions.

9.1 How it works

Upon receipt of a valid court order, we implement targeted logging for specified queues. When a client connects to the specified queue, we log the connecting IP address, the timestamp of the connection, and the queue identifier. This logging continues for the duration specified in the court order.

9.2 Limitations

Prospective logging captures only the IP address of the connecting client. If the client connects via Tor, the logged IP address will be a Tor exit relay, not the user's real IP. We cannot correlate the logged IP with any identity. We cannot decrypt or provide message content. We cannot determine which specific queue a target uses without the requesting authority providing the queue identifier.

9.3 Implementation timeline

Technical implementation of prospective logging typically requires 24-72 hours after receipt of a valid court order. In emergency situations, we will make reasonable efforts to expedite this process.

10. Server Seizure and Physical Access

In the event that authorities seize our physical or virtual server infrastructure (Beschlagnahme unter § 94 StPO), we provide the following information to assist with forensic analysis.

10.1 Full-disk encryption

Our servers use full-disk encryption. Access to stored data requires the encryption passphrase. We will provide this passphrase if compelled by valid court order.

10.2 What a seized server contains

A seized server will contain: the SMP server software (open source, verifiable against the public repository), server configuration files, encrypted message queues (16 KB blocks, encrypted by users' clients, which we cannot decrypt), queue metadata (random identifiers, timestamps), and TLS certificates and server keys (these protect the transport layer, not message content).

10.3 What a seized server does not contain

A seized server will not contain: decryption keys for message content (these exist only on users' devices), user identities, account data, or registration information, historical IP address logs (unless prospective logging was previously ordered), communication graphs or metadata linking queues to each other or to users, or any plaintext message content.

11. User Notification

German law does not require us to notify users about law enforcement requests in most circumstances. However, our position is as follows.

We cannot notify specific users even if we wished to, because we cannot identify users. We have no mechanism to deliver a notification to a specific person, as we have no user accounts, email addresses, or other contact information. The anonymity of our service means that user notification is technically impossible in most cases.

Where notification is legally permitted after the conclusion of an investigation, and where we can identify a specific target (e.g., through a queue identifier that was previously associated with a person through the investigation itself), we will consider providing notification in accordance with applicable law.

12. Cost Reimbursement

Pursuant to § 23 JVEG (Justizvergütungs- und -entschädigungsgesetz) in conjunction with the Anlage 3 JVEG, telecommunications providers are entitled to reimbursement for costs incurred in complying with lawful surveillance and data production orders.

We reserve the right to claim reimbursement for: technical implementation costs for prospective surveillance orders, staff time for data retrieval and production, and equipment and infrastructure costs directly attributable to compliance.

Reimbursement claims will be calculated in accordance with the applicable JVEG rates. We will not delay compliance with a valid court order pending resolution of cost reimbursement.

13. Transparency Reporting

We publish a semi-annual Transparency Report documenting all law enforcement interactions. This report includes: the total number of requests received (broken down by type and requesting authority), the number of requests complied with, the number of requests rejected (with anonymized reasons), the amount of data produced, and a warrant canary statement.

Transparency Reports are published on our website at simplego.dev/legal/transparency and in our GitHub repository.

13.1 Warrant canary

Our Transparency Report includes a warrant canary. This is a signed statement affirming, at the time of publication, whether we have received any secret court orders, national security letters, or gag orders that prohibit us from disclosing their existence. The absence of a warrant canary in a future report may indicate that such an order has been received. This mechanism provides transparency even where direct disclosure is prohibited.

14. What We Will Not Do

Regardless of the legal instrument presented, we will not: install backdoors in our software or modify our encryption implementation, weaken encryption for specific users or queues, implement blanket surveillance of all server traffic, retain data beyond what is legally required or technically necessary, provide access to decryption keys we do not possess, provide false or misleading information about our technical capabilities, or circumvent or undermine the end-to-end encryption of the SimpleX Protocol.

We consider these positions non-negotiable, as they protect the security of all users, including those who are not targets of any investigation.

15. Frequently Asked Questions

Can you identify who sent a specific message?

No. We have no user accounts and the protocol prevents us from linking queues to identities. Even if we know a queue identifier, we cannot determine who created it or who sends messages to it.

Can you decrypt messages if provided with a court order?

No. We do not possess decryption keys. A court order cannot compel us to produce data that does not exist. This is not a policy choice; it is a technical impossibility.

Can you tell us who a specific user communicated with?

No. The SimpleX Protocol uses unidirectional queues and is specifically designed so that the server cannot construct communication graphs.

If a suspect uses Tor to connect, can you provide their real IP?

No. Tor connections show only the Tor relay IP address. The user's real IP address never reaches our server.

Can you provide the total number of users?

No. We have no user accounts and cannot count unique users. We can provide the total number of active message queues, but this does not correspond to a user count (one user may have many queues, and queues are not linkable to users).

Can you preserve messages before they are delivered?

Yes. With a valid preservation request, we can prevent the automatic deletion of messages in specified queues. However, the messages will remain encrypted.

What happens if you receive a request that you believe is unlawful?

We will decline the request and inform the requesting authority of our legal reasoning. If the authority disagrees, they may seek a judicial determination. We will comply with any final, binding court order from a competent German court.

16. Contact for Law Enforcement

All law enforcement requests:
Email: legal@simplego.dev
Subject: "Law Enforcement Request" / "Behördliche Anfrage"

Emergency requests (imminent danger to life):
Email: legal@simplego.dev
Subject: "EMERGENCY / EILANFRAGE"

Postal address:
IT and More Systems
Sascha Dämgen
Am Neumarkt 22
45663 Recklinghausen
Germany / EU

We accept requests in German and English. Requests in other languages must be accompanied by a certified German or English translation.