Law Enforcement Guidelines
Table of Contents
- Purpose of This Document
- Service Description and Architecture
- What Data We Can and Cannot Provide
- Legal Requirements for Data Requests
- Request Process and Submission
- Emergency Disclosure Requests
- International Requests (Mutual Legal Assistance)
- Preservation Requests
- Prospective Surveillance Orders
- Server Seizure and Physical Access
- User Notification
- Cost Reimbursement
- Transparency Reporting
- What We Will Not Do
- Frequently Asked Questions
- Contact for Law Enforcement
For law enforcement agencies: SimpleGo operates encrypted message relay servers using the SimpleX Messaging Protocol. Due to the protocol's architecture, we do not possess user identities, decryption keys, or communication metadata. This document explains what data we can technically provide in response to valid legal process, and the legal requirements for requesting it. We cooperate fully with lawful orders, but can only provide data that technically exists on our systems.
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. |
Due to the architecture described above, investigations targeting users of our service are most likely to succeed through endpoint-focused techniques (device forensics, traditional surveillance) rather than server-side data requests. We provide this guidance in good faith to help allocate investigative resources effectively.
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
Request Processing Workflow
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
Requests should be submitted to:
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.
For verified emergency requests involving imminent danger to life, contact us at legal@simplego.dev with subject line "EMERGENCY / EILANFRAGE" and include your badge number, department, and a callback number for verification.
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.
Server seizure will disrupt service for all users of that server, not just the investigation target. We request that authorities consider proportionality (Verhältnismäßigkeit) and whether a less intrusive measure (such as prospective logging under § 100a StPO) might achieve the investigative objective without disrupting service for uninvolved users.
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.html 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.
Inhaltsverzeichnis
- Zweck dieses Dokuments
- Dienstbeschreibung und Architektur
- Welche Daten wir bereitstellen können und welche nicht
- Rechtliche Voraussetzungen für Datenanfragen
- Anfrageprozess und Einreichung
- Notfall-Offenlegungsanfragen
- Internationale Anfragen (Rechtshilfe)
- Sicherungsanordnungen
- Prospektive Überwachungsanordnungen
- Serverbeschlagnahme und physischer Zugriff
- Nutzerbenachrichtigung
- Kostenerstattung
- Transparenzberichterstattung
- Was wir nicht tun werden
- Häufig gestellte Fragen
- Kontakt für Strafverfolgungsbehörden
Für Strafverfolgungsbehörden: SimpleGo betreibt verschlüsselte Nachrichten-Relay-Server unter Verwendung des SimpleX Messaging Protocols. Aufgrund der Protokollarchitektur besitzen wir keine Nutzeridentitäten, Entschlüsselungsschlüssel oder Kommunikationsmetadaten. Dieses Dokument erläutert, welche Daten wir auf gültige rechtliche Verfahren hin technisch bereitstellen können und welche rechtlichen Voraussetzungen dafür erfüllt sein müssen. Wir kooperieren vollständig mit rechtmäßigen Anordnungen, können aber nur Daten bereitstellen, die technisch auf unseren Systemen existieren.
1. Zweck dieses Dokuments
Diese Richtlinien richten sich an Strafverfolgungsbehörden, Staatsanwaltschaften und Justizbehörden, die Daten von SimpleGos SMP-Relay-Server-Infrastruktur anfordern. Dieses Dokument bietet: eine technische Erläuterung unserer Dienstarchitektur und deren Auswirkungen auf Ermittlungen, eine klare Beschreibung der Daten, die wir bereitstellen können und welche nicht, die rechtlichen Voraussetzungen, die wir vor der Befolgung einer Anfrage prüfen müssen, den Prozess zur Einreichung gültiger Anfragen und eine ehrliche Einschätzung des Ermittlungswerts der Daten, die wir besitzen.
Wir veröffentlichen diese Richtlinien im Interesse der Transparenz. Wir sind überzeugt, dass sowohl die Öffentlichkeit als auch die Strafverfolgung von einer klaren, ehrlichen Beschreibung unserer Fähigkeiten und Grenzen profitieren.
2. Dienstbeschreibung und Architektur
SimpleGo betreibt öffentliche SMP-Relay-Server (SimpleX Messaging Protocol), die den verschlüsselten Nachrichtenaustausch ermöglichen. Das Verständnis unserer Architektur ist wesentlich für realistische Erwartungen an die bereitstellbaren Daten.
2.1 Funktionsweise unseres Dienstes
Unsere Server fungieren als temporäre verschlüsselte Nachrichten-Speicher-Relays. Der Client des Absenders verschlüsselt eine Nachricht mit mehreren Schichten Ende-zu-Ende-Verschlüsselung. Die verschlüsselte Nachricht wird an unseren Server gesendet und in einer Nachrichtenwarteschlange gespeichert. Der Client des Empfängers ruft die verschlüsselte Nachricht ab und entschlüsselt sie lokal. Unser Server besitzt zu keinem Zeitpunkt die Entschlüsselungsschlüssel und verarbeitet nur verschlüsselte Daten.
2.2 Keine Benutzerkonten oder Registrierung
Unser Dienst hat keine Benutzerkonten, keinen Registrierungsprozess, keine Anmeldedaten, keine E-Mail-Adressen, keine Telefonnummern und keine Nutzerprofile. Nutzer verbinden sich anonym über TLS oder Tor. Es gibt kein Konzept eines "Nutzers" in unserem System, nur kryptografische Queue-Identifikatoren.
2.3 Keine Kommunikationsmetadaten
Das SimpleX-Protokoll ist spezifisch so konzipiert, dass der Server nicht erfahren kann, wer mit wem kommuniziert. Jede Konversation verwendet mehrere unabhängige, unidirektionale Nachrichtenwarteschlangen. Ein einzelner Server sieht niemals beide Seiten einer Konversation. Queue-Identifikatoren sind zufällig und können vom Serverbetreiber nicht mit realen Identitäten korreliert werden.
2.4 Clearnet- vs. Tor-Zugang
Unsere Server sind sowohl über Standard-TLS-Verbindungen (Clearnet) als auch über Tor-Onion-Services (.onion) erreichbar. Bei Clearnet-Verbindungen ist die IP-Adresse des verbindenden Clients während der aktiven Verbindung im flüchtigen Arbeitsspeicher unseres Servers sichtbar. Bei Tor-Verbindungen ist nur eine Tor-Relay-IP-Adresse sichtbar, nicht die echte IP-Adresse des Nutzers.
3. Welche Daten wir bereitstellen können und welche nicht
Dieser Abschnitt bietet eine umfassende, ehrliche Bewertung der Datenverfügbarkeit.
| Datenkategorie | Verfügbar? | Erläuterung |
|---|---|---|
| Entschlüsselte Nachrichteninhalte | Niemals | Wir besitzen keine Entschlüsselungsschlüssel. Die Ende-zu-Ende-Verschlüsselung wird von den Clients der Nutzer durchgeführt. Dies ist eine unveränderliche architektonische Eigenschaft. |
| Nutzeridentität (Name, E-Mail, Telefon) | Niemals | Es existieren keine Benutzerkonten. Keine Registrierungsdaten werden erhoben. Keine Identitätsinformationen existieren auf unseren Servern. |
| Kommunikationsgraph (wer mit wem) | Niemals | Das SimpleX-Protokoll verhindert strukturell, dass der Server Kommunikationsbeziehungen ermitteln kann. |
| Kontaktlisten oder Adressbücher | Niemals | Diese existieren nur auf den Geräten der Nutzer, niemals auf unseren Servern. |
| Historische IP-Adress-Protokolle | Standardmäßig nein | Wir protokollieren IP-Adressen im Normalbetrieb nicht auf persistenten Speicher. Keine historischen Verbindungsdaten existieren, es sei denn, eine prospektive Protokollierung wurde angeordnet (siehe Abschnitt 9). |
| Aktuell verbundene IP-Adressen | Teilweise | IP-Adressen aktuell aktiver Verbindungen existieren im flüchtigen Arbeitsspeicher (RAM). Diese Daten gehen beim Trennen oder Serverneustart verloren. |
| Verschlüsselte Nachrichten-Blobs | Ja | Verschlüsselte, aufgefüllte 16-KB-Datenblöcke in Nachrichtenwarteschlangen. Können von uns nicht entschlüsselt werden. Aufbewahrung bis zur Zustellung oder maximal 30 Tage. |
| Queue-Existenz und Metadaten | Ja | Wir können bestätigen, ob ein bestimmter Queue-Identifikator existiert, wann er erstellt wurde und seinen aktuellen Status. |
| Serverkonfiguration und Software | Ja | Unsere Server-Software ist Open Source (AGPL-3.0). Wir können Serverkonfigurationsdetails bereitstellen. |
| Zeitstempel von Queue-Operationen | Teilweise | Einige Betriebszeitstempel (Queue-Erstellung, letzte Nachrichtenzustellung) können verfügbar sein. |
Aufgrund der oben beschriebenen Architektur haben Ermittlungen, die auf Nutzer unseres Dienstes abzielen, die größten Erfolgsaussichten durch endpunktfokussierte Techniken (Geräteforensik, klassische Überwachung) statt durch serverseitige Datenanfragen. Wir geben diesen Hinweis in gutem Glauben, um die effektive Zuweisung von Ermittlungsressourcen zu unterstützen.
4. Rechtliche Voraussetzungen für Datenanfragen
Als deutscher Diensteanbieter unterliegen wir deutschem Recht. Wir kommen rechtmäßigen Anordnungen zuständiger deutscher Behörden nach.
4.1 Deutsche Inlandsanfragen
4.1.1 Bestandsdaten nach § 174 TKG
§ 174 des Telekommunikationsgesetzes (TKG) erlaubt Behörden die Anfrage von Bestandsdaten wie Namen, Adressen und Kontoinformationen. Da wir keinerlei Bestandsdaten erheben (keine Konten, keine Registrierung), wird eine Anfrage nach § 174 TKG keine Ergebnisse liefern. Wir werden dies schriftlich bestätigen.
4.1.2 Verkehrsdaten nach § 175 TKG / § 100g StPO
Anfragen zu Verkehrsdaten nach § 175 TKG i.V.m. § 100g StPO erfordern einen richterlichen Beschluss eines zuständigen Richters. Verkehrsdaten umfassen IP-Adressen, Verbindungszeitstempel und Kommunikationsmuster. Da wir im Normalbetrieb keine Verkehrsdaten vorhalten (keine IP-Protokollierung, keine Verbindungsaufzeichnungen), wird eine retrospektive Verkehrsdatenanfrage keine Ergebnisse liefern. Eine prospektive Erhebung kann angeordnet werden (siehe Abschnitt 9).
4.1.3 Telekommunikationsüberwachung (TKÜ) nach § 100a StPO
Anordnungen zur Telekommunikationsüberwachung nach § 100a StPO sind das primäre rechtliche Instrument für die rechtmäßige Überwachung von Kommunikation in Deutschland. Solche Anordnungen erfordern: einen richterlichen Beschluss nach § 100e StPO, zureichende tatsächliche Anhaltspunkte für eine schwere Straftat nach dem Katalog des § 100a Abs. 2 StPO (Katalogstraftat), die Bezeichnung des Betroffenen und, soweit möglich, der zu überwachenden Telekommunikation, und die Anordnung muss verhältnismäßig und subsidiär (letztes Mittel) sein.
Bei Vorlage einer gültigen Anordnung nach § 100a StPO können wir eine prospektive IP-Protokollierung für bestimmte Queue-Identifikatoren implementieren (siehe Abschnitt 9). Wir können keine entschlüsselten Inhalte bereitstellen oder Kommunikation im Klartext abfangen, da wir nicht über die erforderlichen kryptografischen Schlüssel verfügen.
4.1.4 Bestandsdatenauskunft nach § 100j StPO
Bestandsdatenauskunft nach § 100j StPO erfordert für Basisdaten keinen Gerichtsbeschluss. Da wir jedoch keine Bestandsdaten vorhalten, werden solche Anfragen eine Nullantwort erhalten. Wir werden schriftlich bestätigen, dass wir keine antwortpflichtigen Daten besitzen.
4.1.5 Eilanordnung nach § 100e Abs. 1 S. 2 StPO
Bei Gefahr im Verzug kann die Staatsanwaltschaft eine Eilanordnung ohne vorherige richterliche Genehmigung erlassen. Solche Anordnungen müssen innerhalb von drei Werktagen von einem Richter bestätigt werden (§ 100e Abs. 1 S. 3 StPO). Wird die Bestätigung nicht erteilt, tritt die Anordnung außer Kraft und die erhobenen Daten sind zu vernichten. Wir kommen gültigen Eilanordnungen nach, verlangen aber die zeitnahe richterliche Bestätigung.
4.2 Anfragen nach dem BKAG
Das BKA kann Anfragen nach §§ 10-12 BKAG zur Abwehr des internationalen Terrorismus oder in seiner Funktion als Zentralstelle stellen. Diese Anfragen unterliegen denselben hier beschriebenen technischen Einschränkungen.
4.3 Anfragen nach Landespolizeigesetzen
Präventive Maßnahmen nach Landespolizeigesetzen (z.B. PolG NRW für Nordrhein-Westfalen) können unter bestimmten Voraussetzungen Datenanfragen autorisieren. Wir prüfen jede Anfrage einzeln auf rechtliche Hinlänglichkeit und Verhältnismäßigkeit.
4.4 Anfragen, die wir ablehnen
Wir werden Anfragen ablehnen, die: keine gültige Rechtsgrundlage nach deutschem Recht haben, keinen richterlichen Beschluss enthalten, wenn ein solcher erforderlich ist, übermäßig breit sind oder keine spezifischen Ziele oder Queues benennen, Daten anfordern, die auf unseren Systemen nicht existieren (z.B. entschlüsselte Nachrichten), die Installation von Hintertüren oder Modifikation unserer Verschlüsselungsimplementierung verlangen, von ausländischen Behörden stammen, ohne den ordnungsgemäßen Rechtshilfeweg zu beschreiten, oder informell ohne ordnungsgemäße rechtliche Dokumentation vorgetragen werden.
5. Anfrageprozess und Einreichung
Ablauf der Anfragebearbeitung
5.1 Erforderliche Angaben
Jede Anfrage muss enthalten: die Identität der anfragenden Behörde und des verantwortlichen Beamten, die Rechtsgrundlage der Anfrage (unter Nennung der konkreten Rechtsvorschrift), einen richterlichen Beschluss oder eine sonstige richterliche Autorisierung (soweit erforderlich), eine konkrete Beschreibung der angeforderten Daten, den Zielidentifikator (Queue-ID, IP-Adresse oder Server-Endpunkt, wenn bekannt) und den von der Anfrage abgedeckten Zeitraum.
5.2 Einreichung
E-Mail: legal@simplego.dev (für nicht eingestufte Anfragen)
Post: IT and More Systems, Sascha Dämgen, Am Neumarkt 22, 45663 Recklinghausen, Deutschland
Betreff: "Behördliche Anfrage" / "Law Enforcement Request"
Wir akzeptieren Anfragen in Deutsch und Englisch.
5.3 Antwortzeit
Wir streben an, den Eingang innerhalb von 2 Werktagen zu bestätigen und innerhalb von 14 Werktagen eine inhaltliche Antwort zu geben. Für Notfallanfragen mit unmittelbarer Lebensgefahr (siehe Abschnitt 6) unternehmen wir angemessene Anstrengungen, innerhalb von 24 Stunden zu antworten.
6. Notfall-Offenlegungsanfragen
In Situationen mit unmittelbarer Gefahr für Leib und Leben können wir verfügbare Daten beschleunigt bereitstellen, auch vor Eingang eines formellen Gerichtsbeschlusses, sofern: die anfragende Behörde eine unmittelbare Bedrohung für Leib oder Leben glaubhaft darlegt, die Anfrage von einem verifizierten Strafverfolgungsbeamten gestellt wird und ein formelles rechtliches Verfahren zeitnah nachgereicht wird.
Dies gilt primär für Fälle mit: unmittelbarer Suizidgefahr oder Selbstgefährdung, die über unseren Dienst kommuniziert wird (wenn ein Queue-Identifikator bekannt ist), Entführung mit unmittelbarer Gefahr für das Opfer, aktive Bedrohungslagen, bei denen Zeit kritisch ist, und Vermisstenfälle mit glaubhaftem Schadensrisiko.
Für verifizierte Notfallanfragen bei unmittelbarer Lebensgefahr kontaktieren Sie uns unter legal@simplego.dev mit dem Betreff "EILANFRAGE / EMERGENCY" und geben Sie Ihre Dienstnummer, Behörde und eine Rückrufnummer zur Verifizierung an.
7. Internationale Anfragen (Rechtshilfe)
SimpleGo ist ein deutsches Unternehmen, das deutschem Recht unterliegt. Wir akzeptieren keine direkten Anfragen ausländischer Strafverfolgungsbehörden.
7.1 Erforderliche Kanäle
Ausländische Behörden müssen Anfragen über einen der folgenden Kanäle einreichen: ein Rechtshilfeersuchen über das Bundesministerium der Justiz (BMJ), eine Europäische Ermittlungsanordnung (EEA) nach Richtlinie 2014/41/EU (für EU-Mitgliedstaaten) oder ein direktes Ersuchen an ein deutsches Gericht per Rechtshilfeersuchen.
7.2 EU-Mitgliedstaaten
Anfragen von Behörden der EU-Mitgliedstaaten im Rahmen der Europäischen Ermittlungsanordnung (EEA) werden über die zuständige deutsche Justizbehörde (typischerweise die Staatsanwaltschaft oder das Amtsgericht mit Zuständigkeit für Recklinghausen) bearbeitet. Wir kooperieren mit der deutschen vollstreckenden Behörde, nicht direkt mit der ausländischen anfragenden Behörde.
7.3 Nicht-EU-Staaten
Anfragen aus Nicht-EU-Staaten müssen über MLAT oder sonstige anwendbare internationale Abkommen eingereicht werden. Das BMJ wird prüfen, ob die Anfrage deutschen Rechtsstandards entspricht, bevor sie an die zuständige deutsche Behörde weitergeleitet wird.
7.4 Hinweis für US-Behörden
US-Strafverfolgungsbehörden (FBI, DEA, HSI, staatliche/lokale Behörden) müssen Anfragen über das MLAT zwischen den Vereinigten Staaten und Deutschland (Treaty Doc. 108-27) leiten. Wir akzeptieren keine US-Subpoenas, Warrants oder Court Orders direkt, da diese in Deutschland keine Rechtswirkung haben.
8. Sicherungsanordnungen
Wir akzeptieren Sicherungsanordnungen zur Verhinderung der Löschung bestimmter Daten, während ein formelles rechtliches Verfahren eingeleitet wird.
8.1 Umfang
Wir können sichern: verschlüsselte Nachrichten-Blobs in bestimmten Queues (Verhinderung automatischer Löschung), Queue-Metadaten (Verhinderung der Queue-Löschung durch den Client) und Server-Protokolle (soweit zum Zeitpunkt der Anfrage vorhanden).
8.2 Dauer
Wir sichern Daten für bis zu 90 Tage oder wie in der Sicherungsanordnung angegeben. Wird innerhalb dieser Frist kein formelles rechtliches Verfahren eingeleitet, werden die gesicherten Daten freigegeben und unterliegen den normalen Aufbewahrungsrichtlinien.
8.3 Was wir nicht sichern können
Wir können nicht sichern: IP-Adressen im flüchtigen Speicher (gehen beim Trennen verloren), bereits gelöschte Daten oder Daten, die nie auf unseren Systemen existiert haben.
9. Prospektive Überwachungsanordnungen
Die operativ nützlichsten Daten, die wir bereitstellen können, sind die prospektive IP-Adress-Protokollierung für bestimmte Queue-Identifikatoren, angeordnet nach § 100a StPO oder gleichwertigen Vorschriften.
9.1 Funktionsweise
Nach Eingang einer gültigen Anordnung implementieren wir eine gezielte Protokollierung für bestimmte Queues. Wenn sich ein Client mit der spezifizierten Queue verbindet, protokollieren wir die verbindende IP-Adresse, den Zeitstempel der Verbindung und den Queue-Identifikator. Diese Protokollierung dauert für den in der Anordnung angegebenen Zeitraum an.
9.2 Einschränkungen
Die prospektive Protokollierung erfasst nur die IP-Adresse des verbindenden Clients. Verbindet sich der Client über Tor, ist die protokollierte IP-Adresse ein Tor-Exit-Relay, nicht die echte IP des Nutzers. Wir können die protokollierte IP nicht mit einer Identität korrelieren. Wir können Nachrichteninhalte nicht entschlüsseln oder bereitstellen. Wir können nicht bestimmen, welche spezifische Queue ein Ziel nutzt, ohne dass die anfragende Behörde den Queue-Identifikator bereitstellt.
9.3 Implementierungszeitraum
Die technische Implementierung der prospektiven Protokollierung erfordert typischerweise 24-72 Stunden nach Eingang einer gültigen Anordnung. In Notfallsituationen werden wir angemessene Anstrengungen zur Beschleunigung unternehmen.
10. Serverbeschlagnahme und physischer Zugriff
Für den Fall, dass Behörden unsere physische oder virtuelle Server-Infrastruktur beschlagnahmen (Beschlagnahme nach § 94 StPO), stellen wir folgende Informationen für die forensische Analyse bereit.
10.1 Festplattenvollverschlüsselung
Unsere Server verwenden Festplattenvollverschlüsselung. Der Zugang zu gespeicherten Daten erfordert die Verschlüsselungspassphrase. Wir werden diese Passphrase bereitstellen, wenn wir durch gültigen Gerichtsbeschluss dazu verpflichtet werden.
10.2 Was ein beschlagnahmter Server enthält
Ein beschlagnahmter Server enthält: die SMP-Server-Software (Open Source, verifizierbar gegen das öffentliche Repository), Server-Konfigurationsdateien, verschlüsselte Nachrichtenwarteschlangen (16-KB-Blöcke, verschlüsselt von den Clients der Nutzer, die wir nicht entschlüsseln können), Queue-Metadaten (zufällige Identifikatoren, Zeitstempel) und TLS-Zertifikate und Serverschlüssel (diese schützen die Transportschicht, nicht den Nachrichteninhalt).
10.3 Was ein beschlagnahmter Server nicht enthält
Ein beschlagnahmter Server enthält nicht: Entschlüsselungsschlüssel für Nachrichteninhalte (diese existieren nur auf den Geräten der Nutzer), Nutzeridentitäten, Kontodaten oder Registrierungsinformationen, historische IP-Adress-Protokolle (es sei denn, eine prospektive Protokollierung wurde zuvor angeordnet), Kommunikationsgraphen oder Metadaten, die Queues miteinander oder mit Nutzern verknüpfen, oder Klartext-Nachrichteninhalte.
Eine Serverbeschlagnahme wird den Dienst für alle Nutzer dieses Servers unterbrechen, nicht nur für das Ermittlungsziel. Wir bitten die Behörden, die Verhältnismäßigkeit zu berücksichtigen und zu prüfen, ob eine weniger einschneidende Maßnahme (wie prospektive Protokollierung nach § 100a StPO) das Ermittlungsziel erreichen könnte, ohne den Dienst für unbeteiligte Nutzer zu unterbrechen.
11. Nutzerbenachrichtigung
Das deutsche Recht verpflichtet uns in den meisten Fällen nicht zur Benachrichtigung von Nutzern über behördliche Anfragen. Unsere Position ist wie folgt:
Wir können bestimmte Nutzer selbst dann nicht benachrichtigen, wenn wir dies wollten, da wir Nutzer nicht identifizieren können. Wir haben keinen Mechanismus zur Zustellung einer Benachrichtigung an eine bestimmte Person, da wir keine Benutzerkonten, E-Mail-Adressen oder sonstige Kontaktinformationen haben. Die Anonymität unseres Dienstes bedeutet, dass eine Nutzerbenachrichtigung in den meisten Fällen technisch unmöglich ist.
12. Kostenerstattung
Gemäß § 23 JVEG (Justizvergütungs- und -entschädigungsgesetz) i.V.m. Anlage 3 JVEG haben Telekommunikationsanbieter Anspruch auf Erstattung der Kosten, die bei der Befolgung rechtmäßiger Überwachungs- und Datenherausgabeanordnungen entstehen.
Wir behalten uns die Geltendmachung von Erstattungsansprüchen vor für: technische Implementierungskosten für prospektive Überwachungsanordnungen, Personalaufwand für Datenabruf und -bereitstellung sowie Geräte- und Infrastrukturkosten, die unmittelbar der Compliance zuzurechnen sind.
Erstattungsansprüche werden gemäß den geltenden JVEG-Sätzen berechnet. Wir werden die Befolgung einer gültigen Anordnung nicht bis zur Klärung der Kostenerstattung verzögern.
13. Transparenzberichterstattung
Wir veröffentlichen einen halbjährlichen Transparenzbericht, der alle Interaktionen mit Strafverfolgungsbehörden dokumentiert. Dieser Bericht umfasst: die Gesamtzahl der eingegangenen Anfragen (aufgeschlüsselt nach Art und anfragender Behörde), die Anzahl der befolgten Anfragen, die Anzahl der abgelehnten Anfragen (mit anonymisierten Gründen), die Menge der bereitgestellten Daten und eine Warrant-Canary-Erklärung.
Transparenzberichte werden auf unserer Website unter simplego.dev/legal/transparency.html und in unserem GitHub-Repository veröffentlicht.
13.1 Warrant Canary
Unser Transparenzbericht enthält einen Warrant Canary. Dies ist eine signierte Erklärung, die zum Zeitpunkt der Veröffentlichung bestätigt, ob wir geheime Gerichtsbeschlüsse, National Security Letters oder Maulkorb-Verfügungen erhalten haben, die uns die Offenlegung ihrer Existenz verbieten. Das Fehlen eines Warrant Canary in einem zukünftigen Bericht kann darauf hindeuten, dass eine solche Anordnung eingegangen ist. Dieser Mechanismus bietet Transparenz auch dort, wo direkte Offenlegung verboten ist.
14. Was wir nicht tun werden
Unabhängig vom vorgelegten rechtlichen Instrument werden wir nicht: Hintertüren in unsere Software einbauen oder unsere Verschlüsselungsimplementierung modifizieren, Verschlüsselung für bestimmte Nutzer oder Queues abschwächen, eine pauschale Überwachung des gesamten Serververkehrs implementieren, Daten über das rechtlich Erforderliche oder technisch Notwendige hinaus vorhalten, Zugang zu Entschlüsselungsschlüsseln gewähren, die wir nicht besitzen, falsche oder irreführende Angaben über unsere technischen Fähigkeiten machen oder die Ende-zu-Ende-Verschlüsselung des SimpleX-Protokolls umgehen oder untergraben.
Wir betrachten diese Positionen als nicht verhandelbar, da sie die Sicherheit aller Nutzer schützen, einschließlich derjenigen, die nicht Ziel einer Ermittlung sind.
15. Häufig gestellte Fragen
Können Sie identifizieren, wer eine bestimmte Nachricht gesendet hat?
Nein. Wir haben keine Benutzerkonten und das Protokoll verhindert, dass wir Queues mit Identitäten verknüpfen können.
Können Sie Nachrichten entschlüsseln, wenn ein Gerichtsbeschluss vorliegt?
Nein. Wir besitzen keine Entschlüsselungsschlüssel. Ein Gerichtsbeschluss kann uns nicht zur Herausgabe von Daten verpflichten, die nicht existieren. Dies ist keine Richtlinienentscheidung; es ist eine technische Unmöglichkeit.
Können Sie uns mitteilen, mit wem ein bestimmter Nutzer kommuniziert hat?
Nein. Das SimpleX-Protokoll verwendet unidirektionale Queues und ist spezifisch so konzipiert, dass der Server keine Kommunikationsgraphen konstruieren kann.
Wenn ein Verdächtiger sich über Tor verbindet, können Sie die echte IP bereitstellen?
Nein. Tor-Verbindungen zeigen nur die IP-Adresse des Tor-Relays. Die echte IP-Adresse des Nutzers erreicht unseren Server nie.
Können Sie die Gesamtzahl der Nutzer angeben?
Nein. Wir haben keine Benutzerkonten und können eindeutige Nutzer nicht zählen. Wir können die Gesamtzahl aktiver Nachrichtenwarteschlangen angeben, dies entspricht aber keiner Nutzerzahl.
Können Sie Nachrichten vor der Zustellung sichern?
Ja. Mit einer gültigen Sicherungsanordnung können wir die automatische Löschung von Nachrichten in bestimmten Queues verhindern. Die Nachrichten bleiben jedoch verschlüsselt.
Was passiert, wenn Sie eine Anfrage für rechtswidrig halten?
Wir werden die Anfrage ablehnen und die anfragende Behörde über unsere rechtliche Begründung informieren. Bei Meinungsverschiedenheiten kann die Behörde eine gerichtliche Entscheidung herbeiführen. Wir werden jeder endgültigen, bindenden Anordnung eines zuständigen deutschen Gerichts nachkommen.
16. Kontakt für Strafverfolgungsbehörden
Alle behördlichen Anfragen:
E-Mail: legal@simplego.dev
Betreff: "Behördliche Anfrage" / "Law Enforcement Request"
Notfallanfragen (unmittelbare Lebensgefahr):
E-Mail: legal@simplego.dev
Betreff: "EILANFRAGE / EMERGENCY"
Postanschrift:
IT and More Systems
Sascha Dämgen
Am Neumarkt 22
45663 Recklinghausen
Deutschland / EU
Wir akzeptieren Anfragen in Deutsch und Englisch. Anfragen in anderen Sprachen müssen von einer beglaubigten deutschen oder englischen Übersetzung begleitet sein.
SimpleGo Legal Framework
All documents available in English and German. Server infrastructure operated under German and EU law.